Skip to main content

Why am I a consultant

Have you ever wondered what do software consultants exactly do? I'll share my view of how I ended up as a software consultant, what I have gained and what do I do as a consultant.

My brief background


I started my career as a programmer in the early years of 2000's as part of my studies and via summer jobs. Back then I was working with web sites and doing... well what ever we could do back then. Few years later I enrolled to university and at some point started working as a programmer to have some side income and work experience. After I graduated I continued working for the same employer I had been been working for the past few years.

After four years of working with the same employer and on pretty much the same applications and technologies I started to notice that I wasn't learning new skills or technologies as much and fast as I wanted to.

Time for a change


I started looking for job openings and had a few interviews with different companies. I chose to work for a company that offered me a job with a in-premises project where I'd be joining a small team who'd been working on the project for a while. This seemed like a great opportunity to work on something new and learn new skills. I knew I'd be working for a company that did subcontracting on the form of software projects for various clients. What I didn't fully realize then was that that's exactly what consultancies in Finland actually do. So by a sheer chance I became a consultant. I worked for the company for a few years with various clients and really started to like how consulting in the software business works.

I've been working as a consultant ever since and the few times I've changed jobs I haven't seriously considered working in any other position.

I'm a consultant - what I have gained from it


I've thought about it more than few times what it means to me to be a consultant and what it has given me compared to my previous jobs.

Networking


The network I have gained during my years as a consultant is something I could have never achieved if I'd been working in product development company or in a company that has a internal software development unit. The professional network that I have gained as a consultant can be divided to different sections.

Clients

The network of different clients in various business domains. Via this network I know a lot of people from different business fields and I have gained working experience in various domains.

External contacts

External contacts consists of clients and their own software developers and it's common to be working side by side with consultants from other companies.

Internal contacts

Internal contacts are all my great colleagues from all the companies I have worked in.

Learning

By working with various clients in different business domains I have gained a lot of knowledge on different business fields. I can see commonalities and differences on how different clients and business fields do things and I can apply that knowledge and compare various technologies and work habits and processes to each other.

I believe I can learn from every client and from every colleague, internal or external, and I can honestly say that I have learned something while working with each of my clients and colleagues.

Learning as a programmer doesn't always mean learning new technical skills, frameworks or languages but also about soft skills, project habits and management or how to organize work and how to not do things.

What do I do as a consultant


Main area of my expertise is programming and that's the role I have when I start working with a new client.

Depending on the client and their needs I have been doing a lot more than just programming. With some clients I have been doing a lot of investigation tasks related to integrations between different systems or investigations on how some legacy systems work.

At some rare occasions my work has also included some work management in the form of introducing or trying to improve existing methods on how a team could organize it's own work better or make the teams work more transparent.

Besides the work I do for clients I also participate in some internal work. I have been doing recruitment interviews and when needed I give support to our sales people when they need assistance in technical matters and sometimes I take part in meeting our new or potential clients.

It's not all rainbows and unicorns


Even though I see a lot of positive aspects with consulting there are some not so great features with consulting that every consultant will face at some point.

Clients don't always know what they want but they want it done yesterday. The client might want one thing on one day and the opposite thing the next day. In worst case the client blames consultants of doing wrong things.

You don't fit in the team. On the outside everything might look fine but working as a consultant means that you are working with other people and some times people just don't get along with each other.

The job isn't what it was supposed to be. A new gig might be sold to you with buzzwords like new technologies, agile teams, up to date CI/CD pipelines but in reality you end up working with legacy systems or abandoned code bases without tests or maybe the agile team means that objectives yesterday were totally different from what they are today.


Why do I do it


To me all the positive outweighs the downsides of working as a consultant. When things get really bad I have the possibility to change projects/clients, it may take some time but it's always possible.

To me the best part of working as a consultant is the variation of clients and projects. I personally don't like working too long (read: years) on a single project even though some consultants do prefer them.

I get to work on various projects on different business domains and constantly learn new skills without the stress of changing jobs.

Popular posts from this blog

Sharing to help myself

It's been a while since my last post but I have a good excuse. I've been in a new customer project (well new for me) for two months now and have absorbed a lot of new information on the technology stack and the project itself. This time I'll be sharing a short post about sharing code and how it can help the one who's sharing the code. I'll be giving a real life example of how it happened to me. My story Back when I was implementing first version of my simple-todo REST-service I used Scala and Play framework for the service and specs2 for testing the implementation. Since then I've done a few other implementations of the service but I've continued to use specs2 as a testing framework. I wrote about my implementation and shared the post through various services and as a result someone forked my work and gave me some pointers on how I could improve my tests. That someone was Eric Torreborre  the man behind specs2 framework. I didn't take his ref

Simple code: Immutability

Immutability is a special thing that in my mind deserves a short explanation and praise. If you're familiar with functional programming you surely recognice the concept of immutability because it's a key ingredient of the paradigm. In the world of object oriented programming it's not as used and as easy to use approach but there are ways to incorporate immutability to parts of the code and I strongly suggest you to do so. Quick intro to immutablity The basic idea of immutability is unchangeable data.  Lets take a example. We have a need to modify a object's property but because the object is immutable we can't just change value but instead we make a copy of the object and while making the copy we provide the new value for the copy. In code it looks something like this. val pencil = Product(name = "Pencil", category = "Office supply") val blackMarker = pencil.copy(name = "Black marker") The same idea can be applied in functions and metho

Simple code: Naming things

There are two hard things in programming and naming is one them. If you don't believe me ask Martin Fowler https://www.martinfowler.com/bliki/TwoHardThings.html . In this post I'll be covering some general conventions for naming things to improve readability and understandabilty of the code. There are lots of things that need a name in programming. Starting from higher abstractions to lower we need to name a project, API or library, we probably need to name the source code repository, when we get to the code we need to name our modules or packages, we give names to classes, objects, interfaces and in those we name our functions or methods and within those we name our variables. Overall a lot of things to name. TLDR; Basic rule There's a single basic convention to follow to achiveve better, more descriptive naming of things. Give it a meaningful name i.e. don't use shorthands like gen or single letter variables like a, x, z instead tell what it represents, what it does