Over the past couple of weeks, I have been writing about software careers, including career values and characteristics of a good programming job. This week: types of skills used in a programming job.
What Makes a Good Programming Job?
Last week, I wrote about how to use career values to evaluate a programming job. This week, I’m going to follow up with some characteristics of a programming job you might find using a values-oriented approach.
Finding Your Ideal Job Using Career Values
In a 2005 interview, computer scientist Guy Steele Jr. recounts this story about applying for a programming job at MIT in the early 1970s:
I was naïve enough to go over there on the Fourth of July and put my head in Bill Martin‘s door and said, “I hear you’re looking for LISP programmers.” I wasn’t 18 yet. Bill looked at me seriously and said, “You’ll have to take my LISP quiz.” He reached in a file drawer and pulled out a three- or four-page quiz and sat me down in his office, and I spent an hour or two doing this quiz. He graded it and said, “You’re the first person who has ever gotten it 100 percent right. You’re hired.”
That’s a fun anecdote about a young computer whiz. It’s also an early example of the type of interview now familiar to every software developer. But what I wanted to know after hearing this story was the same thing that piqued the interviewer’s curiosity: “How did you know that much about LISP?”
Book Review: Deep Work by Cal Newport
For many years, Cal Newport has been writing about ways to get better at doing difficult things. His first three books were manuals for students, advice on learning techniques and where to focus one’s efforts during high school and college. In 2012, he wrote So Good They Can’t Ignore You, about building career capital by mastering valuable skills. While he was writing these four books, he also published the Study Hacks blog, which covers similar topics on a weekly basis.
Cal’s latest book, published last week, is Deep Work: Rules for Focused Success in a Distracted World. This one offers the following challenge: to improve your ability to do what is difficult, you first have to spend less time doing what is easy.
Why Measure Your Productivity?
It’s impossible to measure developer productivity. At least, that’s what the experts say. Martin Fowler came to that conclusion over 10 years ago in a classic article, and the consensus hasn’t changed since then. My favorite recent article on the subject is by Jim Bird, a development manager and CTO.
So let’s take that as a given: Measuring developer productivity reliably and objectively is a hard problem, maybe an impossible one. But rather than rehash the standard arguments, I’m going to change the rules a bit.
Cal and Scott’s Top Performer Course
In an earlier post, I mentioned a pilot course I took a couple of years ago on applying deliberate practice to various types of jobs. Well that original pilot, and a subsequent pilot in 2014, has resulted in a course called Top Performer (not an affiliate link). As part of the homework for the second pilot, I came up with the idea for Project 462 and this blog. So as people are considering the course this week, I thought I would add my thoughts to the mix.
Results Not Guaranteed
In 2013, I took an experimental course on deliberate practice that Cal Newport and Scott Young were developing. In the email announcing the course, Cal warned: “If … you’re expecting guaranteed results, this pilot might not be a good fit.”
It’s a standard marketing technique for products and services to promise guaranteed results. But that’s not really what they’re promising. They may be willing to refund your money if you’re not satisfied, or even throw in a gift card. But that’s not really what you want. You want those results you were promised. Rather than relying on a guarantee that is limited to the purchase price, what if you could make your own guarantee?
Summer Review
It’s summertime here in the Pacific Northwest, and seven months into the first year of this blog. After thirty weekly posts, I thought it would be a good time to consider the themes that have come up so far this year. If you’re a new reader, I hope you’ll find this to be a useful primer.
How to Make Your Job More Interesting
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.
Proving That You Can Juggle Code
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.