A Day In The Life

Taking some inspiration from my favorite ‘cast this week, Guidance Counselor 2.0, by Taylor Desseyn. I wanted to ‘get real’ a little bit about what it’s really like to be a professional software developer and use this post to delve a bit into the day-to-day life of a dev.

A bit of disclaimer first: This is entirely based on my experiences and that of others I am familiar with. That said, there is no single, real answer to the question: What is it like to be a software developer? It literally varies from company to company, position to position, person to person, and even day to day. That’s one of the greatest parts of being a software developer: the variety.

The one thing I can categorically say is this. I don’t know a single developer who spends all day, every day doing nothing but writing code. It just doesn’t happen anywhere I’ve ever seen or even heard of. Even those devs who work for themselves writing their own apps don’t work that way. There are a million other things that need to be done. But let’s start with the obvious.

Coding

Ah, the pure joy that is writing code. It is the developer’s reason for being, their motivation for existing in this career field. And a certain percentage of your day is going to be spent writing code. It’s generally your primary job duty. As such, you’ll spend a chunk of your time writing code. The amount of time you’ll spend on this task will vary wildly, especially the further you get into your career.

Odds are, as an entry-level dev, you’ll get to actually spend more time on coding than when you get further into your career. Don’t get me wrong. As a senior-level dev, you’ll still get to spend a lot of time coding. But you’ll also find that you get pulled into a number of other things as well. That’s the payoff for getting all that experience. And here you thought it was a title and a bigger paycheck!

Production Support

No matter how well your team writes its code, things will still break. As one of my favorite sayings goes: No matter how idiot-proof you make something, the world will just give you a bigger idiot. Plus, Murphy’s Law seems to apply triple to software systems. Anything that can go wrong, will go wrong in some way, shape, or form.

As a result, you’ll get to spend a bit of time trying to figure out what went wrong in production. Sometimes it’s a minor issue and you can take a little time. And sometimes all hell is breaking loose and a production outage is costing the company hundreds of thousands of dollars in lost revenue per minute and everyone is scrambling in an all-hands-on-deck hotline call to get things up and running again.

These events have a number of benefits for you as an individual developer and your team as a whole. For one, you learn new ways your code can break and what you need to do to make your apps more idiot-proof. But there’s one, much bigger benefit these crisis events bring.

The result is that this is one of those times that shows the true culture of the company you work for, and the kind of person your boss is. Sometimes the cause is someone’s fault and sometimes it isn’t anyone’s fault. Things happen. In a time of crisis, regardless of the root cause, does your boss and their boss have your back? Do they support you and uplift and encourage you? Or do they toss you to the wolves and lay the blame on your shoulders? If they don’t have your back, you know it’s time to polish up the resume and find a new company. Because if they sacrifice you once, they’ll absolutely do it again.

Paperwork & Documentation

This is an area where many developers and/or companies struggle. We love to write the code, but we struggle to create documentation that will make it easier to support the code later on. Now, if you’re following a good development process, a lot of that documentation around the design will get created before you even write a single line of code.

However, this initial design won’t necessarily be a detailed overview from a technical standpoint. And even if it is, there will likely be many changes to the design as you get into it. Like armies in a battle, your initial design won’t survive the first few hours and days of actual contact with code. And many of us aren’t particularly good at updating those initial design docs to reflect those changes. Don’t be like that. Keep up good documentation and you’ll save a lot of pain later on.

Meetings

Meetings…meetings…meetings… You’ll spend a lot of time in meetings. These meetings will have a number of different purposes. These days a lot of teams will at least have what they call a daily standup. These meetings are usually at the start or the end of the day and will be used as a touch point where team members give a few seconds of updates on what they’ve accomplished, what they’re working on, and any issues they might need assistance on.

Another frequent meeting you’ll be involved in will revolve around gathering and talking about requirements for tasks you’re working on or will soon start on. These meetings will include what are called “stakeholders”. That’s a catch-all term for anyone from the business and/or client who has an interest or responsibility for something you’re working on.

Learn early in your career two very important skills that will come to the fore during meetings: listening and asking clarifying questions. It’s amazing to me how few developers have learned either of these skills. If you want to set yourself apart from a bunch of your coworkers, learn these two skills. There are few things more irritating than a coworker in a meeting demonstrating that they clearly weren’t listening to what others have said.

One-on-ones are meetings between you and your boss where you’ll talk about your progress and goals and such. All managers should be having these meetings with their staff. If they’re any good anyway.

Another meeting related to that is your annual (or semi-annual) review. This is usually the time to review the last year’s goals and set new goals. This is usually tied to your annual raise as well.

Another kind of meeting you’ll run into frequently is the “all-hands” meeting. These are typically on a regular basis of some kind, either quarterly or annually. During these meetings, executives and senior leadership will share things with the common worker like company updates, “visions” for the future of the company, and meaningless awards or recognitions of employees who have gone “above and beyond”. I’ll be honest. During these meetings, your eyes will glaze over and you’ll probably drift off into a coma of some sort.

The only time you need to pay close attention is when such a meeting is called unexpectedly at the last minute. When that happens, it’s never good news for the common worker, because such a meeting means re-organizations or mergers or layoffs or something similar. And that almost always means that you and your coworkers are about to get screwed in at least one, and probably many, ways.

Training

If you work for any halfway decent company, some of your time will be spent in training. This can take many forms, including hands-on workshops, videos, books, seminars, applications, and so forth. If your employer doesn’t offer opportunities for learning, find another employer. Really. Ongoing learning is really that important to a developer’s career. Technology changes, a lot, and frequently. Get left behind and your career will stagnate and you’ll end up in the same job at the same company for a decade or more until the app or tech you support is replaced with something new or just shut down and you become redundant and no longer have relevant skills that will land you a new position somewhere.

Some of that training will often be mandatory HR training. Usually, when you’re first hired, and then again annually, you’ll have to complete training of some kind around company policies like sexual harassment.

Emails, Instant Messages, and Phone Calls

You’ll spend a lot of time answering emails and phone calls. These might include questions from various people, requests for updates on progress and status, responses to emails and calls you sent out, and so forth. Some people will ignore emails until the end of the day or the start of the next day. Don’t do that. There will be a lot of ad hoc requests, urgent requests, and so forth. At the very least check every 2 hours.

Interviews

Depending on your seniority level and the current state of your company and its needs, you may find yourself asked to participate in the interview process for new candidates. Most good managers will include one or more of their team in the hiring process, especially for the technical parts of the interview process. It won’t take up a lot of your time (unless you’re a dev lead usually), but it will probably come up.

Helping Others

Some of your time will be spent helping your fellow devs. It might be pair programming, design sessions, answering questions, knowledge transfers, cross-training, and so forth. Never be one of those who hoard their knowledge or who are inaccessible to others. Be a team player.

Installing Updates

Yes, a chunk of your time is going to be spent installing software or software updates. Whether its a new tool or an update to something like Visual Studio or Windows, you’ll have to spend at least a little time watching a progress bar. It’s annoying but necessary.

A Typical Day

The typical day that applies to every developer doesn’t exist. As I mentioned at the start, it varies wildly for everyone. But I’ll tell you what a typical day for me consists of. I should mention that I’m a manager of a team of developers for a consulting firm. Even so, I do get to spend a bit of my time hands-on with development tasks. I should also mention that I work from home and my team works entirely remotely.

My typical day starts with reviewing any non-urgent emails or messages that came in after hours. Usually, I do this while I’m eating breakfast. I say non-urgent because anything urgent would have been handled after hours. As consultants, we’re expected to be available when the client needs us.

Once I’m caught up on that, I’ll review the day’s schedule to remind myself if there’s anything I need to prep for, such as gathering information for meetings, getting updates from team members, and so forth.

About the time all that’s wrapped up, I’ll have anywhere from 1 to 3 standups with various client teams. The number depends on the day. While these meetings typically are run by someone on the client side, I will take notes as needed and always be ready to jump in to coordinate or follow up on tasks for my various team members or myself.

On a light day, that will be about it for meetings. On busier days I’ll have as many as 7 or 8 meetings. These are typically scattered across the day and will consist of sprint planning meetings, other team meetings, one-on-ones with my full-time team members, checking in with recruiters on both the current status of contractors who work for me or potential candidates to add, conducting interviews, or other management meetings.

Most days I will also receive requests for support of one kind or another from clients. Some of those requests will be matters I can assist with, be it by fixing the matter myself or jumping on a quick call with the client to work with them on the issue. For those matters that need one of my devs, I’ll coordinate getting one or more of them involved, then hand the matter off.

While I occasionally have to work through lunch, I do all that I can to avoid doing any work during lunch. I might be writing blog posts (like this one) or videos, or just watching YouTube or streaming an episode of a tv show I’m catching up on. Working lunches are generally a bad idea. This includes lunch and learns. Regardless of how it’s presented, a lunch and learn is work. Your brain needs a mental break away from work. Take it if you can.

For me, there are a few other things that can interject themselves into my work day. One fairly common task is cross-training with client teams. This will include meeting with one or more of their dev team to teach them about a technology such as Azure Data Factory or Power Automate, or to hand over knowledge about a particular piece of code that we have implemented for them so that they can take over the long-term support. That’s one of the tasks that I enjoy the most: teaching.

In amongst everything else I might have to do, the rest of my time is set aside for hands-on developer tasks. Some days that might be a good 5 or 6 hours worth of my time. On other days, maybe 2 or 3. And on a rare day, I might have so many other things going on that I’m left with little to no time for code.

As for the code I work on, in my particular case, my team works with Microsoft Dynamics. Since the devs are the Dynamics experts, I let them handle those tasks and take on for myself a lot of the code tasks around the periphery, such as C#, JavaScript, Power Automate, Azure Data Factory, Azure Functions, and so forth.

And I wrap up my day by filling out my timesheets. Oh, the one thing pretty much every developer will have to learn is how to fill out a time sheet. For some companies, it can be simple. For others, they require enormous detail. For the truly absurd, it can go to the extreme. One company I worked for required time sheets detailed to the nearest 5-minute increment. They eventually relaxed the policy when they realized workers were spending an hour every day just updating timesheets. Avoid companies like this.

Conclusion

You might think that since I’m a manager, your day as a full-time dev might not be so chaotic. And that’s true, to a certain extent. But if I were to break it down, my management responsibilities typically only account for 10%-30% of my time on any particular day. The rest is spent doing much the same thing my devs are doing.

When you get down to it, though, I’ll say it again. There is no “typical” day for a developer. And that’s one of the best parts of this job. For most of us, there is endless variety and constantly something new and different to tackle. No two days go the same way. It’s just another reason that this is one of the best jobs in the world. Come… join us.

The post A Day In The Life first appeared on Barret Codes.