Month: November 2023

Type Casting in TypeScript

Ilya SherLeave a comment

( During code review, looking at TypeScript code. )

Colleague: … type casting …

Me: hold a sec, I don’t remember about anything called type casting in TypeScript

Colleague: you know, “as”

Me: yep, there is “as”, I just don’t think it was called type casting when I last re-read the official documentation a couple of months ago.

Colleague: hold a sec, here (shows me Google search results)

Search Results

My suspicion that something is off just grew when no result came from the official documentation.

TypeScript’s “as”

Clicked on few of this articles. They are talking about “as”. What does official TypeScript documentation tell us about “as”? It’s found under the heading Type Assertions. I didn’t see anything about type casting in the documentation.

Type Assertion vs Type Casting

Same thing, you are just showing off by being pedantic about naming!

Statistically probable response

What if I told you there is a practical difference between type assertion and type casting which confused my colleague?

Sometimes you will have information about the type of a value that TypeScript can’t know about… Like a type annotation, type assertions are removed by the compiler and won’t affect the runtime behavior of your code.

Official TypeScript documentation

You are letting TS know which type the value is. This information is used at compile time. Nothing happens at runtime. “cast” to the wrong object and no exception is thrown. That’s type assertion in TS.

In other languages casting has runtime implications.

Reality Check 1

Googled “type assertion vs casting typescript”. First result is What are the difference between these type assertion or casting methods in TypeScript (Stack Overflow). Oops. People are using “casting” all over, even on Stack Overflow… except that one comment at the end of the page:

(myStr as string) isn’t a cast, it’s a type assertion. So you are telling the compiler that even though it doesn’t know for sure that myStr is a string you know better and it should believe you. It doesn’t actually affect the object itself.

Duncan, Apr 13, 2018 at 14:26

… which is countered by

Coming from C# and since Typescript has many C# features, I’d say it is

user2347763, Apr 13, 2018 at 15:17

I’ll have to disagree on the grounds that cast expression in C# “At run time, … might throw an exception.”

Reality Check 2

… whether the underlying data representation is converted from one representation into another, or a given representation is merely reinterpreted as the representation of another data type …

https://en.wikipedia.org/wiki/Type_conversion

So, apparently, type assertion is a specific case of type casting.

Conclusion

I was wrong thinking that “type assertion” is not “type casting”. Apparently, it is. It’s just a specific case. The phrase “In other languages casting has runtime implications.” (that I wrote above) is apparently not correct in the general sense despite Java and C# popping up immediately.

What I’m still having hard time to understand is why those articles choose to use the generic wording. I think we should always strive for precise wording.

If you want to be part of search results, fine, I get it. What’s preventing you from “In TypeScript, type casting is implemented using type assertions (a special case of type casting) that only have compile time implications” (or something similar) though?

Takeaways

  • Always check official documentation (apparently it needs to be said for the 1000th time)
  • If you are posting an article, I recommend sticking to the wording in official documentation, especially when it’s more precise.

Can we make this article more precise? Let me know 🙂

Feedback Essentials

Ilya SherLeave a comment

This is a concise post, summarizing Manager Tools podcasts about feedback. Examples are mine, I couldn’t remember specific examples.

Manager Tools recommendations are based on data about what’s effective gathered from companies from different industries and of different sizes.

Purpose of Feedback

The only purpose of feedback is to encourage productive behavior and to discourage unproductive behavior in the future.

Why Give Feedback?

As a manager, you are measured by results and retention. Results are achievable through behaviors. Your job as a manager is to adjust the behaviors, mostly through feedback, in order to improve results.

Prerequisites

For a feedback to be effective, there must be established relationship. In a professional context, the way to establish and maintain a relationship between a manager and their directs are weekly one-on-one meetings (which deserve a separate post). Without established relationship, feedback will most likely be ineffective. After having one-on-ones for some time, you can start with positive feedback, then add negative.

Be calm when giving feedback. If you are angry, wait until you are calm to give feedback.

Frequency

Overwhelming majority of directs want more feedback. Therefore, the feedback must be short. If it’s not short, it won’t be frequent.

Length

One feedback instance should take 30-90 seconds. (Don’t remember the exact numbers but something close to this).

Timing

The more adjacent in time the feedback is to the discussed behavior, the more effective it is.

Positive to Negative Ratio

Positive feedback is when you encourage productive behavior. Negative feedback is when you discourage unproductive behavior.

Ideally, for 10 positive pieces of feedback there would be one negative piece.

What’s Worthy of Feedback?

Pretty much any behavior, positive or negative.

Note that the amorphous “culture” is just a set of accepted behaviors. Maintaining “culture” can only be done through continuous feedback (by managers on all levels) and can not be done by producing the famous “our culture” style documents alone.

Delivery

Deliver in private. In order of decreasing effectiveness, as for any other communication:

  • Face to face
  • Video conference
  • Voice call

Procedure and Content

Giving feedback consists of the following steps.

Ask

Ask if the recipient is ready: “Can I give you some feedback?”

Do not proceed with feedback if the answer is no. In general, don’t ask questions when the response is irrelevant.

Describe the Situation

Example: “yesterday during the meeting”.

Describe the Behavior

Example: “you were talking over other people “

Describe the Effect

Example: “it made the discussion less effective” (TODO: better phrasing)

Ask to do More or Less

Example: “please don’t talk over other people in future meetings”

This part is left out if the person you are talking to is not under your management. You can’t ask of more or less of a particular behavior in this case. You operate under assumption that the person was not aware of the effect of their behavior and providing the insight can help. If you omit this part, the conversation is not called feedback (according to this model) anymore.

Positive Example

– Can I give you some feedback?

– Sure

– You had deliverable X. You had delivered it on time and the quality met the expectations. This unblocked team Y on time and we are on schedule to finish the whole project, which is important for the client. Please continue delivering on time and to the expected quality.

– Good. Thanks!

Notes:

  • The feedback is about specific behaviors.
  • Schedule and quality of the deliverables are also behaviors.

Common Mistakes

Discussing Attitudes

Do not discuss attitudes, only behaviors. “You have a shitty attitude” is too amorphous and will cause “no, I don’t”. That’s an argument that you can’t possibly win. You should only give feedback about behaviors.

Root Cause Analysis

Don’t try to do root cause analysis with the direct. You are not well equipped to analyze what’s going on inside a head of another person.

More generally, don’t slip into digging into the past. The focus of feedback is future behavior.

Accumulating

Don’t wait for several instances of behavior to occur before giving feedback. Common mistake is to wait “to make sure we have a real issue here”.

Ignoring “Normal” Behavior

The excuse “this is the expected behavior of a person in this role” is invalid. Do give positive feedback for any behavior you want to continue in the future.

Asymmetric Delivery

Making positive and negative feedback items delivery asymmetrical is a mistake. They should be delivered in an identical manner except for the last section when you ask to do more or less of the behavior.

I intend to update this post for better phrasing and possibly more content (still keeping it concise).

Ideally, each point should have a link to the original podcast for deeper understanding. Hope I’ll get to do this some day.