Burning Out

It has been almost a full year since I last posted. I know that I do have these periods where I don't really feel like writing but this time, this isn't intentional.

A lot has happened since the start of the year but most of those events were very much work related. And they're very specific to what I used to do that I don't think I'm allowed to write about them. Sure, I could have figured out how to put those events in a way that won't get me in trouble but as more events came, the less time I had even trying to think about them.

I decided to leave Willis Towers Watson (WTW) mid-August. At least, that's when I passed my resignation. I actually left mid-October, though, because of contractual obligations. And now, I find myself in a BPO called Eastvantage where I started in November— after just a two week break— working for a company called Solutions30.

To be honest, I should have gone on vacation for at least a month before starting at my new job. I don't think that two week break was enough to give my body and mind a reset. But my decision to quickly transition from the old job to the next in such a short time was driven by this ongoing pandemic. There simply isn't anywhere to go to let a whole month quietly pass. And “home” has become a very unquiet place.

I'm burned out.

I came into my new job with a lot of optimism because, for one thing, we have zero reliance on Microsoft products— which was a big consideration when I resigned from WTW. At this new place, we're issued laptops that have Ubuntu pre-installed and while we do have a choice of what IDE to use, PyCharm on Ubuntu really works like a charm in the OS— unlike my experience with it on that Windows 10 system with higher specs.

We work primarily in Python. Although there's no Django in our ecosystem at the moment, we do use OpenERP/Odoo, FastAPI, and Tornado— all of which are Python frameworks/products. In terms of the technology, I can say that I'm transitioning well. In my first month, I've written a new service on Tornado, which I eventually had to rewrite as a FastAPI service; written a fix to some bug about task cancellations given certain conditions; and in the process, figured out things related to Docker, Kubernetes, and Swagger. But I am having trouble finding my rhythm when it comes to our development cycle and internal processes.

And it's burning me out.

Unlike in WTW, we don't really have a buddy system for new hires, which I think is important. Writing code isn't really the challenge here but that's only one part of the job. Keeping track of jobs for yourself and for your team/squad is just as important. And that means moving tickets around Jira and updating Confluence entries, not to mention alerting the next person (whoever that is) that a new task is coming their way. I can't seem to get a handle of when these events are triggered; who the next person is; what the next event is.

I think, there is an assumption that those things ought to be intuitive especially for someone who's been around the software development sphere for some time. But it never is intuitive as experience would tell you that every company has its own process; and as you become accustomed to it, it can be difficult to get your mind into another process. And I guess that's especially true within companies who practice Agile as teams are free to create and tweak their own processes as they see fit.

To give a more concrete example: in two of the companies I worked in, we've always deleted our branches once they've been merged. In the first company, a small-ish one, branches are merged in UAT; and once the changes have been found to be good, UAT is merged into production. In the second company, a large-ish one, branches are merged into the unit/manual testing environment; if it passes there, changes are cherry-picked into the integration testing environment to see that they don't break anything; if it passes there, changes are again cherry-picked into UAT, then to production. Of course, the cherry-picks themselves need to be in a new branch for merging to the next environment and the new branch name will reflect the environment to which it's targetted.

So, in the second company, where there's a ticket called “TIK-123” development starts in a “TIK-123” branch. When it's ready for manual testing, a new branch called “TIK-123-testing” is created where changes from “TIK-123” are cherry-picked into it, and a merge request targetted at “testing” follows. And when the changes are finally production ready, a “TIK-123-production” branch is created and merged to “production”.

It goes without saying that in those two companies, production is always behind the lower environments and is always updated from the next lower environment (usually, UAT). No lower environment is ever updated from production.

It's different where I am now.

That's why it was a foreign concept to me when I was told that there's sort of a one branch per ticket policy; where if you start development on “TIK-123”, you have to use that same branch to see the changes through to staging, UAT, releases, and to production. No cherry-picking. No merging development to stating to UAT to production.

It's not my place to say whether it's a better branching/merging strategy or not. I'm just saying, because without the guidance of a buddy on this one process, things can get a bit tricky. And this is just one process. There are others.

I am always watching the quality of my work, which goes beyond just the programming. I want to integrate well with the people I work with, too. That means, I have to adhere to the current customs because that's what the people around me follow. But at the moment, I don't know what those customs are.

And I'm not getting enough sleep.