Red-Green-Code

Deliberate practice techniques for software developers

  • Home
  • About
  • Contact
  • Project 462
  • CP FAQ
  • Newsletter

What Makes a Good Programming Job?

By Duncan Smith Mar 9 0

Programming

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.

In last week’s post, I described how computer scientist Guy Steele Jr. balanced competing priorities in a set of software career values:

  • Applied vs. theoretical: He uses a CS research background to design commercially successful programming languages.
  • Implementing vs. explaining: Unlike many engineers, he likes to write. This allows him to explain and document the projects he works on.
  • Inventing vs. using: He has contributed to the designs of widely used languages.
  • Contributing individually vs. managing a team: Although he spent some time as a manager, he focuses mainly on individual work.
  • Details vs. vision: His strength is working through the details of an implementation.

A good job is one that aligns with your career values. Here are some characteristics to look for in a programming job if you value writing software that is widely used, communicating your ideas to others, inventing new technology, contributing as a member of a team, and working out the details of a complex problem. Although not every programmer values the same things, I believe these will apply to many programmers in a hands-on coding position. This is especially true early in your career, but they can still be useful if you continue writing code as you reach more senior roles.

Elements of a Good Programming Job

If you value the things I described, then a good programming job should allow you to do the following:

Work on software that your friends can use

In my current job, I often need to look at someone’s résumé to prepare for an interview or decide whether to schedule a phone screen. One challenge in evaluating a résumé is finding an example of the candidate’s work. Résumés often refer to projects that are internal to a company, such as a system used only by a company’s own employees. Or in cases where the candidate has worked on a publicly available system, it’s hard to tell what their specific contribution was.

If you work on something public, it’s easier to describe your experience to a potential employer, which means it’s easier to get the job you want. This is especially true if you can be very clear about the impact your work had on a feature. For example, describe it from the user’s point of view.

Besides the résumé advantage, a publicly available system is also more likely to provide technical challenges. Systems with more users and more visibility have higher standards than internal systems with a limited audience. So all else being equal, working on a public system provides an advantage.

Another way to work on something public is to contribute to an open source project. For résumé purposes, that allows you to refer not only to the system you worked on, but to the actual code commits. That should leave no doubt as to your actual contributions to a project. An active OSS project can also help improve your skills by subjecting your code to frequent review by experienced developers.

Write a lot of code

As I wrote in Why Measure Your Productivity?, a metric can be hazardous for a manager to use while still being useful for an individual. Lines of code written is the most famous of this type of metric. If your manager is evaluating you by how many lines of code you write per day, you should be worried. But measuring that number for yourself can be instructive.

Just as book authors have to write a lot of words to master their craft, programmers have to write a lot of code to get good at programming. There’s no way around it. If your job requires you to spend a lot of time attending meetings, dealing with email, or doing other non-coding activities, you have a problem. You won’t get the practice you need to master the craft of programming.

Work with people who have a variety of skill levels

It’s helpful to work on a team where some people know more than you do, and others know less. The more experienced people can give you advice, and you can reinforce your skills by explaining things to your less experienced peers. Depending on the subject matter, the same person may be able to play both roles, explaining things to you and also benefiting from your advice.

Work on your own projects

It’s unlikely that you’ll get a chance to explore all of your programming interests at your day job. Even if you’re self-employed and direct your own work, you still need to deliver products that your customers will pay for. But it’s no fun to only work on what your boss or your customers tell you to work on. There are enough different programming specialties to find something interesting to do as a side project. If you work on web sites during the day, find some spare time to work on mobile apps. Or vice versa.

Work on important problems

Asking “What Are the Important Problems of My Field?” is a good way to evaluate the work you do. If you’re solving a problem that has already has a good solution, you’re not making the best use of your work time (unless you’re doing it as a learning project). A job that gives you the opportunity to solve new problems, or find better solutions to existing problems, is worth looking for.

The aspiration to work on important problems is a way to summarize the other characteristics. The purpose of exposing your work publicly, putting in the hours, finding people to learn from and teach, and working on side projects, is to get good enough to work on something truly important.

Does it Really Matter What Problem You’re Solving?

As I write this, the latest Coding Horror post starts out with a graph of the Top 20 Reasons Startups Fail. The #1 reason: No market need. In other words, they solved the wrong problem. What is the message of the Hamming Questions and the essays they inspired? Working on the right problems makes a difference to your career.

So what you work on certainly matters. But you can accomplish the long-term goal of working on something important by pursuing short-term goals in which you don’t worry about what problem you’re solving. If you’re in a situation where strategy and business model are someone else’s problem, you can focus on the other elements of a good programming job. And after hours, there are benefits to solving programming puzzles, the ultimate inconsequential problems. But don’t lose sight of the goal, which is to do important work.

(Image credit: Scot Rumery)

Categories: Career

Prev
Next

Stay in the Know

I'm trying out the latest learning techniques on software development concepts, and writing about what works best. Sound interesting? Subscribe to my free newsletter to keep up to date. Learn More
Unsubscribing is easy, and I'll keep your email address private.

Getting Started

Are you new here? Check out my review posts for a tour of the archives:

  • 2023 in Review: 50 LeetCode Tips
  • 2022 in Review: Content Bots
  • 2021 in Review: Thoughts on Solving Programming Puzzles
  • Lessons from the 2020 LeetCode Monthly Challenges
  • 2019 in Review
  • Competitive Programming Frequently Asked Questions: 2018 In Review
  • What I Learned Working On Time Tortoise in 2017
  • 2016 in Review
  • 2015 in Review
  • 2015 Summer Review

Archives

Recent Posts

  • Do Coding Bots Mean the End of Coding Interviews? December 31, 2024
  • Another Project for 2024 May 8, 2024
  • Dynamic Programming Wrap-Up May 1, 2024
  • LeetCode 91: Decode Ways April 24, 2024
  • LeetCode 70: Climbing Stairs April 17, 2024
  • LeetCode 221: Maximal Square April 10, 2024
  • Using Dynamic Programming for Maximum Product Subarray April 3, 2024
  • LeetCode 62: Unique Paths March 27, 2024
  • LeetCode 416: Partition Equal Subset Sum March 20, 2024
  • LeetCode 1143: Longest Common Subsequence March 13, 2024
Red-Green-Code
  • Home
  • About
  • Contact
  • Project 462
  • CP FAQ
  • Newsletter
Copyright © 2025 Duncan Smith