←back to thread

The best programmers I know

(endler.dev)
628 points kiyanwang | 1 comments | 09 Apr 25 06:02 UTC | HN request time: 0.001s | source
Show context
blackbrokkoli ◴[09 Apr 25 08:19 UTC] No.43629992[source]▶
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.

replies(8): >>43630007 #>>43630051 #>>43630093 #>>43630108 #>>43630175 #>>43630276 #>>43630281 #>>43631346 #
jbreckmckye ◴[09 Apr 25 09:13 UTC] No.43630276[source]▶
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.

replies(4): >>43630326 #>>43630443 #>>43630583 #>>43645055 #
1. roguecoder ◴[10 Apr 25 15:42 UTC] No.43645055[source]▶
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.