11 ms·

The best programmers I know

• DeathArrow 2y 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 2y 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 2y 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.
      • DeathArrow 2y ago
        I think this is what the author meant by dividing complex problems in sub problems that are easier to tackle.
  • rowanG077 2y 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 2y 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.
  • wiseowise 2y ago
    For others: if company mostly consists of devs, or God forbid management, like that - run asap and never look back.
  • mrweasel 2y 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.
  • taneq 2y 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 2y 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 2y 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.
• ozim 2y 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.
  • deleted 2y ago
    [deleted]
  • bluetomcat 2y 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 2y 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 2y 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 2y ago
    Reading documentation cover to cover for tools you use a lot is a very worthwhile investment in my opinion. Junior dev or not.
• continuational 2y ago
  I think this "good devs don't complain" mentality risks real issues being overlooked and left unaddressed.
  • wiseowise 2y ago
    Absolutely. I think it is incomplete: good devs never complain… they just give their 2 weeks notice and find a better place.
    • whstl 2y 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_ 2y 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.
      • eptcyka 2y ago
        Exactly, instead of just assuming that a component just does that, they focus on understand fixing underlying problems. Boils my blood when people with years of experience just allow bullshit issues to stew and just blame the platform/device/user/library.
  • Manfred 2y 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
• rethab 2y 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"..
  • taneq 2y 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? :)
  • bluetomcat 2y 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 2y 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_ 2y 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.
  • 2y ago
• roenxi 2y 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 2y ago
  I agree with all this, except that lets keep the number of thought leaders to a minimum.
• djmips 2y ago
  Good generic advice except for 'don't blame the computer' ;-)
• nikolayasdf123 2y ago
  I expected to see a list lol
• blackbrokkoli 2y 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 2y 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).
    • davedx 2y ago
      Read everything DHH wrote, he has lots of insights on this. Scroll down to his books: https://dhh.dk https://dhh.dk I found Lean Startup to be very good too.
  • nvarsj 2y 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.
    • blackbrokkoli 2y 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?
• Cthulhu_ 2y 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 2y 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 2y 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.
  • epolanski 2y 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.
• deleted 2y ago
  [deleted]
• 0xEF 2y 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.
  • fragmede 2y 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 2y 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 2y ago
  I bet few of them get kids early (joking).
• kshri24 2y 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.
  • deleted 2y ago
    [deleted]
  • lacn 2y 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.
  • ZeroTalent 2y 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.
• epolanski 2y 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.
  • irishloop 2y ago
    Do you think there's a way to train focus?
    • udev4096 2y 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
    • deleted 2y ago
      [deleted]
    • criddell 2y ago
      You can lose your concentration skills by not using them. I would expect the reverse is true as well.
    • epolanski 2y 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 2y ago
      Can't tell if you are being sarcastic, but yes of course there is.
    • rhubarbtree 2y ago
• high_na_euv 2y ago
  >You cannot access this site because the owner has reached their plan limits. Check back later once traffic has gone down. Rofl?
• gowthamgts12 2y 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. ```
  • dockerd 2y ago
    https://web.archive.org/web/20250409082704/https://endler.dev/2025/best-programmers/ https://web.archive.org/web/20250409082704/https://endler.de...
• notrealyme123 2y ago
  https://web.archive.org/web/20250409082704/https://endler.dev/2025/best-programmers/ https://web.archive.org/web/20250409082704/https://endler.de... Otherwise rate limited
  • agumonkey 2y ago
    secondary source: https://archive.is/0GcBe https://archive.is/0GcBe
  • h1fra 2y ago
    wondering how can a static blog can be rate limited :|
    • mr90210 2y ago
      Traffic. Huge loads of it.
      • vanschelven 2y ago
        I'm not sure what "huge loads" means in this context though. Remember when nginx was written in 2002 to solve the C10K problem?
      • PeterStuer 2y ago
        How would your static text only blog generate "huge loads" on a CDN?
      • ahofmann 2y ago
        What do you mean? What is huge to you? For me a static blog on a small vps would start to crumble at around 30 to 150 requests per second. This number is broad because the are a lot of moving parts even in this scope. This results in 2.5 million to almost 13 million page views a day. To reach numbers like that you need to get reeeeaally popular. With some planning a static website can be served billions of times a day before saturating the network stack. So what are you talking about?
    • svantana 2y ago
• barlog 2y ago
  1027, so sorry
• dilawar 2y 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 2y 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 2y 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.
• adastrapa 2y 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/best-programmers/index.md https://github.com/mre/endler.dev/blob/master/content/2025/b...
• tsak 2y 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 2y 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 2y 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.
  • mre 2y 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__2 2y 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.
  • foobahify 2y ago
    Logs, tests, debugging, ask questions, build a mental model, test that mental model. The more experience I get the less I guess.
    • hk__2 2y ago
      Right, I misunderstood the meaning of "guess" here.
      • foobahify 2y ago
        Yes. You weren't wrong. You need to first guess in order to not guess :)
  • blueflow 2y ago
    I would consider "exploring and ruling out possible causes" a systematic approach, not guessing.
  • nhinck3 2y 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 2y 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 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.
• deleted 2y ago
  [deleted]
• bob1029 2y 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 2y 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 2y 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.
• fluffet 2y 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 2y 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/ 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.
• dockerd 2y 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.dev/2025/best-programmers/ https://web.archive.org/web/20250409082704/https://endler.de...
  • animesh 2y 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 2y ago
      That feature exists on cloudflare outside of using CF workers or their own compute stuff. It's part of their WAF featureset.
      • Sxubas 2y ago
        I don't think it is WAF related, it clearly says: > If you are owner of this website, prevent this from happening again by upgrading your plan on the Cloudflare Workers dashboard. Looking into it, my hypothesis is that the owners page is SSRd using cloudflare workers and they reached the daily limits.
        • ryandrake 2y ago
          Looking at the archive.org mirror, the content is 2000 words and a few images. It constantly astounds me how much "compute" people seem to need to serve 10K of text in 50K of HTML.
          • jasonjmcghee 2y ago
            If your business is selling server side compute to render front end web apps on the back end, you try to convince an entire generation that it's needed. And a few companies have been very successful in this effort.
• solardev 2y 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?
• doganrabia 2y ago
  [flagged]
• irishloop 2y 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
  • SoftTalker 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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-01 2y 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_adherence_and_assurance https://en.wikipedia.org/wiki/Software_safety#Process_adhere...
  • strken 2y 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-01 2y 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.
      • wat10000 2y ago
        I recently spent a couple of days tracking down a problem that one of my coworkers, who built the subsystem where the bug was lurking, probably could have figured out in an hour or two at most. Why didn’t I hand it off? Because I need to know how this subsystem works. It’s important and quite complicated and this is not going to be the last bug we have, or the last change it needs. It’s part of what I work on so I should understand it. The payoff wasn’t just fixing the bug, it was learning enough to know how to fix it.
• trollbridge 2y 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 https://archive.ph/0GcBe
  • noduerme 2y 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.
• apwell23 2y 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.
  • esafak 2y 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?
    • apwell23 2y 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 .
• gwbas1c 2y 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 2y 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.
  • palmotea 2y 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.
    • 9rx 2y 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.
• notorandit 2y 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
• Imustaskforhelp 2y ago
  Rate limited. Looks like cloudflare wasn't enough which is crazy since it has 100k requests
• t312227 2y ago
  hello, there is a version of this article already available at archive.org: * https://archive.ph/0GcBe https://archive.ph/0GcBe due to cloudflares: "Error 1027 This website has been temporarily rate limited ..." just my 0.02€
• BubbleRings 2y 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!
  • SoftTalker 2y 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"
• __mharrison__ 2y 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.
• wakasaka02 2y ago
  [flagged]
• kittikitti 2y 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.
• nottorp 2y 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...
  • mre 2y 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.
    • nottorp 2y 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.
      • mre 2y ago
        It's true that he no longer steers the project, but his first version shaped the internet as we use it today. At least one could how a modern version of a similar idea would look like. What has changed since then? Which issues should be fixed? You might end up with Deno or perhaps WebAssembly or something else entirely, but it definitely helps to know the people behind the tools we use every day.
• koinedad 2y 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 2y 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 2y 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 2y 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 2y 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/ 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/ 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 2y 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 2y 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 2y 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.
• khana 2y ago
  [dead]
• microtherion 2y 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 2y ago
  I need to do more of these
• Tinos 2y 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.