What Do Programmers Actually Do at Work?
If you’re contemplating a career switch into programming, you’re probably wondering what it’s like. And I don’t mean in the existential sense. Rather, on a day-to-day kind of basis, what’s it like?
Well, today we’ll take a look at what programmers do in the office.
What Do Programmers Do at Work? The Short Version
If you’re looking for an abbreviated answer or a summary, I can certainly provide that. After all, I spent a lot of years working as a programmer in an office. So I can speak at length and summarize quickly.
So, what do programmers do at work?
Well, not surprisingly, they spend a lot of time programming computers. But they don’t do so in a vacuum. They also spend time doing activities that support programming, such as research, learning, collaborating with peers, collaborating with people outside of their group, and participating in the office as general workers.
For the rest of this post, we’ll look at all of this in a little more detail and talk about what it’s actually like.
Understand That Programming Isn’t the Movie Swordfish or Whatever
Before we go any further, you need to get something out of your head. And that’s the idea that programming is any semblance of the way movies portray it (or hacking).
I might be showing my age by citing the (terrible) movie Swordfish, where, apparently, programming involves Hugh Jackman tossing around virtual cubes…or something. But other movies show things that are just as ridiculous. People wearing ski masks, banging on computers like they’re pianos in a jazz bar, bypassing the mainframe and accessing the router. For programmers, this portrayal hews the line between exasperating and hilarious.
Forget all of that. If you were to film professional programming, the result would be like a less interesting version of watching someone play video games. Think more like watching someone make a spreadsheet.
None of this is to say that programming itself isn’t interesting. It’s a lot like doing puzzles all day for money. But it’s nothing like the way popular culture portrays it, from how programmers dress to how they interact with the computers.
Programmers Spend a Big Chunk of Their Time Programming, but Not All Programming Is Created Equal
With that out of the way, let’s dive into the obvious. When you ask what programmers do at work, any smart ass listening to you would say, “they program.”
And, well, that’s true. Programmers program. And unless a company is truly dysfunctional, programmers spend the lion’s share (but not all) of their time programming. But not all programming is created equal. So, let’s look at different types of activities in broad terms.
Greenfield Development
First up is the favorite of nearly all software developers: new feature development. This is commonly known as greenfield software development, deriving from a construction metaphor where you break ground on completely untouched land. But don’t worry, greenfield software development is a lot less soul-crushing than chasing Thumper and Bambi out of a meadow to build a Starbucks.
In the software world, this is where you build a thing. You start with nothing and you proceed from there, laying the software equivalent of a foundation and building up from there.
This tends to be highly rewarding for software developers in the same way that writing a new blog post is more fun than correcting spelling errors in the one you wrote last week. It allows for a feeling of creativity.
But beyond that, it also tends to yield the most productivity. In the initial stages, there are no users to get angry at you for moving a button somewhere else on a page or adding more links to a menu. You don’t have to worry about breaking things that people depend on.
You can just build stuff.
Maintenance Programming
Programmers tend to love greenfield development scenarios for stretches in their careers. Maybe their company starts building a new offering and assigns them to the project. Or perhaps they leave their job to work for a brand-new startup.
But far more often, programmers work on software that exists, as opposed to brand spankin’ new stuff. This is generally known as maintenance programming, and it occupies the overwhelming majority of programming work hours.
Anyone working on adding features to existing pieces of software is operating in maintenance mode. It’s still programming, but you tend to have a larger amount of constraints on the nature of the work that you’re doing and your efforts require more diligence. Where greenfield development tends to skew toward writing new code, maintenance programmers spend just as much time reading existing code, understanding what it does, and making slight modifications to it.
To continue the blogging metaphor that I mentioned, maintenance programming is like correcting a few spelling mistakes and maybe adding another subheading and section to a blog post. It’s still writing, kinda, but it involves more reading of the post and thinking about how your stuff fits in, rather than just tapping out some free-form thoughts.
Troubleshooting
Now we get to the least favorite flavor of programming for most—troubleshooting. It’s not that the activity is inherently uninteresting somehow. It’s just that you’re usually doing it under some pressure, often because of a mistake that you or a teammate made.
When things go wrong, companies often have some sort of support staff to handle them. So, not all issues with the software make it back to the programmers. But some do. And when they do, you become sort of a digital detective.
The first thing you have to do is try to recreate the issue, which is often surprisingly hard. And then once you do recreate it, you have to figure out what went wrong. I like the detective analogy because it’s a lot like crime scene work, in a sense. You’re trying to assemble clues, after the fact, to figure out what went wrong at an earlier point in time.
This is a frequent programming activity as well, particularly after a company has deployed a major release to the field.
Programmers Do a Lot of Research and Learning
Having looked at the different flavors of actual programming, let’s now dive into what other things software developers do. One important complementary activity is learning and research.
And, yes, I’m actually saying that programmers learn on the job. And I’m also saying that’s OK. It wouldn’t fly in a lot of other lines of work, but programmers must do this.
Simply put, programmers work in a landscape that changes so much you could reasonably call it a constant earthquake. Frameworks that everyone was using six months ago become passé. Apple or Microsoft issue operating system updates that change everything. New techniques and technologies come out.
As a programmer, you’re basically in a state of constantly solving problems that nobody has previously solved. So, you have to learn and research.
Thus, programmers spend a lot of time reading how-to tutorials, watching videos, and participating in Q&A sites. They do it on the job, and their employers are fine with it. In fact, a lot of employers will even buy them subscriptions to such things to help.
Programmers Collaborate With Fellow Software Developers
Moving out of the realm of programming and reading about programming, let’s talk collaboration. Software developers usually work in teams. And they also frequently collaborate.
This can take on ad hoc forms, such as wandering over to one another’s desks, asking for advice. It can also feature more formal arrangements, such as design sessions around a whiteboard and formal code reviews. And sometimes it’s just a matter of policy, such as programming teams that implement pair programming.
But whatever form it takes, understand that professional programmers collaborate quite frequently. Some do it in person, some do it over videoconferencing, and some do it through chat platforms. But however they do it, they tend to do a lot of it, the iconic “lone wolf” programmer image notwithstanding.
Programmers Also Work With Other Parts of the Business
And the collaboration doesn’t stop with other programmers on their teams. Programmers interact a lot with other people in the organization as well. You can read a lot more about the nature of that interaction here, so I’ll just summarize the forms that it takes in this post:
- Programmers will have one-on-one meetings with a manager periodically.
- Programmers participate in design sessions that involve people in other disciplines for the sake of deciding what the software should look like and how users will interact with it.
- Troubleshooting frequently involves support techs and operations people, and these will usually be email or phone exchanges. For a serious enough issue, though, you might all appropriate some meeting room as your war room.
- When quality assurance people test the software, programmers will have a lot of back-and-forth with them over defects and resolutions to those defects.
- Programmers will probably do a good bit of digital collaboration with project managers and some in-person status meetings as well.
These types of collaboration don’t dominate programmers’ professional lives (if they do, the company is in “dysfunction” territory). But they definitely happen regularly.
And Programmers Do Things That Other Corporate Workers Do
I’ll close with one last slice of the programmer workday that you might overlook. And this is to say that, at the end of the day, programmers are office workers, just as any others are. So, if you’ve ever been an account manager, salesperson, bookkeeper, administrative assistant, etc., you’ve already experienced some overlap with the programmers.
- Just like you, they’ll go to company all-hands meetings.
- Any corporate-mandated training will rope both of you in, assuming it’s related to overarching concerns.
- You’ll all attend welcome and goodbye lunches.
- Team building or group exercises will snag all of you, too.
Generally speaking, the larger the company, the more this sort of thing occurs. So, there’s plenty of common overlap.
It’s also a good note to close on to emphasize that there’s nothing particularly mysterious or unique about programming for a living. It’s a knowledge work profession and an office job. But so are a lot of things in the office. At the end of the day, what programmers do at work is show up, work in the office, and leave, albeit with a specific and often societally romanticized specialty.
This post was written by Erik Dietrich. Erik is a veteran of the software world and has occupied just about every position in it: developer, architect, manager, CIO, and, eventually, independent management and strategy consultant. This breadth of experience has allowed him to speak to all industry personas and to write several books and countless blog posts on dozens of sites.
