Ask HN: How do I convince developers/companies to use TypeScript?
16 comments
Is there a way you can isolate the "reasons that are well known" into "reasons that can be made to work even in non-Typescript situations"?
Or can the "reasons that are well known" be laid out for closer scrutiny and discussion?
Is it possible that there are multiple paths up the "massively improved productivity" mountain?
Any of these angles could help move the problem even further off the mark of "my subjective perceptions vs. theirs" and into the objective "our perceptions" zone through additional openness.
If this can't be done I'd guess you'd run into a lot of problems that are more psychological in nature. Generally when you say "here's a great thing," (especially if others think they have great ideas also) you get a backlash effect at the very least.
Or can the "reasons that are well known" be laid out for closer scrutiny and discussion?
Is it possible that there are multiple paths up the "massively improved productivity" mountain?
Any of these angles could help move the problem even further off the mark of "my subjective perceptions vs. theirs" and into the objective "our perceptions" zone through additional openness.
If this can't be done I'd guess you'd run into a lot of problems that are more psychological in nature. Generally when you say "here's a great thing," (especially if others think they have great ideas also) you get a backlash effect at the very least.
It is definitely psychological, and I'd say what I'm looking for is pretty much what you asked: good resources that explain all the advantages clearly and debunk the common misconceptions (which usually revolve around the idea that typescript will make it super slow and tedious to write code)
It's very hard to bother people out of nowhere and spend time arguing with them about why they're wrong about TypeScript, and can seem confrontational. That's why it would be a lot easier if there were external resources or even sources of authority vouching for it and helping with people's insecurities around it I suppose.
So what I'm really looking for is finding out what worked for other people. For example if there's a great talk/article/video/whatever that helped convince people easily, or even to use as a base to keep in mind a list of useful facts to mention to people (it's easy to forget when using it what people were thinking before then)
It's very hard to bother people out of nowhere and spend time arguing with them about why they're wrong about TypeScript, and can seem confrontational. That's why it would be a lot easier if there were external resources or even sources of authority vouching for it and helping with people's insecurities around it I suppose.
So what I'm really looking for is finding out what worked for other people. For example if there's a great talk/article/video/whatever that helped convince people easily, or even to use as a base to keep in mind a list of useful facts to mention to people (it's easy to forget when using it what people were thinking before then)
I use Typescript daily and I really enjoy working with it. I've been working with Javascript for quite a while and Typescript made my life a lot easier.
I do however (possibly controversially) find the Javascript world in general rather tiring. There are constantly new (not necessarily more advanced) ways of doing things the most basic things. For me, it's like a ZOO with loads of wild animals, frameworks, Github issues and opinionated evangelists.
Don't get me wrong here - learning new tech is great. Especially if you want to stay sharp until the old age. Nevertheless, sometimes you just want to focus on getting stuff done and not trying out a brand new invention of rendering an input field (which will work and look exactly the same to users). While Typescript is much more than that, a similar sentiment might be making your fellow devs reluctant in trying it out.
Following from the above, I'd imagine that there is some kind of a person (top-down approach: head of engineering, CTO?) that makes decisions about code standards and tech. It might be worth talking it through with them, especially if you have concrete examples how Typescript could improve productivity. That's how we got Typescript into projects at the last place where I worked.
From the perspective of the devs themselves (bottom-up approach), a good motivator might showing the momentum that Typescript has in its adoption. There is a high chance that they'll have to learn it anyway if they plan to move companies at some point which makes it a good tradeoff to start earlier. Get paid for learning kinda argument.
I do however (possibly controversially) find the Javascript world in general rather tiring. There are constantly new (not necessarily more advanced) ways of doing things the most basic things. For me, it's like a ZOO with loads of wild animals, frameworks, Github issues and opinionated evangelists.
Don't get me wrong here - learning new tech is great. Especially if you want to stay sharp until the old age. Nevertheless, sometimes you just want to focus on getting stuff done and not trying out a brand new invention of rendering an input field (which will work and look exactly the same to users). While Typescript is much more than that, a similar sentiment might be making your fellow devs reluctant in trying it out.
Following from the above, I'd imagine that there is some kind of a person (top-down approach: head of engineering, CTO?) that makes decisions about code standards and tech. It might be worth talking it through with them, especially if you have concrete examples how Typescript could improve productivity. That's how we got Typescript into projects at the last place where I worked.
From the perspective of the devs themselves (bottom-up approach), a good motivator might showing the momentum that Typescript has in its adoption. There is a high chance that they'll have to learn it anyway if they plan to move companies at some point which makes it a good tradeoff to start earlier. Get paid for learning kinda argument.
You seem to have made up your mind about the advantages of TypeScript. The word "evangelism" has come up several times.
I'm a fairly junior dev, but I'd like to suggest caution to anyone who might be inclined to think that a technology like TypeScript will represent a clear step forward for anyone looking to take a step into 2022 and leave Javascript behind. The "evangelist". "Organizations/decision makers who haven't adopted TypeScript yet just haven't been exposed enough/had enough misconceptions debunked, and they need to get on the same page with faster moving companies, or get left behind".
1) I don't think this is how most successful companies/orgs think. 2) It seems to me that, as is the case with literally almost every choice of technology or solution, it's a matter of tradeoffs. Pros and cons. What are the honest disadvantages of your company adopting TypeScript? What are the opportunity costs, or how much quicker could you have addressed urgent sprints if you had left the JS alone? Be honest. Will there be a learning curve? I have to imagine there would at least be some friction... I don't think writing good TypeScript is as simple as doing a 1 hour tutorial plus some fiddling, or taking out a week. The other thing to weigh against that is, companies literally never have time. There is never enough time to do everything that you want to do, especially when it comes to stuff that's probably seen as more quality of life centric. Business oriented people want and are under pressure to put out features, tangible stuff.
The sooner you come to grips with that kind of stuff, will probably be the sooner you can do a solid job of framing and selling TypeScript. Be honest about the drawbacks, and then you can give them their due, while making sure that in your pitch, the payoffs are impossible to ignore. My final piece of advice might be to be a bit more gentle in your pitch. I've definitely run into some friction with what felt to me at that time like stubborn and short-sighted decision makers. Maybe the best thing you can do is to, again, frame the pros and cons, give them a fair and even-handed lay of the land, facts only, and then let it feel like it's them that's coming to the decision to use TypeScript. Almost like Jedi mind tricks.
I'm a fairly junior dev, but I'd like to suggest caution to anyone who might be inclined to think that a technology like TypeScript will represent a clear step forward for anyone looking to take a step into 2022 and leave Javascript behind. The "evangelist". "Organizations/decision makers who haven't adopted TypeScript yet just haven't been exposed enough/had enough misconceptions debunked, and they need to get on the same page with faster moving companies, or get left behind".
1) I don't think this is how most successful companies/orgs think. 2) It seems to me that, as is the case with literally almost every choice of technology or solution, it's a matter of tradeoffs. Pros and cons. What are the honest disadvantages of your company adopting TypeScript? What are the opportunity costs, or how much quicker could you have addressed urgent sprints if you had left the JS alone? Be honest. Will there be a learning curve? I have to imagine there would at least be some friction... I don't think writing good TypeScript is as simple as doing a 1 hour tutorial plus some fiddling, or taking out a week. The other thing to weigh against that is, companies literally never have time. There is never enough time to do everything that you want to do, especially when it comes to stuff that's probably seen as more quality of life centric. Business oriented people want and are under pressure to put out features, tangible stuff.
The sooner you come to grips with that kind of stuff, will probably be the sooner you can do a solid job of framing and selling TypeScript. Be honest about the drawbacks, and then you can give them their due, while making sure that in your pitch, the payoffs are impossible to ignore. My final piece of advice might be to be a bit more gentle in your pitch. I've definitely run into some friction with what felt to me at that time like stubborn and short-sighted decision makers. Maybe the best thing you can do is to, again, frame the pros and cons, give them a fair and even-handed lay of the land, facts only, and then let it feel like it's them that's coming to the decision to use TypeScript. Almost like Jedi mind tricks.
Here's my POV as someone who once was a big fan of TypeScript but had to learn how to live without it for a long time and is now having to jump back into TypeScript because of a project.
Extra fluff/annoying -> It only seems like it. On a sufficiently complex or wide codebase that is written in JavaScript there is going to be loads of ad-hoc types/return values. Having a compiler determine what is coming in/out helps a lot.
Dynamic type checking -> This makes it more important to make sure that any dynamic parts are contained and the results conform to something before coming back into the codebase.
As someone who feels comfortable writing plain JS coming back to TS feels hard. Things that just work in the plain JS docs for libs/frameworks don't when the auto generated types are used. An example: a lib I was using allowed almost any string but TS was only allowing strings found in the source code in thus destroying the dynamic nature shown in the docs. I could have fiddled with type signatures and overrides and the like to please TS but I ended up doing a thing that was way easier than that (at the same time having to document why). Situations like this are probably what comes to their minds.
The best way to push for TS would be show how problems/tickets could have been avoided if types had been used.
Extra fluff/annoying -> It only seems like it. On a sufficiently complex or wide codebase that is written in JavaScript there is going to be loads of ad-hoc types/return values. Having a compiler determine what is coming in/out helps a lot.
Dynamic type checking -> This makes it more important to make sure that any dynamic parts are contained and the results conform to something before coming back into the codebase.
As someone who feels comfortable writing plain JS coming back to TS feels hard. Things that just work in the plain JS docs for libs/frameworks don't when the auto generated types are used. An example: a lib I was using allowed almost any string but TS was only allowing strings found in the source code in thus destroying the dynamic nature shown in the docs. I could have fiddled with type signatures and overrides and the like to please TS but I ended up doing a thing that was way easier than that (at the same time having to document why). Situations like this are probably what comes to their minds.
The best way to push for TS would be show how problems/tickets could have been avoided if types had been used.
In general it sounds like you are doing what I would do (show them that it can be introduced gradually/non-disruptively, and what problems it solves).
However, you can't always do a whole lot to change a culturally embedded prejudice against certain practices/technology. The best I could really think of doing is just waiting until bugs are inevitably found, and documenting each case that could have been avoided by the compiler. If your company tracks work done, you could come to your technical leadership and say "we wasted 200 hours this quarter/year/whatever fixing TypeErrors that TS would have caught", and that _might_ move the needle. You can't change the opinion of a horde of developers by talking to them directly, but if a mandate comes to them from on high that's for their own good, that will probably at least get some of them to try it long enough to come around to the idea.
Even that idea is kind of politically risky though, so take it with a grain of salt.
However, you can't always do a whole lot to change a culturally embedded prejudice against certain practices/technology. The best I could really think of doing is just waiting until bugs are inevitably found, and documenting each case that could have been avoided by the compiler. If your company tracks work done, you could come to your technical leadership and say "we wasted 200 hours this quarter/year/whatever fixing TypeErrors that TS would have caught", and that _might_ move the needle. You can't change the opinion of a horde of developers by talking to them directly, but if a mandate comes to them from on high that's for their own good, that will probably at least get some of them to try it long enough to come around to the idea.
Even that idea is kind of politically risky though, so take it with a grain of salt.
What I did was to explain the advantages and disadvantages of Typescript, and document the production issues that could have been detected at the compilation time.
But the most effective for my team perhaps was enabling the checkJs option in Visual Studio Code (javascript.implicitProjectConfig.checkJs). It enables type checking on JavaScript files using The typescript compiler. Even though the files are not typescript and you don’t have a typescript project, it does find a lot of issues. The developers started to use this feature more using type annotations in JavaScript using JSDoc comments. At this point the migration to typescript was approved by everyone.
But the most effective for my team perhaps was enabling the checkJs option in Visual Studio Code (javascript.implicitProjectConfig.checkJs). It enables type checking on JavaScript files using The typescript compiler. Even though the files are not typescript and you don’t have a typescript project, it does find a lot of issues. The developers started to use this feature more using type annotations in JavaScript using JSDoc comments. At this point the migration to typescript was approved by everyone.
The best way that I've found to introduce new things in in new areas. Any new project, even if it works in an existing repo has the opportunity to make their own rules to a certain extent. If you can have your new ways for the new project parts that co-exists with the existing codebase, then we use and wait. Eventually people will want to use the new way in older parts too after experiencing the benefits.
I think the most common one is people using TypeScript with Vue or React. If there's another popular framework that has the use of TypeScript as the default, that would also have a good chance of adoption.
I think the most common one is people using TypeScript with Vue or React. If there's another popular framework that has the use of TypeScript as the default, that would also have a good chance of adoption.
A lot of what is said here is true, but it also depends on what your position is within the organisation - if you are senior (or a peer) and have the respect of your colleagues then you can look at running a training session, followed by writing a piece of an application/a sprint using TS so that they can familiarise themselves with the reasons why it is better.
Which is really the second part of this - you need to spell out why typescript will make their life easier/better. If you can't do that succinctly then it is unlikely that you will be able to convince them.
Which is really the second part of this - you need to spell out why typescript will make their life easier/better. If you can't do that succinctly then it is unlikely that you will be able to convince them.
JavaScript is Typescript except you need to do the compilation in your head!
You are always checking types anyway, so you should use TS and let the computer do that for you. There is literally zero extra work for using typescript beyond initial installation because it’s just offloading a mental requirement to the computer and the computer is much better and faster at it.
You are always checking types anyway, so you should use TS and let the computer do that for you. There is literally zero extra work for using typescript beyond initial installation because it’s just offloading a mental requirement to the computer and the computer is much better and faster at it.
Adopting technologies within an org is a social and economic problem, that's why we have salespeople to convince orgs to do it.
You don't need to convince individual developers or groups of them to adopt it, what you need to do is convince a decision maker that it's worth it for a project and to deliver on it, or become that decision maker.
You don't need to convince individual developers or groups of them to adopt it, what you need to do is convince a decision maker that it's worth it for a project and to deliver on it, or become that decision maker.
People in general tend to choose whatever is easier in front of them.
You could convert some simple work files and showcase the benefit on how it’ll be better than JS. Show them how the “extra fluff” will benefit them in a context witch everyone is familiar with.
You could convert some simple work files and showcase the benefit on how it’ll be better than JS. Show them how the “extra fluff” will benefit them in a context witch everyone is familiar with.
I've managed to do that a bit in a few orgs, by slowly introducing typescript in a code base (and showing that it can be introduced progressively without disrupting too much) to then show how those files have become easier to work with. I guess that's the guerilla style of tech evangelism
The problem is, it's not always possible (if managers refuse to let you do it in the first place) or practical (if you don't get given the time or if you're working with a complicated legacy setup and can't make those kind of changes).
The problem is people can only really see the benefit by working with it for a while, but to work with it there needs to be some initial work to introduce it.
The problem is, it's not always possible (if managers refuse to let you do it in the first place) or practical (if you don't get given the time or if you're working with a complicated legacy setup and can't make those kind of changes).
The problem is people can only really see the benefit by working with it for a while, but to work with it there needs to be some initial work to introduce it.
Make it not be from Microsoft.
I thought about and wrote down my own case for it - if I did it now I'd stress how so many leading orgs are moving to TypeScript as peer pressure. Don't want to be left behind do you?
It's a dev dependency, so maybe you can get the thumbs up to use it on a small piece of the code base as a pilot?
But in other companies and teams I've been at, most of the developers have some prejudice around TypeScript and think it's annoying extra fluff that takes time, or that it's worthless because it doesn't do any dynamic type checking. They often don't want to try using it
What are some good ways you've managed to evangelise TypeScript? Any good resources/talks or study cases that can help people get over it?