Oh boy, we're gonna go to work life experience side today! And I will do it without a single pun. I hope.
So, roughly a year ago I was in the middle of looking for a new job. I didn't go for super exciting in the sense that I kept working on a similar kind of project, a web based ecommerce site, built with React. Rather I chose to work in a place that I felt deserved to get some good attention.
So far I've never been a career guy. I haven't built a path for myself to follow, and the previous (and my first) dev organization was quite flat, so I hadn't thought about titles or progression in the "ladder". These things combined led to minor suprise as in the new job I got the title of Senior.
Getting into it
A good thing with the title is that it did force me to rethink about things a bit. For example, I hadn't thought about being a "role model" before. And I had lacked skills like the ability to really convince others of my good ideas as my very first team had a very good trust between team members ability to deliver, including mine, and I never had to do a lot of convincing to get my will through. Both of these lacking skills were due to flat organization.
My new organization instead is very, very large, and also structured. While in-house development is a relatively new concept in the organization there is decades worth of organization experience, and clearly a need for structure. It is easy to be nearly invisible in such an organization.
So once I started the team was about to do a major release replacing most important parts of the old site. Also the team was large at this time having about 10 developers. Thus I put my focus on things where I didn't need to touch the business/feature side of the stack, trying to get base code hygiene up by doing stuff like npm updates, which seemed to be badly outdated and partially keeping the team back.
This made me productive quite quickly as business knowledge is something that can be very slow to learn. I also made good first impressions by being able to describe the project's status and analyzing nature and skill level of some of the team members after just a few days.
During this time I focused on becoming better with reviewing pull requests, and also spent time on finding a balance to creation of PRs; code reviews was a fresh thing in my previous work so didn't get much of good experience. Initially I also had thought to maintain a notebook with log of stuff that have been talked about, but mostly I haven't kept it up. But at least I have some stuff written on paper instead of almost nothing.
The slow crawl to features
After the first three months my greatest achievement was to fix a suddenly broken user facing web service, succeeding in just a couple of hours with some help despite nobody knowing much anything about the service as all the people who made it had moved on.
Another improvement I did was to fix the site's main navigation, making it robust and snappy. The earlier implementation probably had worked somewhat OK when the site was lightweight, but had become quite slow, troublesome and buggyish over time. Fixing the nav is one of those things that don't seem like a big deal, but having it work great does effect people's experience a lot. The site's NPS went up a great deal after the change, but it is impossible to tell what really added up to it.
But all that stuff was more of a maintenance rather than tackling the business side. And as time passed on the team kept shrinking due to consultant rotation, which put more feature pressure on me. In the end I got a bit too much to chew in too short of a time. During early spring I had a couple of weeks of very low productivity. Why? Well, there was simply way too much scope to handle for a single person, and due to reduced team size it wasn't as easy to bring up that more hands were needed.
I also had some worries in my personal life which didn't really help. Sometimes it isn't only one pile hitting the fan at once!
Correction of course and hidden problems
We got the work rebalanced during spring. I could focus much more on the front-end side of things instead of trying to manage back-end side as well. At the same time issues in my personal life got resolved so I could focus on things better. And did I really need to!
Many of the tasks I worked on had been written by previous team members. This meant I couldn't really tell what was required, and the full scope of the task was a mystery. And for one thing my assupmtions on what needed to be done were revealed to be totally incorrect, which meant that there was a huge chunk of work behind seemingly small looking tasks. Suddenly I had to switch gears to be the ultimate feature coding maniac!
And that is what I did. I changed my balance so that I sacrificed more of my own free time wellness by hyper focusing to getting stuff done. This can be fun for a while, but it is really exhausting over a long period of time. In four weeks I completed a huge chunk of what was required to be done. It didn't end up perfect of course: there were things that weren't understood correctly, and some things that were lacking outside our team. So all the work I did didn't get released by the deadline so we released only a partial feature set.
During all of this I totally changed my level of communication, and became much more verbose in our team chat than I had been. Product owner wasn't happy that we couldn't deliver as expected, which was one reason for my increased verbosity. But I also noticed that there had been much more communication behind the scenes most of which no longer happened at all, because the team size had halved in just six months. To fix this I proposed to make almost all communication transparent by having it on the team channel. I'm yet to see the fruits, because this happened right before my vacation. And I'm still on my vacation!
Learnings
One of the things that held me back a bit over the past year was the size of the team. Many of the old members were on the verbose side which meant they dominated the talks. I mostly made remarks on code quality and issues, and threw some suggestions. I don't know if these were partially the reason why the team lost so many members. In the other hand, the project was "finished" in the sense that it had become the company's main site, and it is typical for people to move on when that kind of change happens.
I've now also had the change to reflect seniority of other people with the same title. Thanks to this experience, and others during the past year and events from earlier on in my career, I think I'm now ready to take a bigger responsibility over the future.
The biggest annoyance I'm currently facing is the fact how much code (TypeScript) I need to work on. I would love to work on the front-end issues, the browser side of things, but most of my time is now spent on a step deeper. And it almost feels like HTML and CSS don't exist in the universal JS. This is silly considering most of the site is static content pages, and the hard business logic parts shouldn't be in the front-end.
But when you work on universal JS that executes the same code on server and client, you easily make the mistake where you ship back-end belonging stuff to the browser. And it is also fashionable to re-implement browser features! Universal JS creates this mindset, and if the framework does not fight against this (at least Gatsby does not) you will end up with lots of issues that you shouldn't have in the first place.
I want to consider big changes to the project as an attempt to get rid of some nasty issues the current architecture has caused.
And I want to learn a skill I haven't had to perfect earlier on my life: convincing others of my seemingly wild and crazy ideas. And before that I will need to have a look at React 18, Remix, and Astro. Possibly each of them solve pain points that I have.
Top comments (0)