A Day in the Life of a (Senior) Developer

Have you ever noticed how hard it is to explain your work to someone outside your field? If you’re anything like me, there’s a long pause when you need to fill out some official paperwork and it has a question about your job. “If I put in ‘developer’, are they going to understand that I’m a computer programmer… of sorts?” Then you just end up typing “programmer” and hope nobody ever asks you to explain the finer points of Assembly. That’s painful enough, but having to explain what you actually do in your day-to-day is pure agony.

Now, what did I do? I “volunteered” to write about the subject. Genius. Oh well, here goes: in the novel that follows, I’ll try my best to explain what a developer like me does at Exove and how the job changes as you gain experience and responsibilities. A post like this is certainly not Star Trek – people have boldly gone here before. I’ll try to keep my explanation on a somewhat generic level; hopefully this post won’t require an engineering degree to understand. That’d be preferable, since I don’t have one.

Dinosaurs, fossils and other ancient history

Before I get started with the day-to-day, let me explain a bit about my history at Exove, just to put things into perspective. I’ve been working here for quite a while now: I started in December 2013, on what you might call the “standard” level for our developers. That means I’ve never been a junior developer or a trainee. I can’t tell you much about what the trainee program is like, except maybe from the mentor perspective. If you’re interested in the trainee program, at least James and Marc have shared their experiences.

Web development is commonly divided into two parts: front-end (the things you see on a web page) and back-end (the things that make the front-end work). I applied for a front-end developer position, and I’m nominally still one in some semi-official paperwork. Exove doesn’t really make the distinction in practise anymore, however, so I mostly concentrate on back-end tasks. It’s important to note that you’re not forever tied to the title and job description you initially apply for. You’re given opportunities to branch out according to your own interests and goals.

I was the first employee in Oulu, so there was always going to be more remote work than is the case for people sitting in the Helsinki HQ; we didn’t even have an office here at first. Starting a whole new office meant an unusual amount of responsibility from the very beginning. I was immediately given a technical lead position in an existing project, because the client was in Oulu and it made sense. After the first year, I became the vice team lead of a mixed Helsinki/Oulu team; after the second year, I became the actual team lead. Nowadays I lead an entirely Oulu-based team. I recently became a senior developer, too, but that wasn’t a huge change of pace – Exove just isn’t really big on fancy titles.

The takeaway from my experience is that it’s rather unusual. Normally when you start in a developer position, you’re expected to be able to handle tasks thrown your way, but you don’t generally need to do any of the throwing. You’ll have a mentor to help you. My career path has been one of quickly increasing responsibilities, but yours doesn’t have to be.

What’s in a Monday?

It’s surprisingly difficult to describe a typical working day at Exove. I might as well start with everyone’s favorite, Monday. I’m sure you expected me to call it the best day of the week and all that, but nope. I often work from home on Mondays, because I’ve never been very good at sleeping on Sunday nights, and commuting to the office would just be a waste of energy. Luckily, remote work is not a problem, as long as your team knows about it and you don’t happen to be expected in a face-to-face meeting. If you like sleeping in, that’s fine too; unless you have the rare morning meeting, nobody will bat an eye if you start at 10 AM. I don’t think I’ve ever had a morning meeting on a Monday.

The first application I usually fire up is Slack, which we’ve been using for messaging since 2015. We rely on Helsinki for a lot of things, so it’s a huge part of my day; I proudly lead our all-time message count statistics with a count of some 210 000 messages posted. That translates to about 150-200 messages for every working day since we started using Slack. Suffice to say that e-mails aren’t that big in our field. There are plenty of those, too, but nowadays they are mostly notifications about tickets from Jira (our ticketing system) or activity in Bitbucket (our collaborative version control system). There’s a lot of stuff you need to read, but for a developer, e-mails you actually need to reply to aren’t very common anymore.

So, chatting is a big part of the day. Then there is, of course, another form of communication: meetings. Those tend to increase in frequency as you gain experience and responsibilities, but I try to keep my schedule as clear as possible, so they mostly cluster on Wednesdays and Fridays. I’m currently the technical lead – the lead developer in charge of actually getting the project done – in six projects, two of which are internal. That means meetings with four clients at least once per sprint, i.e. every two weeks. These meetings are mostly Scrum-style backlog refinement and planning discussions. Besides client meetings, there’s the biweekly staff meeting that everyone attends, and often a monthly guild meeting or two. My role as a team lead also involves dealing with other people’s resourcing (what they’re supposed to work on during the two-week sprint), so there might be a meeting about that during the week, too.

Most of my time each day is spent on development work. That’s where the actual computer programming part happens. Currently, I primarily work with the Drupal content management system. In short, my everyday work is to plan, create and maintain our clients’ web sites. Besides writing code, development involves a lot of discussion with our design people at Exove Design so that we get workable plans to base our work on – anything from “what should it look like on a phone screen” to “what should happen if I click this”. Not every web site is created equal, of course, so the work doesn’t get repetitive or boring. Some sites are purely informational and information only flows from our client to their end users, whereas some are more application-like and involve more interaction with the end user – e-commerce and other e-business sites, for example.

One last frequently occurring thing worth mentioning is writing. Exove doesn’t usually get involved in our clients’ content creation process – other than in a consulting role – but I still get to write quite a bit. It’s not just documentation and guides, either – there are also things like sales offers and of course blog posts like this. I’m especially active in writing solution descriptions for our offers, and one of those tends to appear on my desk at least once per month. This is one of the things that tends to happen as you gain more experience: you’re expected to share your knowledge, pull your own weight in getting new projects and help the company move forward.

So far, I bet most people working in developer roles haven’t seen anything unexpected. What, then, makes Exove different?

Something old, something new, something borrowed, something blue

Let’s face it: from a developer’s perspective, every tech company in Finland is pretty much like any other. Everyone has more or less the same benefits, pays about the same and generally works in a certain fashion with seemingly minor differences. Why have I stuck with Exove for more than six years?

First of all, I like the atmosphere. We have project teams for every project, but those aren’t the only teams you’re in. You can be part of several project teams at once, and those come and go with projects, but you always have a “home” team sitting next to you. Even if none of them work in the same project as you, you always have those same 5-10 people nearby to share ideas and go to lunch with. In an ideal case, your home team is also your project team, and productivity soars. There are also the aforementioned guilds for people sharing a common interest in a specific subject, such as machine learning, sales support or Drupal. They regularly hold training sessions, so you don’t need to learn everything by yourself if you don’t want to.

Another thing that helps reinforce a sort of family feeling is that Exove isn’t as big on the rent-a-developer business model as some other software development companies. Sure, some people do work at client premises, but rarely for long stretches of time or every day of the week. That means you generally work not only with the same people, but from the same office every day. Salaries may be slightly higher in the rent-a-developer model, but on the other hand, you often need to accept some risks, too – such as getting only a low base salary when on sick leave or between projects. I imagine it’s also harder to find people willing to devote time to internal development tasks or company development or, uh, writing blog posts. I’m pretty sure that the family feeling is one major reason for our consistently high ranking in the Great Place to Work competition.

Exove is also highly flexible for a company of its size. Going on study leave, working part-time, or taking a six-week summer vacation by working in extra hours is easy as pie. There’s no approval process at all; you just let the appropriate people know. If you prefer to work 10-18 instead of 8-16, or need to visit the doctor or take the car to the shop during the day, that’s fine. Working from home or your favorite restaurant is perfectly okay. In short, you’re given a lot of freedom in organizing your work and managing your work-life balance. Oh, except that you do need to use a Mac. Everyone uses a Mac. It just wouldn’t be hip and cool if we didn’t.

Last but not least – the focus on, well, focus. In the previous section, you might’ve noticed that I didn’t mention having to spend time doing what many developers fear the most: project management. Sure, in the lead developer role I need to help with it to some extent, but I’m not responsible for it. We have a team of project managers for that. The same goes for other non-development roles like HR, marketing or sales: if I want to take part in a recruitment event to help out HR, I can, but it’s my decision. If I feel like it, I can also just keep wearing my developer hat all day. Having people in non-developer roles is nowhere near a given these days, but we’ve got a bunch of awesome, dedicated people who get us new projects, crunch the numbers or act as the first points of contact for clients. That lets people like me focus on coding.

Come to think of it, maybe that’s the key. Much of what the company does revolves around allowing developers to focus on development work instead of constantly multitasking. That’s nice, because it’s what my contract says I’m paid to do. At the same time, we’re allowed to pursue our other interests, so that we don’t feel like we’re being squeezed dry. It really kind of makes you feel all warm and fuzzy and valued.

Thoughts by