The best programmers I know

Note that this says "best programmers" not "people best at having business impact by making software".

I wonder about this often: If you want to have impact/solve problems/make money, not just optimizing killing your JIRA tickets, should you invest a given hour into understanding the lowest code layer of framework X, or talk to people in the business domain? Read documentation or a book on accessibility in embedded systems? Pick up yet another tech stack or simply get faster at the one you have that is "good enough"?

Not easy to answer, but worth keeping in mind that there is more to programming than just programming.

I am really interested to read articles about "people best at having business impact by making software" , so far I only discovered resources like kalzumeus (patio11), indiehackers, microconf, business of software forum (very old).

The latter are the ones that get promoted to senior staff+, or more likely become directors/VPs.

There is a very low cap on career growth if you are purely focused on programming.

So yes, if you want to climb the corporate ladder or run your own business, programming is a fraction of the skills required.

I think though it's okay to just focus on coding. It's fun and why many of us got into the industry. Not everyone likes the business side of things and that's okay.

> should you invest a given hour into understanding the lowest code layer of framework X, or talk to people in the business domain?

I think talking to people in business domain is the most important thing you can do in SWE or IT in general. The business is the entire reason you write every line of code, the more you understand, the better you will be at your job.

I do find drilling down into lower layers of your software stack helpful, and can make you a better programmer, but in a much more specific way.

> Pick up yet another tech stack or simply get faster at the one you have that is "good enough"?

Both of these are programming skills and less important, IMO. Trends and technologies come and go; if they're useful/sticky enough, you'll end up having to learn them in the course of your job anyway. Tech that's so good/sticky it sticks around (e.g. react) you'll naturally end up working with a lot and will learn it as you go.

It's definitely good to have a solid understanding of the core of things though. So for react, really make sure you understand how useState, useEffect work inside and out. For Java it'll be other things.

Read everything DHH wrote, he has lots of insights on this. Scroll down to his books: https://dhh.dk

I found Lean Startup to be very good too.

> Note that this says "best programmers" not "people best at having business impact by making software".

We can look at a software developer as a craftsperson, and appreciate their skill and their craft, and we can look at them as a business asset, and those are two different things.

Both of which have their merits, but this article is clearly focused on the craftsperson side and that's enough. We don't need to make everything about business and money, and we definitely don't need to reduce the beauty and craft of writing code to Jira tickets.

I don't know. Career plans aside, to me, making software is a means to an end.

There is no inherent value to producing software, as there may be in producing car tires or bananas. The best software is no software.

And then who is the better programmer, the one who knows more about how to make software, or the one who knows more about what software to make?

> The business is the entire reason you write every line of code

It's actually not the entire reason i write or have written every line of code.

It may be surprising to some people on this website for entrepreneurs but there are in fact people who enjoy writing code for the sake of it.

> worth keeping in mind that there is more to programming than just programming.

As a side note, this is what I keep pointing out when people talk about code generated by LLMs. As an activity, this is just one thing that programmers do.

I think the answer to your question (a good question indeed) is "both", or rather to balance development of both capabilities. The decision of how to spend time won't be a single decision but is repeated often through the years. The Staff+ engineers with whom I work _mostly_ excel at both aspects, with a small handful being technical specialists. I haven't encountered any who have deep domain knowledge but limited technical depth.

(edit: formatting)

What's most interesting to me about your point compared to parent comment's is that you're saying "statically, over all time, the most valuable thing to do among all your choices is to understand the business," whereas the parent is saying "dynamically, in this moment, what is most valuable thing to do in this iteration of my actions?"

I think your question is most interesting in terms of long term skill mix or "skill portfolio" a.k.a the career viewpoint, while the parent's is more interesting on a day-to-day basis as you navigate the state space of bringing a project to completion. On a given day, understanding the business may not be the most valuable thing to do, but to your point over the course of a job or career it probably is.

(For example, I can say that I already have sufficient business context to do my programming task for tomorrow. Asking more questions about the business would be wasteful: I need to go update the batch job to achieve the business outcome.)

EDIT: I might go one step further and say the most valuable skill is not understanding the business but understanding how to match and adapt technologies to the business (assuming you want a career as a programmer). Ultimately the business drives income, but presumably you have a job because their business requires technology. So the most valuable skill is, as efficiently as possible, making the technology do what the business needs. That's more of a balance / fit between the two than just "understanding the business."

Ikigai applies to writing code as well.

Generally we aren't paid for our business expertise. In fact, most businesses actively resist giving developers deep domain responsibility.

This is manifest in management methodologies: developers are largely interchangeable cells in a spreadsheet. I'm not saying this is a good thing.

The reasons for this are complex, but generally, business people want us to solve the technical problems they can't handle themselves, they don't want us to "relieve" them of product management, customer relationships, and industry knowledge. Why would they? It would devalue them.

You can be the “best” programmer at home/internet, and just another employee at work.

I’m retired, these days, and spend the majority of every day, writing software.

I treat it as a craft, and do it for personal fulfillment and learning. I enjoy learning, and solving problems. I also enjoy creating stuff that I find aesthetically pleasing.

For example, I write iOS apps, and I’m working on a new version of a timer app that I’ve had in the App Store, for over a decade. I had added a Watch app to it, and had gotten to the point where it was ready for the App Store, but I kept having sync issues. It wasn’t a “showstopper,” but it was aesthetically not pleasing.

I determined that it was an issue that could be addressed by improving the fundamental design of the app, which had basically been constant for many years.

So I'm rewriting it completely.

That’s not something that makes “commercial” sense, but it’s what I want to do. I’ll also take the opportunity to redesign the basic UI.

I enjoy having that kind of freedom.

I also like to write about my work. I know that very few people are interested in reading it, but I do it, because it helps me to learn (the best way to learn, is to teach), and it helps me to focus my thoughts.

> Generally we aren't paid for our business expertise. In fact, most businesses actively resist giving developers deep domain responsibility.

Chicken/egg imho.

Yep. A developer with "business impact" might be seen as a liability.

One aspect might be that a developer who engages in "business" effectively stops being "subordinate". Management decisions need to be justified on a different level to maintain legitimacy.

Thank you for sharing. I love hearing stories of these kinds of "software gardens". I wish you many years of joy tending yours.

Software is a craft.

There is an inherent value in programming, just like there is one in gardening, woodworking, producing art, or playing a musical instrument.

The value is in the joy that the activity brings. (Note that this tends to be a different kind of value than business value.)

Im somewhat puzzled as to why so many devs are insistent that being a good developer means you need to be a good PM.

These roles require wildly different skills and knowledge.

Usually the outcomes are better if you combine two people who are good at their jobs rather than hoping one person can do it all.

To me, cars are a means to an end. And I can imagine a world without cars more easily than a world without software.

Do you imagine that we just somehow evolve capabilities beyond it? or do we eventually produce universally perfect software solutions and leave it at that?

It's not really about that.

If I hire you to make software for me, I don't really want software; I want a problem to go away, a money stream built, a client to be happy. Of course, that probably requires you to build software, unless you invent a magic wand. But if you had the magic wand, I'd choose it every single time over software.

Not so with food, furniture or a fancy hotels, where I actually want the thing.

>The best software is no software.

Eh, I disagree. I like a lot of the software I'm using. There's inherent value to producing music with Ableton, cutting videos with Final Cut Pro, or just playing Super Mario for entertainment. Those are all more software than no software.

If I had a magic wand to make you satiated, you wouldn't need food. If you're in it for the taste I will magic wand you some taste in your mouth. If I had a magic wand to give you a roof over your head, protection and a bed, you wouldn't need a hotel.

The magic wand argument doesn't make sense. Then you can also get everything else.

Not to be snarky, but my definition of best programmers would balance these. I do spend more time than most understanding the depths of tech stacks and the breadth of potentially useful ones. At the same time I strive to make software that gets the job done with only the abstractions that pay off in a short to medium timeframe.

The trap avoid are those business impact folks that demonstrate an unwillingness to get better at actual programming, which ironically would increase their impact.

Edit: an example is fixing a problem without understanding its cause.

You could argue that GenAI music creation is "no software". You say what you want and it magically appears.

Life goals! I'd love to do this if I ever retire.

This thread is kind of wild and something I've never heard anywhere in tech. Every place I've worked would consider a developer at least 5X more valuable if they actually had business or product sense, and could operate without the need for constant symbiosis with a "product guy". At one BigTech company we've all heard of, our division didn't even have product people. The engineering lead was expected to handle all of the product duties, and they wouldn't hire you if they didn't think you could at least grow into that role.

It's one of the reasons I went back for a business degree and then re-entered tech. No, of course nobody in Silicon Valley cares about the "MBA" title (HN sees it as a negative), but everywhere I've interviewed/worked they've appreciated that we could talk about the economic and business impact of the software, and not just the algorithms and data structures.

Good engineering skills are transferable to being a good PM: you need to break down problems, scope them to fit a particular time allotment, estimate an effect on user experience (stats, tracking, what is a good signal and what isn't) and have the agility to react to changing requirements as things are getting built.

Why it makes sense for them to be a single person? Often, "changing requirements" really comes from an engineer learning new things (this framework does not provide this, this external dep is going to be late, I'd need to learn 2 new things so will need more time...), and really, an engineer is the first one who'll know of some of the challenges and what's even feasible!

Now, the skills an engineer needs to develop to be a good PM is good communication and ability to document things at the right level, and lots of empathy for a customer and a business person (so they can "walk in their shoes"). Arguably, all things that will make a great engineer even better.

I've been in teams where we've had a very senior, experienced PM tell us that he's looking for another position in the company because our team does not need them: we already did the stuff they were hired to do. That was a sign of a great PM who did not try to actively wrestle control out of our hands when the team was chugging along just fine.

Breaking down problems (vertical slicing) isnt inherently a dev skill. Insofar as it is a transferable skill to break down problems it is more of a life skill.

Scoping tickets is more of a project management skill. Again, not a dev skill.

Estimating effect on user experience - requires empathy, again not a dev skill.

If you redefine the dev job as including PM skills then sure, PM skills are dev skills.

But theyre not.

>Why it makes sense for them to be a single person? Often, "changing requirements" really comes from an engineer learning new things

So? Happens to me too. I can tell the PM these things i learned. Thats a hell of a lot easier than managing all stakeholder interactions, empathizing and balancing their demands.

It only really makes sense to combine the two roles if the project is inherently very straightforward, a salary can be saved and the person doing both roles is suffiently qualified for both roles.

That sounds great, and I would advise you to value it. Most tech companies are not this forward thinking (often to their own detriment)

The result of that top-down management style is buggy code, blown deadlines, security holes, and the slowest software development I've ever seen.

I've found it possible to migrate to a less top-down Desert style just by finding executives who are frustrated by those problems and saying, "I have an idea I've seen help" and then getting the team together and saying, "hey, it turns out the executives would like us to write software well. What should we try first?"

Product has plenty of work remaining: they should be handling whatever subset of strategy, prioritization, analytics, BI, QA, facilitation, design and contracts that they have the skills for. But it requires engineers to actually collaborate with them as a peer, rather than engage in power struggles, and that requires everyone on the team to understand what we are building, for whom, and why.

For any given ticket, unless you remove all creativity for an engineer, they will have to balance how deep and how wide they go, how much they refactor, and how much they skip, in order to be effective and not end up with a contraption that's extremely high risk to review and roll out to production: all of that is scoping.

If you are not doing that, you are being micromanaged and I feel for you in your engineering job.

And trust me, non-technical PMs are ill-equipped to figure out an incremental path to that North Star product or feature you want to ship — how you split branches and deliver value incrementally is something only a good engineer can do (well).

If you do not consider how an implementation will affect the user, you might just satisfy the requirement with an actually terrible experience (but the ticket never said it needs to load in under 30s and with no visible redraws and jumping elements): a good engineer will implicitly consider all of these, even if unspecified in a task (and many more, I only used an outrageous example to make a point).

Breaking down problems is certainly a life skill, but engineers are inherently good at it: it's the very definition of an engineer, and you can't be one without it. I have however seen PMs who mostly channel and aggregate customer experiences and stakeholder requests without an ability to consider (broken down, stepwise, incremental) paths to completion.

If you are good at all of these, you'd likely be a good engineer too: this does not mean that one can't be good at PM without being an engineer, just that a great engineer is very close to being a great PM too.

I am not against the division of labour and different motivations driving where each person invests their time, but if we are talking about a great either PM or engineer, they are pretty much of the same mindset with focus on different parts of the job that needs to be done — 90/10 split vs 10/90 split (and anything in between).

And finally, whether you are a great craftsman at engineering (or PMing), it is slightly different from a great engineer.