A year in review, ah yes, the time to look back at my accomplishments, my failures, what I learned, what I want to learn, where I want to improve, and maybe a bit of what is next.
While I have dabbled in Javascript & Node in the past and have been exposed to them both on fully backend teams, this past year has been my first experience of having an environment where Javascript was everywhere (some tiny exceptions in some areas that I do not have day-to-day involvement though). This proved to be interesting and challenging all at once. Interesting because it forced my mentality to be more accepting and less pedantic. Yes, it is very easy to say, “well, things just work like this in XYZ-language-or-framework!”, but that doesn’t really help much in ramping up with Javascript nor help with ramping up in a new work environment.
Oh yes, the pandemic has taught us how to thrive while working from home. But what I have learned more is to operate well asynchronously and make sure that I have optimized my time properly. In practice, what does that look like? Optimizing my time means that I have maximized the most productivity out of myself and (hopefully) others. So for example, I am in New York; if I am working with someone in Europe, I may take advantage of the overlapping hours that we have, so I can unblock myself or unblock them as best as possible and vice versa. I am constantly thinking about the best structure in my day to keep the flow of a project still moving forward. Regardless of timezone, I learned to avoid being always on. I find myself writing a lot of docs as usual, but also making sure that I have a demo as well if something is extra complex. I have found other folks making plenty of quick demos of work and I love that. It’s just a very easy thing to do to accompany any documentation so we can fully understand how something works. Thinking through a lot of this topic; it is actually not something new for me. In the past, I worked in a fairly distributed team, and I definitely did a lot of writing then; what I am doing better now, is really just adding a lot more detail (and recorded demos!) to my documentation!
I have worked in many monolithic applications before, but I feel like the ramp-up for getting a good grasp of the application has taken me significantly longer than I anticipated. I don’t think this was an issue related to Javascript/NodeJS. I thought about my past experiences; learning a Ruby (Rails) application without knowing Ruby went well. I think one of my main problems I am having with ramping up is that in a lot of areas of the codebase, things are very tightly coupled and the function size for things is often fairly large (some being hundreds of lines long). Luckily, we now have an initiative to have some basic guidelines which provide engineers direction on how to design backend code. It’s not perfect and not every feature will work well with it, but at least there is some structure for most things.
I will just state upfront that I understand that for security reasons, the principle of least privilege is a thing. I get it. I think for me, I really love to understand things as best I can from end to end. What that means to me is that I like to feel complete ownership of the areas that my team has responsibility for. In the past, working on an information retrieval team (search), my team owned a lot of the data warehousing infrastructure, the search indexing servers, etc. Working on a team that owns its own message queues, service, etc. has a lot of power, and not having much of this is something I am adjusting to a lot. I guess a part of me just really loves infrastructure, so I may need to find some hobbies to scratch my itch.
You know, this was something I knew ahead of time going in; a big Javascript shop that builds out a web development tool is going to have a very frontend heavy code base. There are definitely a lot of areas that I haven’t even looked into how they work because it’s just beyond my knowledge of frontend. I suppose you can think of that as a nice problem to have, considering the software we build. On the tail side of this issue, there are quite a bit of engineering design decisions that I feel weren’t given the amount of backend engineering love as they should.