The best programmers I know
> 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.
> "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!
> 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.
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.
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...
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.
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.
https://web.archive.org/web/20250409082704/https://endler.de...
Otherwise rate limited
> 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.
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.
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"..
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.
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.
I think this "good devs don't complain" mentality risks real issues being overlooked and left unaddressed.
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
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.
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.
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
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.
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.
> 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!
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...
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.
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
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
>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...
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. ```
"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.
> 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.
> 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.
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.
> 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)
> 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...
> 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.
> 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.
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.
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.
> 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.
I agree with all this, except that lets keep the number of thought leaders to a minimum.
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.
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.
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.
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?
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.
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.
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.
Rate limited. Looks like cloudflare wasn't enough which is crazy since it has 100k requests
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.
I need to do more of these
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.
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
For any autodidacts out there, that last part is good motivation to reflect some more on the points of this blog post.
Good generic advice except for 'don't blame the computer' ;-)
I bet few of them get kids early (joking).
hello,
there is a version of this article already available at archive.org:
due to cloudflares:
"Error 1027
This website has been temporarily rate limited
..."
just my 0.02€
1027, so sorry
>You cannot access this site because the owner has reached their plan limits. Check back later once traffic has gone down.
Rofl?
I expected to see a list lol
[dead]
[flagged]
[flagged]
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?
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.