Archive for programming

“The nature of programming has changed. For many years we were puzzle-solvers, focused on turning algorithms into sets of instructions to be followed by a computer. We enjoyed solving these puzzles, and we often viewed both the complexity of the puzzle and the obscurity of the solution as evidence of our skill. As applications have become more ambitious and programs have grown even larger, programming has become more of a cooperative effort. We form close-knit teams of programmers. We have code walkthroughs and inspections. We test and maintain other people’s programs. Aware of our human limitations, we have come to view complexity and obscurity as faults, not challenges. Now we write programs to be read by people, not computers.

There is a pleasure in creating well-written, understandable programs. There is a satisfaction in finding a program structure that tames the complexity of an application. We enjoy seeing our algorithms expressed clearly and persuasively. We also profit from our clearly written programs, for they are much more likely to be correct and maintainable than obscure ones.”

“the 10X programmer is hypersensitive to problems. Solving a problem that costs other programmers a minute of waiting will gain a lot more than a minute for any programmer who then encounters that problem later. This is because of flow).

A common experience I have is that I’ll be coding happily, but when I run into a hard bug, I’ll suddenly find myself surfing Hacker News or wasting time – a lot more time than the few minutes it would take to solve.

This is a problem, but it’s not sufficient to just say that I need to learn better focus and move on. That’s addressing the symptom, not the cause, and this problem is common to many programmers.

The cause is that even small problems will knock you out of flow. Flow is the state of being totally engrossed in work. It’s difficult to get into flow, and a small distraction or irritation can pull you out.

Importantly, the 10X programmer fixes the problems that knock her out of flow. Fixing problems – even trivial ones – , leaving documentation so people can understand faster, keeping a database of common problems, and so forth, all potentially make a much larger difference because of flow than just a few minutes it takes to fix them.”

Programming is part of software development. It doesn’t matter how fancy your code is unless it solves the right problem and you can explain it to others. So, brush up on your communication skills. Learn to listen, to ask good questions, to write clearly, and to present clearly. Serious programming is a team sport, brush up on your social skills. The sloppy fat geek computer genius semi-buried in a pile of pizza boxes and cola cans is a mythical creature, best buried deep, never to be seen again.

Learn your first language well. That means trying it for difficult tasks. Don’t obsess about technical details. Focus on techniques and principles.

Learn another programming language; choose any language that’s quite different from what you are best acquainted with. You can’t be a professional in the IT world knowing only one language. No one language is the best for everyone and for everything.

On a newsgroup recently someone said: “Half of all programmers are below average.” I responded that that was not necessarily true. Certainly half are below the median, but it is remotely possible that only one programmer is above average. (I’ll leave you to decide who I was thinking of.)

I said this flippantly, but I was partially serious. It seems to me that 90% of the code that gets written in the world is written by 10% of the programmers. The other 90% of the programmers write the remaining 10% of the code (and the 10% then fix it.)

OK, this is snobbery. I know it. And maybe my numbers are a little skewed. Perhaps it’s not 90/10. Perhaps it’s 80/20 or even 70/30. But it sure isn’t 50/50!

I once consulted for a company that had 50 developers working on a simple GUI. This GUI was a flat panel touch screen upon which several dozen dialog boxes could be made to appear. These 50 developers worked on this project for five years or more. That’s 25 man-decades, 2.5 man-centuries! COME ON! Three guys could have done this in three months! My buddies and I used to joke that they had one developer per pixel and that each developer wrote the code for his pixel.

OK, so the manager was empire building. Some managers measure their worth by the number of people they manage rather by how much they can get done with how little. Still, I find this problem is not isolated. It seems to me that a large fraction (perhaps a majority) of all software projects are overstaffed by a huge factor.

I wonder if we’d get a lot more done in this industry if 90% of us quit.