DEV Community

Cover image for TypeScript - Engineering Manager's perspective
Milosz Piechocki
Milosz Piechocki

Posted on • Originally published at codewithstyle.info

TypeScript - Engineering Manager's perspective

As a Software Engineer I used to put a lot of focus on making sure that my TypeScript code is typed correctly. Actually, I deemed it to be the key code quality metric. I trusted static typing a lot, believing that the effort invested in figuring out the types pays off many times over. Now that I'm an Engineering Manager, has my perspective changed? Do I still find static typing so important?

It's been a long time since I wrote on this blog. One of the reasons is my transition to an Engineering Manager role which happened about half a year ago. It's been an interesting time, which certainly changed a lot in how I approach software development. In this article, I'd like to focus on how my approach to TypeScript changed during that time.

Being an Engineering Manager at the company I work in encompasses multiple responsibilities such as planning, coordinating with Product Manager and User Experience folks, taking major technical decisions, helping a Team member grow, etc. It's a breadth-first role, as opposed to Software Engineer, which is a depth-first role. The natural consequence of this is that I have less time to focus on the technical aspects, such as static typing.

What's more, as an EM I have to constantly balance how much effort is spent on the product backlog versus technical debt. I realized that even in a company with a strong engineering culture, prioritizing the tech debt is tricky. There is always a lot of things to fix: increasing test coverage, fixing performance, refactoring the code after bad design choices. Improving static typing competes with a lot of other items and sometimes compromises have to be made. As a result, I'm now definitely more cautious when evaluating when it's worth spending a lot of time on improving typing in an area of code.

On the other hand, as an EM I get more visibility into how static typing affects the Team's performance. And I can confirm that the majority of my SWE-era hypothesis about static typing was correct. My Team works with different parts of the product and we have to deal with noticeably more bugs in the areas that are poorly typed. What's more, poorly typed code is far less readable and more error-prone. I get regular complaints from the Team when they have to deal with such code. Also, onboarding new Team members is far easier when the code is typed correctly.

One immensely helpful thing is building a Team culture that values static typing. Folks on my Team put a lot of focus on this when reviewing the code, always asking why someone typed some variable as any (and they better had a really good reason) and suggesting more precise types whenever possible. This allows the team to minimize the tech debt created around static typing so that there's less to clean up later.

Wrapping up, my perspective on static typing has certainly changed. I became more pragmatic about it, always evaluating the effort vs the benefit of complex type refactorings. However, fundamentally, I still believe in the importance of static typing and I would never encourage poor typing. Being an Engineering Manager allowed me to see the benefits of static typing at scale.

Top comments (3)

Collapse
 
swyx profile image
swyx

I have seen EMs shoot down typescript because they think it just makes engineers feel smart without noticeable extra increase in productivity. I wish that we had a way to measure it instead of debating hypotheticals.

Collapse
 
macsikora profile image
Pragmatic Maciej

The problem is that developers like cults, they are or fully in the TS train, and don't see any issue or additional effort, or they don't want TS and see totally no value in it. Both radical perspective are wrong. TS is tradeoff as everything else. I think everything depends from the people, in one team TS will work, in another it will have less impact. If you have typed mindset then TS is a savior, but for many people, because development starts to be less rapid, as they have additional code level to cover, TS is pain in the ass. As I personally would prefer TS, then I see no issue with people choosing differently.

Collapse
 
miloszpp profile image
Milosz Piechocki

I wish that we had a way to measure it instead of debating hypotheticals.

There are studies trying to measure it:
researchgate.net/publication/25963...

IMO it's good to have an open mind and give both approaches a try so that you can make comparisons based on your own experience.