A tale of a migration
Tags: migration, experience, career
Published: 2019-08-08 03:20:58

---
title: A tale of a migration 
published: true
description: In which I share an experience I recently had with a rather challenging project.
tags: migration, experience, career
---

Hi there! I've been working really hard on a project for the last few months now. This is on my day job and it is a migration which has been tough but really enriching in many different aspects. 

I am also really close to be a 5 year employee with the company I work for (nearshore company) and at about 3 with the same client. 

Many thoughts have crossed my mind lately and I wanted to share them somehow, but I want to focus on the migration in this post.

# Disclaimer

I think this would be important to go first so I should probably get it out of the way:

The following adventures *did* come with a cost because of the urgency to release the product. And I do acknowledge this could have been handled differently from a management perspective, and that I *didn't* have to work on it so vigorously by spending so many afternoons, and late nights at it. But I attempted to work to my limit (note that I don't feel I went beyond it) and wanted to prove myself that I could deliver as close to the deadline as possible. I can't stress enough that the pressure came from within and it was not an external factor.

I however, have been discussing this on our retrospective / feedback meetings and one on ones. Something that I would also want to contribute my grain of sand in helping improve within the company.

Okay, okay, I hear you: maybe I was just fooling myself, who knows? I stopped doing a lot of other things I was working on and I'm slowly taking up again like learning Vue, creating screencasts, learning a new spoken language, working on a side project with my friends (who actually entrusted me with a similar leading role (mini spoiler) and I have just not been honest to myself enough to realise it).

Anyway, here we go:

# Once upon a time... (About 4 to 5 months ago)

First it was the fact that I had no real understanding of the business logic (and I still don't fully understand the whole deal, to be perfectly honest). 

Then the fact that it all started as a one man effort on the UI (yours truly), without any real guidance from the UI and UX designers until later on. This required to rewrite part of the stuff that "was already working" on my first attempt, but also implementing new components, new work flows to do things in a platform that "I was supposed to know already". I think this is where we could have managed the time differently. All in alll, I worked on a thing that didn't get used, but morphed into what it is today.

# The technology, the baseline

I need to mention that we are using AngularJS, yes. You read that right. We are migrating stuff to AngularJS in 2019. I want to be clear that I am not at all complaining: I've been working with this company for most of my Front End developer phase and I've learnt a good deal from the other developers; I also think I got more or less the hang of it (hence I was chosen as the one man for the show at the beginning of the migration, I guess).

Being able to work with a technology I am already familiar with was reassuring; the fact that I didn't have to learn from scratch all the things as I went, made the burden a tad lighter and I was confident since I already worked on other parts of the platform, so "I knew what I was doing".

The original idea was to migrate this part of the platform that has been ~~kind of~~ working during the last few years into a more "modern" stack we have migrating applications to for the last couple years (yes, yes, I hear you and I can see all the WAT memes popping up in your head). 

Adding more features on top of the existing one was simply not going to be done fast enough and the analysis made (I did not take part on said analysis, if you were wondering) indicated we were better off rewritting the whole thing before attempting to add new stuff on top.

# Uh oh, some :fire: ahead

Then the unavoidable, so infamous "we need to add more people to this project so we can get it done on time" (I bet this is not common, at all...) phase of the project came along (does it really matter when?), and so did my opportunity to think beyond _my own code_ and see with a broader perspective the codebase as a whole lot bigger chunk of code that would need to be taken care of by several people who would, in turn, be pushing new code in different branches, different features and ways to solve the problems that would arise. I needed to step up my game [earlier]: to think about the folder structure, the routing pieces we would need, how to split the work and try not to have people step on each other's toes.

This, was not my comfort zone. Not at all. I consider myself a good contributor but this time I started being in a sense, responsible for the repo. One thought that was both exciting and scaring at the same time.

Although it all kind of happened naturally, and the upside of working on a migration is that you already have a way to see how stuff behaves, what different screens contain and what they are used for. You have a live reference! So now a team of 5 people on the same codebase at the same time, and myself reviewing all those pull requests, helping to fix the conflicts and learning so much from the solutions other people came up with.

If I wanted to be fancy and boast on this, I would say: I was leading the thing! But in reality I also had someone really great at giving me confidence and who had my back. This _actual_ Technical Lead (_more seniorer_ if you would, experienced dev) encouraged me and left uplifting comments on the reviews from my code. I had not worked with him in a long time, and this was the first time in years that we were on the same team, but he wasn't able to code that much this time. He would pretty much leave stuff to my own judgement for the rest of the project. I can't really tell if this was intentional to be honest, or just that so much work on his side prevented him to actually work on this hands on, but it served me well at the end of the day, so... yay?

# Growing up! (alternatively, realising one has grown up)

I am very glad that this happened even for a small amount of time, it was somewhat an eye openning experience for me into realising that I can actually do stuff like that: not only coding and doing my best at implementing my features as best as possible, or fixing bugs and issues; but actually helping others contribute their code and giving my points of view and advise based on my experience for writting this stuff. I actually enjoyed reviewing all that code!

But the busiest phase of adding new features to the new codebase ended with an internal process cycle, and we were back at being 2 devs at it. Although we now had all those pending PRs, and some of those features weren't finshed because even though we were building a "feature parity" solution, we needed to account for stuff that would come up in the future, like I mentioned. 

Fortunately, this particular experience also involved working closely with the UX designers, QA Engineers, Product Owner, Back End colleagues to communicate the needs from one another and coming to conclusions as to what was needed and how to improve the application as we were building it. I am happy to report that this has been my experience almost all my time working here. This is to say that I acknowledge it has been truly a team effort and that I am very proud of the talented people I work with and really happy with my team.

# All right, I'll shut up

This is kinda getting long, so I will end with noting that even though we had to push the deadline and have had some hiccups along the way; being able to pour my heart and soul into this project, dedicating so much of my time to it and watching it go from 0 to the point it can actually be used to be beta tested has been a tremendously satisfying journey. One that I am really glad I could be part of, and I think it is fair to say: drive it if it was only for a couple aspects of the development of the UI.

# Bonus: Behind the scenes

If you read this far I'll let you know that my wife and kids have been soooo good to me during this time. I pretty much broke the work-life balance on this one (though mostly cut the time I already dedicated to my self-improvement), **but I am certainly not doing it again**. 

Morale of the story is: there is no morale. But hopefully you get something out of my experience, like 

* Do not be afraid to take on stuff, even if it feels beyond your current abilities.
* Accept the fact that other see you as a talented dev, in doing so you are not the opposite of being humble, just fair to yourself.
* Do not work beyond your schedule, *do not* stay up late or stop doing other important things. Messing with your time can be bad, but messing with your family's can do serious damage. Know and respect the limits.
* Migrations can be fun because you know what you can improve, and what already works that you shouldn't touch.

# The bootleg

I like making lists of stuff, and some ideas in no particular order that didn't make it into fully developed paragraphs are:

* Users will complain about you changing their labels. *Do not* change labels unless directed by the design team.
* Take breaks, take a couple of days off and put the phone down. This will help your brain reset.
* Drink lots of water. Do not lose your jug or you will regret it.
* Respect the time of others. You working late does not mean other people should too. It is your decision to stay up late / after hours or whatever, don't try to drag them with you. If you use Slack or a similar tool, just keep a reminder to ask the question first thing in the morning. (Is there a "deliver this in the morning" feature I don't know about?)
* Excercise a lot, take walks, short breaks from sitting. Neck and back can suffer a lot if you don't. (It still hurts!)
* Always always communicate your point of view! eg. "I don't think this will be done during the sprint", "This story was estimated short, we need to add more points", "That button would be better here".
* Also ask a lot of questions to clarify your concerns and have full context of what you will develop.
* Get a really good knowledgeable person who you can talk to: a QA dev, Product Owner, anyone who really knows the current product and can give you hints.
* Pair programming is a super powerful tool and a very wise use of time.