9 ms·

How to become a dramatically better programmer

248 points by henryaj 8y ago

yarinr 8y ago
It has some great points. > When amateurs [play tennis], they don’t edge each other out by being slightly more skillful. Instead, it’s a contest of who makes the fewest huge, gaping blunders. I actually find this idea relevant to so many areas in life. Most of us are just about average in most of the things. It is frequent that hunting down the most critical "huge mistakes" is the easiest way to improve dramatically in a certain field. I feel like doing so just gives you the most bang for your buck, and therefore should often take precedence over slightly improving more general abilities (through a lot of hard work, usually).
- edgarvaldes 8y ago
  >It is frequent that hunting down the most critical "huge mistakes" is the easiest way to improve dramatically in a certain field. A very well known path to improvement in chess, for example. That's why you are encouraged to train tactics, tactics, tactics.
  - evv555 8y ago
    Also an effective chess AI approach, minimax. Algorithm doesn't try to win but tries to cuts off paths that lead to the worst outcomes.
- AnimalMuppet 8y ago
  "It is often easier to not do something dumb than it is to do something smart." - M. J. Ranum?
- lou1306 8y ago
  This begs the question: What best practices can significantly reduce blunders and are (more or less) portable across languages? In my opinion, a good start is learning to use filter/map/reduce instead of big nasty for loops.
  - legulere 8y ago
    Fail fast, avoid mutability, write tests
    - AstralStorm 8y ago
      Fail fast in development. Have fallback code for deployment or you will be in deep trouble. And as all solutions, sometimes the cost is too much for the immutability. Writing tests is a bit glib...
  - AnimalMuppet 8y ago
    Big nasty for loops get replaced by big nasty filter/map/reduce calls. Filter/map/reduce may be less error prone than for loops, but if it would be a big and nasty for loop, it will still be big and nasty. Worse, "nasty" to me means more than just "what was inside the loop is large". It means that the loop itself was nasty, that is, it wasn't just a straightforward iteration over a collection, or a loop with fixed bounds. That means that it's harder to just replace it with a filter/map/reduce. I think that for loops can be hard for beginning to intermediate programmers, but with experience, they get easier. I don't remember exactly how many times I've messed up a for loop in the last decade, but the number is either 0 or 1. It's not 2. "Once in a decade" isn't exactly the source of large-scale bugs that people often claim for loops are. Note well, though: This is not my first decade as a programmer. The number was much higher my first decade. Filter/map/reduce may be easier to learn. You may in fact get to "one bug per decade" faster with them.
    - mseebach 8y ago
      You seem to be comparing a well-written, large for-loop (that has complexities dictated by true constraints, rather than programmer skill) with a poorly written functional chain. This isn't quite fair. The functional style nudges the programmer to think in the smallest semantic steps of transformation, in a way that the for-loop doesn't. Of course the programmer can ignore the nugde and write the same messy for-loop using functional constructs, and a good programmer can equally well write a big for-loop in a very manageable and easy to read style. But for an unexperienced programmer seeking general advice, I feel that recommending the functional style (with an additional urge to "listen" to what the style is trying to get you to do) is a pretty safe bet.
- abecedarius 8y ago
  I'm not sure how generally important this point is: perhaps it matters more for contest-style fields than more open-ended ones. The guy who can't "invert a binary tree" for his Google interview also made Homebrew.
- hinkley 8y ago
  With amateur athletes it’s a balance of both. You have to put in the hours. You can film your gait or your stroke all you want but you have to practice first. A lot of your practice is trying to cement the last four things you learned. You put in the hours and periodically you check in about improving your technique again. If you feel stuck in a plateau it’s probably time.
myWindoonn 8y ago
There's one piece of advice specific to programming which is missing from this listing: Read lots of code in lots of different languages. Aim to read, as a general rule, about twice as much code as you write, and to be able to read twice as many languages as you write in typically. Edit: The average piece of code is written once and read hundreds to thousands of times by people. It's not unreasonable to think of code as a read-oriented activity, not a write-oriented activity.
- gorpomon 8y ago
  This is a suggestion I see given a lot, but something that falls flat to me personally. The analogy I would put forth is that it feels like reading lots of different furniture assembly instructions in the the hopes of getting better at assembling IKEA furniture. Such a thing is informative, but probably not nearly as much as just assembling lots of IKEA furniture. To those who make it a point to read lots of code, are there approaches you take or methodologies you use? Or certain things you look for? Or concepts you compare to them to in your native language?
  - rmgraham 8y ago
    More like encouraging the creators of IKEA furniture assembly instructions to read lots of other instructions so that they can get better at writing instructions. An analogy for improving one's ability to assemble IKEA furniture, using this pattern, would be to watch others assemble all types of furniture in order to improve your own abilities. Wouldn't it?
  - extralego 8y ago
    I think this is a good point. I have mostly gained knowledge of software design by doing this, because once I work through a process that might happen in the code, I can infer the reasoning behind design decisions. I am still learning myself, but so far, reading production code now seems much more valuable than the pseudo code often found in blog posts. They each serve different purposes but I have found myself reading too far into pseudo code when trying to understand a concept can add unnecessary confusion. With production code, what you see is what works. And that just gave me an idea: programming books that only use production code! It might do less handholding and would certainly be harder to write, but maybe the value would make it worthwhile.
poulsbohemian 8y ago
I suppose this article is about programming rather than software engineering but at the same time, I find there are a lot of these articles with heavy emphasis on code. I'd much rather people who want to improve their abilities keep an eye on architecture, and I thought the article yesterday about Uber's reasoning for moving to MySql had some gems in the comments, like this one: https://news.ycombinator.com/item?id=12166585 https://news.ycombinator.com/item?id=12166585. The code is often secondary to the architectural choices. Get the architecture right, and the language or the quality of the code is frankly, a secondary concern.
- maerF0x0 8y ago
  > and I thought the article yesterday Link?
  - poulsbohemian 8y ago
    https://news.ycombinator.com/item?id=17279687 https://news.ycombinator.com/item?id=17279687. Or I guess rather I should say the article posted yesterday had excellent commentary in 2016 and 2013 ;-). The money quote was " And in this particular case, I'd say they shouldn't be using the database to do locking around sending a receipt. It should be put into a queue and that queue should be processed separately, which avoids the transaction problem altogether." For all the people who mock the GoF book or the idea of design patterns, that right there ^ is a pattern of software engineering that you can recognize and apply. It requires a layer of architectural thinking beyond just the code, but it is the kind of thinking that when I see it in people separates them as senior from not senior.
    - sevensor 8y ago
      I think the problem with the GOF book is that too many people used its respectability for too long to justify terrible designs, in opposition to both common sense and the guidance in the book itself. This has tarnished the reputation of what otherwise might be a pretty useful book.
beat 8y ago
Some of this hinges on work environment, not just habits. I was glad to see the reference to Cal Newport's "Deep Work", but it's hard to do deep work when you have three meetings scheduled that afternoon. edit: I consider Deep Work a must-read for anyone serious about doing hard things.
- rubidium 8y ago
  FYI your startups website gets flagged by chrome as your certificate date being invalid.
  - beat 8y ago
    Yeah, I know. I hit a wall on it and have been taking a break before starting it back up. The cert expired, and when I say "I'm not doing anything with this", I need to mean it. It'll get fixed in about a month; I'm planning on firing the machine back up with a fresh perspective after the 4th of July.
startupdiscuss 8y ago
I wonder if there is any data on the efficacy of these techniques. Deliberate practice makes sense to me, but I really wonder if the others require purposeful study or if you just pick up metaskills if you hack away at your project. Heck, in 5 years I might be reading an HN article: "Deliberate practice isn't all its supposed to be." And an article about how the original deliberate practice study was flawed because it just forced people into hours of extra practice or something.
- mseebach 8y ago
  It's a question of keeping track of which is the map and which is the territory. The point, I believe, is to be continually and relentlessly introspective, asking yourself how you can do better today than yesterday (and having a realistic view of what 'better' is). Deliberate practice can be helpful in forcing such introspection, if you let it. If you just go through the motions, it won't help much, certainly not sustained. You end up with cargo-culting. The classic example is the GoF Design Patterns book - it was a very good book, at least at it's time, you could expand your horizons a lot by reading it, and get a lot of tricks up your sleeve to deal with certain tricky, but relatively common, situations. But if you start actively to impose design patterns on code that doesn't need it so you can tell yourself (or your peers or whoever might listen) that you're a design patterns kind of guy, you end up with overly complex and hard to read (ie: bad) code.
- ztjio 8y ago
  I think the mistake here is that you think “purposeful study” and “pick up metaskills as you hack away at your project” are not both examples of (potential) deliberate practice. What makes either one deliberate or not is whether you make a point to focus on how well it was done, how it achieved goals (or not) and how to improve. That’s the deliberate part and that’s the part that makes the difference and is missing by default. As long as you’re constantly evaluating and making attempts to improve, it doesn’t matter so much in what context you’re doing the thing, whether it be for fun, for learning, for work, or whatever. “Practice” simply means you’re actually doing a thing as opposed to studying it theoretically. Though I think many people have a habit of reading into that word the notion that what you are doing is a throwaway or has very low expectations of success or importance. But keep in mind that what a doctor does every day is called “practice.”
megaman22 8y ago
The biggest barrier I often see is that people won't get in there and try things. It's code, and it's under version control. You can do basically anything, and the worst usually is you have to pull down a fresh copy. So much indecision and debate and time wasted, because people won't poke at things to figure out how they work.
- convolvatron 8y ago
  when i approach a new largish (say < 500k lines) codebase I'm supposed to be working on, I'll often just go on a giant tear and completely refactor it to be the way I like it. in the process I end up breaking several foundational assumptions and have to spend even more time carefully backing out my changes and trying to get it to work again. rewriting the whole thing isn't your job (usually). check out a fresh new copy. now you can make a pretty informed decision about the best way to make the changes you're actually being paid to make. or, more rarely, now I have a less tested but substantially smaller version (once I replaced a 500k library with a 15k version by gutting all the abstraction layers), and if its not a maintenance smallest-delta kind of deal, I just go with that. anyways, the shortest path to the goal isn't always to chip away gingerly at the surface with your eyes closed and your head turned away - take a nice deep dive, you can always swim back up.
tgb 8y ago
Surely five minutes spent learning a debugger isn't really in the spirit of the rest of the post. It should be more like "read the entire man page of the debugger and try some of it out." Five minutes is only enough to learn how to shove the work-flow you already know into a new tool, not to learn the work flow that is actually suited to that tool.
asdsa5325 8y ago
Repost from 10 days ago: https://news.ycombinator.com/item?id=17208419 https://news.ycombinator.com/item?id=17208419
hellofunk 8y ago
> Everyone’s strategy, therefore, should be to identify and eliminate these big, costly rookie blunders, one by one. This is far more effective than getting quicker, hitting harder, or making that one brilliant shot now and then. Brilliant observation.
andrewstuart 8y ago
Things that contribute to the ability to get things done: - ability to solve problems - understanding of the data structures you are working with - ability to formulate solutions that requires less code - doing one thing at a time - knowing how to use the debugger - experience working within the architecture of the application you are working on About 1,000 other things too.
rossdavidh 8y ago
The things listed are all nice and all, but here's what I've seen result in dramatically better programming: Know your problem domain. There are, in basically every field of programming, some very domain-specific problems which you need to know about, that will be much more important in whether or not you do good programming than any of the things listed here. If you're handling money with your software, you need to know about different things than if you're not. If you're making front ends in government or legal domains, there are huge implications that will impact very low level technological choices. For example, are you allowed to do a DELETE? Or do accounting or legal requirements mean that you have to make a new row, which is the correction to the original row? If you don't know that about your problem domain, it doesn't matter how good you know your language, debugger, etc. Just one example, and every problem domain has them. Know about your problem domain. It has a dramatically bigger impact on your programming than any of the things listed in this article.
purplezooey 8y ago
What about dealing with a-holes. That's as important of a skill as anything listed in the article.
RickJWagner 8y ago
I found some it useful for me. Hacker News paydirt!
eksapsy 8y ago
There was one point where I just disagreed from my standpoint. The pomodoro technique. In programming for me, it never really worked. I mean, let's say I just got an idea for a specific piece of code, if the pomodoro triggers a break, I just lost my line of thought. When I'll get back after the 5 minute break, I will no longer remember what I was doing or how exactly I thought doing it. I don't really know if for you folks it worked, but for me for this reason it didn't work and it never probably will.
- rossdavidh 8y ago
  I can believe it works differently for others, but for me the pomodoro technique works very well. When I'm "in the zone" and banging away, I am much more likely to _fail_ to notice that there is a much easier approach that I could be trying. Interrupting my work occasionally for a few minutes, and then coming back, vastly increases the odds I will realize, "oh wait, instead of spending the next three hours doing this thing here, I could change a bit of this other part of the codebase and not even need that." Just my experience.
Tinned_Tuna 8y ago
"Start viewing willpower as a resource that can be depleted, and make sure you aren’t wasting it on trivial things." The concept of ego depletion is not as certain as it once was. http://www.slate.com/articles/health_and_science/cover_story/2016/03/ego_depletion_an_influential_theory_in_psychology_may_have_just_been_debunked.html http://www.slate.com/articles/health_and_science/cover_story...
- rossdavidh 8y ago
  The basic idea of "I'm tired, and more likely to make sloppy choices" is pretty well established, however.
tty89 8y ago
What are some of the "Meta" things for a web programmer (backend in dotnet) who is also interested in systems programming?
- davidjnelson 8y ago
  Perhaps things like reflection, the clr, and how the clr implementation interacts with the os.
  - deleted 8y ago
    [deleted]
madshiva 8y ago
You want be better? Error handling...
casper345 8y ago
Find a mentor, someone who refined their craft for years and only through experience they know the shortcuts and right implementations. My coding mentors really kicked me in the butt from being a cowboy self-taught coder to one who needs to read more about the theories of coding and philosophies behind them to up my game.

248 points by henryaj 8y ago

It has some great points. > When amateurs [play tennis], they don’t edge each other out by being slightly more skillful. Instead, it’s a contest of who makes the fewest huge, gaping blunders. I actually find this idea relevant to so many areas in life. Most of us are just about average in most of the things. It is frequent that hunting down the most critical "huge mistakes" is the easiest way to improve dramatically in a certain field. I feel like doing so just gives you the most bang for your buck, and therefore should often take precedence over slightly improving more general abilities (through a lot of hard work, usually).

edgarvaldes 8y ago
>It is frequent that hunting down the most critical "huge mistakes" is the easiest way to improve dramatically in a certain field. A very well known path to improvement in chess, for example. That's why you are encouraged to train tactics, tactics, tactics.
- evv555 8y ago
  Also an effective chess AI approach, minimax. Algorithm doesn't try to win but tries to cuts off paths that lead to the worst outcomes.
AnimalMuppet 8y ago
"It is often easier to not do something dumb than it is to do something smart." - M. J. Ranum?
lou1306 8y ago
This begs the question: What best practices can significantly reduce blunders and are (more or less) portable across languages? In my opinion, a good start is learning to use filter/map/reduce instead of big nasty for loops.
- legulere 8y ago
  Fail fast, avoid mutability, write tests
  - AstralStorm 8y ago
    Fail fast in development. Have fallback code for deployment or you will be in deep trouble. And as all solutions, sometimes the cost is too much for the immutability. Writing tests is a bit glib...
- AnimalMuppet 8y ago
  Big nasty for loops get replaced by big nasty filter/map/reduce calls. Filter/map/reduce may be less error prone than for loops, but if it would be a big and nasty for loop, it will still be big and nasty. Worse, "nasty" to me means more than just "what was inside the loop is large". It means that the loop itself was nasty, that is, it wasn't just a straightforward iteration over a collection, or a loop with fixed bounds. That means that it's harder to just replace it with a filter/map/reduce. I think that for loops can be hard for beginning to intermediate programmers, but with experience, they get easier. I don't remember exactly how many times I've messed up a for loop in the last decade, but the number is either 0 or 1. It's not 2. "Once in a decade" isn't exactly the source of large-scale bugs that people often claim for loops are. Note well, though: This is not my first decade as a programmer. The number was much higher my first decade. Filter/map/reduce may be easier to learn. You may in fact get to "one bug per decade" faster with them.
  - mseebach 8y ago
    You seem to be comparing a well-written, large for-loop (that has complexities dictated by true constraints, rather than programmer skill) with a poorly written functional chain. This isn't quite fair. The functional style nudges the programmer to think in the smallest semantic steps of transformation, in a way that the for-loop doesn't. Of course the programmer can ignore the nugde and write the same messy for-loop using functional constructs, and a good programmer can equally well write a big for-loop in a very manageable and easy to read style. But for an unexperienced programmer seeking general advice, I feel that recommending the functional style (with an additional urge to "listen" to what the style is trying to get you to do) is a pretty safe bet.
abecedarius 8y ago
I'm not sure how generally important this point is: perhaps it matters more for contest-style fields than more open-ended ones. The guy who can't "invert a binary tree" for his Google interview also made Homebrew.
hinkley 8y ago
With amateur athletes it’s a balance of both. You have to put in the hours. You can film your gait or your stroke all you want but you have to practice first. A lot of your practice is trying to cement the last four things you learned. You put in the hours and periodically you check in about improving your technique again. If you feel stuck in a plateau it’s probably time.

myWindoonn 8y ago

There's one piece of advice specific to programming which is missing from this listing: Read lots of code in lots of different languages. Aim to read, as a general rule, about twice as much code as you write, and to be able to read twice as many languages as you write in typically. Edit: The average piece of code is written once and read hundreds to thousands of times by people. It's not unreasonable to think of code as a read-oriented activity, not a write-oriented activity.

gorpomon 8y ago
This is a suggestion I see given a lot, but something that falls flat to me personally. The analogy I would put forth is that it feels like reading lots of different furniture assembly instructions in the the hopes of getting better at assembling IKEA furniture. Such a thing is informative, but probably not nearly as much as just assembling lots of IKEA furniture. To those who make it a point to read lots of code, are there approaches you take or methodologies you use? Or certain things you look for? Or concepts you compare to them to in your native language?
- rmgraham 8y ago
  More like encouraging the creators of IKEA furniture assembly instructions to read lots of other instructions so that they can get better at writing instructions. An analogy for improving one's ability to assemble IKEA furniture, using this pattern, would be to watch others assemble all types of furniture in order to improve your own abilities. Wouldn't it?
- extralego 8y ago
  I think this is a good point. I have mostly gained knowledge of software design by doing this, because once I work through a process that might happen in the code, I can infer the reasoning behind design decisions. I am still learning myself, but so far, reading production code now seems much more valuable than the pseudo code often found in blog posts. They each serve different purposes but I have found myself reading too far into pseudo code when trying to understand a concept can add unnecessary confusion. With production code, what you see is what works. And that just gave me an idea: programming books that only use production code! It might do less handholding and would certainly be harder to write, but maybe the value would make it worthwhile.

poulsbohemian 8y ago

I suppose this article is about programming rather than software engineering but at the same time, I find there are a lot of these articles with heavy emphasis on code. I'd much rather people who want to improve their abilities keep an eye on architecture, and I thought the article yesterday about Uber's reasoning for moving to MySql had some gems in the comments, like this one: https://news.ycombinator.com/item?id=12166585 https://news.ycombinator.com/item?id=12166585. The code is often secondary to the architectural choices. Get the architecture right, and the language or the quality of the code is frankly, a secondary concern.

maerF0x0 8y ago
> and I thought the article yesterday Link?
- poulsbohemian 8y ago
  https://news.ycombinator.com/item?id=17279687 https://news.ycombinator.com/item?id=17279687. Or I guess rather I should say the article posted yesterday had excellent commentary in 2016 and 2013 ;-). The money quote was " And in this particular case, I'd say they shouldn't be using the database to do locking around sending a receipt. It should be put into a queue and that queue should be processed separately, which avoids the transaction problem altogether." For all the people who mock the GoF book or the idea of design patterns, that right there ^ is a pattern of software engineering that you can recognize and apply. It requires a layer of architectural thinking beyond just the code, but it is the kind of thinking that when I see it in people separates them as senior from not senior.
  - sevensor 8y ago
    I think the problem with the GOF book is that too many people used its respectability for too long to justify terrible designs, in opposition to both common sense and the guidance in the book itself. This has tarnished the reputation of what otherwise might be a pretty useful book.

beat 8y ago

Some of this hinges on work environment, not just habits. I was glad to see the reference to Cal Newport's "Deep Work", but it's hard to do deep work when you have three meetings scheduled that afternoon. edit: I consider Deep Work a must-read for anyone serious about doing hard things.

rubidium 8y ago
FYI your startups website gets flagged by chrome as your certificate date being invalid.
- beat 8y ago
  Yeah, I know. I hit a wall on it and have been taking a break before starting it back up. The cert expired, and when I say "I'm not doing anything with this", I need to mean it. It'll get fixed in about a month; I'm planning on firing the machine back up with a fresh perspective after the 4th of July.

startupdiscuss 8y ago

I wonder if there is any data on the efficacy of these techniques. Deliberate practice makes sense to me, but I really wonder if the others require purposeful study or if you just pick up metaskills if you hack away at your project. Heck, in 5 years I might be reading an HN article: "Deliberate practice isn't all its supposed to be." And an article about how the original deliberate practice study was flawed because it just forced people into hours of extra practice or something.

mseebach 8y ago
It's a question of keeping track of which is the map and which is the territory. The point, I believe, is to be continually and relentlessly introspective, asking yourself how you can do better today than yesterday (and having a realistic view of what 'better' is). Deliberate practice can be helpful in forcing such introspection, if you let it. If you just go through the motions, it won't help much, certainly not sustained. You end up with cargo-culting. The classic example is the GoF Design Patterns book - it was a very good book, at least at it's time, you could expand your horizons a lot by reading it, and get a lot of tricks up your sleeve to deal with certain tricky, but relatively common, situations. But if you start actively to impose design patterns on code that doesn't need it so you can tell yourself (or your peers or whoever might listen) that you're a design patterns kind of guy, you end up with overly complex and hard to read (ie: bad) code.
ztjio 8y ago
I think the mistake here is that you think “purposeful study” and “pick up metaskills as you hack away at your project” are not both examples of (potential) deliberate practice. What makes either one deliberate or not is whether you make a point to focus on how well it was done, how it achieved goals (or not) and how to improve. That’s the deliberate part and that’s the part that makes the difference and is missing by default. As long as you’re constantly evaluating and making attempts to improve, it doesn’t matter so much in what context you’re doing the thing, whether it be for fun, for learning, for work, or whatever. “Practice” simply means you’re actually doing a thing as opposed to studying it theoretically. Though I think many people have a habit of reading into that word the notion that what you are doing is a throwaway or has very low expectations of success or importance. But keep in mind that what a doctor does every day is called “practice.”

megaman22 8y ago

The biggest barrier I often see is that people won't get in there and try things. It's code, and it's under version control. You can do basically anything, and the worst usually is you have to pull down a fresh copy. So much indecision and debate and time wasted, because people won't poke at things to figure out how they work.

convolvatron 8y ago
when i approach a new largish (say < 500k lines) codebase I'm supposed to be working on, I'll often just go on a giant tear and completely refactor it to be the way I like it. in the process I end up breaking several foundational assumptions and have to spend even more time carefully backing out my changes and trying to get it to work again. rewriting the whole thing isn't your job (usually). check out a fresh new copy. now you can make a pretty informed decision about the best way to make the changes you're actually being paid to make. or, more rarely, now I have a less tested but substantially smaller version (once I replaced a 500k library with a 15k version by gutting all the abstraction layers), and if its not a maintenance smallest-delta kind of deal, I just go with that. anyways, the shortest path to the goal isn't always to chip away gingerly at the surface with your eyes closed and your head turned away - take a nice deep dive, you can always swim back up.

tgb 8y ago

Surely five minutes spent learning a debugger isn't really in the spirit of the rest of the post. It should be more like "read the entire man page of the debugger and try some of it out." Five minutes is only enough to learn how to shove the work-flow you already know into a new tool, not to learn the work flow that is actually suited to that tool.

asdsa5325 8y ago

Repost from 10 days ago: https://news.ycombinator.com/item?id=17208419 https://news.ycombinator.com/item?id=17208419

hellofunk 8y ago

> Everyone’s strategy, therefore, should be to identify and eliminate these big, costly rookie blunders, one by one. This is far more effective than getting quicker, hitting harder, or making that one brilliant shot now and then. Brilliant observation.

andrewstuart 8y ago

Things that contribute to the ability to get things done: - ability to solve problems - understanding of the data structures you are working with - ability to formulate solutions that requires less code - doing one thing at a time - knowing how to use the debugger - experience working within the architecture of the application you are working on About 1,000 other things too.

rossdavidh 8y ago

The things listed are all nice and all, but here's what I've seen result in dramatically better programming: Know your problem domain. There are, in basically every field of programming, some very domain-specific problems which you need to know about, that will be much more important in whether or not you do good programming than any of the things listed here. If you're handling money with your software, you need to know about different things than if you're not. If you're making front ends in government or legal domains, there are huge implications that will impact very low level technological choices. For example, are you allowed to do a DELETE? Or do accounting or legal requirements mean that you have to make a new row, which is the correction to the original row? If you don't know that about your problem domain, it doesn't matter how good you know your language, debugger, etc. Just one example, and every problem domain has them. Know about your problem domain. It has a dramatically bigger impact on your programming than any of the things listed in this article.

purplezooey 8y ago

What about dealing with a-holes. That's as important of a skill as anything listed in the article.

RickJWagner 8y ago

I found some it useful for me. Hacker News paydirt!

eksapsy 8y ago

There was one point where I just disagreed from my standpoint. The pomodoro technique. In programming for me, it never really worked. I mean, let's say I just got an idea for a specific piece of code, if the pomodoro triggers a break, I just lost my line of thought. When I'll get back after the 5 minute break, I will no longer remember what I was doing or how exactly I thought doing it. I don't really know if for you folks it worked, but for me for this reason it didn't work and it never probably will.

rossdavidh 8y ago
I can believe it works differently for others, but for me the pomodoro technique works very well. When I'm "in the zone" and banging away, I am much more likely to _fail_ to notice that there is a much easier approach that I could be trying. Interrupting my work occasionally for a few minutes, and then coming back, vastly increases the odds I will realize, "oh wait, instead of spending the next three hours doing this thing here, I could change a bit of this other part of the codebase and not even need that." Just my experience.

Tinned_Tuna 8y ago

"Start viewing willpower as a resource that can be depleted, and make sure you aren’t wasting it on trivial things." The concept of ego depletion is not as certain as it once was. http://www.slate.com/articles/health_and_science/cover_story/2016/03/ego_depletion_an_influential_theory_in_psychology_may_have_just_been_debunked.html http://www.slate.com/articles/health_and_science/cover_story...

rossdavidh 8y ago
The basic idea of "I'm tired, and more likely to make sloppy choices" is pretty well established, however.

tty89 8y ago

What are some of the "Meta" things for a web programmer (backend in dotnet) who is also interested in systems programming?

davidjnelson 8y ago
Perhaps things like reflection, the clr, and how the clr implementation interacts with the os.
- deleted 8y ago
  [deleted]

madshiva 8y ago

You want be better? Error handling...

casper345 8y ago

Find a mentor, someone who refined their craft for years and only through experience they know the shortcuts and right implementations. My coding mentors really kicked me in the butt from being a cowboy self-taught coder to one who needs to read more about the theories of coding and philosophies behind them to up my game.