I’m a developer, not a coder – my experiences of working in an innovation consultancy

I joined Tammerforce, the Tampere office of Futurice, as a summer employee in May 2018. My background was not the most typical one for a software developer. I had a Bachelor’s degree in Business Administration, some working experience from e.g. university research and development (mainly in social services), lots of experience performing in front of an audience as a semi-professional musician, some marketing gigs, event organizing and such. As a matter of fact, I only had very minor experience within IT – just a few months of consultancy work the previous summer, two years of very lazy studies in the local university, several smaller scale projects of my own, and an active role in organizing TampereJS, a local web developer meetup. I had also spent a lot of time in the local startup community, getting into business development, lean validation, and all that jazz.

To be honest, I was never interested in computers when growing up. The reason I got into coding in my mid-20s was because I saw it as a way to create something “concrete” – or as concrete as intangible digital things can be, anyway. To me, coding seemed in many ways similar to creating music, one of my favorite hobbies for years: starting with nothing, sitting in front of a computer for a few nights, and ending up with a song, or in this case, something like a working web app.

As a result, I feel that as an employee, my biggest strength is not my technical capability. To be clear, I don’t feel incapable as a coder, but I do feel that I’m not using my full potential if I’m limited to strictly implementing technical tasks defined by someone else. This was something that weighed heavily when looking for a job back in spring 2018. So when I started at Futurice, I had high hopes of not being “just a coder”, but being able to contribute in more ways in my work.

From day one

When I started at Tammerforce, I joined a client team as the fourth developer. At first I worked on some smaller tickets in products – that we had built earlier for the client – that needed some small additional features developed or issues fixed, while getting used to the tools and ways of working. From the beginning, my teammates asked my opinion on doing things, and I pushed for e.g. enforcing a clean git history for easier maintenance work. Even as the newest and least experienced developer, my thoughts and contributions were valued, which gave me a strong sense of ownership and commitment in the team, as opposed to making me feel like a “resource” cranking out code.

Pretty soon I also got my first larger task of implementing a new feature integrating two customer-facing services together. The specifications were very vague – instead, the client had a specific business need, making work easier for their customer service staff. One of the two services submitted contact forms to the customer service email inbox, and the other created customer call reservations into a system used by the customer service agents. In some cases a form and a call slot reservation would be related to each other, and the customer service agents needed this contextual information.

Technically these two systems were in no way related to each other. The client had envisioned a solution that involved complex session handling between the two services, which would have required a new backend service to be possible in the first place. After some discussions with the client, I managed to convince them that we should start with the minimum solution that would still solve the problem – that is, adding an ID to the submitted forms, passing the form data in query params to the call reservation system when using the direct link, and including the ID there. This way the customer service agent would be easily able to locate a call slot’s related form from the inbox by searching with the ID.

Getting this idea through was a major personal experience of success for three reasons:

1. Most importantly, I felt like my opinion was valued, not just as a coder but more broadly as a developer, whose main task is to solve problems and create value.
2. This led us to the problem being solved faster and with lower costs, instead of building something more complex only to potentially realize it doesn’t actually make the customer service agents’ work any easier.
3. I had no idea how to build the initially suggested and more complex solution (but let’s not dwell too much on minor details like that).

Surviving technical frustration

Long story short, I’ve since been working continuously on the same account, while the other members of the team have rotated to other accounts. During this time my role has constantly evolved and my responsibilities varied. For example, I’ve led a project where I was responsible for developing an algorithm to predict faults in a power grid, learned a lot about configuring Nginx and Ubuntu servers over SSH, become quite familiar with Docker-based DevOps, and hooked Redux to a legacy product built with (among other things) RxJS, just to make debugging with dev tools possible.

When working with already existing products and services that have users, you’ll often run into things that are not optimal. Some parts of the code are messy and hard to follow, some documentation is nonexisting, some solutions are “definitely not what I would do”, some technical dependencies not exactly cutting edge, and so on. And as the services have users, wiping out the existing code and starting from a clean slate is not an option, no matter how tempting it sounds to a developer. This applies to pretty much all code – even when running git blame prints my own name on the screen.

There’s no sugarcoating it: Working with a large legacy codebase with far-from-cutting-edge technologies and no tests is frustrating. I keep hearing people talking about React hooks – those sound nice and I would certainly like to try them out. Also, all this talk about serverless, Lambdas and cloud sounds tempting. But in my work, the main point is providing value for the client. I primarily develop services – code and technical details are secondary. And when the solved problems are motivating, the technology doesn’t matter that much.

Interesting challenges, continuity and ownership

My work has given me lots of interesting and motivating business problems to solve. For example, we are building a large web application (frontend, backend and several microservices) and running four different product flavors of the same application, in eight different server environments. Designing, developing and running that kind of system is a challenging and rewarding task in itself, even when certain pieces of the whole puzzle are not shiny and new. And the abovementioned fault prediction software is another good example: The existing tech stack and source code were not exactly the latest hip and cool, but designing and developing the prediction algorithm, as well as solving the business problem of pre-emptively allocating repair personnel to minimize grid downtime, were both challenging and motivating things to work on.

One thing that people often associate with working in a consultancy is this dreaded model of delivering something quickly and never seeing the thing you built in action. This is far from what I’ve experienced. The account I’ve been working on has been active for several years now, and apart from very minor exceptions, we keep maintaining and further developing the services we have built for the client. This kind of longevity really creates a sense of ownership and makes me want to ensure the applications we build are good and maintainable. Not just because of professional pride, but also because I will be involved in fixing them if they break.

Another very rewarding aspect for me has been deepening the client relationship and my personal role in it. During my time in Tammerforce, the team has more than doubled in size, and I’m currently the Scrum Master in a longer running development project.

Developing and coding

My daily work involves continuous communication with the client, development task allocation, application level coding, DevOps, onboarding new team members, participating in sales and account management, and whatnot.

And that’s just what I do in the account work.

A promising career in acting, and all the other responsibilities

One of my favorite things about working at Tammerforce is the balance between feeling like working in a large company, and working in a small company. With its 500+ employees and offices in multiple countries, Futurice as a whole is an environment that offers financial stability and large scale international opportunities, whereas Tammerforce with its 70+ employees is quite an agile environment to work in. There’s not a lot of bureaucracy, and I for one have been able to do pretty much anything that I felt like doing in my work.

Some of my more crucial marketing contributions.

In addition to my primary duties I have done for example marketing, recruitment events, student organization collaboration, sales support, some workshop facilitation, speaking at events, and surprisingly many minutes of acting in front of a camera. I’ve also been organizing some “extracurricular activities” – such as organizing an employee cruise, and engaging my coworkers in a wellness campaign.

Some of my big screen acting right here.

So when someone asks me what my job is about, I like to say that I develop things: software, systems, services, business, processes, client relations, marketing, communities, my colleagues’ tolerance of bad puns, my biceps and whatnot. Coding is just one of the tools I commonly use in my work.

If developing things in the heart of Tampere sounds appealing to you, check out what Tammerforce has to offer at https://promise.tammerforce.com/