Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The best programmers I know

endler.dev

Post reply on HN
Print view View original

41–50 of 320 posts

Re: The best programmers I know

#41

Post by blackbrokkoli »

nvarsj wrote: post #31
blackbrokkoli wrote: post #22

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 s…

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…

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?

Re: The best programmers I know

#42

Post by olex »

OvbiousError wrote: post #19
continuational wrote: post #7

I think this "good devs don't complain" mentality risks real issues being overlooked and left unaddressed.

The full quote being > Most developers blame the software, other people, their dog, or the weather for flaky, seemingly “random” bugs. > The best devs don’t. > No matter how erratic or mischievous the behavior of a computer seems, there is always a logical explanation: you just haven’t found it yet! I don't see how you can conclude from that that real issues would be overlooked? I interpret this to be the opposite.

I agree. The author isn't saying that the best devs never complain about something. He's saying they never leave it at complaining and throw their hands up, but dig in until the find the underlying reason for the behavior, or a way to work around it, as long as the problem remains in their way.

Re: The best programmers I know

#43

Post by ethanwillis »

davedx wrote: post #37
blackbrokkoli wrote: post #22

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 s…

> 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 soft…

> 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.

Re: The best programmers I know

#44

Post by eptcyka »

zwnow wrote: post #29
OvbiousError wrote: post #19

Earlier quoted context omitted.

The full quote being > Most developers blame the software, other people, their dog, or the weather for flaky, seemingly “random” bugs. > The best devs don’t. > No matter how erratic or mischievous the behavior of a computer seems, there is always a logical explanation: you just haven’t found it yet! I don't see how you can conclude from that that real issues would be overlooked? I interpret this to be the opposite.

Idk lots of popular languages/tools simply suck, addressing issues is interpreted as crying about it by more experienced devs. Experienced that a lot in my career so far. So I think the original comment is fair.

If an experienced developer looks at someone who tries to address suckage of a tool/language sucking and then characterises the behaviour as crying about it, it is the experienced dev that also takes part in the suckage.

Re: The best programmers I know

#45

Post by zwnow »

eptcyka wrote: post #44
zwnow wrote: post #29

Earlier quoted context omitted.

Idk lots of popular languages/tools simply suck, addressing issues is interpreted as crying about it by more experienced devs. Experienced that a lot in my career so far. So I think the original comment is fair.

If an experienced developer looks at someone who tries to address suckage of a tool/language sucking and then characterises the behaviour as crying about it , it is the experienced dev that also takes part in the suckage.

Yea agree, sadly in dev communities there is a lot of gate keeping considering dev behavior on Stackoverflow for example.

Re: The best programmers I know

#46

Post by eptcyka »

Cthulhu_ wrote: post #25
wiseowise wrote: post #9

Earlier quoted context omitted.

Absolutely. I think it is incomplete: good devs never complain… they just give their 2 weeks notice and find a better place.

Or to phrase it differently, they take ownership and responsibility of their own problems and have a problem-solving mindset. If the problem isn't solveable by them but caused / exacerbated / the solution is blocked by their job, they can find another one. Or could, in any case, after a bizarre hiring boom it seems the market has quieted right down again.

Exactly, instead of just assuming that a component just does that, they focus on understand fixing underlying problems. Boils my blood when people with years of experience just allow bullshit issues to stew and just blame the platform/device/user/library.

Re: The best programmers I know

#47

Post by jpap »

rowanG077 wrote: post #5
DeathArrow wrote: post #2

I agree with all but one of his assertions. >Don’t Guess If you are working on critical software like code running in a rocket or medical device, sure, never guess is mandatory. But I and many other people can be in a hurry. We have to or want to move fast where it matters. I don't have the time to research every single detail nor I am interested in knowing every single detail. I am mostly interested in building some…

This. In fact a lot of what I do are guesses. And then check whether it works. I think if you don't work like this you will be completely paralyzed to achieve anything.

Agreed; I do this all the time as well. I don't think it as "guessing" per se, I think of it as forming a hypothesis based on the intersection of my existing knowledge of the problem and any new observations [1], then testing it to figure out if the hypothesis was correct. If proven incorrect, the process helps me reform into a new hypothesis and the cycle continues until the problem area becomes clear enough to solve outright.

[1] By reading more of the code, RTFM, observing logs, tracing with a debugger, varying inputs, etc.

Re: The best programmers I know

#48

Post by patrickjd »

blackbrokkoli wrote: post #22

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 s…

> 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)

Re: The best programmers I know

#49

Post by bt1a »

OvbiousError wrote: post #19
continuational wrote: post #7

I think this "good devs don't complain" mentality risks real issues being overlooked and left unaddressed.

The full quote being > Most developers blame the software, other people, their dog, or the weather for flaky, seemingly “random” bugs. > The best devs don’t. > No matter how erratic or mischievous the behavior of a computer seems, there is always a logical explanation: you just haven’t found it yet! I don't see how you can conclude from that that real issues would be overlooked? I interpret this to be the opposite.

... trust me..

this time it really was a cosmic ray bitflip

Re: The best programmers I know

#50

Post by lacn »

davedx wrote: post #37
blackbrokkoli wrote: post #22

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 s…

> 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 soft…

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."

Post reply on HN