ASK HN: How are you becoming a better programmer? | Hacker News Reader

ASK HN: How are you becoming a better programmer?

19 pointstom_ilsinszki15 comments

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.

What are the most significant techniques / books / methods / thoughts that improved you as a programmer?

View on HN

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.

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

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)

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

Reply on news.ycombinator.com