Mastering TypeScript Errors

Despite working with TypeScript professionally since 2019, I’ve been approaching TypeScript errors with a great deal of trepidation and fear. There’s so much information being returned. Although it’s not as much as Java stack traces in volume, I’ve struggled to make sense of TypeScript error traces and know how to parse them. Whereas most of the time I could resolve most errors with varying amounts of brute force or logic, sometimes a TypeScript error trace can really leave me clueless.

So, this week presented me with a golden opportunity to face some fears and turn trepidation into budding confidence. I was working with the react-select package and some custom components in the codebase. I was making some modifications and I was confronted with the Great Wall of Error.

Something like these…

Instead of freaking out at the Great Wall, I decided to break it down and make sense of it. I need to spend more time on the TypeScript website because the documentation on understanding errors is really excellent.

This part really started to solve the primordial puzzle for me:

“Each error starts with a leading message, sometimes followed by more sub-messages. You can think of each sub-message as answering a “why?” question about the message above it.” (emphasis mine)

If we take the second screenshot as an example, the way to parse the error trace seems to be as follows:

  1. TypeScript will highlight the offending line with a red squiggly line.
  2. Top message in the error trace is the leading message. In this case, it’s Type ‘Record<string | number | symbol, string | string[] | Record<string | number | symbol, string>>’ is not assignable to type ‘RecursiveObject<string | number>’.
  3. Why? Because Index signatures are incompatible.
  4. Why? Because Type ‘string | string[] | Record<string | number | symbol, string>’ is not assignable to type ‘RecursiveProperty<string | number>’.

And so on.

I’m going to be taking these insights into my work next week and side projects.

So, thank you TypeScript website!

Examining What Is Important To Work On In Software Projects

I observed this week several vectors acting on my thinking. It’s important to focus on the product and the overall mission, as I said last week. That’s the main vector. But then, you look at the active sprint, and you look at what else is left. Low priority tasks left there as low-hanging fruit. Second vector comes in – I want to work on something that is valuable to the team and organization, something that advances the main vector.

So, I look at the backlog and look at the bigger tasks, not prioritized in the current sprint. There are still tickets there, needed to get the release over the finish line. Bigger tasks like API integrations or outstanding features. So, then you weigh up the first two vectors. Something valuable, preferably not low-hanging fruit, and something that advances the product. By my own internal logic, picking up something from the backlog makes sense then.

And this is where internal logic is not not sound, but defies a third important vector team norms and culture. What does the team do? What is accepted in the team? And there, internal logic – even if sound – can come up short with team norms. In some teams, it’s acceptable and encouraged, on some level, to pick up tasks from the backlog. But in others, it’s not if it wasn’t included in the initial sprint planning and not added later during sprint refinement.

There is no actionable method on offer here. Thinking through things, as you navigate a new role and organization, will help you identify the important vectors at play and your own internal logic.

First Week Thoughts

First full week at new role behind me. Really grateful to jump into modern, well-architected, and advanced codebases.

The technologies I’ll be delving into on my own time and getting comfortable with:

1) Formik

2) React-Query

3) Yup schema validation

4) Styled components

5) Advanced TypeScript generics

Two things that I have been doing and practicing, as I navigate the new role:

1) Keeping product-first thinking in selecting tasks to work on. What creates the most value? What does the team need done to get over the launch line? What helps the product the most? This requires a lot of communication and starting to build relationships.

2) Pushing myself out of the comfort zone by picking non-trivial tasks to complete. It may be nice to get a little thing done to get my feet wet, but I learn more about the products and team by working on something a little more complex. Examples include a bug fix or a new feature

New Role After a Difficult Job Search!

I started a new role today at Cabonline Group. Excited to be part of the team and look forward to working with everyone!

It was an extremely difficult job search process, in the one of the toughest job markets I’ve ever encountered in my career. A lot of pre-conceived ideas about my position in the market, my craft, and who I am as an engineer were either refined in fire or completely obliterated.

Key lessons after this most recent period:

  1. Interview prep now is more important than before in a market that is being driven by the market and employers.
    • Don’t eschew DS and algorithms – get good at them, get good at solving them, and get good at communicating the process as you solve them.
  2. System design is important for senior roles. It may not look like how you prep for them, but being ready for them is essential.
  3. Our feelings as engineers about coding tests are not important. The market and employers are not listening to us about them. They will continue to use them, so get used to them and get good at them. See the first point.
  4. ATS is here to stay. Understand how the software analyzes resumes and play the game.
  5. You don’t know how companies scrutinize applicants. The criteria differ from employer to employer. Accept it and be prepared. Some favor open source contributions, while others value code tests. Some look for a stellar behavioral interview. You never know. I learned this from talking to Amaechi on Codementor.
  6. The most effective and useful feedback will come from people you hire or you don’t know. Seek it out and listen to them intently. Feedback from Christoph really changed my thinking and transformed my job search. I’m really indebted to him. Without his insight, I wouldn’t have gotten this job!

We are tribal beings, and an impromptu tribe of people helped me in landing this new role. I want to thank them because I am indebted to all their help, insight, guidance, time, mirroring, and experience.

Adam Castle, Yury Vinter, Christoph Nakazawa, Justin Bartlett, Harry Clayton Cook, Brett Hardmann, Alexey Bykov, David Stephenson, Amaechi Johnkingsley

So, thank you!

My Strained Relationship with Software Development

I wrote the original version of this piece, last year on Medium. This is an expanded and less guarded take.

I didn’t want to study software engineering in college. I first wanted to study English literature and drama. That wasn’t an option at home. So, I looked at the other things I had dreamed about since childhood – architecture. I put together a portfolio and applied to Bartlett School of Architecture in London. They hid the rejection letter from me and told me no. So, I fought them and the first compromise was computer-aided product design. I just wanted some art in whatever I studied.

There was none of that. It was all math, physics, and science.

Continue reading My Strained Relationship with Software Development

Verified by ExactMetrics