Recently a Twitter friend asked me to describe a typical day at my job. That sounded fun, so here we go. It’s not thrills and excitement, but I’ll try to give you a slice of life as an employed software developer at a generic corporate job.
I try to wake up around 7 AM and be in the office by around 8:30 AM. Nobody makes me punch a clock, and nobody really watches when I come and go, but I do try to put in the number of hours expected of a full time employee.
When I arrive at work, I start my computer and pour myself some coffee or tea and the first thing I do is check my messages. Email, and our company chat rooms. We use Microsoft Teams, but a lot of companies use Slack. I wan’t to know if anything unexpected happened overnight or in the morning before I arrived, and if so I want to catch up. Usually there’s nothing.
Another part of this is that I work in an office with other people. It’s a semi-open plan office. We have half-height cubicles. If you sit down, you are alone. If you stand up, you can see over the walls. Working in a cubicle is not a hellish nightmare like Dilbert and The Matrix would have you believe. The people around me are my colleagues and friends. When I arrive, I am aware of the room even if I don’t think about it. If something important is going on, then I will see groups of people huddled and talking about it, and instinctively that will draw my attention and I will go and see what they are talking about. In that way, I stay informed of anything important that is happening.
If there are any major problems or outages, or anything needing my attention, then that might become the focus of my attention for the entire day. But most days even if there is a problem it’s not something I can fix, so I just focus on my own work. I check my email, and I check the latest messages on the company chat rooms, and if none of it seems directly related to my work, then I just get to work on the tasks at hand.
Usually I already know what work needs to be done because it’s the same thing I was working on yesterday.
I work at my desk, but I’m not chained to my desk. People freely move about near me, and very often I need help from other people. I can go and ask them for help. Or I can message them on the computer. Also, I have become one of the subject matter experts on my team, so sometimes other people need my help.
Usually my team and I have a meeting sometime early in the morning to discuss what we have been doing and what we plan to do that day. We call this a “stand-up”. Here there is usually a manager or someone representing management who especially wants to know about any impediments—anything blocking an engineer’s progress. If there is any impediment, then it’s the manager’s job to help the engineer get around it.
I am an engineer and a developer, so most of my time each work day is focused on those task. But this does not mean I spend all my time at a computer coding. I spend some of my time in meetings helping other people understand what my team has done and plans to do. I spend other time in meetings helping myself and my team understand what we need to do. A very large part of the work is social. If you are on a team for any length of time, then you become an expert on that part of the program. People will ask you questions, and you’ll be the house expert.
On a typical day there is not any fire to put out, so I focus on my engineering tasks. That may mean I attend a meeting, and I learn some things from the meeting. Or I don’t. Sometimes I’m just expected to be at meetings for no good reason. Other times, I choose to be at them for my own edification. People don’t normally micromanage me. It’s not like wage-labor where they always tell you where to be. Sometimes I know I’m expected to be someplace, but other times there are meetings that I can attend or I can hide and pretend I never saw the invitation. And sometimes I negotiate with a teammate so that he attends for both of us and fills me in later—and I’ll get the next one.
At my desk, during my free time, I spend some time writing code to develop a new piece of software or fix a problem in an existing program. I almost always have between two and five different problem or tasks to juggle, and I have some sense of the priority and deadlines of them.
If I am unclear on that, then I will speak with a manager. It’s the manager’s job to clarify matters of priority. As a developer, with more seniority and experience I begin to have a better sense of what really matters and what I should spend my time on—but as a developer it is never actually my decision. Developers do not make business decisions. We just deliver what the product managers ask for. As a developer, even if you are a full-time employee, you still work somewhat like a third-party contractor. Making business decisions is not the role of a software developer. We just do what they order.
An individual person may wear two hats. He may have the authority to make business decisions, and he may also write the software. But that is not what I do. I just make the software they ask me to make. And if I see anything that looks like a business decision, I stop and I elevate the question to a manager. I don’t make business decisions. I only make technical engineering decisions.
That does not mean people don’t care about my opinion on matters of product. I still have a seat at the table—literally. This week I attended a meeting where we presented our latest revisions of the software to the product managers. They are people just like you and me. Some of them were even software developers before they moved over to the product side. It was a free discussion, and if I had something to say then I could certainly have said it. But I was proud of our product, and I thought it looked very good.
This division of concern is common in any company where software is a big part of the business. They will hire engineers to build the software. And they will also hire “product” people, who are business people responsible for making decisions about what the software should be, and how it should be. You will often hear software engineers refer to them as “Product”, with a capital “P”. They are not our enemies. In most cases, they are friends and colleagues who have a keen eye for good design and good engineering—and for what the buyer wants. They represent the business and the final consumer. They make decisions about what to build. We, as software engineers, build what they ask for. And we all get paychecks as a result of pleasing the customer.
I have never in my career complained about too much interference from Product. In my experience, Product has been the strongest and best ally in favor of good design and good engineering—just the man or woman who wants it done right and who has the ear of the business executives so he can convince them.
If it sounds like I did not write a lot of code today, then that is also a fairly accurate appraisal. Sometimes I don’t write very much. The more useful you become for your knowledge alone, the less time you have for direct engineering. One colleague of mine is such an expert that he spends most of his time just sitting at his desk while one person after another asks him questions. If he does not write much code himself, who could blame him? I spend too much of his time asking him my many questions. I certainly could not blame him.
That is one take on a day in the life of a software developer.