Programming is creative work. Given a problem, you have to find a solution, then explain it to a computer in a way that humans can also understand. But unless you’re working on your own project, you don’t have total creative freedom. You have to use the tools and technologies that your team has selected, and your technical decisions are generally reviewed by other developers. On the other hand, it’s rare that you are told exactly how to solve the problem. If someone already knows that much about the solution, they could just implement it on their own. So it’s up to you to work out the details.

« Continue »

Peopleware is one of those books that show up on recommended reading lists for software development managers. Joel Spolsky was recommending it back in 2002. (It was written in 1987 and revised in 1999 and 2013). Chapter 16 (in the 3rd edition) begins with this vignette:

Circus Manager: How long have you been juggling?

Candidate: Oh, about six years.

Manager: Can you handle three balls, four balls, and five balls?

Candidate: Yes, yes, and yes.

Manager: Do you work with flaming objects?

Candidate: Sure.

Manager: …knives, axes, open cigar boxes, floppy hats?

Candidate: I can juggle anything.

Manager: Do you have a line of funny patter that goes with your juggling?

Candidate: It’s hilarious.

Manager: Well that sounds fine. I guess you’re hired.

Candidate: Umm… Don’t you want to see me juggle?

Manager: Gee, I never thought of that.

« Continue »

Do these questions sound familiar?

• What are the important problems of your field?

• What important problems are you working on?

• If what you are doing is not important, and if you don’t think it is going to lead to something important, why are you … working on it?

They come from a 1986 speech by mathematician and Turing award winner Richard Hamming. Hamming originally asked them in the dining hall at Bell Labs, but they have since inspired other people who are interested in finding the best way to spend their work hours.

« Continue »

In Making Sense of the Deliberate Practice Debate, I argued that deliberate practice is the best way to get better at a skill, even if you believe that innate ability (talent) plays a significant role in how people become experts. In the next few posts, I’m going to start investigating how software developers can apply deliberate practice to a specific skill: Writing correct, efficient, and maintainable code for a software component given well-defined requirements. But first, let’s take a closer look at that skill.

« Continue »