The best programmers I know

https://endler.dev/2025/best-programmers/

by kiyanwang • 1 year ago

631 307 1 year ago

DeathArrow2• 1 year ago

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 something or solving a problem, I don't care about implementation details as much. Sure, some times details do matter a lot but it's a part of the job to have an understanding of which details matter more and which matter less.

So, I don't guess out of laziness, but because I have things that are more important and more interesting to do and time is a finite resource.

Many decisions can be reverted with minimal loss if they will be proved wrong in the future. Bugs can be solved with ease.

I'm not saying to move fast and move things, but learn how to do the right trade-offs and making educated guesses is a valuable tool.

So I would add another assertion to the the list:

Learn to value time, don't procrastinate, avoid analysis paralysis.

pmg101• 1 year ago

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.

actionfromafar• 1 year ago

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.

rowanG077• 1 year ago

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.

jpap• 1 year ago

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.

wiseowise2• 1 year ago

For others: if company mostly consists of devs, or God forbid management, like that - run asap and never look back.

mrweasel• 1 year ago

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.

taneq2• 1 year ago

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.

arkh• 1 year ago

The best devs talk to principal engineers and junior devs alike. There is no hierarchy. They try to learn from everyone, young and old. The newcomers often aren’t entrenched in office politics yet and still have a fresh mind. They don’t know why things are hard and so they propose creative solutions. Maybe the obstacles from the past are no more, which makes these people a great source of inspiration.

That's how you can work against the normalization of deviance. Never dismiss new people commenting on what you may doing wrong for no reason. Yes, you've been doing X in an unusual way and no accident happened still; but there's a reason you should not do it this way and it may cost a lot to relearn it by experiencing it.

And same thing with old rules for which no one has an idea of why they exist but are still followed. Any rule should have an explanation for its existence and their relevance checked periodically.

muzani• 1 year ago

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.

ozim2• 1 year ago

Reading documentation - if you are junior take time to go one level deeper to understand / fix issues you have. Then read also stuff adjacent to that.

By trying to read some documentation like a book from cover to cover will be waste of time.

bluetomcat2• 1 year ago

Absolutely. LLMs offer you compressed documentation at your fingertips. Instead of scrolling through man pages and function references to find that specific flag or parameter you are interested in for the problem at hand, you can directly formulate such a question to the LLM, and it will give you a pretty good result.

Zanfa• 1 year ago

Another issue LLMs help with is identifying the correct keywords or terms to look up. Especially with manpages, I've had numerous times where I roughly know what I'm looking for, but in the presence of hundred-plus flags and options, I can't even grep to the right place because I don't know the exact term I need. So I sometimes use LLMs as glorified grep with semantic synonym support.

iroddis• 1 year ago

I think the GP was proposing an organic way to expand knowledge. Reading adjacent documentation expands your knowledge of what’s possible. An LLM will tell you how to do a specific thing, but you need to know such a thing is possible before you can effectively ask about it.

In this way, LLMs may passively discourage discovery by providing immediate, specific answers. Sometimes there is value in the journey.

Wool2662• 1 year ago

Reading documentation cover to cover for tools you use a lot is a very worthwhile investment in my opinion. Junior dev or not.

ozim2• 1 year ago

There are always better sources to read usually than documentation cover to cover.

There is no "only SO and LLM shortest path" vs "always read full documentation" - there are always more sources like blog posts, walk troughs that will be much better investment of time.

Sometimes you need someone to explain architecture of the tool much differently than it is described in documentation when documentation is dry. Sometimes you need better examples better aligned to what you are trying to do. You need different approaches to grasp the thing.

bonoboTP• 1 year ago

Sometimes I just open the NumPy or the Python docs and browse it (or other libraries like PyTorch). Even after about 2 decades of Python experience, I often find something new and neat even on the "basic" pages that I didn't know about. Reading release notes can be useful also.

Many people seem to have an irrational aversion to reading documentation and manuals. They'd rather speculate and guess and state false things than to just open the docs to understand how the thing works.

I'd say if you use the tool daily for years, it makes sense to invest into actually reading the docs.

continuational• 1 year ago

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

wiseowise2• 1 year ago

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

whstl6• 1 year ago

Especially in the current job market climate.

I talk regularly to recruiter friends and there seems to be a bimodal distribution going on, with some developers finding jobs straight away vs unlucky ones staying unemployed for months on end.

I recently helped a couple devs that were laid-off in 2023 and still haven’t found anything else.

Cthulhu_3• 1 year ago

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.

Manfred• 1 year ago

Are you talking about the "Never Blame the Computer" section?

I don't think that addresses complaining, but rather redirecting blame to something nobody has control over instead of digging into the issue and finding the root cause

OvbiousError• 1 year ago

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.

zwnow2• 1 year ago

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.

nindalf• 1 year ago

If you can’t make a COBOL stack work it means you’re a bad developer. Don’t complain, make it work!

olex• 1 year ago

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.

bt1a• 1 year ago

... trust me..

this time it really was a cosmic ray bitflip

rethab• 1 year ago

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

taneq2• 1 year ago

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

bluetomcat2• 1 year ago

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.

dehrmann• 1 year ago

You could argue that a "feature" of Stack Overflow is the culture. They're building a reference, not a help desk, so they expect questions to be original and researched. Once you're in a corporate environment, if you don't have experience in asking good questions, you'll come off as incompetent.

Cthulhu_3• 1 year ago

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.

epolanski5• 1 year ago

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.

ancientrevolver• 1 year ago

Your workflow sounds interesting.

I understand the power of flash cards and SRS in general. But was wondering how you decide when to put something into an SRS when learning something new. Especially in a tech/programming context.

roenxi• 1 year ago

Although these are all qualities of good devs, they are qualities of a lot of middling devs too. Reading the documentation and understanding the tooling isn't that rare.

Although I will say the "Status Doesn’t Matter" thing is a symptom not a cause. If there isn't any question you're one of the best then status doesn't matter - people know you're the best and there is no need to remind them. The people who fight strongly for status are the insecure ones who think they need to remind people otherwise they'll lose their place in the pecking orders. Typically people who are a few steps shy of the best - silver medallists if you will - are the ones who need to spend a lot of time reminding people they are almost the best.

liampulles• 1 year ago

I agree with all this, except that lets keep the number of thought leaders to a minimum.

djmips• 1 year ago

Good generic advice except for 'don't blame the computer' ;-)

nikolayasdf123• 1 year ago

I expected to see a list lol

blackbrokkoli3• 1 year ago

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.

soulchild37• 1 year ago

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

davedx2• 1 year ago

Read everything DHH wrote, he has lots of insights on this. Scroll down to his books: https://dhh.dk

I found Lean Startup to be very good too.

nvarsj• 1 year ago

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.

blackbrokkoli3• 1 year ago

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?

davedx2• 1 year ago

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.

ethanwillis• 1 year ago

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.

lacn2• 1 year ago

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

esperent2• 1 year ago

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.

ChrisMarshallNY• 1 year ago

I’m retired, these days, and spend the majority of every day, writing software.

I treat it as a craft, and do it for personal fulfillment and learning. I enjoy learning, and solving problems. I also enjoy creating stuff that I find aesthetically pleasing.

For example, I write iOS apps, and I’m working on a new version of a timer app that I’ve had in the App Store, for over a decade. I had added a Watch app to it, and had gotten to the point where it was ready for the App Store, but I kept having sync issues. It wasn’t a “showstopper,” but it was aesthetically not pleasing.

I determined that it was an issue that could be addressed by improving the fundamental design of the app, which had basically been constant for many years.

So I'm rewriting it completely.

That’s not something that makes “commercial” sense, but it’s what I want to do. I’ll also take the opportunity to redesign the basic UI.

I enjoy having that kind of freedom.

I also like to write about my work. I know that very few people are interested in reading it, but I do it, because it helps me to learn (the best way to learn, is to teach), and it helps me to focus my thoughts.

patrickjd• 1 year ago

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)

jbreckmckye2• 1 year ago

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.

rrr_oh_man• 1 year ago

Generally we aren't paid for our business expertise. In fact, most businesses actively resist giving developers deep domain responsibility.

Chicken/egg imho.

yobbo• 1 year ago

Yep. A developer with "business impact" might be seen as a liability.

One aspect might be that a developer who engages in "business" effectively stops being "subordinate". Management decisions need to be justified on a different level to maintain legitimacy.

pydry2• 1 year ago

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.

roguecoder2• 1 year ago

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.

dakiol• 1 year ago

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

karmakaze• 1 year ago

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.

Cthulhu_3• 1 year ago

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)

holysantamaria• 1 year ago

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

graemep• 1 year ago

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.

epolanski5• 1 year ago

I don't know, I would say that's a quality of engineers, not programmers.

Those can be two different things in the same way a sous chef might be much more proficient at cooking/preparing several dishes but not have the skills to create a menu and run a successful cuisine in a successful restaurant/hotel.

0xEF• 1 year ago

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

This was a problem _before_ LLMs were so widely used, but they have compounded it 100 fold.

In the end, I think it always comes back to RTFM. But that's the hard path and users have been conditioned to think of the Internet as a tool that allows them to jump to the end of that path, immediately heading to Stackoverflow, Reddit, Quora, etc. Admittedly, it is almost always easier to just have someone tell you how to solve a problem than it is to take the time to understand what the problem is, apply what you know and troubleshoot. But it will leave you stagnant, hardly able to grow as a developer, exercising no creativity and demonstrate a lack of understanding.

I'm a terrible programmer. I know I am. But every time I slog through a problem in my weird little projects, solving it in a way that makes my coding buddies go "uh, huh...well, it _does_ work..." I learn something, not just about solving that specific problem, but about how the system I'm working in functions.

RTFM culture had it right back in the day, though it annoyed me younger self to no end. As a wee lad, I'd jump on those local BBSs and just start pushing questions about computers to the greybeards, rarely getting straight answers and typically being pointed to the manual, which I clearly hadn't read. Started listening to them after awhile. Glad I did. The value of reading the docs prior to asking my questions extends well beyond code and even computing. Do it with your car, your home appliances, business models, heck, do it with your legal system and government. The point is, RTFM is the foundation on which the House of Understanding is built. It promotes self-sufficiency, greater familiarity with the system in which you are working and the intimacy required for more complex and creative problem-solving later one. Most importantly, it promotes growth.

Now, that's all assuming the documentation is good...which is a different conversation altogether.

fragmede2• 1 year ago

specific tools aside, there's an underlying ethos of giving a man a fish vs teaching a man to fish. if you ask a question and get it answered, you've solved your problem for the day, but tomorrow you'll have to bug that person again. which then makes that person a bottleneck. inefficient.

FinnLobsien• 1 year ago

All of these point to how to master being a developer, which is great and I think a good guide. But not everyone is after mastery.

For your head of SRE or something, sure that's what you want. But I'd argue that for founders especially, it's often better to get good enough to get to effectiveness, even if you're not able to perfectly debug every edge case.

markus_zhang• 1 year ago

I bet few of them get kids early (joking).

kshri24• 1 year ago

Can't find any fault in this article. Agree with pretty much everything except for one point:

"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 has been, I think, close to 15+ years since I have been actively coding professionally. I am always learning. When I started my career I spent a fair bit of time answering questions on Stack Overflow rather than asking questions. That helped a lot as it felt like a "Real-World challenge" to solve someone else's problem. So it totally depends on how you use Stack Overflow.

With LLMs, I don't use it for "vibe coding" as the kids do these days. This is, IMHO, a wrong way to use LLMs. LLMs are great for integrations into software you are building where it has to analyze realtime events and produce summaries, or even for automating mundane things. But it definitely is not a replacement for a programmer. At least not in its current incarnation. The way to use LLMs is to ask it to provide a birds-eye/10,000 ft view on a topic you want to understand/explore. Why? Because sometimes, you don't even know how something works because you have no idea what it is called (technical terminology/jargon). That's where LLMs help. Once you know the terms/jargon, you can then refer to official documentation/papers rather than relying on the LLM. This IMHO is an underrated superpower of LLMs.

lacn2• 1 year ago

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.

ZeroTalent2• 1 year ago

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.

koolba• 1 year ago

Don’t they have some convoluted XML schema? Or are you sending the rendered text of the html versions of the reports?

GardenLetter27• 1 year ago

I do the same even just for logs where I can't be bothered formatting it for a proper field by field diff.

mattmanser• 1 year ago

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.

asl2D2• 1 year ago

Different way people learn, and different way they create. Other creative fields have that dichotomy too, but i guess we are closer to math, and always try to find "correct way" of doing things, while our field is actually really flexible and allowing for a lot of self expression.

asl2D2• 1 year ago

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.

nottorp4• 1 year ago

This is not a LLM feature, but a failure of traditional search engines.

skydhash3• 1 year ago

For drawing it’s usually better to buy a book or a course (from a good platform like New Masters Academy), and then practice (a lot)

nottorp4• 1 year ago

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.

onthewall• 1 year ago

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.

epolanski5• 1 year ago

I want to add another one, ability to handle emotions (mentioned but mostly in terms of patience) and ability to stay focused.

Two programmers that start with similar levels at the thing that OP listed, but one able to stay focused and productive and the other jumping on YouTube, HN half the day (yes, that's me in many periods) etc are gonna have different impact and progression with time.

irishloop2• 1 year ago

Do you think there's a way to train focus?

criddell• 1 year ago

You can lose your concentration skills by not using them. I would expect the reverse is true as well.

udev40963• 1 year ago

No and it's pointless to force yourself to focus. If it's not natural, it's not worth it. Do things for fun and stop taking yourself too seriously

epolanski5• 1 year ago

For me what has helped is to realize the triggers that make me distracted which is why I emphasized the emotional part.

I tend to distract myself under stress/boredom e.g., when I realize this is happening I get back to working and resist the urge of distracting.

In time, you get better, you need to train it till it starts being more natural.

kaffekaka• 1 year ago

Can't tell if you are being sarcastic, but yes of course there is.

rhubarbtree• 1 year ago

I did pomodoros for years to recover my productivity after time in academia.

Now I’m the most focused person in the office. But it took a very very long time.

VonTum• 1 year ago

It is uncanny how well this describes me. I've been trying all kinds of things, like website blockers, timeouts, breaks, etc. nothing's stuck.

And it's all about "getting in the zone". Once I'm there, things fly, but the sputtering engine of editing 3 lines then alt-tabbing to youtube for 20 minutes makes progress very slow.

It's weird, I know exactly what to do, or what to look into, but just "don't want to?"

I have noticed one thing, namely evenings are my golden hours. I'm trying to do all of my shopping, chores, etc during regular working hours, and then actaully working 5pm-?am. Maybe this will fix it.

high_na_euv• 1 year ago

You cannot access this site because the owner has reached their plan limits. Check back later once traffic has gone down.

Rofl?

gowthamgts12• 1 year ago

welp. looks like we hit the ratelimits:

``` You cannot access this site because the owner has reached their plan limits. Check back later once traffic has gone down.

If you are owner of this website, prevent this from happening again by upgrading your plan on the Cloudflare Workers dashboard. ```

dockerd2• 1 year ago

https://web.archive.org/web/20250409082704/https://endler.de...

notrealyme123• 1 year ago

https://web.archive.org/web/20250409082704/https://endler.de...

Otherwise rate limited

agumonkey• 1 year ago

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

h1fra• 1 year ago

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

mr90210• 1 year ago

Traffic. Huge loads of it.

svantana• 1 year ago

cheap hosting services do that, don't they?

montymintypie• 1 year ago

This is what happens when you run your blog behind cloudflare workers - they want you on pages instead, or to pay $5/month forever on the off chance you get slashdotted...

StrLght2• 1 year ago

Cloudflare claims that Pages allow unlimited traffic [0]. So it seems like author is using Workers, probably on a free plan.

[0] https://www.cloudflare.com/plans/developer-platform/

hk__23• 1 year ago

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

amelius• 1 year ago

The best programmers I know always find programming challenges everywhere, and a rate limit function was probably one of them.

szszrk• 1 year ago

That's how I see devops applied in practice in some places - just replace ops with dev. Then things like this happen daily.

I don't blame the author at all - we should do "works most of the time" projects more often and stop caring that much about SLAs. But that downtime in an article that focuses on "Know Your Tools Really Well" is hilarious way of showing that dev and ops are rather different skill sets.

Hamuko• 1 year ago

At least my free Cloudflare-hosted blog was able to withstand being on the HN front page once. I think they've over-engineered their "static" site hosting to the point where it can fail under heavy traffic.

__jonas• 1 year ago

The irony is that Cloudflare actually offers free static hosting with unlimited traffic, this just seems to run on a Cloudflare compute service for some reason? Perhaps it’s server rendered.

reverendsteveii3• 1 year ago

I certainly would. Getting blasted w traffic because of an insightful post is an edge case that it doesn't make sense to design around and I'm not really gonna want my personal blog to be a time or money sink when I could be spending either on things that I like more than that. So I'm gonna go with the free tier of something that provides basic protection and availability and if I do get hug-of-death'd by some content aggregator or another it's no real loss to me that they use the wayback machine rather than hit my page directly because I'm not monetizing.

barlog• 1 year ago

1027, so sorry

dilawar• 1 year ago

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

Some references are a pleasure to use. For rust crates, I always go to docs.rs and search there. It's just fantastic. i can search for a function that returns a particular type or accept a particular type etc. hoogle from Haskell was lovely too when I took a functional programming course in college. Cpp reference is also pretty good -- thanks for adding examples.

Today I was reading boto3 python library docs, and I immediately missed docs.rs!

Zambyte• 1 year ago

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.

nickjj• 1 year ago

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.

WillAdams• 1 year ago

Powerful argument for Literate Programming:

http://literateprogramming.com/

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

ClikeX• 1 year ago

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.

palmotea5• 1 year ago

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

postalrat• 1 year ago

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

weakfish• 1 year ago

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

jilles• 1 year ago

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

adastrapa• 1 year ago

For those who can't access the website, I found the article is also available on GitHub here: https://github.com/mre/endler.dev/blob/master/content/2025/b...

tsak• 1 year ago

Really Read the Error Message and Try to Understand What’s Written

This is a surprising stumbling block for a lot of developers when they encounter a problem. Most times the solution is hiding in plain sight (albeit at least one level of abstraction lower sometimes) and reading what the error was can help to quickly solve an issue.

Anecdotal evidence: We use `asdf` for managing Python, Go and NodeJS versions for our main project. On a fresh Fedora/Ubuntu install, running `asfd install` fails to compile Python as it is missing a few dependencies that are required for Python's standard library. The output that is provided when the `asdf` command fails is pretty self explanatory IF you care to read it.

moffkalast• 1 year ago

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.

mattbee• 1 year ago

Assuming you're working on regular software where you can run it in isolation, without cost, I disagree with "don't guess".

A guess might be your best opportunity to test a theory about a bug you don't understand. That's particularly true where you're a newcomer to an area and the documentation is written for someone with different experience.

A series of guesses and tests can narrow down the problem, and ultimately help you fix a bug on your own terms, a bit like tracer fire.

I much _prefer_ to build a mental model, and to spot the bug as a deviation from that model. And unguided guesswork can be a sign that you're flailing. But guessing can be a strategy to build that model.

mre5• 1 year ago

In my book that's not a guess, but a hypthesis, which is indeed a great way to narrow down the problem space. What I meant was to avoid blind guessing in the hope of striking luck, which comes back to haunt us most of the time.

hk__23• 1 year ago

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

foobahify2• 1 year ago

Logs, tests, debugging, ask questions, build a mental model, test that mental model. The more experience I get the less I guess.

hk__23• 1 year ago

Right, I misunderstood the meaning of "guess" here.

blueflow• 1 year ago

I would consider "exploring and ruling out possible causes" a systematic approach, not guessing.

nhinck3• 1 year ago

I've worked with far too many people who, along with not "Reading the error message" do just guess at how to get rid of the error message. Like literal stab in the dark, what if I just change this and re-run it.

t-writescode• 1 year ago

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

bob10292• 1 year ago

Not guessing is perhaps the most important thing to the business.

I developed a lot of my problem solving skills in semiconductor manufacturing where the cost of a bad assumption tends to be astronomical. You need to be able to determine exactly what the root cause is 100% of the time or everything goes to hell really fast. If there isn't a way to figure out the root cause, you now have 2 tickets to resolve.

I'll throw an entire contraption away the moment I determine it has accumulated some opacity that antagonizes root cause analysis. This is why I aggressively avoid use of non-vanilla technology stacks. You can certainly chase the rabbit over the fence into the 3rd party's GitHub repo, but I find the experience gets quite psychedelic as you transition between wildly varying project styles, motivations and scopes.

Being deeply correct nearly all of the time is probably the fastest way to build a reputation. The curve can be exponential over time with the range being the value of the problem you are entrusted with.

Taek• 1 year ago

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.

jppope• 1 year ago

I completely agree - though there are places where I trust an implementation of things like a well known algorithm.

However, to add onto this, I'm consistently shocked at how often it is much CHEAPER to "roll your own." We've done some reviews on systems after a few years and the number of bugs and security vulnerabilities we experience with code based around packages is much MUCH higher. Its hard to put a number to it because the time cost of fixing those issues is variable, but its substantial. Its also amazing to me that it can be cheaper to build your own vs using a 3rd party vendor for something that would appear to be highly specialized - of course opportunity cost is a real thing.

noduerme3• 1 year ago

This is a hard take, just because we all build on stacks. When we trust that Math.Abs() is going to work in some language, or that some socket library is going to do what it says on the tin, we're standing on the shoulders of giants. I also avoid frameworks as much as possible, but by frameworks I mean anything I'd rather roll myself in a scripting language, particularly when learning and keeping up with the framework seems like more of a hassle. But for the layers and layers of underlying software and hardware behind me writing REST calls and async functions?

Also, there are higher level libraries that are sometimes good, because why reinvent the wheel every time you make something? Pixijs is one I use a lot. Also, Chart.js. Jquery. Moment.js. Good ol' Bootstrap 4 alpha's CSS handles a ton of use cases, and I never need to think about it again. There's very little in those that I haven't at one time or another rolled myself, but having a toolkit that you know and doesn't change much saves you a lot of time. The danger is more getting into libraries that aren't already dead, and are still in active development ;)

pc864• 1 year ago

This is smart if you work for a company that actually needs this level of robustness. The problem is that most don't, and a lot of people who work for these companies wish they were working someone "better"/"more important," so they pretend they actually do need this level of performance.

The guy like you on a mission critical team at a cutting edge company is a godsend and will be a big part of why the project/company succeeds. The guy who wants to build his own ORM for his no-name company's CRUD app is wasting everyone's time.

jon-wood• 1 year ago

This is very contextual. If I'm building a web application for an early stage startup which is basically a bunch of pretty CRUD views I'm absolutely using a framework for it, there's no point in hand rolling everything when the problem being solved is exactly what a framework is designed to do. If it's something safety critical, or where getting software updates out to it is going to be a problem, I'm probably going to end up hand rolling a lot more and depending on frameworks less, because I need to understand what the failure modes are and how it's going to deal with them.

tshaddox• 1 year ago

What programming languages are you using? Compilers and interpreters are pretty darn complicated, not to mention operating systems and computer hardware.

flessner• 1 year ago

I think you're correct, but certain libraries are so widespread enough that it's sensible. Especially S3, SQLite (as mentioned), Postgres and Redis usually offer good abstractions.

Other than that, time and crypto are two things I also wouldn't code myself, both are just too easy to mess up.

roguecoder2• 1 year ago

Frameworks are just someone else's architecture.

They are helpful if you have the same problems as that other company, but I worry about software that uses frameworks because the programmers don't feel confident building their own. It means when it comes time to evolve beyond the off-the-shelf architecture, programmers keep plowing ahead far past when they should have added another level of abstraction & encapsulation.

On the other hand, I also see applications where people dogmatically avoid using pre-existing architectures but also don't take the time to build their own. You end up with references to one table scattered all across the code base in hand-composed SQL.

I'd much rather take an outgrown-framework over a spaghetti mess.

theutopian• 1 year ago

Well said, well written.

skrebbel• 1 year ago

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.

rcxdude2• 1 year ago

I think you may have misread, they are saying they will try to stay on something as common and boring as possible, as opposed to NIH.

sitkack• 1 year ago

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.

sevensor• 1 year ago

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.

fluffet• 1 year ago

Solid points!

Shame the author doesn't mention the Swedish secret of snus. That's the best productivity hack I know bar none. Anyone else out there?

jrockway• 1 year ago

Reading the error message is a good idea. I try to make the fragments of my error messages unique so that in some error like "foo the bar: get bar: lookup bar source: i/o timeout" you can search for "lookup bar source" and get the one point in the code that the error actually came from. (In go, this involves error wrapping and adding the minimum necessary context at each level.) This survives minor refactors (whereas line numbers don't) and cross-subsystem or cross-subsystem errors (next time the error is "foo the bar: get bar from remote bar repository https://bar.example.com/: get bar: lookup bar source: i/o timeout"). I also obviously try to get my team to do this ;) At my last job, before I joined the team, someone said that stack traces would eliminate the need for error wrapping. They tried it. It didn't. Customers (and support) could never figure out what was going on. But adding a handful of carefully chosen words at each level? Suddenly much easier.

Reading the source code is also a great idea. You'll always pick up some good ideas from other people's code. I learned this the hard way, but also kind of the easy way... at Google, sometimes we had good documentation. Eventually I realized it was often out of date, and so just got in the habit of reading the server code that I was interacting with. Suddenly, everything was much clearer. Why does it return an error in this exact case with this exact set of circumstances? There is a condition for just that case. Set this useless flag and that block is skipped. You'll never see that in the documentation, the exact details behind why something works how it's working exists in one person's mind at one point in time, and the code is the only thing that remembers. So, ask the code.

In both cases, some easy-to-use text searching tool is helpful. I always use rg (and deadgrep inside emacs), but there are many.

dockerd2• 1 year ago

For those unable to open the link due to owner site being hit by Cloudflare limit, here's a link to web archive - https://web.archive.org/web/20250409082704/https://endler.de...

animesh• 1 year ago

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.

fideloper• 1 year ago

That feature exists on cloudflare outside of using CF workers or their own compute stuff. It's part of their WAF featureset.

lapcat3• 1 year ago

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?

semiquaver• 1 year ago

Presumably the author didn’t claim that they were one of them :)

gorjusborg2• 1 year ago

I think it is a fairly common trait of bad programmers to design a system based on completely unrealistic operating conditions (like multiple orders of magnitude of extra traffic).

Now that they've gotten the hug of death they'll probably plan for it next time.

nocman• 1 year ago

presuming to be able to identify "the best programmers"

He was identifying the best programmers he knows (as is obvious from the title). I don't think it is unreasonable at all for even a semi-technical person to be able to do that.

Also, it is highly likely that the author never expected their article to receive a high volume of web traffic, and allocated resources to it with that assumption. That doesn't say a thing about their technical abilities. You could be the best programmer in the world and make an incorrect assumption like that.

ergonaught• 1 year ago

There's some irony, is there not

There is not.

udev40963• 1 year ago

Most developers are terrible at system administration which is quite disappointing and is one of the reason that the author uses Clownflare. Being able to maintain systems is as important as writing code

reverendsteveii3• 1 year ago

I can identify a lion without being able to chase down and kill a gazelle on the hoof

kwertyoowiyop• 1 year ago

The best programmers know that using the free resource of the Internet Archive is the optimal approach for their own effort and cost, versus making their own website scale for a temporary load? (Kidding…I think)

mre5• 1 year ago

Author here. The site was down because I'm on Cloudflare's free plan, which gives me 100k requests/day. I couldn't care less if the site was up for HN, honestly, because traffic costs me money and caches work fine. FWIW, the site was on Github Pages before and it handles previous frontpage traffic fine. So I guess if there were any irony in it, it would be about changing a system that worked perfectly well before. My goal was to play with workers a bit and add some server-side features, which, of course, never materialized. I might migrate back to GH because that's where my other blog, corrode.dev, is and I don't need more than that.

solardev3• 1 year ago

Interesting, I'd never seen a Cloudflare rate limit before. Are they dynamically handling every pageload with an uncached worker? Pages or the regular CDN wouldn't work?

irishloop2• 1 year ago

I think I'm at a stage in my life where I can accept that I am not, nor will I ever be, one of the best programmers

SoftTalker2• 1 year ago

Yeah the older I get the more I see how average I am at almost everything, and how much I don't know about a lot of things.

dielll• 1 year ago

guess your website got Hacker news Hug of death. Getting the error below:

Please check back later Error 1027 This website has been temporarily rate limited

You cannot access this site because the owner has reached their plan limits. Check back later once traffic has gone down.

If you are owner of this website, prevent this from happening again by upgrading your plan on the Cloudflare Workers dashboard.

lqet• 1 year ago

The best programmer and the best Linux wizard I knew had absolutely no background in CS, he stumbled into programming in this 20ies because he had to develop a tool for his Master thesis in a completely unrelated field (agriculture). He then quickly taught himself Java, Python, C++, JavaScript, PHP, and PostgreSQL scripting. By his early 30ies he was the established senior developer at the company I worked back then. He was very strong and quick in non-algorithmic programming tasks, but I also often marveled the naivete with which he approached algorithmic tasks: he would google around for a day, and then find out about standard undergraduate CS algorithms, would then get very excited about them, and quickly implement his own version.

shdh• 1 year ago

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.

BiraIgnacio• 1 year ago

The best programmers I know have traits that tells me they could be the best anything I know. They just really care, the are professionals and want to do their best.

agentultra• 1 year ago

the importance of writing cannot be over-stated.

If you want to solve nasty, hard Heisen-bug problems you need to write. Ask questions, write down the answers. Follow the trail.

Some times you need to be more formal. Learning how to write maths is invaluable. Distributed systems, security, performance at scale… all benefit from a solid understanding of some pretty simple maths.

Writing is thinking! Challenge yourself, examine your thoughts, and learn to write well. It pays off in spades.

1970-01-012• 1 year ago

Don’t Be Afraid To Get Your Hands Dirty..code is just code

All the other topics bring great wisdom, but 'go touch the code' is no longer the responsible thing for senior devs. Junior devs working on minor things, sure. However, senior devs should be rigorously following a process to 'getting their hands dirty'. When senior devs are tinkering with business critical or life critical code, they are usually unaware that the weight of responsibility of everything the software does is now theirs. That's why process exists.

https://en.wikipedia.org/wiki/Software_safety#Process_adhere...

strken• 1 year ago

I think you might be misreading "don't be afraid to get your hands dirty" as "go poking at stuff for trivial reasons without following any proper process" instead of "don't offload parts of your job to other people out of fear".

I imagine that, if an engineer at Pacemaker Incorporated is given a task that's touching an area they're not comfortable working on, the author would suggest that "sorry, talk to Alice" is not a good attitude while "okay, but I'll need to go through some training, do you mind if I reach out to Alice for mentorship?" is.

1970-01-012• 1 year ago

It's ambiguous to the point where 'just get to work' can be seen as the action that the effective senior devs do:

They are not afraid to touch it.

They never say “that’s not for me”

Instead, they just start and learn.

trollbridge• 1 year ago

Great "hug of death" from Cloudflare worker limit exceeded... too bad we can't have the good old days of easily-hosted static text sites for a post like this.

Archive available at: https://archive.ph/0GcBe

noduerme3• 1 year ago

Odd. I've never hosted anything with Cloudflare, but I run some sites through them to mitigate dDos. I'd be pretty bummed if I actually paid them to host something and got borked by their limits the day I hit the HN frontpage.

apwell232• 1 year ago

You built and shipped a critical service for a (larger) org. You wrote a famous tool You contribute to a popular open source tool You wrote a book that is often mentioned

all this will brand you as 'super nerd' and limit your career earning potential unless you are planning to become a principal engineer at google . don't be know for nerdy shit.

esafak2• 1 year ago

A principal engineer at Google lives comfortably. If you don't want to get into the business side of things, what better can you do?

apwell232• 1 year ago

most ppl have near zero chance of getting to principal engineer at google. but getting to mediocre paper pushing managment job is achievable for most .

gwbas1c2• 1 year ago

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.

Why?

Often there's a lot of context in the reference that only makes sense once I've had some hands-on time with whatever the reference is describing.

This is especially the case when learning a new language or API: I'll go through a tutorial / quickstart; "guess" at making a change; and then go back and read the reference with a better understanding of the context.

BTW: This is why I like languages and IDEs that support things like intellisense. It's great to be able to see little bits of documentation show up in my IDE to help me in my "guess" stage of learning.

metalliqaz• 1 year ago

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.

palmotea5• 1 year ago

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

9rx13• 1 year ago

The trouble is that there is a strong correlation between being able to design good interfaces and being able to prepare good documentation. Meaning, where guessing fails, the reference is bound to also fail due to inaccuracies or failing to communicate what you need to know. Which stands to reason as both require concern for how the user perceives the product. That is a skill in its own right.

In practice, so many times I've spun my wheels thinking I just didn't understand the reference only to find out that there was a bug or change that invalidated the reference. Nowadays, if I must interface with a product built buy someone who doesn't understand the user, I'll go straight to the source code if guessing fails or resort to probing the system if code isn't available. Not only is it faster, but you'll gain a better understanding of what is going on than some stumbling attempt to describe it in natural language will ever be able to communicate.

ctxc2• 1 year ago

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

socksy• 1 year ago

I think my preferred LLM usage style these days is to try something on my own, and then get the LLM to critique what I did. I think it's both better for learning (just like learning natural languages, it's better for learning to make a mistake and be corrected than it is to look up the right answer each time), and also I think the stakes are lower since you're not relying on the LLM to not hallucinate. You can also learn some new threads to pull on that you can investigate on your own etc

perrygeo• 1 year ago

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.

d0mine3• 1 year ago

Formulating your assumptions before you run code and check saves you from rationalizing after the fact whatever behavior you happen to observe. Invalid predictions help improve understanding, learn.

Winsaucerer• 1 year ago

Interesting, I had a similar approach while studying philosophy. I much prefer to think and write than read, so I'd often think through a philosophical problem first, and then read others on the topic. I'd find that this order helped me grasp a topic well.

I don't know if I do the same thing with programming.

iamwpj• 1 year ago

I agree with this. I have to learn a lot about a new tool before I can effectively use the docs (beyond the getting started). If it's area where I'm already familiar, then sometimes I can jump in pretty easily, but often fumbling is a key step.

mycall• 1 year ago

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.

d0mine3• 1 year ago

Actually, your approach “test yourself first, then learn” is better for learning compared with just learning first according to research.

alphazard• 1 year ago

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.

wging• 1 year ago

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.

asdfman123• 1 year ago

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.

gwbas1c2• 1 year ago

Honestly, some references are very confusing. Sometimes they "say everything," but don't give enough context to really understand.

That's why examples are also critical.

notorandit• 1 year ago

I think I met a few. Two or three in 40+ years. They simply can figure out the entire thing at least from high level view. Often also to the finest details. I need to carefully read the blueprints, the docs, some example code. Then I can start coding

t312227• 1 year ago

hello,

there is a version of this article already available at archive.org:

* https://archive.ph/0GcBe

due to cloudflares:

"Error 1027

This website has been temporarily rate limited

..."

just my 0.02€

BubbleRings• 1 year ago

In job interviews, I pushed candidates hard to at least say “I don’t know” once.

Yes yes! Although, in an interview, there is not always an easy way to separate out people that can’t say “I don’t know” during day to day work, from those that can. But what a difference. A strong need to hide a lack of omniscience is wildly irritating to me, in co-workers and people in general. It causes such problems!

SoftTalker2• 1 year ago

Ha. “I Don’t Know” is probably my most common answer to questions at work, often followed up immediately with "What have you tried" or "What has changed"

Imustaskforhelp• 1 year ago

Rate limited. Looks like cloudflare wasn't enough which is crazy since it has 100k requests

__mharrison__2• 1 year ago

I would add filing bugs as "going to the source". I've worked with many developers who have spent hours trying random combinations of keystrokes before asking for help from a colleague, let alone filing a bug with a project.

kittikitti• 1 year ago

I can't access it because of CloudFlare limits. I didn't even know CloudFlare could be a bottleneck or effectively take your site as hostage until you pay.

nottorp4• 1 year ago

To know a tool well, you have to know:
its history: who created it? Why? To solve which problem?
its present: who maintains it? Where do they work? On what?

I'm not clear on that. Why does the person matter? So you can check if their political views align with those of your tribe, or what?

But then, I never read the user names on HN comments I reply to, and I guess the article author does. Maybe even keeps files on them...

mre5• 1 year ago

The creator matters because they are the key to understand the reason was created in the first place and under which circumstances. You get to learn about their other work, which might also be relevant to you, the limitations of the tool based on the problem is was designed to solve, and the broader ecosystem at the time of creation. For example, if you're a frontend developer it helps to know who Brendan Eich is, where he worked when he invented JavaScript, and what Netscape wanted to achieve with it. You would even learn a bit about the name of the language.

Similarly, it helps to know who maintains the code you depend on. Is there even a maintainer? What is the project roadmap? Is the tool backed by a company or otherwise funded? What is the company's mission? Without those details, there is a supply chain risk, which could lead to potential vulnerabilies or future technical debt.

nottorp4• 1 year ago

it helps to know who Brendan Eich is, where he worked when he invented JavaScript, and what Netscape wanted to achieve with it

That may have been relevant 15 years ago, whatever Eich wanted to do with JS, it's been out of his hands for a long time.

And you could also do the reverse and form an opinion about him based on JS :) Might not be very flattering.

koinedad• 1 year ago

Lots of good stuff in here I wholly agree with. The simplest one is the “read the reference” one. This is a super power if you can get into the habit of it.

boerseth• 1 year ago

I am wondering how universally useful these qualities are across disciplines. It might be interesting to consider each of the categories in a totally different field. Take dancing for example. I am very fond of Argentine tango, and will attempt to consider the article in light of it.

## Read the reference

It is very difficult to dance from written instuctions, but I think one hugely underappreciated resource is watching very intently great instructors dance basic movements. I did this in my early days, because it is very enjoyable entertainment when you apreciate this dance, and it was I think a large part of why I progressed rather quickly.

I could go on about this point, but I think there is a similar thing going on with humans and our mirror neurons when we watch others do something, to how we acquire spoken languages, and the recent wave of input-based language learning movements.

Another way to interpret this point might be to know the history of the dance, of Argentina, the broader dance communities and movements across the world, and the culture in general. The main advantage to this I think is to contextualize a lot of what you learn, and that the dancer becomes more immersed in the activity.

## Know your tools really well

Dancing involves some tools external to the dancer, like clothing and shoes, the dance floor of course, perhaps talcum powder to reduce friction, and most importantly the music.

While there is considerable advantage to be gained from wearing an outfit suited for dancing, there's a quick and hard cutoff as to how much knowing more about these things improve your dance. The same applies to the floor surface and so on.

But of these "tools", I think the biggest gain is found in familiarizing oneself with the music. Both gaining intuition about the structure of songs, melodies, and rhythms, but also gaining deeper insight and access to the emotions at play. Dancing is an opportunity to interpret all of these aspects of the song, and being familiar with the music, the medium that connects one with ones partner and also the thing you are trying to represent through movement, goes hand in hand with being able to execute the movements of the dance at all.

All of the points of the article apply here: the history of the music inform you of what the tango is all about, and of the different sounds and movements that are available to us today; the present, in the sense of what music is currently popular, and played live; limitations, in the sense of what different styles of tango music work with what sorts of movements and feelings; finally, the ecosystem is like a summary of all of the above, and something that people discuss at length in every milonga, like which orchestra they prefer, or which contemporary groups they like.

However, one thing that I think qualifies as a tool, although somewhat subtly, is the dancer's own body. I have not pursued this avenue very far yet, and am thrilled to realize that this is something I really ought to do. I know only a little bit about human anatomy, after strength training years ago. And as for my own body specifically, perhaps something like yoga, pilates, or calisthenics would be valuable.

## Read the error message / Break down problems

While there are no error messages in dancing, you definitiely feel when something isn't quite working out. If you're in a class and are trying to learn a step, it is crucial to be able to be critical of your own performance, and look for faults or inconsistencies.

Maybe a step feels a little off, like there's something awkward going on between you and your partner.

One thing I have noticed is that, if you are trying to go over a sequence of steps A-B-C-D, and something isn't quite working out at point C of the sequence, the soure of the error is usually actually somewhere in either point B, or perhaps already at point A.

This might remind some of looking at a stack trace of an error, and trying to figure out at which turn things went sideways. The problem is frequently not located exactly at the point where the error was actually raised.

## Don't be afraid to get your hands dirty

One of the dangers for any learner is calcifying into bad habits that were adopted at an early stage of learning. In order to break out of these, you have to be willing to abandon old guardrails, be uncomfortable over again, and to learn something over. This might be analogous to refactoring some kind of broken legacy code.

Growth is also possible through experimentation, abandoning old patterns in search of something new and potentially interesting. This also requires courage, and feels a lot like getting ones hands dirty, and applies to both programming and dancing and probably many other things alike.

## Always help others / Write / Status doesn't matter / Build a reputation

Since dancing is a communal activity, it is not so vital to be writing in order to be heard. But I still think that communication in this space is hugely valuable.

From what I have seen, any healthy dance community has great communication between the more experienced dancers and the less experienced ones. Unhealthy ones are often referred to as snobbish, The alternative, where there is a strong divide and exclusion from the top downward, are often referred to as snobbish, and I would characterize that as unhealthy. That sort of a scene will gradually wane from the high barrier of entry, and will wither and die if not already sufficiently large.

## Never stop learning / Have patience

Any tango dancer will tell you, no matter how experienced or accomplished they may be, that one never stops learning this dance. Even decades into ones journey, it is extremely common to hear dancers say that they're still working on their walk - which also happens to be more or less the very first thing you learn in your very first class.

## Never blame the computer

In a dance that famously requires two people, it is very easy for a lot of people to blame one's partner when something goes wrong. I think it is much more valuable to take the opposite approach, and always look to what you can improve in your own dancing, whether you are a leader or a follower, long before attempting to throwing accusations and corrections at your partner.

There may of course eventually come a breaking point, at which you want to raise some questions and explore together for a solution. But to immediately correct your partner, before they've even had a chance to correct themselves, is never a good approach in my opinion.

## Don't guess

I think this one is hard to stick to rigidly when learning how to dance. If you want to be completely sure of a movement before you try it out, you'll forever remain paralyzed. We all have to do some guessing in the beginning, trusting that our muscles move us through space in about the right way as the dance is supposed to be performed.

However, these guesses that we make are frequently wrong, and result in incorrect technique and bad habits which must be weeded out and corrected before they calcify too much.

So while I think not guessing at all is impossible, I think we really should not underestimate the value of any means available to us for correcting incorrect guesses that we have made and accumulated. These include someone more experienced than us that we trust, or private lessons from tutors who know what they're talking about.

## Keep it simple

It is funny, but this exact piece of advice is also so very frequently heard in tango classes. As you progress and learn and acquire vocabulary in tango, speaking now mainly about leaders, it is very easy to want to use it all and throw every shiny new step and sequence you know at the poor follower that you've convinced to join you on the floor.

Many also are nervous and afraid of the silence that comes with not moving all the time, and keep leading step on every beat in order to never make it seem like they're running out of ideas.

But in actual fact, it can be wildly better to relax, and do simple steps well, with tasteful pauses aligned with the music, than to hurriedly toss around every step that you know.

## My own final thoughts

Despite the fact that code is run on computers, and dance is performed by humans, I think this analogy holds really well. If you think about it, dancers are just meat robots performing fuzzy instructions written to their brain by themselves and dance instructors, or whatever they've acquired by watching others dance. You could summarize as follows the mapping in this analogy:

    Spec            <-> The goal that the dance-student is aiming for
    Code            <-> Steps that have been acquired by a dancer (maybe imperfect)
    Runtime         <-> A night out on the dance floor
    Error           <-> Improper technique
    Programming     <-> Learning and improving as a dancer
    Programmer      <-> Learner/teacher

I think an interesting insight here is that both the learner and the teacher play a role as the "programmer". A learner that is totally passive and lacking in introspective ability will perhaps not learn as quickly. So, the points of the article are applicable to both of these parties.

For any autodidacts out there, that last part is good motivation to reflect some more on the points of this blog post.

curseofcasandra• 1 year ago

Read the Reference
don’t ask the LLM

To be fair, you can use LLMs to get to the reference. Gemini is pretty good at that. ie. You can ask it how to do such-and-such in Python and to provide a link to the official documentation.

1vuio0pswjnm7• 1 year ago

"Most developers blame the software, other people, their dog, or the weather for flaky, seemingly "random" bugs."

"Language" is omitted from this list; the author is "Rust consultant".

This could be a coincidence.

nayuki• 1 year ago

Excellent article that resonates with me a lot.

Read the Reference
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.e. read the Apache Webserver Documentation, the Python Standard Library, or the TOML spec.
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.

This is underrated. When I was a beginner at programming, I read books like "Sams Teach Yourself Java in 21 Days" and various O'Reilly books such as CSS. But over time, I drifted over to reading online documentation, and mostly from primary sources such as documentation that comes with the language. For example, I read Sun/Oracle's Javadoc web pages and Python's standard library web pages instead of any third-party summary of it; I read the Java Language Specification as well as new improvements in JSR/JEP pages; I read MDN web pages instead of books (I'm aware of W3C spec pages but they are too dense for daily use; I only consult them for rare edge cases and ambiguity). I learned Rust from first-party tutorials ( https://doc.rust-lang.org/book/ ) and not someone else's rehash; the first-party material is excellent and hard to beat.

This doesn't apply to everything, though. I don't think there is a good first-party tutorial or reference for C and C++. I still don't know what the best tutorials are out there, but my favorite reference is https://en.cppreference.com/w/ , which is clearly a third party.

Also, as I get more experienced over the years, I drift into reading the source code of the applications and libraries that I use, and sometimes read mailing lists / issues / pull requests to see or participate in the software development process.

An expert goes in (after reading the reference!) and sits down to write a config for the tool of which they understand every single line and can explain it to a colleague. That leaves no room for doubt!

I work under this philosophy, but it can be extremely hard. I still have trouble understanding what every line of a Maven XML file (Java build tool) does. Ant (for Java) was similarly opaque. I've seen way too many tutorials that have an ethos of "just copy this example code and modify a few bits without questioning the rest, trust us about it".

Read The Error Message

The failure of the user to read computer error messages is a source of IT jokes since forever ago.

Most awesome engineers are well-spoken and happy to share knowledge. The best have some outlet for their thoughts: blogs, talks, open source, or a combination of those.

Check. I have a website and repositories of open-source code authored by me.

Never Stop Learning; Build a Reputation; Don’t Be Afraid to Say “I Don’t Know”

Check to all.

Clever engineers write clever code. Exceptional engineers write simple code.

This is something I always strive to do - make the code as simple as possible while still solving the problem (such as functional and performance requirements). I sometimes find myself de-optimizing code to sacrifice a bit of speed in exchange for shorter code and better human comprehension.

paines• 1 year ago

Read The Error Message Yes thats right for most things, unless it's your beloved GNU C++ compiler. You might just have forgotten a const in your template method and it will give you 5 pages of hell for that.

progforlyfe• 1 year ago

Read The Error Message

100% !!! I get so annoyed when engineers get an error message and just copy/paste in Slack saying "I got this error: xyz" and nothing else... No inspection of the error, no reading docs or at least putting it in a search engine. No "This is what I tried so far...". Just a brand-dead copy/paste and shoving it someone else's plate to perform all those steps.

jleyank• 1 year ago

A quick scan didn’t find two rules I try to keep in mind:

- know what you don’t know.

- don’t be an asshole.

If you’re known, and known as somebody you want on the team life will be easier. Sorry if I’m repeating others, but life tends to be a team sport and you should play well.

microtherion• 1 year ago

I'm a big fan of "reading the reference", but documentation often does not cater to that use case anymore. Instead of curling up with an authoritative book (like the Perl, Python, C, or C++ books, the dtrace book, or the O'Reilly X11 or BSD reference manuals), I get to, in the better case, click around a 1000 page web site, or, in the worse case, watch 50 videos covering 10% of the functionality.

Fruitmaniac• 1 year ago

I need to do more of these

Tinos• 1 year ago

Fantastic post - you've made me feel a lot better about admitting that I didn't know something during my interview yesterday!

Really well written and insightful.

The best programmers I know

Related Stories