
How to become a dramatically better programmer - henryaj
https://recurse.henrystanley.com/post/better
======
myWindoonn
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
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?

~~~
jrockway
I think the idea here is to look at the code for the libraries you're using.
The documentation might lead you to believe it behaves in a certain way, but
the actual code is the true source of truth. Open it up and have a look
instead of wondering.

Something I liked about working at Google is that I never had to wonder what
the lifecycle of a certain request looked like. I could always open up the
code for the server I was trying to talk to, and piece together what "internal
error" really meant, or what "optional" fields were actually required to make
the request succeed.

~~~
antoaravinth
That's excellent point. When I digged into express source I understood several
things like how it extends the response object via prototype to add methods
like send etc. Also you will understand how exactly next function is
implemented and then you can literally understand anything about the library.

------
poulsbohemian
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
> and I thought the article yesterday Link?

~~~
poulsbohemian
[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
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.

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

~~~
lou1306
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
Fail fast, avoid mutability, write tests

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

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

------
Tinned_Tuna
"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...](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)

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

------
beat
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
FYI your startups website gets flagged by chrome as your certificate date
being invalid.

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

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

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

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

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

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

~~~
davidjnelson
Perhaps things like reflection, the clr, and how the clr implementation
interacts with the os.

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

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

------
asdsa5325
Repost from 10 days ago:

[https://news.ycombinator.com/item?id=17208419](https://news.ycombinator.com/item?id=17208419)

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

------
RickJWagner
I found some it useful for me.

Hacker News paydirt!

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

