Recently, my favourite time building software I've ever had has been developing Loginllama.
It's so abundantly simple.
Just NextJS pushed to Vercel.
I don't write fancy commit messages - just "x". And then deploy straight to production.
Creating a new product
— Josh Ghent (@joshghent) February 14, 2023
❌ No development environment
❌ No local development
❌ No commit messages (just "x")
It's the fastest I've ever shipped.
Contrasting this with most of my "jobby job" software development, and the joy is quickly sapped.
To work on anything the ticket needs scoping and then writing. Followed by an hour long "refinement" to point out that Kevin the designer still hasn't attached their the Figma link to the ticket (come on Kevin!), and Janine is raising concerns that it's not possible to do (it's technology, it's always possible!).
Then you come to evaluate the amount of time it will take, which if you do not work on software involves one simple step - stick your head out the window and just gather a general "feeling" then call it a 5 or 3, or 8, none of it means anything anyway. Software estimates are one step away from the ridiculed pseudoscience of homeopathy. It's a total farce, but some people believe in it. And that's the important part.
Now that you've got your estimation, your project manager and your team sit down and prioritise it and divide the work into a sprint. Basically a sprint is the amount of work you can conceivably regurgitate to meet an imaginary deadline.
Of course, bug fixes are priority number 1 you think. Think again! If it's not affect that many customers then it's fine! Just add more features and the shareholders are happy.
Before you get started on the actual work, you need to meet with your manager to discuss OKR's - the things you hope to achieve to make the company more money.
When you get back, you check your inbox and see Sarah has requested you give 360 feedback on her. So you spend the next hour trying to understand the questions and then just resigning and giving them "excellent" on everything.
I could go on, but I'm hoping some of this resonates with you.
Of course, my scrappy "x" commits and pushing to production does not really scale for a large team. And arguably, rushing to code before looking at the metrics and requirements is foolish. But, I would hope, there is a happy medium.
Unfortunately, many organisations I have worked for solve this problem by aggressively hiring. Even during a down period for the economy, most software companies (which is to say, companies) are hiring aggressively. They need QA engineers, frontend engineers, full stack engineers, devops engineers - you name it, they need it.
But, the question never gets ask of why we have all this complexity in the first place.
No body wonders why we need more documentation than the great library of Alexandria to write an app that helps find you someone to walk your dog.
It's a classic case of Parkinsons Law. Technology should enable us to do more with less. In reality, the opposite is true.
What's the solution?
Unfortunately, there isn't a one size fits all solution. And in many cases, lots of people don't want a solution, because it would mean admitting that their job is unnecessary and their work is unvalued.
In any case, you can try to do the following
Ask good questions. Questions such as "help me to understand why X" or "what is preventing us from Y approach?" helps everyone clarify their thoughts and justify the position. This should be an interrogation but rather a friendly discussion with the aim of getting things done, not out of a personal vendetta against busywork (however tempting).
Be careful what you measure. Goodharts law states that whenever you begin to measure something, it ceases to become a good measure. For example, if you want to measure the productivity of car builders, you could measure how many cars are built per day. But if all these cars break down due to quality issues, of what value is the measurement. Instead, try to measure things that lead to better outcomes. For example, in the car factory you could measure the ratio of vehicles produced to the number that have defects.
Aggressively cull meetings. It's already been written about at length how meetings can be corrosive for deep work. But still, most organisations have lots of regular and "quick catch up" meetings. As teams scale, complexity of communication also scales. It's not uncommon to have teams dedicate 1 day per "work cycle" to meetings - sprint reviews, refinements and planning. Be a leader and ask if these meetings need to be in place, can they be reduced by doing more work async? Are they achieving the outcomes they set out to solve? Can we focus the discussion more?
Busy work will always exist but it doesn't have to just be accepted. But be kind, some peoples entire life is busy work.