The best programmers I know

I always get a lot of pushback for avoiding frameworks and libraries, and rolling most things by hand.

But, most frameworks and libraries aren't built to be audit-grade robust, don't have enterprise level compatibility promises, can't guarantee that there won't be suprise performance impacts for arbitrary use cases, etc.

Sometimes, a third party library (like sql-lite) makes the cut. But frameworks and libraries that reach the bar of "this will give me fewer complications than avoiding the dependency" are few and far between.

Ooh, I was in semiconductor manufacturing too! As a junior ion implant engineer, I was looking into yield problems. Some of the tests were flaky and I traced the issue back to one of the transistors not delivering enough current. Great, we know how to fix that! More arsenic! I proposed a small scale experiment, those wafers tested great, and we started rolling out the process change. Those wafers tested great too.

Until we got word back from packaging post test. Every single die failed for excessive current draw. Several hundreds of thousands of dollars worth of scrap. I was correct, but I wasn’t deeply correct.

What surprises me in retrospect is that everybody signed off on this. It’s not like we didn’t have processes, I just somehow managed to talk a bunch of people who should have known better into doing it anyway.

> This is why I aggressively avoid use of non-vanilla technology stacks

I was with you until this line. I've never seen a codebase where Not Invented Here Syndrome resulted in a stack that "antagonizes root cause analysis" in any way. I once worked at a C++ shop that had NIH'ed a supposedly thread safe string class, and it wasn't pretty.

There's plenty mature robust tech out there, and the chance that your own inventions are equally free of quirks and edge cases as battle-tested frameworks/libraries/databases that have had 1000s of eyeballs on them sounds quite unlikely to me, regardless of your programming skill.

You ultimately own all of your dependencies, even if you never look at them. Back in the 90s and early 2000s, when starting a new project I'd do a couple things.

1) look for all the problems we were going to need to solve and look for 3rd party libs that solve those problems

2) I would do a set of PoC using just that 3rd party library and see what the dev experience as like. I build it from source, read the code, look at the code hygiene, etc.

3) Everything would get checked in as source into our repo, a "full build" would build the 3rd party libraries, you would get source level debugging into everything. You could make invasive changes into libs as part of development, etc.

Every dependency had to earn its place, you didn't just pull in a bunch of things because you needed one function.

When you need this capability is at the exact wrong time for your build and dev process to be able to take on this work. People are panicking, shits broken, no one knows what is going on. If you have everything lined up, you can still do solid engineering using the scientific method, fix your problem and move on.

Well said, well written.

>> Read the Reference

>> Don’t Guess

> I find that, when working with a new "thing," I often like to guess for about an hour or so before I really do a deep dive into the reference. Or, I'll read a stackoverflow answer or two, play around with it, and then go to reference.

I think that's fair. I've definitely seen "not best" programmers only guess and only read stackoverflow, over and over, forever, and never read the reference. They have no idea what's going on and just spin making a mess in until something sticks. I kinda read that item as a response to people like that.

Agreed. Make a guess, then verify that guess with running code, repeat.

I'm surprised this is controversial; engineering ostensibly follows the scientific method. Without forming hypotheses and testing them, there is no scientific method. Unless we want to nitpick the difference between guessing and hypothesizing, making guesses is a critical part of programming.

I always come back to Peter Naur’s essay "Programming as Theory Building". It's 40 years old now but still nails the essence of programming. The value produced by programming is a shared working theory of the system, not the source code itself. I can't see how you would develop a sufficient theory without first forming hypotheses.

This is why I tend to Google instead of chatgpt everything. I always end up finding these little interesting nuggets in comments/threads in SO

Middle-out learning is a great way to tackle brand new things. Do some overviews, see what other people do and think about the thing, then dive into it's manual once you have a worldview of it.

I think people are going to interpret "Don't Guess" in a way that is totally impractical and not what the best programmers do.

You should have a strong sense of the model that a tool or library presents to you as the consumer. And you should use that model to "guess" about the behavior of the tool. You should choose tools that are coherent, so that your guesses are more accurate than not, and avoid using libraries/tools with many special cases that make it hard to "guess" what they do.

The best programmers do not double check the docs or implementation for every function that they call. They are good at writing tests that check lots of their assumptions at once, and they are good at choosing tools that let them guess reliably, and avoiding tools that cause them to guess incorrectly.

Leverage in programming comes from the things you don't have to understand and the code you don't have to read in order to accomplish a goal.

I also find it damn near impossible to focus on the reference. I know it sounds childish, but I just can't do it sometimes. Playing around with code is how I got here.

same. It is so hard to write good documentation, especially when the author is also the designer. There is so much context that is easy to take for granted and thus leave out.

I don't think your approach is bad, nor is it in conflict with the advice in the article, at least in spirit. You aren't (I think) describing a situation where your untested guesses end up in a released product, or in ill-founded advice to colleagues. (Both of those actually do happen.) Forming and testing hypotheses is valuable, building on unfounded assumptions is a very different thing.

>> "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 references, even Tutte books.

I don't think that's what he means by the advice. I think it's more about systematic knowledge vs. fragmented knowledge. Someone who "learns" through an LLM or Stack Overflow is not going to have the overall knowledge of the tool to be able to reason what's available, so will tend to use it in very stereotyped ways and do things in harder ways because they don't know what's possible. You can still get that systematic knowledge through an accessible text.

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.

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.

> Oftentimes, it’s surprisingly accessible and well-written

I'm happy this person works with quality software. I haven't been always been as lucky.

Powerful argument for Literate Programming:

http://literateprogramming.com/

The two best programmers I worked with had well-thumbed copies of Knuth's TAoCP....

It can be a bit hard to go to the source when you don't know the name of your problem.

Most projects should follow diataxis and we’d be in a lot less pain

God, the boto3 python docs are _insanity_. The lack of type hints, having a single method for getting a client that could be for 100 different services…

For the uninitiated, boto3 is the official AWS python library. To get a client for, say, S3, you do `boto3.client(‘s3’)` - instead of the sane thing, like, you know, `boto3.s3.S3Client()`

Personally, I think the newer ones ask better, curious questions. The more experienced ones know when not to follow common practice.

Things change really fast, more so with AI tools, so it's important to have people question why we do it a certain way.

I also agree with most of it, apart from that. I actually think this advice comes from the different ways people learn. And if you don't learn the way the author does, this advice feels wrong and jarring.

I learn by doing, not reading. If I read something but don't actually use it I'm liable to forget it. My brain seems to classify it as "not practical, not needed". If I do actually use it, however, I tend to learn it quickly.

So for me documentation is pretty terrible, reading how something works doesn't help, I need to see examples. When I see something in action, I actually learn it. Even copy/pasting works as I'll poke at the copied code, changing variables, playing with params, add/remove comments, etc. No code is ever just copied, it's always manipulated, cleaned up, unnecessary cruft removed.

And there's a whole load of documentation out there that has no examples, or really poor examples that don't relate to how you want to use something.

And for me with an API that doesn't make "sense" I find it really hard to ever remember. Like SQL Server's "OVER" clause, I've used it intermittently over the years and every time I come to use it, I have to re-learn it again. I find those sort of APIs really frustrating.

This is why I love LLMS. I drop 200, 100+ page 13F filing reports into Gemini, and after 10 minutes, it finds anomalies for me. This was impossible before, as these reports are not standardized at all.

Love this, I have the same view. I use them for search in cases where I have to circumlocute and can't quite say what I mean (I found an old book I could only remember very vague broad strokes about this way when no search engine could do it) and for "framework" questions, e.g. what is this about and how do the pieces relate, which I would go so far to say is another type of search problem (it's search where I'm starting from zero). I still have to take it with a grain of salt but to your point it's enough to familiarize me with "landmarks" in the information space and then to start building more solid understanding from that foundation.

> When I started my career I spent a fair bit of time answering questions on Stack Overflow rather than asking questions.

I don't think you can answer SO questions as a hobby any more. I used to do it on my morning coffee but at some point it got full of professional reputation growers that answered everything 30 seconds before it got posted. And when you do find an unanswered question the mods jump on you for giving "teach the man how to fish" answers instead of ready to copy/paste code.

This is exactly how I use LLMs currently. It's like a kickstart into any subject imaginable, and at this level of use they seem largely free of errors.

I recently started drawing (my own little middle age crisis) and i am so out of depth, so far from even understanding what is possible, and the internet filled with so much junk tutorials, that sometimes ability of LLM to parse my intent and guide me towards the key words and names is a godsend, of course it probably would be better to ask a person who knows this stuff, but it's not always convenient. In my use case best part of LLMs is Soft input, and the soft output is not a problem.

There's some irony, is there not, in presuming to be able to identify "the best programmers" when you've created a programming blog that completely falls down when it gets significant web traffic?

Off-topic: is the rate-limit because they host on a Cloudflare compute service? I ask because I would like to know if this feature would be available for just using the domain hosting.

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

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.

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.

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

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.

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

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

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

Sometimes all you need is passion.

I feel like the way universities teach data structures and algorithms isn't a great way to instill the joy of problem solving.

That being said, not everyone has that spark. And you can always lose it.

The best programmers I know don’t use cheap hosting that rate-limit your static blog.

wondering how can a static blog can be rate limited :|

secondary source: https://archive.is/0GcBe

Honestly this one's been made a lot easier with LLMs.

Like just today I got a nebulous-ass error trying to compile some old cpp package, threw that into 4o and in a few seconds I get an in-depth analysis back and a one line correction that turned out to fix the entire thing. Literal hours saved lmao.

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.

> I'm not sure if all this advice will become irrelevant or if those programmers trained in the 2020ies will not become those "best"..

It's how they use the AI. If they see it as a glorified StackOverflow where you paste a big chunk of code and ask "why does it not work", they'll be in trouble. If they are able to narrow-down their problems to a specific context, express them well and take the output of the AI with a grain of salt, they'll be 10x programmers compared to what we were in the 2000s, for example.

I dunno, do they really make it that easy? From what I've seen they can give you some example code, and often it works, but when it doesn't, you actually need to know what you're doing to fix it up.

Fixing someone else's code is a great exercise, so maybe they're actually learning useful skills by accident? :)

I'm kinda conflicted that you shouldn't use AI.

With a good combination of Cursor, NotebookLM, flashcards (I use RemNote) and practicing you can accelerate a lot your learning.

Nothing stops you from reading specs, docs and having AI assist you doing so.