[​​Black Belt] This topic looks far into the future. Don’t worry about it yet—but don’t ignore it forever, either.

At this point, you’re getting your footing in the industry. Figure on five to ten years of building experience and credibility. What lies past that for a programmer? I mean, aside from obscene wealth, a big house, and a fast car?

Programming to…Programming

First of all, there’s programming. For some, that’s what you’re put on Earth to do, and you can make a good living doing it, so why stop? Many companies have acknowledged the value of very skilled programmers, and your pay can keep climbing—you don’t need to go into management to get the bucks.

However, some companies are not so progressive. If you stay in programming more than ten years, you’ll need to shop around more for jobs. I’ve talked to a number of tech companies whose pay simply tops out no matter how good you are, and I’ve talked with managers who won’t pay a programmer more than the manager makes. There’s no use in trying to convince them otherwise; just move along.

Another option is contracting. You bid on jobs either by the hour or by completion of the job. The upside is you (usually) make a lot more money per hour. The downside is you need to look for jobs a lot more often—and in lean times you may not be able to find any. Before considering this route, you must have a sufficient professional network for finding jobs, plus enough money in the bank to sustain your household when a job falls through.

The best resource for advancing your programming career is Chad Fowler’s The Passionate Programmer: Creating a Remarkable Career in Software Development [Fow09]. He’ll help you develop both the skills and the self-marketing required to command the higher salaries.

Next, you won’t spend your career at one company, and there’s a special skill to finding and landing jobs. Most of us have learned this the hard way, after taking a few jobs that weren’t a good match. Save yourself the trouble! Andy Lester teaches job-hunting skills in Land the Tech Job You Love [Les09].

Technical Lead

As you gain skill and experience—and increased salary—you will be expected to provide leadership as well. While leadership of the technical form doesn’t come with the privilege of bossing people around, it does come with the privilege of bossing the product’s design around.

Design is a separate skill than programming. The technical lead must work at both the big-picture level (seeing how the bricks fit together) and down at the guts level (building the bricks). Think of it as doing the right thing in the right way.

Of course, a product’s design is merely a concept in people’s minds; it’s the manifestation of that concept—the code your team writes—that really counts. The second essential skill of a technical lead is shepherding a design as it is built. This isn’t just documentation with pretty pictures at the front end of a project; it’s hands-on writing code with people and making sure that the code develops over time toward the design and that the design evolves as project needs shift, too.

Management

If the technical lead role sounds like a bunch of responsibility with no authority, there’s always management. Managers do get the privilege of bossing people around. (It doesn’t work very well, but one can try.) Some programmers move into management because that’s the only path upward in their company, and others genuinely have a talent for it.

That talent is a delicate balancing act between leading a team and serving the team. The leadership authority is pretty straightforward: people (mostly) do what the manager tells them to do. The service part, however, is just as important: the manager must match the work with the skills and interests of the workers, must provide them with equipment and training for both near-term goals and long-term growth, must fend for the team’s budget and other resources, and must do much, much more.

If meetings and office politics drive you crazy, management is not your path. Much of a manager’s work is accomplished in meetings: meetings with team members to make sure the right things are getting done the right way (aka managing down), meetings with superiors to ensure the team’s work is aligning with the business needs (managing up), and meetings with peers to make sure the work is coordinated with the rest of the company (managing across).

Some managers attempt to also keep programming at the same time. I’ve never seen this work well; both their management work and their programming work get short-changed. Managing even a small team—and doing a good job at it—is a full-time job. Do one job or the other; don’t try to do half of two jobs.

Product Management

While product management is in the domain of marketing (egad!), it’s a natural transition for programmers who want to get into what products the company builds more than how the products are built. In fact, many product managers start their careers in engineering.

You probably have a gut feel for what your product should do. That’s a good start. However, much like programming, the role of a product manager is part taste (aka gut feel) and part science. You’ll need some education on marketing to fill in the latter half.

If your company attends trade shows or hosts conferences, that’s a good opportunity to get out and talk with customers and the sales team. Try it. If you have fun, product management may be a path for you.

Academia

Some programmers will hit industry and decide they had a lot more fun in school. Teaching/research has its own pressures and rewards; if this is your gig, you can make a good living there. See David Olson’s advice in ​Academic Perspective: Graduate School​.

Even for programmers who stay in industry, it’s worth paying attention to research coming from academia—those underpaid and overworked grad students turn out some good ideas. Consider joining associations like ACM^[54] and IEEE^[55] to keep abreast of the latest research.

Actions

This tip isn’t something you can act on today—ideally you’re having a great time with programming. However, make a note to do a gut-check every year or so: do you enjoy the role you’re in? Where do you see yourself going next? Is there any strategic-level learning or experience you can start on now to help you get there?