Microservice onboarding…
It has been a crazy couple of months since I took my new role. I have had so much new stuff to learn I haven’t been making a lot of time for other technical pursuits in my spare time. But that being said I am on paternity leave right now, so I figured it was a good time to sit back and reflect on my first couple of months. Similar to Choose the first project that I was asked to work on was to write a new Micro Service. This got me to thinking maybe this is the way to on board a senior engineer.
What does it tell the company about he new employee
First it quickly shows you if the person you hired can actually do what they say. If they can’t stand up a new app for a small service but have sold themselves as senior level you probably want to find that information out as quickly as possible. I wish this wasn’t a reason for doing something, but unfortunately there are a lot of people in our industry who really play buzzword bingo on their resumes, but their actual technical skills don’t live up to what they sell them as.
It is also going to show the new company how adaptable is this person. How quickly can they learn the new build environment, and follow the new companies coding standards and processes.
It gives the company a really engaged engineer as they start out doing what is considered in the product development world the best kind of work which is new development from scratch.
Benefits for the employee
You start out on green field which gives you a bit of time to learn the new system architecture. It also keeps the excitement and engagement level high as everyone loves knocking out a new project. As opposed to traditionally when you are fixing bugs to learn a code base, it is a great way to get into the guts of the code, but it is often work that isn’t nearly as fun, so it is sort of a taking your medicine approach to get up to speed. It is effective, but not always enjoyable.
You learn the new build and deployment environment. Going into my role I was used to doing everything as a maven build and we were deploying to Amazon EC2 containers. In my new role it is gradle multi module builds and docker containers running under Amazon’s Elastic Container Service. We are also doing continuous deployment which has been new and exciting. Most companies I have worked with in the last 10 years have been doing continuous integration, but I hadn’t actually seen someone make it all the way to the continuous delivery route, and it is an amazing thing to see. We also have a different development flow as a result doing Trunk Based Development as opposed to at Choose where we did GitFlow for our development model.
Where wouldn’t this work
It goes without saying you need a couple of things to take this approach. If you are developing a monolith and not a micro service architecture you can’t take this approach and are probably stuck with the traditional onboarding models. Also you would need a certain level of seniority to really have this be successful. If you were bring a junior or mid level engineer on board and they probably will have never stood up a production app before and will be used to working on an app that someone else boot strapped. So to take this approach with an employee like that you would need to provide much more guidance and mentoring for the employee so that they don’t get overwhelmed and frustrated with the task.
All in all I hope that future roles I take start out this interesting as it is definitely a fun stage in my career to get to do all these fun and challenging projects from the beginning.