What does a software developer do all day, anyway?

The story is a little different for all software developers, depending on the technologies they use and the work environment, but I'll describe what my day looks like as a developer at the Alabama Department of Transportation.

First, our work schedule is pretty strict. We have to work the same hours as everyone else in the organization. That means we arrive at 8AM, take an hour lunch at noon, and work until 5. We are discouraged from coming in early or staying late. They also don't like us to work through lunch. Having worked in environments where 60 hour work weeks were common, this doesn't bother me so much. However, as a contractor who gets paid for every hour I work, the extra hours are a nice little bonus. While this is the typical schedule, we will have "crunch time", when a "sprint" of the application must be completed before a certain date and can't slide. Then, everyone works extra to get the work done.

That's the schedule, so what do we actually do all day?

I get to work a few minutes early, check in with the administrative assistant, and then go over any email that I received the night before (I don't get much email here). I keep my email inbox clean, so if it's not important, I delete it. If I will need to refer to it later, I move it to the Archive folder. If it's work that I need someone else to do, I delegate it to them. I follow the principle of the three D's - Do, Delegate, or Delete. This is a much simpler and somewhat immature form of Zero Inbox Bounce, which Scott Hanselman explains here. Hopefully, I can get to that one day, but since I get so few emails in a day, I'm not sure how much that would help.

After I check my email, I take a look at my tasks in our issue tracking system. We use Microsoft Team Foundation Server to manage our source code and do issue tracking. It's an awesome system and it even integrates with the tool that I use to write code. My job is a little different than the other developers on my team. I work on the underlying architecture of the system that they use to write the application. In a sense, I'm the guy that makes the hammers, drills, and other tools that the others use to build the house with.

After deciding what I will work on for the morning, I launch my IDE (integrated development environment) and start looking at the code I have to work on. I use Microsoft Visual Studio to write code because we use the Microsoft .NET technology "stack" for software development. At 8:27, I wander into the conference room for our daily standup meeting. Actually, most of us sit during this meeting, it usually takes a little longer than fifteen minutes, and we sometimes solve problems in the meeting. It's not quite agile, but it's not a bad meeting and everyone leaves knowing everyone else's status.

Once I get back to my desk, I put on my noise-cancelling headphones, put on some Tangerine Dream music, and start working on code. Almost all of the code I write is re-used by other developers in the organization, so I have to be very careful about my design and implementation. I strive to make my code easy to use (and maintain) and work hard to reduce the amount of repetitious code the other developers have to write when they build new screens or convert the legacy screens to the new technology.

After I write a few lines of code, I press Ctrl+S. It's a habit. This will ensure that my latest code is saved to disk in case something goes wrong. I think the Ctrl+S habit is something that every developer (or probably even every other professional that uses a computer editor) acquires in their career. After the code is ready to be tested by me, I press Shift+Ctrl+B, which tells Visual Studio to "build" the code into software that can be run. If there are any build errors (misspelled keywords, missing semicolons in C# code, etc.), I fix them and build again until it succeeds. I then press F5 to debug the code. Debugging is when you run the code in a special mode that allows you to put breakpoints in your source code. When the computer runs your code to that breakpoint, it will stop execution there and let you examine the state of the application at that point. This lets you see the value of variables and whether or not you're passing the correct data around to different functions. Some days I will spend most of my time writing code, others will be spent debugging code and fixing bugs as I find them. A bug is some line or lines of code in your system that causes it to work incorrectly. Finding and removing bugs is one of the most important skills you should develop if you are a developer (or want to become one). Debugging can be stressful because some bugs are deep in the system. The most frustrating bugs are the ones where you spend hours debugging only to find you've used the wrong variable or left out a comma or semicolon somewhere.

Here is an interesting story on the origin of the word "bug" to describe computer bugs.

Once the code has passed my local testing procedures, I commit the changes to our source control server, which kicks off an automated build on the build server. Once the build server has completed its build, it deploys it to the proper place for use by the other developers. For instance, if I'm working on code that is included in one of our shared libraries (NuGet package), it will be deployed to our private package repository. The next time a developer looks at the updated packages in their system, they will see the new version number and know that there's a new version they should use. We generally communicate enough to know when a new version is coming.

When lunch time comes, I go outside and get in the car with Laurie and we head to a nearby park where we sit and eat a picnic lunch while enjoying nature. Sometimes, we are visited by various cars filled with people partaking in very pungent marijuana and playing loud music. They don't usually stay more than thirty minutes. We've started calling the place "Pot Park" due to all the smokers who visit during their lunch break.

After lunch, I come back and work on my code some more. Throughout the day, I am approached by other developers who ask for my assistance solving a problem that they have with the system. This is the most rewarding part of my job as I like to help others solve problems. It feels good when we work together to squash a bug or clean up bad data in the system that is caused by faulty code. Sometimes, these questions lead to the discovery of a flaw in the underlying architecture, so I'll enter a bug in the issue tracker and start working to fix it in the core code.

Since last year, I've helped ALDOT implement a new system back-end utilizing ASP.NET Core 2 WebApi. We call it wapi and it has become the core of our back-end. By using Jeff's repository library (written on top of Entity Framework), wapi reads and saves data to the database using a RESTful interface. The existing application is now being modified to request its data from wapi using a library that I wrote called Wapi.Client.

Some days, I don't write much code. Instead, I design new subsystems or modules on existing systems. One of my current tasks is to rewrite our navigation subsystem to use the new wapi back-end. I've been working on that design off and on for about a week now. For design documentation, I use the excellent online diagramming tool Draw.io.

I also write documentation. We use the built-in wiki on TFS to keep up with our developer documentation. I maintain a good portion of that documentation along with the help of another developer. Good documentation describes how to use the core system in clear, concise English and includes plenty of examples. I try to follow this definition as much as possible.

Once the code has been released to the development server, I check to make sure that it runs like it's supposed to. We then move it on to the test server, where a Quality Assurance (QA) analyst will test it thoroughly. If they find a bug, they will add a bug to the issue tracker and assign it to me (or re-assign the existing ticket if it's in the current iteration). I'll then fix the issue and re-release.

I've known that I wanted to be a software developer since I was ten years old. I'm fortunate that I was able to get a job doing what I am passionate about. It's nice to write code all day and see the computer systems work the way we tell them to.

It's satisfying to know that the software that we write is ultimately used to manage all of the state road construction projects and construction materials in Alabama. Our team works hard to make sure that we release the best software we can. I'm proud to be a member of a team that cares so much about the quality of their code.

Pros:

• Work indoors in air-conditioned space
• Access to the right tools to get my job done
• Enough technical freedom that I can build the right solution for the problem at hand
• Good team dynamics - we all get along nicely and everyone is mostly professional (we have moments of stress where things don't run as smoothly as they could, but what team doesn't?)
• Hands-off management - We aren't micromanaged here. We're given tasks and expected to perform them within the allotted time
• Plenty of "rope" - We're given a good amount of rope. Enough to hang ourselves with if we're not careful...

Cons:

• Work indoors in air-conditioned space - we don't work outside, so we don't get any sunlight or exercise. That's just a side-effect of being an office worker