
How I Became a Better Programmer - Flollop
http://jlongster.com/How-I-Became-Better-Programmer
======
couchand
There's a lot of value here, but I have to raise concerns about a few things.

First, the title: written in the past tense makes it seem like he believes the
journey is complete. The article itself doesn't convey that message,
fortunately. But I think it's worth noting that a critical skill for a
professional is constant education - don't be satisfied that you're already
"better", get better every day.

I also strongly disagree with the suggestion that you should ignore the form
of your code. Code is read many, many times more than it is written, so
improvements to your own and your teammates' understanding can pay huge
dividends.

In particular, the advice to "not worry about" DRY and duplicate freely
reveals a common misunderstanding. DRY shouldn't be taken literally, it is a
recognition that repetition is evidence of some greater underlying truth. By
duplicating freely rather than thoughtfully avoiding duplication, you're just
creating opportunities for bugs.

~~~
richdougherty
Responding to your last two paragraphs...

James's suggestions about ignoring code form, DRY, etc resonate with me
because I'm someone who is usually inclined to spend too much time on those
things. I consciously try to reduce the effort I put into those things and
instead focus on trying to get the code to actually _do_ something!

~~~
BurningFrog
The time to clean up the code is when it already _does_ what it should.

That is: Make it pretty and readable and DRY once the code works. Until then
my code can have several ugly and improvised things I've left for later.

~~~
fauigerzigerk
_> The time to clean up the code is when it already does what it should._

I'm a bit skeptical of that as a general principle.

I want code to be a consistent representation of my mental model of the
solution _at all times_. I use code to help me think, remind me of my thinking
and communicate with others. It's not just a series of commands that make a
machine do something.

As long as any ugliness is not in conflict with this purpose it's fine. I can
totally live with functions that are a bit messy and probably need cleaning up
later.

~~~
tshannon
Yep, I agree. I see it more as a list of priorities, not necessarily
sequential steps.

1) Make it work 2) Make it maintainable 3) Make it fast

All three should be on your mind when developing something, but if you have to
choose between 2 and 1, go with 1.

~~~
AstralStorm
And you end up with the 60+ year old TODO this way. Or lack proper reason
comments (the why) and end up in a gaggle of legacy code.

My rule is simpler: never write instant legacy code. If it feels like
something you won't understand a month later, it likely is legacy code.

If it reads badly (and I'm not talking about this or that brace or whitespace
choice), then it also provably is in that category.

~~~
ant6n
If there is actually a trade-off like tshannon notes, then by not making it
work first, you may end up with un-finished projects.

~~~
AstralStorm
The solution to making it work first is to make a prototype with the correct
design. You do not have to implement it at once.

(On C2 wiki, a proper SpikeSolution)

If you hit a case your design cannot cleanly handle, it is time for redesign,
but often a tiny amount of design constrained by use cases will expose a good
design quickly.

------
markwaldron
Those that are complaining about this article: Care to share the experiences
that made you a better programmer? Can you link to blog posts yourself or
others made that we may find useful?

~~~
pacaro
I like this question!

I think that working in constrained environments early in my career gave me
lasting instincts both for efficiency and maintainability/sustainability. I
wrote a lot of code on Win16, GeoOS, Epoc32, and a variety of embedded
systems. Debugging tools aren't good, the dev-test-repeat cycle can be
arbitrarily long, so you learn to avoid a certain sloppiness.

I've been having fun with PICO-8 on a Pocket CHIP, it has some similar
constraints, the keyboard is awful and the screen is small, so there are
similar incentives, and the added bonus that making a cute game is fairly
accessible.

~~~
pacaro
Also, pre-internet I learned from books. I lived in a provincial town, so I
would go to London, buy a book and then devour it, but if I didn't understand
something, I had to either keep plugging away until I did understand it, or
wait possibly weeks til my next opportunity to find another explanation.
Keeping looking at blogs until you find an explanation that makes sense is an
amazing resource for getting shit done, but doesn't encourage deep
understanding when you really need to internalize something

------
SnowingXIV
___Learn C - Just the basics, if you don 't already. I think it's valuable to
understand why everyone complains about it._ __

When you say just the basics, what are you referring to? Syntax? Pointers?
Dealing with garbage? I 've got a vague idea about it, but never had to really
do anything with it so I feel now is a good time to mess around with it.

Great read though, always a pleasure seeing James mentioned (someone that
definitely inspires me).

~~~
anatoly
I think most advice to "learn C" really aims to get you to learn how things
work closer to the metal. What actually becomes of your code and data, broadly
speaking, once your high-level language's interpreter or compiler have had
their way with them.

So things like:

\- viewing primitive objects, structs and arrays as blobs of bytes arranged
between address X and address Y

\- a pointer as an address of that blob. Understanding what it means to copy
that blob vs. to pass around the pointer: calling by value/reference not in
terms of the semantic effect, but in terms of what happens underneath.

\- the stack and how it's typically used, esp. in recursion. Local vars vs.
heap-allocated vars. How control flow leaves its trace on the stack. How
arguments are passed and return values are returned.

\- complex data objects viewed as blobs of memory pointing to each other vs.
pointers. Concept of "owning" such a blob and how ownership is passed.
Understanding how your language's runtime keeps track of the blobs if you
don't have to, and what are common pitfalls.

\- clear understanding of the difference between int8, int32, int64. Strings
as null-terminated or counted arrays. Bitops.

"Learn C" is just a useful way to force you to internalize all of the above,
because you can't properly "learn C" without doing that. But it's the above
that helps you back in your favorite language. That, and perhaps the fact that
C gives you a feeling what it's like when you can look at a line of source
code and understand immediately what happens in the machine (broadly) when
executing it. No hidden effects. C++ doesn't have that (constructors you don't
know about when looking at the line, exceptions etc.) That "local clarity"
isn't the most important thing in the world, but if you feel and appreciate
it, perhaps you'll strive for local clarity back in your favorite language,
too.

------
jondubois
My advice is that whenever you become confident/comfortable in your current
work, that's when you have to change team or company. Whenever it gets easy,
it means you have stopped learning. I agree with what was said about tools; it
doesn't make you a better programmer to know all the latest ES6 features and
frameworks. What makes you a better programmer is your ability to adapt and
customize your approach to different situations and environments (with
different scalability, stability, interactivity, security, time and regulatory
constraints). I've been through a lot of different companies (I usually stay 6
months to 1.5 years each on average) and the environments/workflows are
usually VERY different each time. After changing a few times, it gets easier
to move between different companies - You learn how to produce code that is
universally acceptable and not just acceptable within the confines of a single
company.

~~~
sillysaurus3
_My advice is that whenever you become confident /comfortable in your current
work, that's when you have to change team or company. Whenever it gets easy,
it means you have stopped learning. I agree with what was said about tools; it
doesn't make you a better programmer to know all the latest ES6 features and
frameworks._

It's tough to say. Given a choice between being a JS ninja capable of
hammering out [http://www.track-trump.com/](http://www.track-trump.com/) in a
week, or a generalist with a wide variety of skills, the former is so much
more valuable from a monetary standpoint that it'd be hard to turn it down.

It's less satisfying, and you end up less capable in certain respects, but it
all depends which axis you want to optimize along.

~~~
TeMPOraL
Offtopic, but I have to say - I love the site you linked. This should be a
standard thing done about every politician in power.

~~~
sillysaurus3
It's the brainchild of Sam, Greg, Alec, and Peter.
[https://twitter.com/sama/status/822494523959877632](https://twitter.com/sama/status/822494523959877632)

Greg is the JS ninja I was referring to.
[https://twitter.com/sama/status/822500368797966336](https://twitter.com/sama/status/822500368797966336)

------
Bahamut
Not sure I agree with a lot of those recommendations - the number one
recommendation I have is to challenge yourself as much as possible, whether it
is with picking up algorithms, or learning new things such as the workings of
a compiler. Other aspects include challenging yourself to be more efficient in
your workflow, such as running through your thought process faster, decrease
iteration time due to absorbing prior lessons, etc. This also includes the
humility of being willing to learn from anyone, including developers who
haven't been in the profession as long or haven't accomplished as much as you
- ego can get in the way of challenging yourself to better yourself, and maybe
that more junior person will indeed become better than you/has better
intuition.

Make sure you get good rest too - all the learning in the world won't help you
if you cannot retain what you learn. If you're in a pressure cooker of a job,
consider transitioning to a less stressful job to give yourself space to work
on yourself so you're better prepared for the long haul/set yourself better up
for success.

Lastly, focus on being a problem solver - this means if you see a point of
friction/inefficiency/tricky situation, that is something to be solved. Your
success rate in solving these problems is ultimately what drives stable
success. This means practice as much as possible applying your mind to these
problems, and if you fail, be ruthless about figuring out what you did wrong
and iterate. Very few people can get away with being excellent there with
minimal effort.

------
hinkley
> Even now, though, I continually doubt myself. The point is that this feeling
> doesn't go away so just try to ignore it,

No. This is the advice you'd expect from someone in their early thirties who
has been coding and doing nothing else their whole adult life.

Your doubts should fuel your learning and temper your decisions. They are the
voice in the back of your head and you can make it work for you instead of
against.

Mastery isn't working harder, it's working smarter. It involves retraining
your instincts to match your rational understanding of the domain. You get the
shape of a problem and you naturally gravitate toward a reasonable solution
without having to intellectualize the whole process first. If challenged, you
of course have to walk back your intuition and build a step by step case, not
just a rationalization, but that's fine because you've trained for that.

Study something else, anything else. Preferably with a teacher. What you're
going to learn about the process of learning (and teaching) will be profound.
It will make picking up and putting down new things easier, which will keep
you from getting in a rut later.

Source: 40-something who spent his precocious twenties only coding. I learned
a hell of a lot but I didn't know everything.

~~~
vdnkh
When you mean studying something else, do you mean something academic or
hobby-based? I think having deep hobbies are really beneficial, and with mine
I like to take a more "organic" or free-form approach to learning.

~~~
hinkley
Generally I think developers don't see our 60 year history as a liability.
We've only begun to figure stuff out (the 90's and early 00's were punctuated
by arguments over Tony Hoare's work in concurrency, that was all done in the
mid 70's by people who don't seem to be aware that they were all written by a
single person).

I think specifically it helps to deep dive on something that is much older
than programming. A craft, an art, a sport, or a physical passtime (dancing,
martial arts, kayaking). People have been teaching that stuff for centuries
and it turns out they actually know a few things that we only pretend to know.
Two things in particular stand out.

Cross-training is one. The notion that pushing harder, white-knuckling
everything, is a virtue in software development is rarely ever challenged. Not
good yet? Just keep doing it.

The second is that we don't get that rules exist in a context. Always do this.
Never do that. As you mature it is partly your responsibility to figure out
when you are no longer part of that context. When you are ready, you will
understand why you had to follow the rule and why you are now free of it. Look
at the backlash against DRY. A bunch of people who've been using it for 10-15
years figuring out it's not all roses. See also: 'it depends...'

------
coding123
Ok I came in thinking this was going to be another "don't do this, don't do
that" type of deal, but was pleasantly surprised about it being upbeat and
closer to e-prime. Nice job.

~~~
a3n
TIL: e-prime. Thanks.
[https://en.wikipedia.org/wiki/E-Prime](https://en.wikipedia.org/wiki/E-Prime)

~~~
sillysaurus3
The E-Prime article used to be written in E-Prime. Unfortunately it looks like
they reverted it.

It was especially fascinating because the first sentence was something like
"E-Prime refers to a version of the English language..." instead of "E-Prime
_is_ a version...". The article had all sorts of interesting quirks that
really highlighted the diffs.

------
JCDenton2052
" (This also applies to the DRY principle. Don't worry about it so much. Feel
free to duplicate.)"

The sort of advice followed by programmers when building systems that will
accumulate heavy technical debt that someone else will eventually have to sort
out.

You will not become a better programmer this way.

~~~
Chris2048
application of DRY can also accumulate technical debt.

The main thing is communication - duplicate, but put comments in both places
regarding the duplication so they can be merged if they haven't diverged after
time.

This is also why I dislike "no comments in code" principles - communication is
key, and there are some things only plain English can convey; If all your
comments are code, you aren't communicating enough!

------
philippeback
We've got pretty good continuations, call/cc, generators etc in here too.
[http://pharo.org](http://pharo.org)

If you do want to leave the comfort zone, this is a must.

And we really do not care for the framework du jour, even if we use some.

------
_pmf_
I think that a lot of the cognitive dissonance between what we think very good
programmers do and what we ourselves do stems from the fact that the people
whom we perceive to be very good programmers do greenfield projects and we
non-rockstars are stuck having to maintain legacy applications, where there's
a lot less room to be "very good"; mostly, it's a success to do this work for
2 weeks before giving up.

------
snackai
He mentions SICP, which is trending on HN right now:
[http://sarabander.github.io/sicp/](http://sarabander.github.io/sicp/)

------
partycoder
I would shorten it to:

\- develop critical thinking

\- take time to learn

\- force yourself to understand (avoid cargo cult)

\- accumulate non-redundant experience

~~~
alextheparrot
At this risk of sounding like a Buzzfeed headline, number 3 has been key for
me. Diving into a new "whatever" and asking how and why it does something
makes it so much easier to "get" something. Bottom up vs top-down approach.

------
jaequery
all of these suggestions are tbh ok. but id like to say one of the things that
helped me most to get better was when i wrote my own framework. doing so helps
you understand not just to code, but how to architect for many many different
scenarios.

this allows you to write simpler and cleaner code, which is a high quality
code.

and lots of coders think clean code means isolating code into many different
pieces but that is so far from the truth. clean codes to me are generally less
lines of code, files, and places to look for your stuff. its elegant and
efficient. should put effort to separate less and group more. i cringe
everytime some dev breaks up a simple methid into dozen pieces when there
arent much justification to begin with.

so pls try write your own framework as an exercise. even in a crowded seas of
framework, coming up with your own will be the best learning excercise you can
do imho. it doesnt even have to be framework but something along the lines
that will lead you to think outside the box.

------
sriram_iyengar
Excellent practical comments. Have not attempted the compiler piece yet. Will
try Also, taking pet projects and tech to completion has helped me learn tech
deeper. Plus doing office-Wide sessions in sharing them.

------
Fifer82
I also have 10 years experience but I am in the same job because I can't
defeat recruitment agencies. If today a new Framework, let's call it
"Framework9" is announced, all jobs will instantly want 3 years experience,
and 4-5 years experience of all other known frameworks, preferably in all
languages, and preferably a designer who is a master of photoshop and CSS,
with a long history of blah blah blah blah

I am really starting to wonder what other careers are possible as this kind of
sucks. I am especially bad at bullshitting so I don't really get anywhere.

~~~
CaRDiaK
In my experience that's often sign of either a job position where they don't
really know what they want, or a recruiter casting a wide net trying to catch
people with a bit of each on their resume. Playing keyword bingo. I've had
much more success by looking around on the likes of linkedin / twitter to find
the good recruiters. Single people with their own shop or ones within an org.
The ones who seem to be well recommended or seem to know their game. Approach
them personally, make friends with them, get to know them. Tell them you are
bad at BS. Once they get to know you, they will go to their network. Let them
do their job of finding you the position. Or, they will put you on their books
for when a suitable one comes up. I find the quality of positions and work is
much higher doing things this way. This took me a long time to work out too.

------
antoaravinth
>> Take on big projects. Get uncomfortable.

To add few more points on this, work on side projects. I have to tell, how a
side project can help you. For example, I was very comfortable using React in
my project. I thought of building a simple preview container (for different
sizes from desktop, mobile, tablets), where user can drag and drop few
components, position them etc.

I'm in the initial phase of this and guess what, its really helpful. Making
you uncomfortable at times (as in this case for using React to position
components on the fly, which I had never done before) helps a lot.

------
keithnz
I agree with the author, I think people are getting too hung up on the "fluff"
statement. His point is that their are deeper issues in programming that will
make you a better programmer. Still useful to write clear concise code, just
don't get hung up on it, and certainly don't mistake it for being a good
programmer.

My other piece of advice would be to code with other people as much as you
can, ideally from very different programming backgrounds.

------
latenightcoding
I'm glad the author mentioned learning new languages. I have been coding Go
recently and even tho it's not my main language, it has helped me to think
about simpler designs when I'm using other languages.

Other than that becoming proficient in C and systems programming (Thanks xv6
book) was a major game changer for me.

------
darkerside
Regarding the claim that only Scheme implements continuations, aren't
coroutines/generators in Python a type of continuation as well?

~~~
metaphorm
yes, they absolutely are. the author would probably argue that only scheme
natively implements first-class continuations though, which is more specific
and a little different.

------
j_s
Step 1: Document all the things.

Step 2: Update the documentation the next time through.

There is no step 3! ;)

------
k__
> Find people who inspire you, but don't idolize them.

Luckily this is rather easy in the JavaScript world, haha.

Many good devs have bad attitudes, which makes it a bit harder for junior devs
to value their skills, but it prevents them from being idolized too much.

Also, I always think it's a good sign if devs I look up to said stuff I found
bad, so I know I still see them as humans and not as infailable idols.

> Don't devalue your work

This is a hard one.

On the one hand, if you work with too much non-technical people, they tend to
overvalue your work. I met rather much mediocre devs who got sold to me by
managers as the best devs ever. They simply always "delivered", which some
devs don't. But finishing your work is a minimum in my eyes and not the "best
thing ever".

On the other hand, if you only work with highly skilled devs, you could start
to think you can't do anything right. In the end you got skills worth mad
money to non-technical people, but you think you wouldn't get a job ever again
if you lose your current one.

> Don't feel pressured to work all the time.

This is hard, especially for us devs who think of programming as their hobby.

I started freelancing 2 years ago and got about 4 weeks holidays in this time.
I worked on many weekends. Not because of "crunch time" but because I liked
what I was doing, but I found out it really takes its toll :\

Now I try to do 3-6 month long projects and 1 month holiday after every
project. Also, only weekend work on "crunch time".

> Ignore fluff.

This is really hard, because fluff is fun.

I started with JavaScript by reading "JavaScript: The Good Parts" and "Pro
JavaScript Techniques" and I learned a lot of pit-falls before I went in my
first big JavaScript project.

But I came at the price of fluff everywhere.

It gives me a nice feeling reading about other devs who just don't get
async/await, observables or destructuring. Not because I think they are
idiots, but because I think "This seems to be hard and I already know about
it!"

But yes, I probably poured days into learning observables and probably can't
use them in my next projects.

> Dig into past research.

This is a nice thing, because most people don't do this.

I got a big book on HCI research of the last 50 years or so and I always find
nice solutions for my problems there. Since many of the web and mobile
problems have already been solved with experiments on research devices that
never went mainstream.

> Take on big projects. Get uncomfortable.

Also: Let your life depend on it ;)

If you need to pay the rent with a project, you're much more inclined to
"really" finish the thing and "really" learn the hard parts you need to
understand before you can implement the solutions, which you need to "ship".

(Okay, letting your life depend on it isn't that good of an idea, but if money
is involved it's often easier for me to walk to the end. You always should
have enough money backed up to survive a failed project or two, so you can
also logically justify to leave your comfort zone)

~~~
weavie
> I got a big book on HCI research of the last 50 years or so and I always
> find nice solutions for my problems there. Since many of the web and mobile
> problems have already been solved with experiments on research devices that
> never went mainstream.

Please share, which book is this?

~~~
k__
the human computer interaction handbook

by Julie A. Jacko and Andrew Sears

------
omgno
> Learn C - Just the basics, if you don't already. I think it's valuable to
> understand why everyone complains about it.

WHAT? C is beauty, C is art, C is clean and concise. What is this guy talking
about? Nobody complains about C, it's about C++ they complain, you idiot.

------
arkadiytehgraet
Apparently the author still has a long way to go to become somewhat good,
given how this link returns 502 on moderate load for a something like a simple
blog. I also wonder if this discredits the article itself.

~~~
metaphorm
I don't think it discredits the author's coding skills to _not_ being using
cloudflare (or similar) on what is otherwise a very low traffic blog. you
don't get HN spiked every day.

------
fiatjaf
He writes "find people who inspire you, but don't idolize them".

And yet, his blog repository[1] which is, in his words, "This is just a stupid
simple server that indexes posts off the filesystem", has 1193 stars. Why
would anyone star anything like that if not because they idolize jlongster?

[1]: [https://github.com/jlongster/blog](https://github.com/jlongster/blog)

~~~
nsfmc
i don't see the contradiction. he's not asking for people to star his repo and
it's not unreasonable to offer this advice if you perceive harmful cults of
personality developing in a community. besides, lots of people just star
things for lots of different reasons, bookmarking, giving props or ???.

~~~
fiatjaf
"or ???", what does that mean?

I didn't point a contradiction, just noted that he has fans that idolize him.
The contradiction is theirs.

~~~
pm
Having an audience doesn't mean having a cult of personality.

