[deleted]
The best programmers I know
91–100 of 320 posts
Re: The best programmers I know
#92Earlier quoted context omitted.
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?
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.)
Re: The best programmers I know
#93https://web.archive.org/web/20250409082704/https://endler.de... Otherwise rate limited
The best programmers I know don’t use cheap hosting that rate-limit your static blog.
Re: The best programmers I know
#94I've read (or not read as it is in some cases) some really bad and/or really convoluted documentation.
Some industry standard tools, like Jackson, don't even have documentation but instead point you to various tutorials that are written by others on how to use it: https://github.com/FasterXML/jackson-docs
One of the nice things that LLMs have done is taken some of that mess of missing/poor/convoluted/scattered-to-the-winds documentation and distilled it into something accessible enough that you either get a useful answer or get a useful direction on how to narrow your search for the answer.
I think "read the docs" is good advice; but even the article itself doesn't go so far as to say *all* documentation is good.
Re: The best programmers I know
#95I don’t get this one: > Don’t Guess If you work with anything but a very simple program, you often must guess what could be the cause(s) of your issue in order to know where to look. The more experienced you are, the more accurate your guesses will be.
Logs, tests, debugging, ask questions, build a mental model, test that mental model. The more experience I get the less I guess.
Re: The best programmers I know
#96> "Don’t go to Stack Overflow, don’t ask the LLM, don’t guess, just go straight to the source. Oftentimes, it’s surprisingly accessible and well-written." It's a bit like math books. I dreaded reading formal math during my engineering -- always read accessible text. Got a little better in my master's and could read demse chapters which got to the point quickly. At least now I can appreciate why people write terse ref…
I haven't used Haskell in years, but I still find myself wishing for Hoogle no matter the tool I'm using. Being able to just go "I know I want a value of type X, what functions return type X?" is so useful. I think Scala may be the only other language I have used whose docs let you search by type signature like that.
I have been playing around with Zig a lot lately, and their doc system is quite nice too. I particularly like how they will embed the source of how what you are looking at is implemented, and often an example of how it is expected to be used. Being able to see the language in action all over the docs has helped with making it super easy to pick up. Being able to search based on type signature a la Hoogle would really be killer though.
Re: The best programmers I know
#97I 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 quite agree. It's simply a slider isn't it, with "no time, no knowledge, pure guesswork" at one end and "infinite time, thorough analysis, perfect understanding" at the other end. Clearly the left end is dangerous but the right end can also be, due to opportunity costs. Making a judgment on where the slider should be for each decision/change is a key skill of the craft.
I also find that my "context windows" can only hold so much. I can't understand everything all at once. So if I do very deep dives, I tend to forget (temporarily) other parts of the problem/stack/task/whatever. The solution for me is to create as much as possible as self-contained testable units. Not always possible, but something to strive for.
And I find that this skill of organising is the limit for how large/complex systems I can build before they become unmaintable. This limit has increased over time, thankfully.
Re: The best programmers I know
#98https://web.archive.org/web/20250409082704/https://endler.de... Otherwise rate limited
The best programmers I know don’t use cheap hosting that rate-limit your static blog.
The best programmers I know always find programming challenges everywhere, and a rate limit function was probably one of them.
Re: The best programmers I know
#99Note 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…
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,…
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.
Re: The best programmers I know
#100> "Don’t go to Stack Overflow, don’t ask the LLM, don’t guess, just go straight to the source. Oftentimes, it’s surprisingly accessible and well-written." It's a bit like math books. I dreaded reading formal math during my engineering -- always read accessible text. Got a little better in my master's and could read demse chapters which got to the point quickly. At least now I can appreciate why people write terse ref…
I think this also ties into using tools that help faciliate this workflow.
Being able to jump to a definition of library code lets you really quickly move from your code to some function you're trying to figure out. With code editor support this is a seamless experience that can happen without a real context switch.
Without this, you might leave your code editor, Google for the project it's related to, find it on GitHub, open up the "dev" version of GitHub (hitting . when logged in on a repo's home page) so you can explore the project, then do a project search for that function and wade through a bunch of results until you find it.
That or find the code locally where your package manager might have saved it but if your app is in Docker that could be a problem because it might not be volume mounted so you won't be able to explore it from the comfort of your local code editor.