Fundamental Qualities of Good Programmers | Hacker News Reader

Fundamental Qualities of Good Programmers

hackerschool.com

67 pointsSethMurphy29 comments

I've seen the claim that "programming languages are just tools for telling computers what to do" quit often, and I think it really misses the mark to the detriment of whoever believes it.

Programming languages are "just" tools for expressing ideas. Ideas that a computer can then run. A programming language really is a language and it ultimately affects what you can easily say, how you say it and even how you think about problems. Put another way: semantics are important.

Of course, if you only know one language well and you believe it's just a way to direct your computer, you won't realize this.

It sounds like you missed the footnote:

> This is not to say that all programming languages are equivalent, that they are equally good at all tasks, or that it isn't worth learning more than one programming language. Just that all good programmers have a deep understanding of at least one language.

Not just ideas, it's a way to express the computation formally in an abstract way. Being executable by a machine comes as a direct consequence of that.

You are right that knowing several languages expand ones abilities to express computation as it brings new abstractions on the table.

It's better to know multiple paradigms, learning multiple languages is just one of the ways of achieving this. I made my C# more functional just by reading about F#, Haskell etc.

In pre-university school I would always wish that instead of trying to describe a complicated procedure/formula in words (and failing), that the teachers would just write a program. Code can be a very effective means of communication between humans as well.

Having a good mental model of your programming environment

This also does a lot to cut down on cargo cult programming [1] which in my experience is much more prevalent than I would like. Having a solid understanding of the environment you're working with makes it much harder to blindly follow the examples of others, because it's much easier to determine whether or not all/part/any of their example applies to your situation.

[1] http://en.wikipedia.org/wiki/Cargo_cult_programming

A long time ago one of my teachers told me

"One day, they'll figure out a way to build machines which will implement what you're thinking. Even then they will near clear thinkers to run them."

Almost everything listed there on this list is a skill. They are not qualities and perhaps aren't even fundamental.

Curiousity, tenacity, perseverance, patience, imagination. Add in some courage to show others unfinished work and the humility to take help/criticism.

Those are qualities I have seen in good programmers.

These are not innate qualities really. But they are qualities which escape quantification.

But reading a lot of code and debugging ... those are skills & need to be built. And then built upon.

I do not disagree with you, though I think focusing on whether these things are qualities or skills misses the broader point that I was trying to make (that this list is a tool that helps me be introspective about the progress I'm making towards becoming a good programmer). It's my fault for not communicating it more clearly.

I agree that curiosity, tenacity, perseverance, patience, and imagination are all qualities that good programmers have, but when thinking about how I can improve, I find the question "How can I be more curious?" less helpful than "How can I be more systematic when I'm debugging?"

I'm running into more people that are proud to know nothing deeply. "Why bother? I know how to search on Google! I can learn!" I'm glad this article doesn't buy into it.

Sure, the knowledge is out there and you can acquire it over time, but without having internalized that knowledge and given time for strong intuition to develop, you're not going to be nearly as effective.

I guess one counterpoint would be Alfred Einstein and him famously not knowing his own phone number.

He stated why would I waste brain cells on something that is alphabetically sorted in a book?

I agree you need to know things like how malloc() works, how a function (lets say c) is allocated on the stack into frames, etc....

Just wanted to throw that out there. I love not knowing everything, but that has come after many years of learning what I don't need to memorize/internalize.

Programming languages are much more than tools; they are frameworks of thought.

Breadth of knowledge beats being an expert in a single language hands down every time. If you are not familiar with other programming languages and concepts then you will not be a good programmer in your own language. Each language only exposes certain concepts. Using other concepts in other languages lets you bring those patterns into your chosen language—albeit with greater difficultly. Without that knowledge you are more likely to just fumble through it rather than building something cleaner.

Also relevant is the Sapir-Wharf hypothesis (http://en.wikipedia.org/wiki/Linguistic_relativity). Language ultimately determines what you think.

What is the difference between the algorithmic thinking and mathematical thinking?

Practice vs theory I guess and being aware of math as a superset of computer science.

When given a question about plotting a data set, the algorithmic thinker will introduce quarternions and give you an efficient algorithm. The mathematical thinker will generalize to N-dimensional piecewise differentiable manifolds and prove under which conditions an efficient algorithm exists (non-constructively, of course, because that proof is more beautiful)

This sounds more like engineering and scientific approach then.

More like the fundamental attribution error.

Finding bad code is easy. Finding people who are irremediably bad programmers is not that easy. The most you will find is people who are still learning, or have some specific bad habit.

My experience tutoring at university would beg to differ. Perhaps irremediably bad is not the right word, but as a tutor of ~30 first year students you find yourself almost having to give up on half the class.

I TA'd Intro to Computer Science (Java Programming) at UCSC for 2 years and I would emphatically disagree with you. The whole time I was tutoring (groups and one on one) I never met anyone who I thought couldn't learn to program. It was 100% a function of time. Some people certainly got it quicker, but I never met anyone who couldn't get it at all given they put in the time. I probably worked with over 200 students indirectly and 50 one on one and I never felt I had to 'give up' on any of them. In fact it was one of the most enjoyable and rewarding jobs I've had.

One of the problems I have with formal education is that nobody has ever considered how to motivate students. As you say, most subjects really are a function of time and effort. Even with serious roadblocks, a good tutor should be able to teach you if you spend the time. The only place where you can't teach someone is where there are discoveries to be made.

I guess I could’ve phrased it more carefully. Sure, I think everybody can learn to program, but given the limited amount of time you can spend with each student and their predisposition toward some of the key elements of programming it's just unlikely that you can teach 30 first years how to legitimately program given just a 2 hour lab each week. Keep in mind some of the students are just 'tasting' programming and some students have ridiculous external commitments too.

I tutor people 1 on 1 now, besides working, and it's incredibly better. Never in this scenario have I met anybody who's never had those 'aha' moments.

I'm guessing considerably more than half the class finds itself wanting to give up on you.

Author here. I might be misunderstanding what you mean, but if you're saying that these qualities are not innate, I definitely agree with you. If you want to become a better programmer, I think these are all things that you can get better at with practice. The purpose of the post was to highlight and give names to the way we (at Hacker School) think about programming.

>Finding people who are irremediably bad programmers is not that easy

What? I can go get you a few hundred right now if you want. It is trivially easy to find tons of bad programmers.

>The most you will find is people who are still learning

I wish. Mostly I find people who should be still learning, but don't want to. People who have an incredibly superficial knowledge of one set of technologies (lets say php+mysql) and think they are set. The kind of depth of knowledge you would expect from someone with 6 months of experience, even though they've actually been doing it for 5+ years.

I'd like to add being good at googling. Usually better programmers literally google better (find better results and faster) than weaker ones.

It’s unfortunate there are always people who think bring resourceful is not a essential quality of a good programmer...

"It's hard to imagine a good programmer who is slow"

I have seen those. They were slower than me but were smarter than me.

"Having a large code radius"

It's not about the number of lines of code, it's about flatness of hierarchies. It's easy to deal with thousands of components but it's hard to deal with factories of factories of factories.

I think the title is somewhat misleading, maybe "What We Teach at Hacker School" would be more democratically accurate. This is a list of acquired skills, i.e. not fundamental. I think the only fundamental quality of a good programmer is that they really, really enjoy programming. When you have this indeed fundamental quality, becoming good is only a matter of time.

I recommend (re)reading "Great Hackers" by pg and (re)watching "Hammock Driven Development" by Rich Hickey.

Another fundamental quality: Always trying to find faults and errors everywhere and in everything. Especially in random blog posts.

Most of the items cited are not qualities, but approaches to solving a problem.

Reply on news.ycombinator.com