[​​White Belt] You need perspective on your peers (and their roles) very early in the job.

Programming is sometimes a solo activity, like the coding cowboy who gets to call all his own shots. But for the vast majority of the time, it’s a team of programmers building a product together, and you’ll need to work in cooperation with others to be effective.

Roles

First let’s talk about who’s on your team and what they do. These roles vary depending on the company, and there may be specialist roles at your company that I don’t discuss, but they usually go something like this.

Programmers

When most people think of “programmers,” they think of nerds with thick glasses sitting at computers and typing industriously. While the glamour part is all true, the typing part is only half true—there’s also a lot of nonprogramming time required to shepherd a product to completion. There’s bug hunting, testing, meetings, and other duties. These vary tremendously depending on the organization and your product’s development stage. (Hint: the bug hunt right before shipping always sucks.)

In an organization with minimal overhead—that is to say, programmers get to spend most of their time on design and implementation—this is quite a fun role. You must already be halfway convinced if you’re reading this book. People can, and do, spend their entire career in this role. Progressive companies will pay super-senior programmers the same kind of money they pay directors and vice presidents.

There are lots of titles that go with this role: programmer, developer, software engineer, firmware engineer, and so forth. They’re mostly the same. “Engineer” doesn’t mean anything special in the software world, because there’s no special qualifications for an engineer vs. a programmer. (This is different in fields that have licensing requirements, like civil engineering.) “Firmware engineer” is usually reserved for people working on embedded systems and operating system components.

If this is the role you want but it’s not your first job, don’t despair—you can get here. New product development requires experience, so it’s usually necessary to prove yourself in another role first.

Tech Leads

A technical lead is just a programmer with some official blessing to call the shots on technical matters. Frequently a team with five or more programmers will have a tech lead who has expertise in the problem domain or a track record of good leadership. This person is not, however, a manager with the authority to hire or fire.

Since this role is usually earned within the organization—as opposed to being hired in from the outside—tech leads tend to have solid experience and sound judgment. You would do well to ask one to mentor you, as in Tip 15, ​Find a Mentor ​.

To get to this role yourself, you have to pay your dues. It usually takes several years of solid work and informal team leadership to attain this role.

Architects

The architect title has two distinct meanings. In some companies, the architect is considered an analyst who collects product requirements and drafts a detailed design document that other programmers are supposed to go implement. Then the architect receives a hefty consulting fee and leaves.

In other companies, the architect is just a team lead—someone who has demonstrated a knack for leadership and design. This architect sticks with the product through its development. There’s no free pass to create a design and leave—he has to eat his own dog food.

There are additional titles that boil down to the same thing: chief scientist, fellow, and whatnot. These honorifics are generally bestowed on a very small handful of people at large companies.

Managers

Now we’re stepping outside the realm of technical leadership and into the management ranks—the folks who do the hiring, firing, and performance reviews.

Programming managers come in two varieties: those who are managers by trade​—​we call these “people managers”​—​and those who used to be programmers. Both have advantages. Good people managers may not understand the technology, but they do understand team dynamics, such as how to hire the right team and get them working together well. (My very best manager was a people manager.)

Managers who used to be programmers are a mixed bag. Some of them, frankly, would rather be programming but got promoted into management, usually because they were good technical leaders. This kind of manager is great at guiding you on programming issues, but you’ll need to look elsewhere for guidance on long-term career issues. You may want to find a more people-skilled mentor to help you on that side, as discussed in Tip 15, ​Find a Mentor ​.

If you want to move into management, consider that you won’t program anymore; you’ll spend your time on project planning, personnel, budget, and so forth. It’s a very different job. However, if you have the people skills and you want more authority within the company, management could be right up your alley.

Testers

Testers are responsible, obviously enough, for testing the product before it gets released to customers. However, there’s a lot of ways to test a product and therefore a lot of variation in how testers do their job. At the simplest, they read the user guide and poke around in the user interface. At more advanced levels, they write automation scripts and programs to do the testing for them—they’re not that different from programmers.

Testers and programmers often have an antagonistic relationship. Programmers can get offended when testers find bugs, but the programmer needs to remember that a bug found in-house is far better than a bug found in the field. Testers can consider it a victory to find a bug, but the tester needs to remember that bugs are not victories to revel in; they are failures. Both roles need to remember that they’re playing on the same team and share a common goal: to ship a high-quality product.

Testing is a common job for inexperienced new-hires. If you’re in this role and you were hoping for a programming job instead, don’t worry—testing has its plus side. You get to see the product from the end user’s perspective, and this perspective is easily lost at the programmer’s point of view. When it comes to the company’s bottom line, end-user value is the only value that counts.

To move into programming, the path is straightforward: program your way out. Automate manual tests, build test tools, and do anything that involves writing code. In every company I’ve seen, testers who can program, without fail, get sucked into programming.

Build/Deployment

Larger engineering organizations may have dedicated people for builds and tools. These folks have highly specialized skills with version control, automation tools, packaging tools, and release processes. They also get very grumpy when you break the build—one build master I worked with had a tomahawk she named Bad Mojo, and you didn’t want to see the two of them walking toward your cube.

Another related specialization is deployment. Products that run on hundreds or thousands of servers require a special level of care and automation to keep them running. These people make sure that new code will deploy correctly, roll it out in stages, and manage any problems that come up. This may look like system administration on the surface, but it’s far more technical; the issues with staged deployment (and possible rollback) with thousands of servers could easily be more difficult than the application itself.

To put these technical specializations in perspective, consider a company that operates servers at Google’s scale. Some of Google’s most advanced software are tools to help programmers distribute workload across the cluster or work with data at the petabyte scale.

Your Role on the Team

Your first job won’t be chief architect of a new product. You’ll get grunt work because, from square one, you need to start on small things before you’ll be trusted with large things. It’s a natural cycle as old as the craft trades; apprentices need to work their way up.

A manager of mine put it this way: if you’re a silversmith’s apprentice, you won’t start on casting; you’ll start on something much less glamorous, like filing. You get cast parts from the master and file down the rough edges. When you have that down, you can try your hand at casting. Of course, your first molds and casts will suck—meaning you’ll have a lot of rough edges to file down afterward. Then you see firsthand, ah-ha, the better I make the mold and pour the cast, the less filing I have to do!

In the same way, the budding programmer may start on something like testing. You’ll have to tediously figure out how to test various parts of the code to make sure they work. Then when you get moved up to writing some code—along with their tests—you’ll be motivated to write modular code that’s easy to test. If you don’t, it’s only yourself that you’re punishing.

So, don’t get discouraged when you enter the workforce with wide eyes and idealism, only to get some role you think is crummy. You won’t be there forever; you just need to work your way to the role you want.

Actions

If you’re not yet in the professional world, you’ll have to file this one away for future use.

• Step 0: Get a job.

• Step 1: Go chat with some of your teammates and figure out what they do. There’s often a difference between a person’s title and what they do. Alice and Bob may both have the title “software developer,” but Alice may be the database expert and Bob is the Unix guru. Simply introduce yourself and ask what someone is working on; with some time, you’ll figure out people’s specialties.

• Step 2: Based on what you’ve seen people in your team doing, what looks the most interesting to you? Write down what you want to be doing in a couple years.

• Step 3: Brainstorm some short-term actions you could take to get you closer to your goal. Pick three and act on them over the next six months.