22 ms·

Reflections on 10k Hours of Programming

421 points by herbertl 5y ago

rckrd 5y ago
Author here, thanks for posting. Here's some more color on the reflection on comments, straight from the Linux Kernel documentation that capture my intention much better: "Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it’s much better to write the code so that the working is obvious, and it’s a waste of time to explain badly written code. Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to chapter 6 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it."[0] [0] https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
- efsavage 5y ago
  The WHY is also very useful in comments, especially in business/UI/glue code where special cases abound.
  - klysm 5y ago
    I would say the why might be more important than the what a lot of the time
  - david-gpu 5y ago
    Came here to comment along those lines. The WHY often will be elaborate enough that it deserves a design document that includes things like: who is the owner of those requisites, what is the rationale behind them, who are the stakehilders who signed off, what interactions it has other components, what alternative designs were considered, etc.
  - dirkt 5y ago
    This. And in particular if there are multiple ways to do it, and you had to choose a particular way for a reason. Comments should explain the decision process (if one was necessary) that lead to this variant. Because if there's no comment explaining it, the next developer looking at it will say "oh, but it's much simpler if I just do it that way", and will run into trouble because he didn't realize the pitfalls.
- rgrmrts 5y ago
  Interesting reading about RuneScape in your post. I got into programming because of RuneScape and writing bots! Great memories. I enjoyed reading this post. Cheers!
  - rckrd 5y ago
    Thanks! Likewise. Truly a great sandbox for budding programmers.
    - mastersummoner 5y ago
      I got into programming at 14 because of writing scripts in Gemstone, a text based MMOMUD. Didn't even realize what I was doing was programming until college though...
      - calrizien 5y ago
        Gemstone! That game changed everything for me
  - AQuantized 5y ago
    Writing increasingly sophisticated bots and trying to figure out what exactly would earn you a ban was my own first practical experience with coding. I mostly managed to dodge bans on my most used accounts at the time, but interestingly when I checked back a year or two ago the majority had been permanently suspended. I wonder if they have some method of retroactively determining if someone was botting?
- Retric 5y ago
  The exception to the WHAT/HOW divide is working around a 3rd party bug. Documenting workarounds can help prevent reintroducing the same bug when someone edits or copies the code. This can be especially helpful if the 3rd party bug gets fixed in such a way that your workaround now fails.
- ajuc 5y ago
  > NEVER try to explain HOW your code works in a comment Never is a strong word, sometimes the algorithm is just inherently complex and it's worth it to explain what you are doing. Why is much more important, but it's also partially solved automatically by git blame and adding the task number to each commit message (and writing good commit messages which IMHO is more important than writing good comments). Each line of your code has commit message associated with it whether you care about it or not - make it useful.
  - bccdee 5y ago
    Yeah algorithms in particular are where I'm hesitant to say "never explain how your code works." They can be dense, deeply-nested, and hard to break down into semantically-meaningful variables and function names. Sometimes it's good to explain what's going on there.
    - Salgat 5y ago
      That's what people don't understand. We don't think in code, we have a translation layer from human language/thought that we think through when parsing a programming language. As long as the comments are kept accurate, they can greatly improve your ability to parse through a block of complex code, which is crucial when you're trying to hotfix an issue. It also gives newer programmers to the codebase a chance to help understand what that block of code is doing beyond it just being some blackbox with an input and output.
  - cjohansson 5y ago
    Yeah the how is important when auditing the correctness of code. I would say "Never listen to an advice about never doing something, there is always a case were breaking the rules is good"
    - deleted 5y ago
      [deleted]
  - vhakulinen 5y ago
    From the linked post: > Know when to break the rules.
- franciscop 5y ago
  Small typo, it's "Malcolm Gladwell in Outliers" not "Outsiders", I particularly noted it because I learned the word "outliers" in English thanks to that book.
  - rckrd 5y ago
    Thanks, fixed!
- juancb 5y ago
  What's your take on the difference between explaining how code works and describing what it does? I only ask because of bits like the TCP rate estimator sometimes have step by step comments that might be interpreted as explaining how the code is doing something. For example take the app limited detection function: https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_rate.c#L182-L197 https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_r...
  - mastersummoner 5y ago
    My take is that step by step commented explanations make sense when it's something either extremely complicated or making use of a system or tech that's not widely known. Otherwise, clearer code, smaller methods and better variable/method names are the way to go imo.
- mastersummoner 5y ago
  Another reasonable exception is referencing external sources - whether it's a specific library you borrowed code from, a piece of documentation needed to better understand what's going on, or a reference to a SO post explaining some weird workaround you've implemented.
- baconforce 5y ago
  I've seen this interpreted by smart engineers in a counter-productive way, in that they believe their code is so good that none of it ever needs any comments and hence they never write them despite the fact that their code isn't all that clear. It's more hubris than anything. Otherwise, there are many techniques you can use to make the code self-explanatory. I've taken a comment before and restructured the code to literally read like the comment.
- Clubber 5y ago
  The best comments are about intent. I can read the code and tell you what it does, but I have no idea if that's what it's supposed to do without knowing the intent.
- baby 5y ago
  > try to avoid putting comments inside a function body This makes me sad. Think about others who will have to reverse engineer your code. Not every functionality should be split into a function, unless you want to add 10 layers of abstraction and misdirection.
- dnautics 5y ago
  I think sometimes you want to put why in a comment. Just today I wrote a two paragraph comment (usually I don't write many comments at all) that describe the business need for why this the code is necessary (in my case, connecting to a 3rd party data source that overshares, describing the nature of the oversharing, outlining the -- very complex -- steps in the pruning algorithm, and noting that there are corner cases we might miss and also noting that we shouldn't care -- a handful of bad apples in a machine learning algo will probably disappear in the wash).
  - lugged 5y ago
    Yup, I rarely ask "what's this code do" or "how does this code do that". But "why the fuck" is a daily occurrence. Self documenting code explains how and what. If you need a comment to explain how and what its a code smell. Sometimes it's ok but ideally it should be rare. I try not to overcomment but when I write code that looks confusing or clever I try to explain why I've done it that way. If I'm optimising, I'll explain why. If I'm making an assumption about something related but elsehwere I'll explain that. If I'm leveraging some context that isn't explicit, I'll explain that. ... Also, type of code matters, glue code rarely needs exhaustive comments. Library code often gets line by line commentary so when someone comes in to change something for their use case they have a clear understanding of what they're really changing, and who and what might break because of their change. I notice library code tests often get more comments explaining what and why I'm adding an assertion. Glue code test rarely needs comments in tests.
- jbverschoor 5y ago
  Don’t agree. Longer pieces of code are way easier to reason about. Deep function nesting, which seems clean is very confusing mentally, and also difficult to describe in terms of function name. Explain *why* you’re doing something a certain way. This also includes a little bit of how and what. Other than that, just make sure your business terms are reflected in the code, or at least have a proper definition of things, which you can easily reason about.
  - cudgy 5y ago
    Agreed. When looking at complex code, it can be helpful to expand the functions inline to be able to view all of it in a single screen flow. Switching between too many files and functions sometimes creates friction, making it more difficult. However, when writing the code if a section of code is repeated more than 2 times, it should be considered to break it out into a separate function with a useful name.
    - fiddlerwoaroof 5y ago
      Unless you’re doing something like performance analysis, I think needing to peek into the definition of a function to understand a piece of code is a smell: it indicates that the function is only abbreviating and not providing an abstraction.
      - dragonsngoblins 5y ago
        Well a lot of the time when you are looking at something you are trying to diagnose some problem or another, which means you want to be 100% sure of what something is doing. Even if the function provides a good abstraction you might still want to make sure that it is doing exactly what it says on the tin because you are desk checking some weird behaviour and you want to make sure each step is acting correctly
        fiddlerwoaroof 5y ago
        Agreed, but that means you verified that the use site was correct and are now examining whether the abstractions it depends on were implemented correctly. My point is just that you shouldn’t normally have to keep both sides of a call site in mind at once.
- 908B64B197 5y ago
  > tell WHAT your code does, not HOW And also Why. I personally like an executive summary of the code, ie, I just got to this file, what am-I looking at.
- hutzlibu 5y ago
  I prefer over-commenting a lot, over under-commenting. The only harm is, when you miss the important bits over too much blabla, or when you forget to update comments. There are not many worse things, than wrong documentation/comments. "you want your comments to tell WHAT your code does, not HOW" but I agree very much to this.
- ransom1538 5y ago
  "Comments are good, but there is also a danger of over-commenting." IMHO The only way to tell if you are able to comment well is to do this: Work on some project - then in 2 years come back to that project and add a feature to it. You will learn real quick how good your comments are. Spoiler alert: You wont care about "how" - you will want to know "why".
- hinkley 5y ago
  It’s an old assertion of the Refactoring community that a commented block in the middle of a function is a separate function trying to break free. If the code is interesting in its own right, move it. That also extends to how. If the algorithm is interesting or complex enough you should move it as well, as the point of the host function is not to show how clever you are, but to accomplish a task. Empirically I’ve found that I get much less pushback on algorithmic tweaks when I isolate them to a separate function. The reader doesn’t have to include them in their local reasoning, and I suspect but cannot prove that they tell themselves that they can always revert that code cleanly, so let’s just leave it be for now and see what happens.
- tpoacher 5y ago
  Define "comments". Like many arguments, disagreements below are mostly not disagreements about facts but disagreements of definitions at heart, only masquerading as disagreements about facts. Beyond a trivializing definition of "whatever follows a #", each time the word "comments" appears in the discussion below, it seems to actually refer to something entirely different from one person to the next.
moonchrome 5y ago
>In many cases, what you're working on doesn't have an answer on the internet. >That usually means the problem is hard or important, or both. Really ? If a problem is important someone likely already tackled it. I mean 15 years ago this was less likely, but these days there's so much work in the open and search is very good, when I find there aren't any references for my problem it usually means I misinterpreted the problem or I'm doing something very niche.
- rckrd 5y ago
  You're implying the reverse causation. The reflection is "can't find answer" -> "might be hard", not "might be hard" -> "can't find answer". Surely there is copius documentation on a significant number of hard problems.
- tonymet 5y ago
  When you get above the 40th percentile in problem difficulty or novelty, there are no answers or even discussions on the internet.
- mrweasel 5y ago
  I feel like your argument is a little along the line of: “ Everything that can be Invented has been Invented”
  - moonchrome 5y ago
    No, just that CS/programming is mature enough that important stuff has already been explored so if I'm hitting a dead end either I'm doing something very specific that hasn't been investigated yet or (more likely) I'm not framing the problem correctly.
skohan 5y ago
> Syntactic sugar is usually bad. I disagree with this one. It can be bad, but if it helps syntax get out of the way to reveal the intent of your code, I think it's pretty good
- rckrd 5y ago
  Yes, maybe usually was too strong of a word - I think this varies with the language. In Go and JavaScript (where I mostly work), it's usually not that useful. In languages like C# and Java, I've found syntactic sugar to be very useful (e.g. lambda notion)
  - silviot 5y ago
    I'm under the impression that, in Javascript, > async/await is syntactic sugar on top of the promises and provides a way to handle the asynchronous tasks in a synchronous manner. as is stated on this website I just found with one second of googling to support my thesis: https://dmitripavlutin.com/javascript-async-await/ https://dmitripavlutin.com/javascript-async-await/ If that is true, I believe it's incredibly useful syntactic sugar.
    - rckrd 5y ago
      Fair enough, there are clearly lots of useful syntactic shortcuts. I'm referring to things like prefix/postfix increment/decrement, object spreading vs. object rest, and ternary expressions. I'd avoid cases where extending the language is done in a non-obvious and ambiguous way.
      - dfee 5y ago
        I love me some spread operators and ternary expressions. …mumbles something about prying those from my cold dead hands.
        skohan 5y ago
        Yeah I think there's a time and a place for ternaries, but when used correctly they're just so concise. Like if you have super long expressions in your ternaries, or you have a bunch of nested/chained ternaries it can be hard to parse, but in a lot of cases it's so nice to get something onto one line instead of needing an if/else
devwastaken 5y ago
I appreciate these, but in my experience it's not that relevant. The harder problems in programming are more of knowing your ecosystem. Knowing the design patterns necessary to create well meaning, understandable code in the first place. This is especially cumbersome when working on projects with complex data patterns. For example, working with GUI applications and C/+ can make your code a big pile of garbage really quickly because representing your data in something like an ORM is not standard, you can't do the many tricks like getters/setters in C/+, but you can in Python, or C#, etc. The benefits of VM languages are, in my opinion, not appreciated enough. In my opinion knowing the right tools for the job is far more important than how you comment your code, how you name your variables, or anything else. I wish there were more posts where people impliment an application with multiple tool sets and compare them, give insight into what some things are good for and not. "Tool Benchmarking" might be a good term for it.
- rckrd 5y ago
  Lucky for you #6 is "Have a wide variety of tools and know which ones to use for the job." :)
- nerdponx 5y ago
  > I wish there were more posts where people impliment an application with multiple tool sets and compare them, give insight into what some things are good for and not. "Tool Benchmarking" might be a good term for it. I recently started working on a project like this. It's hard work. Building a complete tool in one language takes a long time. Not to mention 2, or 5. Moreover, many (most?) programmers are only "fluent" in one or two languages. Even if you "know" a language, you might not know the full build toolchain, or you might not know common idioms, etc. Most people probably want to work on building new/interesting/fun stuff, not reimplementing the same toy program in several different languages.
  - rckrd 5y ago
    I've actually found that knowledge diffusion between different languages and different types of developers can be significant - e.g., game developers work much differently than distributed systems engineers. Not always, but sometimes, an interesting knowledge arbitrage opportunity when fields start to collide.
carlisle_ 5y ago
>Know when to break the rules. For rules like "don't repeat yourself," sometimes a little repetition is better than a bit of dependency. Glad to see DRY called out here. I've seen so much crazy code simply to avoid breaking, The Rule.
- ctvo 5y ago
  Trade-offs are the heart of this profession. Developers who stick blindly to DRY, SOLID, any dogma really, come off as inexperienced.
- franciscop 5y ago
  Same here, furthermore I've written so much crazy code early on to avoid breaking The Rule, looking back I'm double horrified; at what I did, and knowing that a lot of junior programmers are going through that phase now.
- Jtsummers 5y ago
  What's frustrating is that DRY is often paired with something like "The Rule of Three". Do repeat yourself about three times until you actually understand what it is that's being repeated (or whether it's just coincidental) so it can be refactored. But a lot of people forget that part and focus only on DRY. Is the magic number 1024 the same in all instances, for example. Or is it merely a coincidence that it's the same in a few places. Is the apparently repetitious code: context = create_context(); context.action(params); In several places really the same? Or is it a coincidence that right now none of them pass any parameters to create_context and use the same params in their call to action? Avoiding the repetition makes it hard to even ask that question. And disentangling the different cases later is riskier than keeping a few pieces of repeated code around for a while to understand the situation better.
  - jaredsohn 5y ago
    Instead of calling it 'The Rule of Three', call it WET (Write Everything Twice); makes it easier to remember (although I think that is one less repetition than suggested in the parent.)
boyadjian 5y ago
Don't be afraid of simplicity: The most simple it is, the better it is
- rckrd 5y ago
  Agreed!
3pt14159 5y ago
I agree with almost all of these viewpoints. The comment one though isn't quite right. Sometimes you just need a comment. For example, I was writing some code to an API and the company was offering a private experimental feature. The API was JSON, but this one feature was enabled by adding a small stringified JSON object to a field of the larger JSON post body. If a developer looks at it, they'll think "this must be wrong" but with a comment that briefly mentions why, everyone will be saved some time.
- rckrd 5y ago
  I agree - I think I needed to add a bit more nuance, which I did in https://news.ycombinator.com/item?id=28087165 https://news.ycombinator.com/item?id=28087165
  - mastersummoner 5y ago
    Appreciate the clarification. Comments can (and are) definitely overused and abused, but they absolutely have their place.
- rzimmerman 5y ago
  Yes I agree with the sentiment, but I think long comments are useful for explaining why a choice was made. Or an idiosyncrasy of the system like you said.
  - christophergs 5y ago
    This. Comments are for why.
    - jlc 5y ago
      IMO commit messages are for why.
      - magnusmundus 5y ago
        Do you really prefer digging through years of commit messages to find why a particular line exists? It's a very impractical place for those. And good luck finding the origin of that line if there was an extensive refactor in between. Also, how do you notify a later viewer that there's a "why" they should check? A comment that says "check commit messages for this line"? :) Not to mention: you're losing the notes as soon as you move repositories, or worse, version control systems. Yes, I've hit the "SVN git migrate" wall way too many times. For that reason I even started leaving issue numbers in comments for when it's particularly important, in case we lose the commit<->ticket link down the line.
barce 5y ago
There's lack of proof to back up the 10k hours. I get that he has worked 15 years at prestigious companies but I have to take his word on it. Some aphorisms jelled with me but other's didn't, so we're again at a "he said; she said" impasse.
- rejectedandsad 5y ago
  He’s an ubermensch to be perfectly clear - most things that work for him aren’t going to work or apply to the rest of us because we aren’t tall, white, chiseled Adonises that went to Ivies and worked at Google. I think most people should take the advice of experts like him - people that didn’t start from the bottom - with several grains of salt.
Fiahil 5y ago
> 5. Simple is hard. Yes.
- Supermancho 5y ago
  Simple is easy to maintain, so this is more of an inane statement. It's supposed to makes sense by reaffirming something vague in the context the reader's experience. This is an example of the worst kind of bullet points, pervading the "learned lessons" blogspam.
yellowbanana 5y ago
For me the most helpful general guideline has been. Make the code easy to change. I can break rules like DRY, if the repeating myself makes it easy to change.
- rckrd 5y ago
  Yep, modularity is immensely valuable. Requirements change. Technology changes.
- ithinkso 5y ago
  Yes, I often feel like 'refactorability' is way undervalued. The focus is on writing abstractions that can be easily extended to handle more cases but as soon as some case doesn't fit, it will be hacked in because the code is abstracted in a very narrow way and cannot be easily refactored to accommodate this new case 'natively'. Do that for a couple of years in a single codebase and the beautiful abstraction design has changed into a state machine with a transition between almost every pair of states
karmakaze 5y ago
This is a fine list, but not unlike many others. What I find missing are the deeper elements rather than the rules of thumb or general observations. Things that I find valuable after 10k+ hours are ways of transforming a conceptual understanding of a problem into abstractions that produce a comprehensible and maintainable implementation. Talking about naming variables in depth alone would be more valuable than this listing, and I do hope there will be follow-up posts that go in to some of these points as well as cover topics that don't neatly summarize as 1-liners.
- rckrd 5y ago
  Great idea. Some in-depth follow ups are on my radar (I've been trying to publish 1 post a day, yet, never run out of ideas.)
michaelbarton 5y ago
Might disagree with the author on what is deliberate practice. I would say the implementing code at work is not deliberate practice in the sense that it’s defined in the original 10k hours thesis. I think in the strictest sense deliberate practice is picking something that you’re weaker at, and spending time deliberately working on that. I imagine that some part of the author’s 10k hours was working on projects outside their comfort zone, while others were within it. The argument would be doing stuff that you’re comfortable with or don’t have to think too hard about would not be deliberate practice.
- rckrd 5y ago
  Agreed - tough to nail down a definition of deliberate practice for software engineering. I credit three sources - Working on a large open-source gave me access to high-quality reviewers from around the world. - Likewise, at Google, I was surrounded by some exceptionally smart people. - Finally, like you said, working on projects outside the scope of my work and expertise.
  - michaelbarton 5y ago
    Thanks for your comment. I enjoyed your article. Deliberate practice is something I’ve thought about before in the context of programming and it’s hard to nail down. Especially because of how some of the skills are not programming at all. E.g. How might you deliberately practice skills like requirements gathering or managing stakeholders.
- rustyminnow 5y ago
  As an R&D engineer my grandfather used to say that if you're working on something new everyday for 20 years that's a lot of experience. But if you're working a job you can master in a year, is it actually 20 years of experience, or 1 year of experience 20 times? I'm not saying you're wrong - just implementing code at work by itself isn't deliberate practice - but I think it can be if you work just outside your comfort zone. Personally, I find work incredibly dull when I'm not learning something new.
markus_zhang 5y ago
Configuration is hard. Most of the cases I see people eventually crank out their own DSL and "teach" other people to use it.
- rckrd 5y ago
  Author here, ironically, guilty of this https://matt-rickard.com/virgo-lang/ https://matt-rickard.com/virgo-lang/
- hipjiveguy 5y ago
  You may be implying this, but DSL is the root of all evil, imho. Unless it is code, and compiles, and can be debugged, or inspected via intellisense, then you have to "throw it over the wall", and cross your fingers.
__hjf 5y ago
This is a great read. Posts like this make me not fear being “just a developer” for the rest of my life.
- rckrd 5y ago
  Software engineering is one of the highest leverage things you can do. Keep it up!
azangru 5y ago
> Well, I'm certainly not a world-class expert > Most recently, I worked as a professional software engineer at Google on Kubernetes If this is not a world-class expert, who is?
- mgkimsal 5y ago
  ... "which allowed me to have my code peer-reviewed by some of the best engineers." The "I'm not an expert" mindset probably comes from working with many other people who, collectively, are certainly 'more expert' than the single author.
- deleted 5y ago
  [deleted]
ipnon 5y ago
"And the disciples came, and said unto him, Why speakest thou unto them in parables? He answered and said unto them, Because it is given unto you to know the mysteries of the kingdom of heaven, but to them it is not given. For whosoever hath, to him shall be given, and he shall have more abundance: but whosoever hath not, from him shall be taken away even that he hath. Therefore speak I to them in parables: because they seeing see not; and hearing they hear not, neither do they understand."
- hipjiveguy 5y ago
  lol... and... relevant
bluetomcat 5y ago
For me, the most valuable insight has been to understand the problem at hand with its intrinsic complexity, constraints and requirements. Only then can you construct efficient and clear abstractions with as little accidental complexity as possible. Sometimes this can mean writing a very small amount of glue code calling external libraries. Sometimes it can mean avoiding a library/framework and rolling your own solution which solves a specific subset of the problem, enabling a smaller footprint and less dependencies. No silver bullet, really.
rajasimon 5y ago
I don't understand the 11'th one can someone explain to me also the given link seems broken. > If you have to write a comment that isn't a docstring, it should probably be refactored. Every new line of comments increases this probability. (For a more nuanced take, the Linux Kernel Documentation)
- adamnemecek 5y ago
  He means that you should avoid commenting single lines but instead write comments on whole functions.
- rckrd 5y ago
  Link should be fixed. It's https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
- tudelo 5y ago
  One way that I was taught is via the HTDP "design contract". So in this case a "docstring" translates to defining the method contact (its inputs and outputs) and the purpose of the function (what the function does). https://course.ccs.neu.edu/csg107/design-recipe.html https://course.ccs.neu.edu/csg107/design-recipe.html is a random link that describes all the steps, with something like 2. being the one mentioned (I think, I'm not OP.)
naikus 5y ago
> Syntactic sugar is usually bad. When I read this, ES6 classes came to my mind :) Great post btw!
bishoprook2 5y ago
After 30k/40k/??? hours of programming, I wish I had spent a chunk of the time learning how to play the piano well or something.
- GnarfGnarf 5y ago
  There's not as much money in piano as in programming.
  - bishoprook2 5y ago
    Looking back, that shouldn't have been so much of a driving force. Now that I think of it, the right answer would have been several 10k hour professions. I can't say that the products I designed in 2020 were more complex or amazing than those in 1980. It would have been a chance to achieve high levels of proficiency in multiple fields.
    - cdaven 5y ago
      The "10k hours rule" is of course just a rule of thumb, with a lot of exceptions depending on the skillset. I believe the number of hours required for mastering the violin was 25k. I think the programming field is large enough to learn and improve your whole life. You probably have to change domains, programming languages, frameworks, architectures, companies, and switch from web to mobile, from frontend to backend, from serverless to embedded -- but there are always new ways of experiencing the beginner's mind.
- mastersummoner 5y ago
  Ouch. Well, never too late to take up piano or woodworking or something. After 40k hours of programming, rock climbing might be out though... your poor hands!
  - bishoprook2 5y ago
    Luckily I managed to pop out of the other end of the machine with my limbs intact.
eeegnu 5y ago
> 23. While rare, sometimes it's a problem with the compiler. Otherwise, it's always DNS. Is DNS here just referring to Domain Name System, as in to reference problems with systems out of our control?
- rckrd 5y ago
  Domain Name System - As a developer working on Kubernetes. It's always DNS.
- syoc 5y ago
  A lot of organizations control their own name servers. There are also heaps of problems that can manifest on the client.
- jgalentine007 5y ago
  9 out of 10 times when I would troubleshoot people's problems with active directory / exchange / lync / office 365 it was... DNS!
martinhath 5y ago
Good post, and a good list. Here's a mind dump on some of the items: Right off the bat: > Well, I'm certainly not a world-class expert, but I have put my 10,000 hours of deliberate practice into programming. Okay, I don't know the authors exact history here, but I seriously doubt that they've had anything that's even close to 10k hours of deliberate practice of programming. Why? Because programmers basically /never/ do any deliberate practice. We don't have anything that's even close to what a piano player does when they practice fingersetting, chord transition, scales, or the like. I'm not even sure what this would look like, but I suspect that it is fundamentally different. Most musical instruments have a physical or mechanical side to them that is completely disjoint from the "musical" part of it. For instance knowing how to play a cool solo a guitar (meaning knowing which notes to pick and how long to hold them for), and being able to have your left hand fingers in the right positions in the right times and your right hand picking the right strings has almost nothing to do with each other. The way it usually works (I'm an amateur player who hasn't played in years, so maybe some professionals can take over this analogy) is that you practice very slowly and ramp up quicker and quicker untill "magically" your muscle memory takes over and it all kind of just happens. The result is that you don't really pick each indivitual note anymore, you kinda just play that part (when practicing you've decomposed the whole piece into small parts), and each part is atomic to you. Starting in the middle of a part doesn't quite work. The only programming analogy I can think of (from the top of my head) is how effortless it feels to write `for (int i = 0; i < n; i++)`, or something like it. But we only spend a negligible time on actually writing out the lines of code when programming, so while being able to effortlessly write out a bunch of standard `for` loops doesn't really push the needle in any way. For a performing musicial, of course, this is very different, because the /have/ to play it right! Imagine having to write all your `for` loops in sync with the beat of music. > 4. Syntactic sugar is usually bad. It's hard to really get exactly what this means, because if taken literally it is obviously not true. Pretty much any loop or control flow structure is just syntax over goto, but I assume the author doesn't really think we should manually write out the gotos. Having recognizable patterns in a codebase is good. Cramming in some esoteric syntax quirk of your language into your code because it technically fits is not good. > 5. Simple is hard. Again, difficult to get something concrete out of this since it reads as a zen mantra. If they mean that finding a simple solution to a difficult problem is hard then I agree. If they mean that a system being simple means it is hard to use then I disagree. > 7. Know the internals of the most used ones like git and bash (I can get out of the most gnarly git rebase or merge). Knowing the internals of e.g. `bash` is too far for me. I'm happy if I even knowing the surface of it! I guess they mean that cargo culting these tools usually doesn't lead you anywhere good and that invesing the time into them will pay off, as opposed to "cookbooking" it, like with git in that xkcd. > 9. Only learn from the best. So when I was learning Go, I read the standard library. I think this is important, but it is very difficult for programmers to do this, > 10. If it looks ugly, it is most likely a terrible mistake. I don't think this is good advice because it suggests that all code should "look nice" and if it doesn't it's just wrong. In my experience the number one metric (if you can even call it that) one should be concerned about is flexibility. If your code is "rigid" and difficult to change it really doesn't matter a whole lot how nice it looks, because, presumably, you're not really sure exactly what you're doing, and the code you write will probably not last very long in the codebase. It's hard to put a number on this, but I'm pretty sure most of the code I write does not last a month. All the time I'd spend worrying about whether this code was "ugly" is effectively wasted, because in a month it will not exist any more. Make code easy to replace. > 11. If you have to write a comment that isn't a docstring, it should probably be refactored. I also don't agree with this. I think it's completely reasonable to have comments in function bodies expalining what this part of the function does. See Jon Blow's related blog post[0]. Docstrings are for users of a function, but you might also want comments for the people reading the function body. Sometimes this can be avoided by writing Good Code, sometimes not. > 12. If you don't understand how your program runs in production, you don't understand the program itself. Very true; I'd phrase it as "understanding the problem", in Mike Acton lingo [1]. If you don't understand The Problem, then you don't understand what your program, which is (a part of) the solution to The Problem, does either. > 14, 15, 16 This is good advice, and I imagine it's difficult for beginners (or novices) to make sense of what to do here; some circles advocate for always pulling in dependencies, others for always inlining 3rd party trees in your own codebase. I actually think this is one of the parts of programming as a field that has the potential for some kind of a paradigm shift. I'm not convinced that in 25 years we'll be still trying to write generic "libraries" for others to use, and other people will download semvers of libraries to ensure compatibility. There has to be a better way. > 17. Know when to break the rules. For rules like "don't repeat yourself," Thank you! DRY is probably the worst of the n-letter programming mantras. DO repeat yourself! Do whatever you need to quickly get a better understanding of your problem! > 18. Organizing your code into modules, packages, and functions is important. Knowing where API boundaries will materialize is an art. This is also very true. Given an API, filling in the function bodies is often close to trivial, and coming up with the API in the first place is indeed an art. [0]: http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm... [1]: https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc
GnarfGnarf 5y ago
10K hours??! Try 100K hours (55 years x 50 wks/yr x 40 hrs/wk). I still don't know much.
- otagekki 5y ago
  What would you expect to be able to do after 100k? Coding and debugging any codebase in any of the 10 most used languages without internet? God knows if I'll still be alive after 55 years
  - GnarfGnarf 5y ago
    A lot of time was spent acquiring problem domain knowledge: life insurance, manufacturing, transportation, sales, packet-switching networks, typography, printing, food industry, graphics, GIS, etc.
    - otagekki 5y ago
      That definitely broadens your horizon. The more I think about it the more I think that your value as a programmer comes from your knowledge of the domain.
SavantIdiot 5y ago
There's a really good book called "Code Complete" from 1993 (revised several times) that I think captures a lot of this sentiment in a more organized and illustrated way. A lot of stuff on this list has been tribal knowledge for decades (well, except for the part about build pipelines, language choices, and Stack Overflow, etc.). My first code mentors in the 80's & 90's said some of the same things in this list, and I passed them down to my mentees (?) as well. https://www.powells.com/book/code-complete-9780735619678 https://www.powells.com/book/code-complete-9780735619678
temeritatis 5y ago
> While rare, sometimes it's a problem with the compiler. Otherwise, it's always DNS. I don't quite understand this one? Does it refer to domain name server? So if you're having network issues it's always DNS problems? > Corollary: Most code out there is terrible. Sometimes it's easier to write a better version yourself. I never cut-and-paste directly from stack overflow. I cut from several sources, combine the best practices and adapt everything to make something novel, and hopefully "better". But i think it's important that you understand what it does before you use it. This might seem self-evident, but my experience tells me not everyone agrees with this methodology. If i find inspiration to a solution, i usually leave a link to the original source or stack overflow page.
- vvoyer 5y ago
  The DNS part is a joke (I guess?) about how unreliable and surprising DNS issues can be. You could do the same with caching.
  - temeritatis 5y ago
    Oh certainly. In fact, caching issues (on multiple levels) is a constant pain in the ass in my line for work anyway. It can be so subtle sometimes that you spend hours looking at something that shouldn't be an issue. But it is, and i think we all know why.
- deleted 5y ago
  [deleted]
mastersummoner 5y ago
I will say, I think the one point in this article I disagree with is about finding answers on the internet. There are certainly been many times I've needed to dig into the source of something I'm working on, but much more often than not I've been able to find an exact (or close enough) answer with a couple of different Google searches. Granted, this may be because the areas I work in are less technically complex than, say, writing low-level code or IoT instructions.
- cdaven 5y ago
  And probably because you work with one of the most popular languages and frameworks in the world? Try an old, obscure niche language, and the experience will change completely.
edumucelli 5y ago
Too many of the items are deeply influenced by Golang principles or quotes I have seen from Gophers. I think this is a very interesting Go-oriented reflections on 10k hours of programming. I think it boils down to each 10k hours of programming on (or mostly on) a certain language will give your different reflections that we think are general.
gumby 5y ago
Good list, and indeed not really advice for beginners. I'm not sure reading the standard library for language X is necessarily a good way to learn the conventions and practices of a language. Typically a standard library contains a lot of complex corner cases that don't need to be worried about when writing ordinary code. (Expanding). The standard library authors don't know the users of the code. While when you're writing a piece of code with a limited number of developers (could even be thousands) you might, for example, say "all our accessors for class X return const results" while the standard library authors have to handle the non-const case"
- pphysch 5y ago
  The advice is "learn from the best", not "learn from the standard library". The Golang standard library just happens to be among the best, according to the author.
- rckrd 5y ago
  Good point. If you're writing your own library, maybe. If you're writing business logic mostly, probably not. Thanks for the perspective.
lordnacho 5y ago
Good list, and the litmus test is I would have disagreed with a lot of it when I started, or at least I'd have wondered why it mattered. My summary, and it won't be useful at all, is that a lot of programming decisions come down to judgement. Comment or not? Config file or DSL? Is it ugly? Is is a rare feature of the language? All of these things are the kind of thing that you could argue if you wanted, but an experienced programmer will likely have better arguments. One thing I still don't agree with is the first one. There's a lot of things, mostly trivial, that are easier to find on SO than in the source code. In fact something like "what's the idiomatic way to concat a string in $lang?" is best found on SO rather than the source code, because the source code will allow more than one way to do it. For number 2 problems ("In many cases, what you're working on doesn't have an answer on the internet."), the answer is again judgement. For this you want to have a network of programmers you've built up over the years that you can ask. I have a couple of good friends on chat that I can just pop a question to, and it saves a heck of a lot of time. Hard to find though, they have to be someone who is basically gonna work for free for you, and you have to provide a similar level of service when they have a question for you.
jdeaton 5y ago
> If you have to write a comment that isn't a docstring, it should probably be refactored. Yikes. Can't read past that.
- danuker 5y ago
  Instead of a comment informing a user how something works (or how something does not work), write a test demonstrating and documenting its use. The test will not forget, and has a docstring explaining what and why. But crucially, it is automated, and does not rely on mistake-prone humans to check (as is the case of a comment).
waynesonfire 5y ago
Each point is true to me. Very nice job articulating these ideas.
greyman 5y ago
> 4. Syntactic sugar is usually bad. I agree now, after switching from Python to Go.
welder 5y ago
I recently reached 10k hours too this week. (I've coded more than 10k, but only tracked time for 10k) Here's my language usage for those 10k hours: https://twitter.com/alanhamlett/status/1423738961550184449 https://twitter.com/alanhamlett/status/1423738961550184449
cudgy 5y ago
10,000 hours programming is not specific enough of a target to equate to Gladwell’s examples. It’s like saying “I practiced playing sports for 10,000 hours, so I am a professional athlete.” Now, if you developed using a single language targeted on a specific platform for 10,000 hours while challenging yourself at a high level, you would have a very strong level of expertise in that area. Furthermore, Gladwell made the distinction that the hours spent should be deliberate and tailored to improve skills. Working on tasks handed down to you by your superiors at Google is not deliberate practice.
- pnt12 5y ago
  I could not agree more. By this logic, every young professional is incompetent and every older one is very competent. But reality is very different. I would say age and hours of experience bring wisdom, but not necessarily better thinking.
giraffe333 5y ago
At least where I work, the DNS rule is "Batten's Law" because that guy's said it so many times, and been right so many times. https://www.battenworks.com/ https://www.battenworks.com/ It's DNS And, when you're sure it's not DNS, it's DNS
BatFastard 5y ago
Reflections on 40k hours of programming. Developers are a pain in the ass. But I still love making things work!
xupybd 5y ago
Sounds like the author is closer to 30,000 hours.
l0b0 5y ago
Let me compare the ones I might've disagreed with as a newbie (out of college, maybe a few tens of hours total programming) and what I think of them now, after 17 years as a programmer. - "Browsing the source is almost always faster than finding an answer on [the web, Stack Overflow didn't exist yet]." This would have taken a very long time as a newbie, not being familiar with C-style languages (I was working in PL/SQL and XForms, mostly) and the architecture of big software. Nowadays, depends how many levels of dynamic dispatch (the devil) the code uses. If it's more than one, the code is so unreadable as to be worthless to try to read. - "Know the internals […].", same as above. - "Syntactic sugar is usually bad." Depends how much more intuitive the sugar is than the salty version. Still the same opinion nowadays. - "While rare, sometimes it's a problem with the compiler. Otherwise, it's always DNS." Disagree both as a newbie and now, but then I'm probably not working on anything similar to OP. - "Some programmers are 10x more efficient than others." Certainly I was a <1x programmer as a newbie, but I don't think I've ever seen a 10x programmer. I've seen programmers which get features "done" by committing so many programming horrors that we were still dealing with the tech debt years later while they were at a FAANG, and I've also seen programmers which can whip up excellent code quickly but are unable to treat colleagues as adults. - "There's no correlation between being a 10x programmer and a 10x employee (maybe a negative one)." I wouldn't have thought so as a newbie, but this rings true now. Visibility, agreeing with the boss on whatever they think is cool, being able to serve up banter on request, and joining all the "social" events are important because nobody is able to gauge programmer productivity yet. - The "Heptagon of Configuration" is an interesting observation which I don't think I ever agreed with, but for different reasons. As a newbie because for most systems whatever we were using was usually decent enough, and now because I don't think this trend is cyclic but instead chaotic. We go from environment variables to Bash to INI to flags and so on. Usually this change is because we adopt some language or framework which staunchly refuses to treat anything but the Chosen Language as a valid configuration format, and so the existing configuration has to be adapted to work with N+1 opinionated (for the wrong reason) systems with as little pain as possible.
robertwt7 5y ago
> If it looks ugly, it is most likely a terrible mistake. I agree with this, looking back at my first year of professional coding I just realise how important code review is. Even if you are working for a small software agency / consultant, you have to force them to do code review before merging. Otherwise, you will spend a long time trying to make your code look better which mostly you won't be able too because lack of experience
rukuu001 5y ago
> In many cases, what you're working on doesn't have an answer on the internet. That usually means the problem is hard or important, or both. For me, it’s usually meant I’m doing something so wrongheaded it’s never come up before.
sghiassy 5y ago
How is reading a library’s source code FASTER than StackOverflow?

421 points by herbertl 5y ago

Author here, thanks for posting. Here's some more color on the reflection on comments, straight from the Linux Kernel documentation that capture my intention much better: "Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it’s much better to write the code so that the working is obvious, and it’s a waste of time to explain badly written code. Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to chapter 6 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it."[0] [0] https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting https://www.kernel.org/doc/html/v4.10/process/coding-style.h...

efsavage 5y ago
The WHY is also very useful in comments, especially in business/UI/glue code where special cases abound.
- klysm 5y ago
  I would say the why might be more important than the what a lot of the time
- david-gpu 5y ago
  Came here to comment along those lines. The WHY often will be elaborate enough that it deserves a design document that includes things like: who is the owner of those requisites, what is the rationale behind them, who are the stakehilders who signed off, what interactions it has other components, what alternative designs were considered, etc.
- dirkt 5y ago
  This. And in particular if there are multiple ways to do it, and you had to choose a particular way for a reason. Comments should explain the decision process (if one was necessary) that lead to this variant. Because if there's no comment explaining it, the next developer looking at it will say "oh, but it's much simpler if I just do it that way", and will run into trouble because he didn't realize the pitfalls.
rgrmrts 5y ago
Interesting reading about RuneScape in your post. I got into programming because of RuneScape and writing bots! Great memories. I enjoyed reading this post. Cheers!
- rckrd 5y ago
  Thanks! Likewise. Truly a great sandbox for budding programmers.
  - mastersummoner 5y ago
    I got into programming at 14 because of writing scripts in Gemstone, a text based MMOMUD. Didn't even realize what I was doing was programming until college though...
    - calrizien 5y ago
      Gemstone! That game changed everything for me
- AQuantized 5y ago
  Writing increasingly sophisticated bots and trying to figure out what exactly would earn you a ban was my own first practical experience with coding. I mostly managed to dodge bans on my most used accounts at the time, but interestingly when I checked back a year or two ago the majority had been permanently suspended. I wonder if they have some method of retroactively determining if someone was botting?
Retric 5y ago
The exception to the WHAT/HOW divide is working around a 3rd party bug. Documenting workarounds can help prevent reintroducing the same bug when someone edits or copies the code. This can be especially helpful if the 3rd party bug gets fixed in such a way that your workaround now fails.
ajuc 5y ago
> NEVER try to explain HOW your code works in a comment Never is a strong word, sometimes the algorithm is just inherently complex and it's worth it to explain what you are doing. Why is much more important, but it's also partially solved automatically by git blame and adding the task number to each commit message (and writing good commit messages which IMHO is more important than writing good comments). Each line of your code has commit message associated with it whether you care about it or not - make it useful.
- bccdee 5y ago
  Yeah algorithms in particular are where I'm hesitant to say "never explain how your code works." They can be dense, deeply-nested, and hard to break down into semantically-meaningful variables and function names. Sometimes it's good to explain what's going on there.
  - Salgat 5y ago
    That's what people don't understand. We don't think in code, we have a translation layer from human language/thought that we think through when parsing a programming language. As long as the comments are kept accurate, they can greatly improve your ability to parse through a block of complex code, which is crucial when you're trying to hotfix an issue. It also gives newer programmers to the codebase a chance to help understand what that block of code is doing beyond it just being some blackbox with an input and output.
- cjohansson 5y ago
  Yeah the how is important when auditing the correctness of code. I would say "Never listen to an advice about never doing something, there is always a case were breaking the rules is good"
  - deleted 5y ago
    [deleted]
- vhakulinen 5y ago
  From the linked post: > Know when to break the rules.
franciscop 5y ago
Small typo, it's "Malcolm Gladwell in Outliers" not "Outsiders", I particularly noted it because I learned the word "outliers" in English thanks to that book.
- rckrd 5y ago
  Thanks, fixed!
juancb 5y ago
What's your take on the difference between explaining how code works and describing what it does? I only ask because of bits like the TCP rate estimator sometimes have step by step comments that might be interpreted as explaining how the code is doing something. For example take the app limited detection function: https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_rate.c#L182-L197 https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_r...
- mastersummoner 5y ago
  My take is that step by step commented explanations make sense when it's something either extremely complicated or making use of a system or tech that's not widely known. Otherwise, clearer code, smaller methods and better variable/method names are the way to go imo.
mastersummoner 5y ago
Another reasonable exception is referencing external sources - whether it's a specific library you borrowed code from, a piece of documentation needed to better understand what's going on, or a reference to a SO post explaining some weird workaround you've implemented.
baconforce 5y ago
I've seen this interpreted by smart engineers in a counter-productive way, in that they believe their code is so good that none of it ever needs any comments and hence they never write them despite the fact that their code isn't all that clear. It's more hubris than anything. Otherwise, there are many techniques you can use to make the code self-explanatory. I've taken a comment before and restructured the code to literally read like the comment.
Clubber 5y ago
The best comments are about intent. I can read the code and tell you what it does, but I have no idea if that's what it's supposed to do without knowing the intent.
baby 5y ago
> try to avoid putting comments inside a function body This makes me sad. Think about others who will have to reverse engineer your code. Not every functionality should be split into a function, unless you want to add 10 layers of abstraction and misdirection.
dnautics 5y ago
I think sometimes you want to put why in a comment. Just today I wrote a two paragraph comment (usually I don't write many comments at all) that describe the business need for why this the code is necessary (in my case, connecting to a 3rd party data source that overshares, describing the nature of the oversharing, outlining the -- very complex -- steps in the pruning algorithm, and noting that there are corner cases we might miss and also noting that we shouldn't care -- a handful of bad apples in a machine learning algo will probably disappear in the wash).
- lugged 5y ago
  Yup, I rarely ask "what's this code do" or "how does this code do that". But "why the fuck" is a daily occurrence. Self documenting code explains how and what. If you need a comment to explain how and what its a code smell. Sometimes it's ok but ideally it should be rare. I try not to overcomment but when I write code that looks confusing or clever I try to explain why I've done it that way. If I'm optimising, I'll explain why. If I'm making an assumption about something related but elsehwere I'll explain that. If I'm leveraging some context that isn't explicit, I'll explain that. ... Also, type of code matters, glue code rarely needs exhaustive comments. Library code often gets line by line commentary so when someone comes in to change something for their use case they have a clear understanding of what they're really changing, and who and what might break because of their change. I notice library code tests often get more comments explaining what and why I'm adding an assertion. Glue code test rarely needs comments in tests.
jbverschoor 5y ago
Don’t agree. Longer pieces of code are way easier to reason about. Deep function nesting, which seems clean is very confusing mentally, and also difficult to describe in terms of function name. Explain *why* you’re doing something a certain way. This also includes a little bit of how and what. Other than that, just make sure your business terms are reflected in the code, or at least have a proper definition of things, which you can easily reason about.
- cudgy 5y ago
  Agreed. When looking at complex code, it can be helpful to expand the functions inline to be able to view all of it in a single screen flow. Switching between too many files and functions sometimes creates friction, making it more difficult. However, when writing the code if a section of code is repeated more than 2 times, it should be considered to break it out into a separate function with a useful name.
  - fiddlerwoaroof 5y ago
    Unless you’re doing something like performance analysis, I think needing to peek into the definition of a function to understand a piece of code is a smell: it indicates that the function is only abbreviating and not providing an abstraction.
    - dragonsngoblins 5y ago
      Well a lot of the time when you are looking at something you are trying to diagnose some problem or another, which means you want to be 100% sure of what something is doing. Even if the function provides a good abstraction you might still want to make sure that it is doing exactly what it says on the tin because you are desk checking some weird behaviour and you want to make sure each step is acting correctly
      - fiddlerwoaroof 5y ago
        Agreed, but that means you verified that the use site was correct and are now examining whether the abstractions it depends on were implemented correctly. My point is just that you shouldn’t normally have to keep both sides of a call site in mind at once.
908B64B197 5y ago
> tell WHAT your code does, not HOW And also Why. I personally like an executive summary of the code, ie, I just got to this file, what am-I looking at.
hutzlibu 5y ago
I prefer over-commenting a lot, over under-commenting. The only harm is, when you miss the important bits over too much blabla, or when you forget to update comments. There are not many worse things, than wrong documentation/comments. "you want your comments to tell WHAT your code does, not HOW" but I agree very much to this.
ransom1538 5y ago
"Comments are good, but there is also a danger of over-commenting." IMHO The only way to tell if you are able to comment well is to do this: Work on some project - then in 2 years come back to that project and add a feature to it. You will learn real quick how good your comments are. Spoiler alert: You wont care about "how" - you will want to know "why".
hinkley 5y ago
It’s an old assertion of the Refactoring community that a commented block in the middle of a function is a separate function trying to break free. If the code is interesting in its own right, move it. That also extends to how. If the algorithm is interesting or complex enough you should move it as well, as the point of the host function is not to show how clever you are, but to accomplish a task. Empirically I’ve found that I get much less pushback on algorithmic tweaks when I isolate them to a separate function. The reader doesn’t have to include them in their local reasoning, and I suspect but cannot prove that they tell themselves that they can always revert that code cleanly, so let’s just leave it be for now and see what happens.
tpoacher 5y ago
Define "comments". Like many arguments, disagreements below are mostly not disagreements about facts but disagreements of definitions at heart, only masquerading as disagreements about facts. Beyond a trivializing definition of "whatever follows a #", each time the word "comments" appears in the discussion below, it seems to actually refer to something entirely different from one person to the next.

moonchrome 5y ago

>In many cases, what you're working on doesn't have an answer on the internet. >That usually means the problem is hard or important, or both. Really ? If a problem is important someone likely already tackled it. I mean 15 years ago this was less likely, but these days there's so much work in the open and search is very good, when I find there aren't any references for my problem it usually means I misinterpreted the problem or I'm doing something very niche.

rckrd 5y ago
You're implying the reverse causation. The reflection is "can't find answer" -> "might be hard", not "might be hard" -> "can't find answer". Surely there is copius documentation on a significant number of hard problems.
tonymet 5y ago
When you get above the 40th percentile in problem difficulty or novelty, there are no answers or even discussions on the internet.
mrweasel 5y ago
I feel like your argument is a little along the line of: “ Everything that can be Invented has been Invented”
- moonchrome 5y ago
  No, just that CS/programming is mature enough that important stuff has already been explored so if I'm hitting a dead end either I'm doing something very specific that hasn't been investigated yet or (more likely) I'm not framing the problem correctly.

skohan 5y ago

> Syntactic sugar is usually bad. I disagree with this one. It can be bad, but if it helps syntax get out of the way to reveal the intent of your code, I think it's pretty good

rckrd 5y ago
Yes, maybe usually was too strong of a word - I think this varies with the language. In Go and JavaScript (where I mostly work), it's usually not that useful. In languages like C# and Java, I've found syntactic sugar to be very useful (e.g. lambda notion)
- silviot 5y ago
  I'm under the impression that, in Javascript, > async/await is syntactic sugar on top of the promises and provides a way to handle the asynchronous tasks in a synchronous manner. as is stated on this website I just found with one second of googling to support my thesis: https://dmitripavlutin.com/javascript-async-await/ https://dmitripavlutin.com/javascript-async-await/ If that is true, I believe it's incredibly useful syntactic sugar.
  - rckrd 5y ago
    Fair enough, there are clearly lots of useful syntactic shortcuts. I'm referring to things like prefix/postfix increment/decrement, object spreading vs. object rest, and ternary expressions. I'd avoid cases where extending the language is done in a non-obvious and ambiguous way.
    - dfee 5y ago
      I love me some spread operators and ternary expressions. …mumbles something about prying those from my cold dead hands.
      - skohan 5y ago
        Yeah I think there's a time and a place for ternaries, but when used correctly they're just so concise. Like if you have super long expressions in your ternaries, or you have a bunch of nested/chained ternaries it can be hard to parse, but in a lot of cases it's so nice to get something onto one line instead of needing an if/else

devwastaken 5y ago

I appreciate these, but in my experience it's not that relevant. The harder problems in programming are more of knowing your ecosystem. Knowing the design patterns necessary to create well meaning, understandable code in the first place. This is especially cumbersome when working on projects with complex data patterns. For example, working with GUI applications and C/+ can make your code a big pile of garbage really quickly because representing your data in something like an ORM is not standard, you can't do the many tricks like getters/setters in C/+, but you can in Python, or C#, etc. The benefits of VM languages are, in my opinion, not appreciated enough. In my opinion knowing the right tools for the job is far more important than how you comment your code, how you name your variables, or anything else. I wish there were more posts where people impliment an application with multiple tool sets and compare them, give insight into what some things are good for and not. "Tool Benchmarking" might be a good term for it.

rckrd 5y ago
Lucky for you #6 is "Have a wide variety of tools and know which ones to use for the job." :)
nerdponx 5y ago
> I wish there were more posts where people impliment an application with multiple tool sets and compare them, give insight into what some things are good for and not. "Tool Benchmarking" might be a good term for it. I recently started working on a project like this. It's hard work. Building a complete tool in one language takes a long time. Not to mention 2, or 5. Moreover, many (most?) programmers are only "fluent" in one or two languages. Even if you "know" a language, you might not know the full build toolchain, or you might not know common idioms, etc. Most people probably want to work on building new/interesting/fun stuff, not reimplementing the same toy program in several different languages.
- rckrd 5y ago
  I've actually found that knowledge diffusion between different languages and different types of developers can be significant - e.g., game developers work much differently than distributed systems engineers. Not always, but sometimes, an interesting knowledge arbitrage opportunity when fields start to collide.

carlisle_ 5y ago

>Know when to break the rules. For rules like "don't repeat yourself," sometimes a little repetition is better than a bit of dependency. Glad to see DRY called out here. I've seen so much crazy code simply to avoid breaking, The Rule.

ctvo 5y ago
Trade-offs are the heart of this profession. Developers who stick blindly to DRY, SOLID, any dogma really, come off as inexperienced.
franciscop 5y ago
Same here, furthermore I've written so much crazy code early on to avoid breaking The Rule, looking back I'm double horrified; at what I did, and knowing that a lot of junior programmers are going through that phase now.
Jtsummers 5y ago
What's frustrating is that DRY is often paired with something like "The Rule of Three". Do repeat yourself about three times until you actually understand what it is that's being repeated (or whether it's just coincidental) so it can be refactored. But a lot of people forget that part and focus only on DRY. Is the magic number 1024 the same in all instances, for example. Or is it merely a coincidence that it's the same in a few places. Is the apparently repetitious code: context = create_context(); context.action(params); In several places really the same? Or is it a coincidence that right now none of them pass any parameters to create_context and use the same params in their call to action? Avoiding the repetition makes it hard to even ask that question. And disentangling the different cases later is riskier than keeping a few pieces of repeated code around for a while to understand the situation better.
- jaredsohn 5y ago
  Instead of calling it 'The Rule of Three', call it WET (Write Everything Twice); makes it easier to remember (although I think that is one less repetition than suggested in the parent.)

boyadjian 5y ago

Don't be afraid of simplicity: The most simple it is, the better it is

rckrd 5y ago
Agreed!

3pt14159 5y ago

I agree with almost all of these viewpoints. The comment one though isn't quite right. Sometimes you just need a comment. For example, I was writing some code to an API and the company was offering a private experimental feature. The API was JSON, but this one feature was enabled by adding a small stringified JSON object to a field of the larger JSON post body. If a developer looks at it, they'll think "this must be wrong" but with a comment that briefly mentions why, everyone will be saved some time.

rckrd 5y ago
I agree - I think I needed to add a bit more nuance, which I did in https://news.ycombinator.com/item?id=28087165 https://news.ycombinator.com/item?id=28087165
- mastersummoner 5y ago
  Appreciate the clarification. Comments can (and are) definitely overused and abused, but they absolutely have their place.
rzimmerman 5y ago
Yes I agree with the sentiment, but I think long comments are useful for explaining why a choice was made. Or an idiosyncrasy of the system like you said.
- christophergs 5y ago
  This. Comments are for why.
  - jlc 5y ago
    IMO commit messages are for why.
    - magnusmundus 5y ago
      Do you really prefer digging through years of commit messages to find why a particular line exists? It's a very impractical place for those. And good luck finding the origin of that line if there was an extensive refactor in between. Also, how do you notify a later viewer that there's a "why" they should check? A comment that says "check commit messages for this line"? :) Not to mention: you're losing the notes as soon as you move repositories, or worse, version control systems. Yes, I've hit the "SVN git migrate" wall way too many times. For that reason I even started leaving issue numbers in comments for when it's particularly important, in case we lose the commit<->ticket link down the line.

barce 5y ago

There's lack of proof to back up the 10k hours. I get that he has worked 15 years at prestigious companies but I have to take his word on it. Some aphorisms jelled with me but other's didn't, so we're again at a "he said; she said" impasse.

rejectedandsad 5y ago
He’s an ubermensch to be perfectly clear - most things that work for him aren’t going to work or apply to the rest of us because we aren’t tall, white, chiseled Adonises that went to Ivies and worked at Google. I think most people should take the advice of experts like him - people that didn’t start from the bottom - with several grains of salt.

Fiahil 5y ago

> 5. Simple is hard. Yes.

Supermancho 5y ago
Simple is easy to maintain, so this is more of an inane statement. It's supposed to makes sense by reaffirming something vague in the context the reader's experience. This is an example of the worst kind of bullet points, pervading the "learned lessons" blogspam.

yellowbanana 5y ago

For me the most helpful general guideline has been. Make the code easy to change. I can break rules like DRY, if the repeating myself makes it easy to change.

rckrd 5y ago
Yep, modularity is immensely valuable. Requirements change. Technology changes.
ithinkso 5y ago
Yes, I often feel like 'refactorability' is way undervalued. The focus is on writing abstractions that can be easily extended to handle more cases but as soon as some case doesn't fit, it will be hacked in because the code is abstracted in a very narrow way and cannot be easily refactored to accommodate this new case 'natively'. Do that for a couple of years in a single codebase and the beautiful abstraction design has changed into a state machine with a transition between almost every pair of states

karmakaze 5y ago

This is a fine list, but not unlike many others. What I find missing are the deeper elements rather than the rules of thumb or general observations. Things that I find valuable after 10k+ hours are ways of transforming a conceptual understanding of a problem into abstractions that produce a comprehensible and maintainable implementation. Talking about naming variables in depth alone would be more valuable than this listing, and I do hope there will be follow-up posts that go in to some of these points as well as cover topics that don't neatly summarize as 1-liners.

rckrd 5y ago
Great idea. Some in-depth follow ups are on my radar (I've been trying to publish 1 post a day, yet, never run out of ideas.)

michaelbarton 5y ago

Might disagree with the author on what is deliberate practice. I would say the implementing code at work is not deliberate practice in the sense that it’s defined in the original 10k hours thesis. I think in the strictest sense deliberate practice is picking something that you’re weaker at, and spending time deliberately working on that. I imagine that some part of the author’s 10k hours was working on projects outside their comfort zone, while others were within it. The argument would be doing stuff that you’re comfortable with or don’t have to think too hard about would not be deliberate practice.

rckrd 5y ago
Agreed - tough to nail down a definition of deliberate practice for software engineering. I credit three sources - Working on a large open-source gave me access to high-quality reviewers from around the world. - Likewise, at Google, I was surrounded by some exceptionally smart people. - Finally, like you said, working on projects outside the scope of my work and expertise.
- michaelbarton 5y ago
  Thanks for your comment. I enjoyed your article. Deliberate practice is something I’ve thought about before in the context of programming and it’s hard to nail down. Especially because of how some of the skills are not programming at all. E.g. How might you deliberately practice skills like requirements gathering or managing stakeholders.
rustyminnow 5y ago
As an R&D engineer my grandfather used to say that if you're working on something new everyday for 20 years that's a lot of experience. But if you're working a job you can master in a year, is it actually 20 years of experience, or 1 year of experience 20 times? I'm not saying you're wrong - just implementing code at work by itself isn't deliberate practice - but I think it can be if you work just outside your comfort zone. Personally, I find work incredibly dull when I'm not learning something new.

markus_zhang 5y ago

Configuration is hard. Most of the cases I see people eventually crank out their own DSL and "teach" other people to use it.

rckrd 5y ago
Author here, ironically, guilty of this https://matt-rickard.com/virgo-lang/ https://matt-rickard.com/virgo-lang/
hipjiveguy 5y ago
You may be implying this, but DSL is the root of all evil, imho. Unless it is code, and compiles, and can be debugged, or inspected via intellisense, then you have to "throw it over the wall", and cross your fingers.

__hjf 5y ago

This is a great read. Posts like this make me not fear being “just a developer” for the rest of my life.

rckrd 5y ago
Software engineering is one of the highest leverage things you can do. Keep it up!

azangru 5y ago

> Well, I'm certainly not a world-class expert > Most recently, I worked as a professional software engineer at Google on Kubernetes If this is not a world-class expert, who is?

mgkimsal 5y ago
... "which allowed me to have my code peer-reviewed by some of the best engineers." The "I'm not an expert" mindset probably comes from working with many other people who, collectively, are certainly 'more expert' than the single author.
deleted 5y ago
[deleted]

ipnon 5y ago

"And the disciples came, and said unto him, Why speakest thou unto them in parables? He answered and said unto them, Because it is given unto you to know the mysteries of the kingdom of heaven, but to them it is not given. For whosoever hath, to him shall be given, and he shall have more abundance: but whosoever hath not, from him shall be taken away even that he hath. Therefore speak I to them in parables: because they seeing see not; and hearing they hear not, neither do they understand."

hipjiveguy 5y ago
lol... and... relevant

bluetomcat 5y ago

For me, the most valuable insight has been to understand the problem at hand with its intrinsic complexity, constraints and requirements. Only then can you construct efficient and clear abstractions with as little accidental complexity as possible. Sometimes this can mean writing a very small amount of glue code calling external libraries. Sometimes it can mean avoiding a library/framework and rolling your own solution which solves a specific subset of the problem, enabling a smaller footprint and less dependencies. No silver bullet, really.

rajasimon 5y ago

I don't understand the 11'th one can someone explain to me also the given link seems broken. > If you have to write a comment that isn't a docstring, it should probably be refactored. Every new line of comments increases this probability. (For a more nuanced take, the Linux Kernel Documentation)

adamnemecek 5y ago
He means that you should avoid commenting single lines but instead write comments on whole functions.
rckrd 5y ago
Link should be fixed. It's https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
tudelo 5y ago
One way that I was taught is via the HTDP "design contract". So in this case a "docstring" translates to defining the method contact (its inputs and outputs) and the purpose of the function (what the function does). https://course.ccs.neu.edu/csg107/design-recipe.html https://course.ccs.neu.edu/csg107/design-recipe.html is a random link that describes all the steps, with something like 2. being the one mentioned (I think, I'm not OP.)

naikus 5y ago

> Syntactic sugar is usually bad. When I read this, ES6 classes came to my mind :) Great post btw!

bishoprook2 5y ago

After 30k/40k/??? hours of programming, I wish I had spent a chunk of the time learning how to play the piano well or something.

GnarfGnarf 5y ago
There's not as much money in piano as in programming.
- bishoprook2 5y ago
  Looking back, that shouldn't have been so much of a driving force. Now that I think of it, the right answer would have been several 10k hour professions. I can't say that the products I designed in 2020 were more complex or amazing than those in 1980. It would have been a chance to achieve high levels of proficiency in multiple fields.
  - cdaven 5y ago
    The "10k hours rule" is of course just a rule of thumb, with a lot of exceptions depending on the skillset. I believe the number of hours required for mastering the violin was 25k. I think the programming field is large enough to learn and improve your whole life. You probably have to change domains, programming languages, frameworks, architectures, companies, and switch from web to mobile, from frontend to backend, from serverless to embedded -- but there are always new ways of experiencing the beginner's mind.
mastersummoner 5y ago
Ouch. Well, never too late to take up piano or woodworking or something. After 40k hours of programming, rock climbing might be out though... your poor hands!
- bishoprook2 5y ago
  Luckily I managed to pop out of the other end of the machine with my limbs intact.

eeegnu 5y ago

> 23. While rare, sometimes it's a problem with the compiler. Otherwise, it's always DNS. Is DNS here just referring to Domain Name System, as in to reference problems with systems out of our control?

rckrd 5y ago
Domain Name System - As a developer working on Kubernetes. It's always DNS.
syoc 5y ago
A lot of organizations control their own name servers. There are also heaps of problems that can manifest on the client.
jgalentine007 5y ago
9 out of 10 times when I would troubleshoot people's problems with active directory / exchange / lync / office 365 it was... DNS!

martinhath 5y ago

Good post, and a good list. Here's a mind dump on some of the items: Right off the bat: > Well, I'm certainly not a world-class expert, but I have put my 10,000 hours of deliberate practice into programming. Okay, I don't know the authors exact history here, but I seriously doubt that they've had anything that's even close to 10k hours of deliberate practice of programming. Why? Because programmers basically /never/ do any deliberate practice. We don't have anything that's even close to what a piano player does when they practice fingersetting, chord transition, scales, or the like. I'm not even sure what this would look like, but I suspect that it is fundamentally different. Most musical instruments have a physical or mechanical side to them that is completely disjoint from the "musical" part of it. For instance knowing how to play a cool solo a guitar (meaning knowing which notes to pick and how long to hold them for), and being able to have your left hand fingers in the right positions in the right times and your right hand picking the right strings has almost nothing to do with each other. The way it usually works (I'm an amateur player who hasn't played in years, so maybe some professionals can take over this analogy) is that you practice very slowly and ramp up quicker and quicker untill "magically" your muscle memory takes over and it all kind of just happens. The result is that you don't really pick each indivitual note anymore, you kinda just play that part (when practicing you've decomposed the whole piece into small parts), and each part is atomic to you. Starting in the middle of a part doesn't quite work. The only programming analogy I can think of (from the top of my head) is how effortless it feels to write `for (int i = 0; i < n; i++)`, or something like it. But we only spend a negligible time on actually writing out the lines of code when programming, so while being able to effortlessly write out a bunch of standard `for` loops doesn't really push the needle in any way. For a performing musicial, of course, this is very different, because the /have/ to play it right! Imagine having to write all your `for` loops in sync with the beat of music. > 4. Syntactic sugar is usually bad. It's hard to really get exactly what this means, because if taken literally it is obviously not true. Pretty much any loop or control flow structure is just syntax over goto, but I assume the author doesn't really think we should manually write out the gotos. Having recognizable patterns in a codebase is good. Cramming in some esoteric syntax quirk of your language into your code because it technically fits is not good. > 5. Simple is hard. Again, difficult to get something concrete out of this since it reads as a zen mantra. If they mean that finding a simple solution to a difficult problem is hard then I agree. If they mean that a system being simple means it is hard to use then I disagree. > 7. Know the internals of the most used ones like git and bash (I can get out of the most gnarly git rebase or merge). Knowing the internals of e.g. `bash` is too far for me. I'm happy if I even knowing the surface of it! I guess they mean that cargo culting these tools usually doesn't lead you anywhere good and that invesing the time into them will pay off, as opposed to "cookbooking" it, like with git in that xkcd. > 9. Only learn from the best. So when I was learning Go, I read the standard library. I think this is important, but it is very difficult for programmers to do this, > 10. If it looks ugly, it is most likely a terrible mistake. I don't think this is good advice because it suggests that all code should "look nice" and if it doesn't it's just wrong. In my experience the number one metric (if you can even call it that) one should be concerned about is flexibility. If your code is "rigid" and difficult to change it really doesn't matter a whole lot how nice it looks, because, presumably, you're not really sure exactly what you're doing, and the code you write will probably not last very long in the codebase. It's hard to put a number on this, but I'm pretty sure most of the code I write does not last a month. All the time I'd spend worrying about whether this code was "ugly" is effectively wasted, because in a month it will not exist any more. Make code easy to replace. > 11. If you have to write a comment that isn't a docstring, it should probably be refactored. I also don't agree with this. I think it's completely reasonable to have comments in function bodies expalining what this part of the function does. See Jon Blow's related blog post[0]. Docstrings are for users of a function, but you might also want comments for the people reading the function body. Sometimes this can be avoided by writing Good Code, sometimes not. > 12. If you don't understand how your program runs in production, you don't understand the program itself. Very true; I'd phrase it as "understanding the problem", in Mike Acton lingo [1]. If you don't understand The Problem, then you don't understand what your program, which is (a part of) the solution to The Problem, does either. > 14, 15, 16 This is good advice, and I imagine it's difficult for beginners (or novices) to make sense of what to do here; some circles advocate for always pulling in dependencies, others for always inlining 3rd party trees in your own codebase. I actually think this is one of the parts of programming as a field that has the potential for some kind of a paradigm shift. I'm not convinced that in 25 years we'll be still trying to write generic "libraries" for others to use, and other people will download semvers of libraries to ensure compatibility. There has to be a better way. > 17. Know when to break the rules. For rules like "don't repeat yourself," Thank you! DRY is probably the worst of the n-letter programming mantras. DO repeat yourself! Do whatever you need to quickly get a better understanding of your problem! > 18. Organizing your code into modules, packages, and functions is important. Knowing where API boundaries will materialize is an art. This is also very true. Given an API, filling in the function bodies is often close to trivial, and coming up with the API in the first place is indeed an art. [0]: http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm... [1]: https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc

GnarfGnarf 5y ago

10K hours??! Try 100K hours (55 years x 50 wks/yr x 40 hrs/wk). I still don't know much.

otagekki 5y ago
What would you expect to be able to do after 100k? Coding and debugging any codebase in any of the 10 most used languages without internet? God knows if I'll still be alive after 55 years
- GnarfGnarf 5y ago
  A lot of time was spent acquiring problem domain knowledge: life insurance, manufacturing, transportation, sales, packet-switching networks, typography, printing, food industry, graphics, GIS, etc.
  - otagekki 5y ago
    That definitely broadens your horizon. The more I think about it the more I think that your value as a programmer comes from your knowledge of the domain.

SavantIdiot 5y ago

There's a really good book called "Code Complete" from 1993 (revised several times) that I think captures a lot of this sentiment in a more organized and illustrated way. A lot of stuff on this list has been tribal knowledge for decades (well, except for the part about build pipelines, language choices, and Stack Overflow, etc.). My first code mentors in the 80's & 90's said some of the same things in this list, and I passed them down to my mentees (?) as well. https://www.powells.com/book/code-complete-9780735619678 https://www.powells.com/book/code-complete-9780735619678

temeritatis 5y ago

> While rare, sometimes it's a problem with the compiler. Otherwise, it's always DNS. I don't quite understand this one? Does it refer to domain name server? So if you're having network issues it's always DNS problems? > Corollary: Most code out there is terrible. Sometimes it's easier to write a better version yourself. I never cut-and-paste directly from stack overflow. I cut from several sources, combine the best practices and adapt everything to make something novel, and hopefully "better". But i think it's important that you understand what it does before you use it. This might seem self-evident, but my experience tells me not everyone agrees with this methodology. If i find inspiration to a solution, i usually leave a link to the original source or stack overflow page.

vvoyer 5y ago
The DNS part is a joke (I guess?) about how unreliable and surprising DNS issues can be. You could do the same with caching.
- temeritatis 5y ago
  Oh certainly. In fact, caching issues (on multiple levels) is a constant pain in the ass in my line for work anyway. It can be so subtle sometimes that you spend hours looking at something that shouldn't be an issue. But it is, and i think we all know why.
deleted 5y ago
[deleted]

mastersummoner 5y ago

I will say, I think the one point in this article I disagree with is about finding answers on the internet. There are certainly been many times I've needed to dig into the source of something I'm working on, but much more often than not I've been able to find an exact (or close enough) answer with a couple of different Google searches. Granted, this may be because the areas I work in are less technically complex than, say, writing low-level code or IoT instructions.

cdaven 5y ago
And probably because you work with one of the most popular languages and frameworks in the world? Try an old, obscure niche language, and the experience will change completely.

edumucelli 5y ago

Too many of the items are deeply influenced by Golang principles or quotes I have seen from Gophers. I think this is a very interesting Go-oriented reflections on 10k hours of programming. I think it boils down to each 10k hours of programming on (or mostly on) a certain language will give your different reflections that we think are general.

gumby 5y ago

Good list, and indeed not really advice for beginners. I'm not sure reading the standard library for language X is necessarily a good way to learn the conventions and practices of a language. Typically a standard library contains a lot of complex corner cases that don't need to be worried about when writing ordinary code. (Expanding). The standard library authors don't know the users of the code. While when you're writing a piece of code with a limited number of developers (could even be thousands) you might, for example, say "all our accessors for class X return const results" while the standard library authors have to handle the non-const case"

pphysch 5y ago
The advice is "learn from the best", not "learn from the standard library". The Golang standard library just happens to be among the best, according to the author.
rckrd 5y ago
Good point. If you're writing your own library, maybe. If you're writing business logic mostly, probably not. Thanks for the perspective.

lordnacho 5y ago

Good list, and the litmus test is I would have disagreed with a lot of it when I started, or at least I'd have wondered why it mattered. My summary, and it won't be useful at all, is that a lot of programming decisions come down to judgement. Comment or not? Config file or DSL? Is it ugly? Is is a rare feature of the language? All of these things are the kind of thing that you could argue if you wanted, but an experienced programmer will likely have better arguments. One thing I still don't agree with is the first one. There's a lot of things, mostly trivial, that are easier to find on SO than in the source code. In fact something like "what's the idiomatic way to concat a string in $lang?" is best found on SO rather than the source code, because the source code will allow more than one way to do it. For number 2 problems ("In many cases, what you're working on doesn't have an answer on the internet."), the answer is again judgement. For this you want to have a network of programmers you've built up over the years that you can ask. I have a couple of good friends on chat that I can just pop a question to, and it saves a heck of a lot of time. Hard to find though, they have to be someone who is basically gonna work for free for you, and you have to provide a similar level of service when they have a question for you.

jdeaton 5y ago

> If you have to write a comment that isn't a docstring, it should probably be refactored. Yikes. Can't read past that.

danuker 5y ago
Instead of a comment informing a user how something works (or how something does not work), write a test demonstrating and documenting its use. The test will not forget, and has a docstring explaining what and why. But crucially, it is automated, and does not rely on mistake-prone humans to check (as is the case of a comment).

waynesonfire 5y ago

Each point is true to me. Very nice job articulating these ideas.

greyman 5y ago

> 4. Syntactic sugar is usually bad. I agree now, after switching from Python to Go.

welder 5y ago

I recently reached 10k hours too this week. (I've coded more than 10k, but only tracked time for 10k) Here's my language usage for those 10k hours: https://twitter.com/alanhamlett/status/1423738961550184449 https://twitter.com/alanhamlett/status/1423738961550184449

cudgy 5y ago

10,000 hours programming is not specific enough of a target to equate to Gladwell’s examples. It’s like saying “I practiced playing sports for 10,000 hours, so I am a professional athlete.” Now, if you developed using a single language targeted on a specific platform for 10,000 hours while challenging yourself at a high level, you would have a very strong level of expertise in that area. Furthermore, Gladwell made the distinction that the hours spent should be deliberate and tailored to improve skills. Working on tasks handed down to you by your superiors at Google is not deliberate practice.

pnt12 5y ago
I could not agree more. By this logic, every young professional is incompetent and every older one is very competent. But reality is very different. I would say age and hours of experience bring wisdom, but not necessarily better thinking.

giraffe333 5y ago

At least where I work, the DNS rule is "Batten's Law" because that guy's said it so many times, and been right so many times. https://www.battenworks.com/ https://www.battenworks.com/ It's DNS And, when you're sure it's not DNS, it's DNS

BatFastard 5y ago

Reflections on 40k hours of programming. Developers are a pain in the ass. But I still love making things work!

xupybd 5y ago

Sounds like the author is closer to 30,000 hours.

l0b0 5y ago

Let me compare the ones I might've disagreed with as a newbie (out of college, maybe a few tens of hours total programming) and what I think of them now, after 17 years as a programmer. - "Browsing the source is almost always faster than finding an answer on [the web, Stack Overflow didn't exist yet]." This would have taken a very long time as a newbie, not being familiar with C-style languages (I was working in PL/SQL and XForms, mostly) and the architecture of big software. Nowadays, depends how many levels of dynamic dispatch (the devil) the code uses. If it's more than one, the code is so unreadable as to be worthless to try to read. - "Know the internals […].", same as above. - "Syntactic sugar is usually bad." Depends how much more intuitive the sugar is than the salty version. Still the same opinion nowadays. - "While rare, sometimes it's a problem with the compiler. Otherwise, it's always DNS." Disagree both as a newbie and now, but then I'm probably not working on anything similar to OP. - "Some programmers are 10x more efficient than others." Certainly I was a <1x programmer as a newbie, but I don't think I've ever seen a 10x programmer. I've seen programmers which get features "done" by committing so many programming horrors that we were still dealing with the tech debt years later while they were at a FAANG, and I've also seen programmers which can whip up excellent code quickly but are unable to treat colleagues as adults. - "There's no correlation between being a 10x programmer and a 10x employee (maybe a negative one)." I wouldn't have thought so as a newbie, but this rings true now. Visibility, agreeing with the boss on whatever they think is cool, being able to serve up banter on request, and joining all the "social" events are important because nobody is able to gauge programmer productivity yet. - The "Heptagon of Configuration" is an interesting observation which I don't think I ever agreed with, but for different reasons. As a newbie because for most systems whatever we were using was usually decent enough, and now because I don't think this trend is cyclic but instead chaotic. We go from environment variables to Bash to INI to flags and so on. Usually this change is because we adopt some language or framework which staunchly refuses to treat anything but the Chosen Language as a valid configuration format, and so the existing configuration has to be adapted to work with N+1 opinionated (for the wrong reason) systems with as little pain as possible.

robertwt7 5y ago

> If it looks ugly, it is most likely a terrible mistake. I agree with this, looking back at my first year of professional coding I just realise how important code review is. Even if you are working for a small software agency / consultant, you have to force them to do code review before merging. Otherwise, you will spend a long time trying to make your code look better which mostly you won't be able too because lack of experience

rukuu001 5y ago

> In many cases, what you're working on doesn't have an answer on the internet. That usually means the problem is hard or important, or both. For me, it’s usually meant I’m doing something so wrongheaded it’s never come up before.

sghiassy 5y ago

How is reading a library’s source code FASTER than StackOverflow?