For the last few years, I’ve essentially been a software developer doing Tier 1 support. Instead of proactively being able to simplify and optimize our software solutions, all I could do was react to the business units who were reporting issues. The pile of bugs kept growing and growing and managing those bugs proved to be in itself almost a full time job. I know that I’m not the first developer to be in this situation and I certainly won’t be the last. If you haven’t been in this spiral of decay let me tell you something: It Bleeping Sucks! Just know that it doesn’t have to be this way.

In my latter days of obtaining my bachelors degree in Computer Science at Ball State University I was introduced to Agile principals of software development during a game programming class. Almost instantaneously, I could feel the impact and see the value in using this principals and I was hooked. Last year I obtained my ScrumMaster certification (which was disappointingly easy).

In the very late half of 2016 and the first few weeks of 2017, I helped design our SDLC processes at work. In February, the IT department was restructured and I was moved to our Software Development team. Now that I’m shielded from the daily ballistics of tickets coming the business units, I find myself actually analyzing and designing systems before jumping into a solution. Additionally, I also find myself refactoring code for the first time in three years.

At first I thought this was because I’m physically separated from the business. Interestingly, I’ve found out that what is actually happening is that the SDLC process actually increased our the delivery of new features and bug fixes at such a rate that the business is running out of things to request. To put this in perspective, in 2016 we had only about 10 production releases whereas we have had 8 releases in under 2 ¹⁄₂ months. Also, the business units seem to be taking much more time to define project requirements. This has caused me to make a major shift in my day-to-day thinking and overall picture of what is happening around me.

Honestly, I’m relearning what is really is to be a developer. Remember that for 3 years beforehand, I was essentially acting as Tier 1 support and running triage on the system to just get the ticket board to be quite. Now, I have to learn to adapt to this new environment. I really wasn’t able to analyze the problem and designing the solution. I just furiously Google searched whatever line of code I was working on until it worked (which never did). I felt like I was just wasting my time and never getting anywhere and getting intensively frustrated. Then I stumbled upon a blog post that caught my eye: Design Your Ideal Week-Increase Productivity by Marie Poulin

I decided to design my week with some themes that I feel are important for a software developer and strategically divided up my calendar to stay focused on my tasks.

Design

Designing the software solution before you begin writing code.

Create

Writing your code and documentation.

Refactor

Reinventing and cleaning your code. Paying off technical debt.

Personal Development

Reading blogs, listening to podcasts, conferences, and reflect.

Not Negotiable

Lunch, workout, remove yourself from your desk and pull your mind away from what you are working on.

Email

Reserved from responding, clearing, or sending email.

Here’s a look at my calendar I’ve created.

Update: August 5, 2017 After a few months of sticking to a schedule like this, it has increased my productivity, decreased my anxiety, and provided me with a great means to better myself and improve everyday. If you’ve been struggling to feel like your actually going somewhere, I highly suggest you implement this system into your life. I mean, if the guy that wrote the Dilbert cartoons says it works, what excuse could you have not to try it?