November 16, 2025 Opinion
November 16, 2025 Opinion
I was thinking about what makes a software engineer productive. There are so many things that come to mind: enough focused time, right tooling, fundamental knowledge, soft and hard skills, energy, motivation, attitude. So much of everything and you can definitely find arguments online for one or the other being the most critical. In this post I want to argue, what is more critical, but rather want to make a point that generally there are two categories and then suggest some action items in the end based on this. Additionally, I will try to present examples with personal stories.

Image credit: Gemini
These are examples of things where being good enough is usually sufficient to get a great boost in productivity but where pushing for being world-class good only gives smaller diminishing returns and only makes you good in that specific area.
Typing speed. Naive example, but for its simplicity it’s easy to understand. Extremely slow typing speed would slow you down. But the difference between really fast 100wpm and 150wpm is tiny for your productivity as a software engineer. To give a personal flavor, back in my university I trained my typing so I could type fast but then when I was in a sports programming competition (speed matters there), the guy who was a slow typer but a ‘big brain’ easily would beat me on hardest problems.
Tooling familiarity. For example, your IDE. If you get lost on how to use it at all, doing anything even simple is extremely tedious. Remember how frustrating it is to find some simple functionality that should be there right at your fingerprints. I would say this is logarithmic as well, but the curve bends at a much higher elevation compared to typing, so you do need to spend deliberate time to learn core functionality of IDE and your entire productivity will be elevated. Knowing some nice rarely used features probably won’t help too much. Back at my first job, I learned how to be productive with JetBrains ReSharper and could execute large refactorings quickly – this distinguished my productivity from others, but not too much from others who knew these tools as well.
Physical and mental health. Being sick sucks for productivity so it is clear the healthier you are the better your productivity is going to be. The difference between being “generally healthy” and “an elite athlete” on your ability to code is not 10x, lol. My intensive Muay Thai classes don’t help me with my coding at all, but general weekly activities help maintain a healthy baseline that doesn’t make you ‘tired’. Arguably this becomes more important as you age. With age our mental capabilities degrade a bit as well as needs for rest increase.
… there are more …
This is a category I have for things where being better actually makes your productivity be higher, either just linearly or even exponentially, being good is good, being better is much better, and being great makes you 10x.
Fundamental knowledge and understanding. The way I imagine it is that fundamental knowledge is setting the upper limit on your productivity. If you don’t have enough fundamental knowledge it would be hard to break through the “ceiling” and come up with something truly innovative. Yeah, that’s why big tech is chasing those ML PhDs with ludicrous pay as this is what is pushing that most upper boundary limit. That’s why new grads, people who acquired some strong knowledge, are like those big unknowns with huge potential. I know many folks who studied with me, but having had more in-depth knowledge, have achieved greater results sooner.
Consistency. If you are productive consistently, the progress might not be visible immediately but over time it will become apparent and accumulated and it will get you really far. This time I think of this somewhat as linear dependency up to a point, but I also think there is a ‘breaking point’ where this converts into exponential uptrend – there aren’t many people in that space to even compare with you. Imagine someone with great knowledge, but just not consistently utilizing it.
Mental resilience and attitude. Having the right attitude towards dealing with stress, projects, being ‘can handle anything’, being resilient usually sets apart people who get stuck at some point and those who get more done. Resilience is what allows you to tackle a complex, multi-month project without giving up. It’s what allows you to take criticism in a design review and turn it into a better product. This one is arguably hard, but I would also say this psychological factor is huge.
Soft interpersonal skills. If you are a single engineer trying to do something your productivity is capped. Someone who can clearly articulate a technical vision, persuade a team, and mentor others can be that “multiplier” of their impact across the entire organization.
… there are more …
So where am I going with these two buckets of Hurdles vs Levers or whatever we call them? Why does it matter?
IMO it does matter a lot as most engineers spend their time optimizing the wrong thing.
Let’s conclude this as a framework:
What are your thoughts? What obvious examples have I missed? Do you generally agree with this categorization or think there is even a 3rd category?
codemore code
~~~~