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?”
There’s a literal answer to that question, and also a deeper answer. Steele gives the literal answer first: in high school, he attended a weekend programming class at MIT, and wrote a LISP implementation for the IBM 1130. The deeper answer appears later in the interview, and has to do with career values.
Career Values
Career values reflect what you consider to be important in a job. If the requirements of a job don’t match your career values, you won’t find it rewarding.
You can evaluate a programming job by considering values like work/life balance, independence, and job security. Like any job, programming jobs offer different options in these areas.
But programmers also need to consider values that are specific to programming jobs. While each programmer has their own values, there are common categories of programming career values. The Steele interview provides examples of career decisions that a programmer could make by following their values.
Programmer Values
Each of the programmer values that follows is presented as a choice between two extremes, but individual programmer preferences will generally fall somewhere between the two endpoints. The more your job matches your preferences, the more motivated you’re going to feel when you arrive at work in the morning.
Applied vs. theoretical
The applied vs. theoretical category is encapsulated in the difference between software engineering and computer science. Computer scientists work in universities and corporate research departments. They may do some programming as part of their job. But most of the world’s code is written by software engineers (or “developers” or “programmers”).
Steele started his career as a professor of computer science, but later worked on designing and documenting programming languages for several companies. So his approach was to use academic training for commercial ends.
While not everyone should get a PhD, some theoretical background is useful for every programmer. Without a good foundation, programmers tend to work by starting with an example and tweaking it until it seems to do the right thing. That’s not a recipe for bug-free and maintainable code.
A theoretical background can also make programmers happier. It’s not much fun when your program seems to behave arbitrarily, or a language feature doesn’t work the way the documentation seems to say it should. The more you know about the fundamentals of the system you’re working with, the more you can be in control of your work. It’s more rewarding to solve a problem by fixing the root cause than by trial and error.
Implementing vs. explaining
“I like to write and many engineers don’t”, Steele says in the interview. Today there are more opportunities than ever for programmers to explain what they know. There’s no need to make a commitment to writing a magazine article or a book. Stack Overflow has all but replaced the imperfect programmer forums of years past, and programmers usually end up there when they’re having trouble with something.
At one end of the implementing/explaining spectrum is the full-time technical writer, who might make a living by writing books or software documentation. A program manager or systems analyst, who converts customer desires into specifications, also fits into this category. But full-time programmers can also benefit from explaining what they know. Explaining something to others is the final step in solidifying one’s own understanding of a concept.
Writing is also a more reliable approach than pure programming for becoming well-known as a programmer. As Steve Yegge wrote in Get Famous By Not Programming,
Do you have any programming heroes? I do! Oddly enough, though, I’ve never really seen much of their code. Most of the famous-ish programmers I respect have actually made their impact on me through writing, and it’s usually just prose, with maybe a little code interspersed.
If you’re applying for a programming job, it’s possible that someone in the hiring process will take the time to peruse your GitHub repo. But that takes effort. It’s a lot easier for them to skim a few of your blog posts or Stack Overflow answers.
That doesn’t mean you can become a famous programmer by skipping the coding step entirely! Post #2 of this blog is called Coding is Underrated, and I explained back then that I’m skeptical of arguments that minimize the importance of coding skill to success at a programming job. But coding and writing skills go well together.
Inventing vs. using
Would you rather use a tool that someone else invented, or invent a tool for others to use? The balance between these two values relates to where you work in the technology stack. Every computer user spends some time at the top of the stack: you probably didn’t write the operating system that you’re currently running, or the browser that you’re using to read this post. But programmers, unlike end users, get to spend some of their time at the bottom of the stack, writing tools. Those tools might just be code libraries used by other developers on the same team, but they are inventions nonetheless.
Steele has had the chance in his career to influence the design of tools in widespread use — the Scheme and Java languages. There’s something unique about building tools for developers. Developers are serious and opinionated about their tools. If you can keep your developer users happy, you’re in good shape.
Contributing individually vs. managing a team
If you spend enough years as a developer and your company has more than a few people in it, you’re likely to get asked to manage a team. The request might be for technical management, like providing design guidance and reviewing code. Or it might be a people management position, where you have to write performance reviews and fill open positions. Senior developers often have mixed feelings about people management. It’s flattering to be asked to take on the responsibility, but it can also mean giving up technical depth. “I’m really more of a technologist than a manager” is how Steele explains his switch back to individual development after some time as a development manager.
Details vs. vision
Steve Jobs played no role at all in any of my designs of the Apple I and Apple II computer … He wanted to be important, and the important people are always the business people. So that’s what he wanted to do. … So it’s very important, even if you are not a business man, find someone who is.” (Steve Wozniak)
According to the founding myth of Apple Computer, Steve Jobs was the visionary and Steve Wozniak handled the implementation details. As Wozniak advises, technology companies need both kinds of founders.
Guy Steele Jr., who prefers detail-oriented jobs, puts it this way: “I’m in the best position at work when I have a visionary and a manager to work with. … Not that I truly compare myself to either, but I’m more like Edison than Einstein.”
This value category has some relation to the manager vs. individual contributor choice. You have more opportunities to implement a vision as a manager, and to work out the details as an individual contributor. But it doesn’t have to be that way. Non-managers who can attract others to their vision are also in demand.
Choosing A Job Based on Values
Choosing a programming job where you’ll be doing work that matches your values is a reliable way to increase your happiness at work. To find examples of career values, look for biographies or interviews of programmers whose jobs seem interesting to you, and see what career choices they made. I like the work that Guy Steele Jr. focused on:
- He built a strong theoretical background (PhD), then used it to design programming languages that people used.
- He used his writing skills to clarify and influence the design of languages.
- He built tools for programmers.
- He mainly worked as a member of a team, though he also spent some time managing a team.
- He worked out the details of the projects he worked on, to make sure the final product worked as described.
By focusing on these values even in high school, he was able to impress a MIT professor and land a programming job based on his unusually complete knowledge of LISP.
Your list of values is probably different than the one I just described. It’s worth making your own list so you have it to refer to when you’re considering a job move.