Live data from Hacker News

The best programmers I know

endler.dev

21–30 of 320 posts

Re: The best programmers I know

#21

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…

Sometimes you also encounter documentation that you either don't understand, or maybe it's just poorly written, in those cases I'd say it fair to guess to keep moving forward. Afterwards you should probably stop and think: "Why did/didn't this work?" and build up your understanding.

I've been reluctant to learn frontend development and our framework of choice is apparently fairly well documented, but I don't even understand large parts of the terminology, why certain solutions work, or why some are more correct. So I guess, and I learn, but you need to keep iterating for that to work.

If you just guess, or ask an LLM, and doesn't question your guess later, then I can see the point of simply not recommending guessing at all. Mostly I think flat out recommending againts guessing ignores how a large percentage of us learn.

Re: The best programmers I know

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

Re: The best programmers I know

#23
> If there was one thing that I should have done as a young programmer, it would have been to read the reference of the thing I was using.

I'd love to do this, but (if I may play the victim for a second), I have real trouble reading something long form; I glaze over after a few paragraphs or just fall asleep. I don't find it compelling reading, especially not if I realize the vast majority won't be relevant.

I don't know if this is from a broken attention span thanks to spending 25 years online, or simply from experience - there's so many tools I've used for one project and never again, or questions I've only ever had once, and "studying" feels wasteful.

This goes back to when I learned Java in college, second year; we had a book, I think I did like the first two pages, but after that I just winged it and googled stuff if I needed it. (which was probably the other huge change in the software development world at the time, Google and easily searched / found online documentation)

Re: The best programmers I know

#24
Maybe this article could be improved by adding “Domain/Business knowledge” and understanding what the business and product actually do. It doesn’t matter if you are a good developer if you are not able to provide solutions because you lack domain knowledge. Depending on the domain it can take quite some time to be a reference

Re: The best programmers I know

#25

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

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.

Re: The best programmers I know

#26

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…

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

Re: The best programmers I know

#27

Maybe this article could be improved by adding “Domain/Business knowledge” and understanding what the business and product actually do. It doesn’t matter if you are a good developer if you are not able to provide solutions because you lack domain knowledge. Depending on the domain it can take quite some time to be a reference

You can work closely with people who have the domain knowledge who work closely with programmers to do this. I have had a job where a major part of it (as well as creating specs etc) was to do this.

Of course the developers still needed some domain knowledge, but much less.

Re: The best programmers I know

#28
post #8

This is great advice. Unfortunately, all these AI tools make it far too easy for beginners to not follow it. I'm not sure if all this advice will become irrelevant or if those programmers trained in the 2020ies will not become those "best"..

Everything comes in cycles I think. There will be a wave of AI generated stuff, but then people / companies will be hit hard by bugs and problems and will reinvent the wheel of quality assurance.

I wonder if AI generated stuff would pass our existing checks, e.g. linters, test coverage, sonar, etc.

Re: The best programmers I know

#29

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.

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.

Re: The best programmers I know

#30

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…

I see what they're saying with "don't guess" and I also agree with you. I'd phrase it something more like "explicitly acknowledge when you're guessing". It's fine to guess with the understanding that you might have to walk it back later if you weren't lucky. What's not fine is stacking guesses on top of guesses, and ending up marooned way out in maybe-land. "Maybe A, and then maybe B, and then maybe C... so it must be D." No, the chances of D for this reason are P(A) * P(B|A) * P(C|B)... ~= 0.

Also don't guess when it's easy to test. "Maybe divisorValue is zero" well slap a printf() in there and see if it is! Often you don't have to guess. I've seen discussions go round in circles for hours asking "what if it's X" when it'd take 2 minutes to find out if it's X or not.

Post reply on HN