I have been programming software for over a decade and occasionally people ask me what I think of programming as a career. My answer is mixed. Though there are many positive features about programming, the ultimate problem is many companies expect programmers to suppress creativity in their work.  Dreaming up and designing new applications and web features is for project managers, clients, and graphic designers— everyone but the programmers.

Certainly there are upsides to programming as a career.  The jobs are plentiful and they pay decently, even for young people, and the jobs typically don’t require years of costly postgraduate education.  Furthermore, many of the jobs can be done remotely, which typically allows the flexibility to work from home or travel while working.

A perennial source of frustration, however, comes down to creative control.  In many organizations, programmers are usually at the bottom of the waterfall when it comes to dreaming up a software project.  Usually the CEO, the client, the project/product manager, and the graphic designers determine what should be built.  They discuss and dream up the purpose, the structure, the interactivity, and the content, and then they settle on a specific graphic design.  Only after the vision is complete does the programmer enter the project and the programmer’s responsibility is to build exactly what everyone else just finished dreaming up.

Nicholas Zakas, a software engineer and author, wrote an insightful blog post on the topic and though I don’t necessarily agree with the entirety of the post, the section on creating versus building is spot on:

Software engineers see themselves very differently than those with whom they work. I’ve come to this conclusion after over a decade in the software industry working at companies large and small. Companies (product managers, designers, other managers) tend to look at software engineers as builders. It’s the job of the product manager to dream up what to build, the job of the designer to make it aesthetically pleasing, and the job of the engineer to build what they came up with. Basically, engineers are looked at as the short-order cooks of the industry.

….

There are a lot of companies that want short-order cooks, they want implementers and builders to march to a specific beat and stay in line. In fact, I’d say most companies want that, large and small. I can’t tell you how many startups contact me offering equity in exchange for building the founder’s vision. The implication: we already have all of this figured out, we just need someone to build it.

When I read Zakas’ post, years of frustration finally made sense.  When you’re a programmer on a team of managers, clients, and designers, you have the absolute least amount of control and input into what gets built.

Everyone expects that they won’t have full control at work.  That’s why it’s called work!  But the disparity in creative input between programmers and literally everyone else on the project is dispiriting.  It’s especially disillusioning to a person who got into programming as a teenager after realizing that a few hours at the keyboard can produce great things.  Zakas writes:

Software engineers don’t get into coding because they want someone to tell them what to do, they get into it because they discovered they could create something useful. Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked.

In the triumvirate of software, product managers, designers, and software engineers, only the engineers are expected to turn off their creative minds and just produce.

The most satisfying project I ever worked on was a self-directed fellowship to design what I still believe is the most practical and elegant real-time transit arrival screen.  (Obviously I’m biased, but indulge me for a moment.)

Though we hired a graphic designer for the final design layout (I did the backend coding), I was able to direct the designer on the placement of everything on the screen.  I had a reason for every color, every font size, every line, and every refresh behavior.  The fellowship ended in 2012 and I moved on to other things, but I still remember the project fondly.

My advice to anyone considering programming as a career is to select a job carefully.  Ask how the company’s development process typically works and see how involved programmers are in the predevelopment phase.  The company’s promotional material may employ buzzwords like “collaboration” but it’s up to you to discover what that means for the programmer role.

In fact, you may be perfectly happy conquering the challenge of putting the visions of others into code and that’s fine.  If you want more input into the overall purpose of what you’re building, choose carefully or even consider applying for a project manager or product manager role.