With a projected 24 percent growth by 2026, the software engineering field boasts stunning job prospects. If you’re interested in coding, software engineering is an industry you should consider in 2023, but what does an actual day in the life of a software engineer look like?

Before we dive in, we should add two disclaimers: Obviously, the job varies day to day. Also, every company has its own culture and quirks.

I started off as a Civil Engineer, but as time went by and I began exploring my passions, I realized I was doing the wrong line of work.

Pursuing a career in software engineering was a daunting task at the time as I was fully engaged at my engineering job and later in my country’s National Youth Service Corps (NYSC) program. My approach was highly unconventional too. I never explicitly learned any programming languages. All I had was the determination to pick up projects I loved, read documentation, fail more times than I could count, and learn on the go. And somehow, it worked out.

All I can say today is, it requires perseverance, curiosity, and a genuine desire to be a good software engineer.

What quickly became apparent to me was that a background in civil engineering was extremely useful for a career in tech because I was already good at math (somewhat) and I’d picked up interpersonal communication at my job. I’d say that the additional responsibility of being a Lead comes with the additional requirement to be a good communicator.

Anyway, on to the day-to-day stuff.

Now this honestly varies for every company and is something I think about a lot, but this is my experience at my company.

There are two distinct aspects of my day.

The first is the time I spend actually writing code, building features and solving bugs. That time is incredibly fun, something I cherish during my day, and allows me to have stimulating conversations with coworkers and gain more experience writing code.

It also tends to be more of a solo operation. The difficulty of professional software engineering is considering the architecture and side-effects of any code you’re going to write. Once you have a design and implementation ready to go, going off to write the code can be a relaxing and stimulating experience.

Number two is my responsibilities as a team-lead, (less so as a regular engineer, but still relevant) is what I call gathering requirements and defending decisions.

My job as a team lead is to provide insight into what my team can and can’t do in regards to pushing a product forward. That might mean a few ad-hoc meetings a day, or conversation with other team leads in regards to the system as a whole.

I think that software engineering has a reputation as a non-interactive profession, but that couldn’t be further from the truth. I’m more successful at my job because I already had to interact with people in an engineering setting previously. Ultimately, the main strength of a developer is understanding business constraints in order to help the company be successful.

I’ll give you a schedule that I usually follow:

9 AM — 11:30 — I try to pick up what I was doing the day before, usually by looking at a failed test or note that I left myself to remind myself. It’s difficult to get all the context that you lost back, so leaving these little breadcrumbs to follow is largely a satisfying way to jump right back into it. This usually involves finishing up a feature, fixing a bug, writing a test, or looking at the priority for the day to determine what has to happen next.

11:30 AM — 2 PM — Meetings with other team leads in order to determine priority start. Since we’re a startup, it’s hard to define what will be the most important thing from week to week, although we use Atlassian stack for some of these. When that’s working, it’s easy to know what to work on next, but there can be times when collaboration in my department is needed.

I usually find some time for lunch in there somewhere.

2 PM — 4 — I like to pair program, which basically means working on a single feature or bug with another engineer. We’d usually jump on a huddle on Slack to get this done. The general idea looks like this: One engineer thinks about the implementation, and the other writes the code. It’s a nice way to learn about the other engineer's perspective and a great time to pick up some new information and knowledge!

4 PM — 5 — I usually buckle down for the rest of the day, and work on features/bugs that are part of my product roadmap or the priorities that were set earlier in the day. I get a lot done here. The pressure of the day closing is a nice motivating factor to get loose ends tied up.

5 PM — 5:30 — This is where I start thinking about the break point I can find in order to clean up from the day, and where I try to leave myself a starting point for the next day that I mentioned earlier.

With all this said, there’s always something unexpected that comes up. I try to stick to a schedule, but the main thing I feel every day is that Software Development is a rewarding field that allows the people in it to directly contribute to a companies success or failure. It can be full of pressure sometimes, but that also leads to an immense amount of satisfaction.

I’m happy to answer any questions you might have about my routine or time at Kiko!

Questions and comments are always welcome. You can read more about me and some of my other articles here.