Doing less with less
Photo by ALLAN FRANCA CARMO
We take a handful of sand from the endless landscape of awareness around us and call that handful of sand the world.
– Zen and the art of motorcycle maintenance, Robert Pirsig
Third grade in New Jersey
I am in third grade in Barclay School in Cherry Hill, New Jersey.
My parents just came home from a PTA meeting.
My Dad, “Dan, Mrs. Bates just told us that you can do whatever you want”.
That left a great impression on me.
It felt very empowering. Things that your third grade teacher says can shape you for the rest of your life.
It never occurred to me to ask how come Mrs. Bates never told me that herself.
There is, in fact, something very empowering about someone close to you telling you that someone else thinks great things about you.
Perhaps, she did that with all the parents.
Your children can do whatever they want, if they just set their mind to it.
Over time, I became less confident about this belief.
I’ll examine 3 areas where doing less with less gets better results: personal wealth, code and business execution.
Do you spend beyond your means?
The banks and credit card companies love people who live beyond their means.
There are 4 kinds of credit cards: Standard cards, Rewards cards (like the GM card where the cardholder gets back 5%), Luxury cards, and secured cards (for poor people, who are absolutely the most lucrative channel for credit card issuers). Over-the-top fees (when you don’t pay on time) can exceed 30% APR for secured cards.
There are advantages to living below your income besides paying 0% APR..
What you save compounds, and by the time you’re 54, you will have enough money to have independence and freedom of decision-making.
Living under your means removes the social pressure and cognitive dissonance of not having money and pretending that you do.
Just be NGAF.
Your personal wealth is not only your money, it’s also your time.
Just as many people live beyond their means, many of us live beyond our time.
We measure ourselves against other people.
We want to achieve a grand goal, and underestimate the amount of time a task will take.
The result is that many people are overdrawn on their time, just as many people are overdrawn at the bank.
We use time management systems to optimize effective use of our time resources.
What if time was not a resource?
Heidegger in his book, “Sein und Zeit (Being and Time)” does not view time as a "resource".
Sein und Zeit views time as the most fundamental aspect of our being.
Time is essential for living a meaningful life. Time is a horizon within which our entire existence unfolds where we must work to live deeply and authentically.
Time is not a "resource" to be optimized; time is a horizon for our entire existence.
Cafe Roval in Tel Aviv - living deeply.
I sit on the steps outside of Cafe Roval with my Aunt Miriam. I am dating Ofra (future wife, although neither of us knew that at the time). My Aunt and Uncle invited us out for coffee. Roval is an old European style cafe, with a glass case, where you can pick out the cake you want with your coffee.
My Aunt says, “She’s the one”.
I ask, “How do you know that?”.
My Aunt, “I picked out cake with her inside, I saw how careful and delicate she is, she’s the one”.
After a moment of thinking, I ask, “What’s going on right now?
She replies “We’re living deeply”.
We are meant to live deeply within our time horizon.
Living under your time, living under your economic means, provides incredible freedom from the social pressure, and the cognitive load of trying to keep up with yourself and with the Joneses.
Do you code beyond your cognition?
This is a topic for an entire book, but it has much in common with personal finance and business management.
Coding beyond your cognition has 3 root causes:
Programmer bloat
Requirements bloat
Communications disconnects
Programmer bloat
Most programmers assume that they need to implement all the business requirements.
This seems like a reasonable assumption.
Once they start implementing requirements, programmers, being human, like to keep their options open.
This results in code implementation with too many features and too much code.
AI copilots have massively exacerbated this problem.
Too much code is too hard to debug, test and too confusing to the end-user once you make it past QA and deliver.
Too much is too hard to maintain. Too hard to sell. Too hard to use.
Business requirements bloat
Business users are no different from programmers.
They assume that they need to implement all the business requirements.
Being human, they also like to keep their options open and implement some features they might need.
But, then the business changes, and with that comes new and changing business requirements for the software.
Before long you have requirements bloat.
Requirements bloat and software code bloat are the main reasons why most software applications these days are difficult to use in the best case or full of bugs in worst case scenarios.
Let’s take an example from the LangGraph QuickStart tutorial to build a basic chatbot application.
The first thing you do when you define a graph is define the State of the graph. The State consists of the schema of the graph as well as reducer functions which specify how to apply updates to the state. In our example State is a TypedDict with a single key: messages. The messages key is annotated with the add_messages reducer function, which tells LangGraph to append new messages to the existing list, rather than overwriting it. State keys without an annotation will be overwritten by each update, storing the most recent value. Check out this conceptual guide to learn more about state, reducers and other low-level concepts.
The conceptual guide doesn’t explain reducers although there are a lot of low-level concepts like this:
A StateGraph is a graph whose nodes communicate by reading and writing to a shared state. The signature of each node is State -> Partial.
Each state key can optionally be annotated with a reducer function that will be used to aggregate the values of that key received from multiple nodes. The signature of a reducer function is (Value, Value) -> Value
Communications disconnects
When programmers don’t understand the business users and when business users don’t understand the business, you get disconnected.
The business changes and/or the operating environment changes and disconnects from the reality of the software.
The reality of the software quickly disconnects from the threat landscape, enabling attackers to exploit vulnerabilities. The bigger the code, the more vulnerabilities.
At those points in time, you need changes to fix the disconnects.
This is euphemistically called technical debt, since some of the code needs to be replaced and other pieces of code in the system need to be removed and other pieces refactored. Like returning a debt to the customer.
The obvious solution is to code under your requirements and do half or a third of the requirements. For business users, the obvious solution is to implement the one critical feature that the business really needs.
Doing much less, frees the developers from the personal pressure, testing load, delivery deadlines and cognitive load of dealing with business users who don’t really understand what they really want and how the business actually works.
Do you execute beyond your systems?
Out of 8.1 billion people in the world, 11 people in 2023 got the Nobel Prize in all the categories, some of which sound absurd in 2024:
The Nobel Peace Prize went to Narges Mohammadi for fighting against women's oppression in Iran and promoting human rights in Iran
I would send Ms. Mohammadi the check in return for not celebrating Iran in any context, but that’s just me.
If I were on the Nobel Prize committee, if that was all I could do for world peace, I’d just keep my mouth shut.
What does business execution have in common with personal economics and software engineering?
Do you have a growth mindset or fixed mindset?
There are people who believe in a growth mindset. Practice long enough and believe in your success and success, wealth and happiness will come.
Other people believe in a fixed mindset and aptitude. If you struggle with success in your business venture, it means that you are not cut out for it.
Both groups are wrong.
Rewarding a growth mindset for effort doesn’t work. People are not stupid - they know when they are working hard and not getting results.
Rewards should be for achieving goals, not for having a growth mindset and being positive with parents at third-grade PTA meetings (although it is very nice).
Fixed mindset and aptitude can take you further in your business venture then you think, just not how you think.
You create freedom to do better work by working less. Working less hours reduces your cognitive load and enables you to make better decisions and find creative solutions to your fixed mindset problems and limited aptitude.
For some reason, I felt compelled to see if there is empirical evidence for my ideas that we should do less with less.
Show me the empirical data
Cognitive Load Theory and Productivity.
A study by Paas & van Merriënboer (1994) showed that learners who dealt with reduced cognitive load performed significantly better in both short- and long-term retention tasks. Another study from Gugerty (2011) found that workers who used simplified task management systems reduced mental fatigue and enhanced output quality.Living Beyond vs. Below Your Means.
Research from the National Bureau of Economic Research (NBER) indicates that people who live below their means report higher levels of happiness and life satisfaction. Conversely, living beyond your means increases stress levels and financial anxiety (Chetty, Friedman, & Saez, 2014).
The American Psychological Association (APA) reports that 72% of Americans experience stress about money at least some of the time, with those living beyond their financial capacity experiencing greater levels of anxiety.Time Management and Burnout
The Journal of Occupational Health Psychology (2018) published a study that found employees who overcommit to tasks and don’t set clear boundaries around their time have a 40% higher chance of experiencing burnout than those who set time limits.
A Stanford University study by John Pencavel (2014) revealed that productivity significantly decreases after working more than 50 hours per week. People who work 70+ hours produce the same amount as those who work 55 hours, further supporting the idea of doing less for better output.Coding Beyond Cognition
A study by Basili and Selby (1987) found that reducing unnecessary complexity in code reduced the bug rate by 45%.
Another study from IEEE Transactions on Software Engineering (2017) reported that developers working on simpler, modular systems with lower cognitive load were able to maintain more stable and secure code with 30% fewer bugs.Executing Below Capacity
Cal Newport’s research on Deep Work (2016), points to studies showing that people who focus on fewer tasks at a time (i.e., working below their maximum capacity) produce higher quality outputs and achieve more in the long run.
Flow theory (Csikszentmihalyi, 1990), shows that optimal performance is achieved in a state of focused engagement, free from distractions and overload.
A study by K. Anders Ericsson (1993) on expert performance demonstrated that the best performers in fields such as music, sports, and science practice their skills for shorter periods of highly focused time and then rest, leading to better long-term mastery.
A Harvard Business Review study (2017) found that executives who reduced the number of tasks they focused on daily achieved 15-20% higher productivity over a six-month period.
Conclusion
We need to do less.
Paradoxically, by doing less, we’ll achieve more.
We’ll achieve long-term mastery and higher quality outcomes at lower stress levels, financial and social anxiety.
We’ll be able to live deeply.