
ASK HN: How are you becoming a better programmer? - tom_ilsinszki
People do not tend to get much better at their professions after 3-4 years - as I heard today in a TED talk.
This made me ask myself, if I was constantly becoming a better programmer or was just staying on the same level.<p>What are the most significant techniques / books / methods / thoughts that improved you as a programmer?
======
patio11
Make stuff. Make new stuff. Make the old stuff better. Find people who are
good at making stuff. Make stuff with them. Get them to tell you why your
stuff sucks. Make your stuff suck less. Find stuff you like. Study how that
stuff was made. Make stuff like it. Do not read stuff or listen to stuff that
does not help you actually make stuff. Realize that making stuff is easy but
making the right stuff is very hard -- optimize efforts accordingly.

------
chipsy
1\. Good/difficult programming books, the more theoretical the better. Blogs
are full of windbags and echo-chamberism; after a certain point, you'll just
waste your time reading them. I've kind of exhausted what I can read from my
local Borders just sitting in the cafe, unfortunately, and it gets fairly
expensive to buy niche stuff.

2\. New languages, new application domains, new concepts. This could mean
"closer to the hardware," or "further from the hardware." They both have uses.
I have a lengthy list of languages I want to get around to learning...but have
no compelling immediate use for, which is a strong discouraging factor. Hence
application domains - if you're doing coding for small embedded processors,
you're forced down to a few language options. If you're doing web apps,
another set of options. If you're doing compilers, a third set of options. Et
cetera. Find the app that lets you learn the language.

3\. Cycling between "research" coding(a tool, algorithm or data structure that
might do something cool and useful) and "production" coding(bang out the app).
If I did only the latter, I probably wouldn't learn anything! But the former
lets me lay down a strategy for "this time, I'll be more efficient by doing
x...." and then I try it and find out if x worked.

I would also note that commercial programming work is likely to limit your
growth unless you're working at a hardcore tech company. (I'm unemployed at
the moment, going into indie game development, and I've been consistently
emphasizing the use of technology to automate more, tighten the iteration
cycle, and wring out more quality in less time, so I have few limits other
than "make it good enough to pay the bills.")

------
scorpioxy
Well, to make a muscle grow you have to subject it to increasing values of
resistance(i.e. weight training).

From what i understand, the brain works in a similar way. So you need to
challenge it with new stuff, harder stuff.

So, if you always work in C, try some higher level stuff. If you always work
on web technologies, try some assembly and so on....

For me, I am trying to learn about newer fields. So re-learn my math skills,
learn more about electronics and stuff like that.

I am also trying to shock my brain into becoming better(not necessarily faster
since age slows you down) by changing the field i am learning every once in a
while. So electronics, then math, then computers....

Note that i know that this is bad if you're trying to become an expert at
something. I'm not. I am just doing this for fun and self improvement.(and
because, apparently, I'm a geek)

------
dmoney
For me, it really helps to have external structure in which to learn. I had
fooled around with computers, but I don't consider that I really learned how
to program until CS 101. Getting a job and learning what a big disgusting mess
software can sometimes be was another big step. Finishing projects I start on
my own is a lot harder.

I started composing a longer response to this, but it's getting too long for a
comment one thing from it. Maybe I'll post it when it's done. Here's a
paragraph from it:

 _One thing I continue to learn is how bad I am at estimating. I think the key
to estimating how long a software project will take is not to lie to yourself.
It's easy to be overly optimistic about your ability to keep things on
schedule by working extra hard or being extra smart (step 1, step 2, ... and
then a stroke of genius happens... step 4: profit!!!). Software complexity
(and hence development time) grows non-linearly with feature set. When you're
thinking about squeezing in one more little waffer-thin feature, you have to
trust your gut when the little exclamation point or question mark appears over
your head._

Also, estimating (and re-estimating) takes time. Giving estimates off the top
of your head is a recipe for disaster.

~~~
hga
Hmmm, it wasn't until almost 20 years after I had started programming that I
could make solid "off the top of my head" estimates (by the end of the project
(C++ multithreading server), per item I was accurate within 30 minutes).

I think it's both a matter of experience including some on the particular
project and eliminating the unknown unknowns. Doing the latter is my first
priority in a project, e.g. by getting _something_ working end to end ASAP.

Also, to avoid the "working extra hard" trap (what, you aren't already working
as hard as it makes sense???), you must always make the estimates in man-
hours, not _The Mythical Man Month_. Then and only then should someone try to
turn that into a calendar schedule, allowing for inevitable downtime and so
on.

------
csomar
Blogs and sites

* Joel on Software * Coding Horror * Paul Graham

You don't have to agree with them all, but knowing others' opinion help you
make yours.

I also hang on Hacker News and StackOverFlow a lot, HN gives varieties of news
and StackOverFlow programming related. The interesting in those communities is
the user base (smart developers), so you can learn a lot from them.

Try to browse the HN archive and read it. Use google

site:ycombinator.com "Ask HN" or "Ask YC" +a keyword.

This will give you discussions on niches you want to know about.

------
revorad
I'm only a beginner but one idea which stuck with me was that of changing my
domain of work ever so often. This is what Richard Hamming suggested to keep
doing great work and this is what Eric Drexler recommends to get a good
understanding of Science as a whole. If you think of programming as a tool for
solving problems, then you could sharpen the tool by applying it to different
types of problems every few years.

------
cmallen
I continue to get better, and I'm almost to the 4 year mark. I've improved
more in the last year than I did in my second year. (First year programming
professionally remains the largest leap, although perhaps the least
significant.)

As to how I become better, I am an obsessive generalist. I don't like not
understanding the stack that makes my projects tick. I don't get into
wasteful/unproductive levels of implementation detail, but I do my best to
grok the things I'm working with.

(I'm capable of patching django core for custom purposes if I need to, for
example.)

I was pretty clueless on CSS until recently. Now I'm very slightly better than
clueless. (I have a better grasp of display and position now, for example.)

I continue to use tables where they're (probably) inappropriate but for my
users, it doesn't matter. Too many IE users and not enough mobile users to
really care.

I just keep learning unfamiliar things and re-integrating what I learn into my
daily grind. Everything I've ever learned about computers and programming and
front-web web dev makes me a better Python programmer.

------
davidcuddeback
One thing that I find to be very valuable is to perform self assessments after
significant milestones. I consider what I did well and what I could improve
upon. Then I consider _how_ to improve. Always exposing myself to new ideas
and trying them on toy projects amplifies this technique, because it gives me
a source of ideas for the "how."

------
aristus
Lately I've been trying to get into performance profiling research. Also,
statistics.

I've been programming full-time for, uh 15 years now. Holy shit. If anything
programming gets harder but more enjoyable as time goes on. If it doesn't
you're stuck in a local maximum.

Always try to work for people smarter and more experienced than you. Spend N
years/months immersed in learning something new while helping them get their
work done. Once people start calling you an "expert", spend N/2 to N time
teaching others. Repeat.

------
cousin_it
I feel I was a pretty good programmer to begin with, and everything I ever
learned only added to my knowledge and professional sanity, not to my raw
skill. Metaphorically, I don't seem to run faster every year, but I do get
better at choosing the path.

------
evlapix
Browse Hacker News daily and remind yourself how little you actually know.

------
hga
For me it was the stroke of luck in my first programming experience being
punched card FORTRAN IV (but more like a II, no logical IFs) on the IBM 1130
in the fall of 1977.

I realized there _had_ to be a better way and so I went straight to the
library and read up on the software engineering of the time ("structured
programming").

Since then I've read a lot on the practice of programming and applied it to my
programming. _And kept reading_ and applying stuff; the key here is to never
stop learning.

Studying good software was probably the other major way. Back then, it was
learning the UNIX V6 kernel with _Lions' Commentary on UNIX 6th Edition, with
Source Code_ plus reading the sources of all sorts of things and working on
some of them.

If you haven't read _The Pragmatic Programmer_ , _AntiPatterns: Refactoring
Software, Architectures, and Projects in Crisis_ , something by Gerald
Weinberg and something by Tom DeMarco and Timothy Lister ( _Peopleware_ is
pretty much required reading), and _The Mythical Man Month_ I strongly
recommend them.

The recent _Coders At Work_ is really good, although at a somewhat higher
level.

My other recommendation is to get serious knowledge of other domains that have
useful ideas and metaphors; for me that would be science in general and
biology in particular.

Hmmm, reading a _lot_ of classic SF (from the '40s on) and studying nanotech
also helped. You want to have a _big_ bag of problem solving tricks.

It also helps to gain a top to bottom understanding of how it all works. There
are _many_ approaches and books for this, I like _The Structure and
Interpretation of Computer Programming_ (SICP) for the higher level stuff, but
also be sure to study some EE, digital design and low level architecture. And
operating systems.

And if you're at all good with your hands, build (assemble) yourself a
computer and get UNIX/Linux running on it. Design and implement a network with
routers and static IP addresses or something like that. Etc.

~~~
hga
Can't believe I forgot this one:

Don't just read code, reanimate it!

Find a large and dead (abandoned) body of code, one where you're not in a
position to get much if any help from someone who had a hand in writing or
maintaining it, and bring it back to life (e.g. get it running on current
systems or a different system).

That makes the difference between simply reading code and really _learning_
the code. Do enough "software archeology" and you'll be able to do all sorts
of things: figure out within a few minutes the likely quality of a large body
of code, recognize the different people who wrote or changed different parts
of it (as in person A, person B...), learn that comments are at best what
someone hoped at one point in time what some code would do, etc.

