Before you learn TypeScript, transpile it.
What is more dangerous, a developer who introduces new methods, libraries, and processes, or a developer who always uses what they know? The first exposes the project to risk, bugs that are inevitable in an unrefined process, extended deadlines perhaps, learning curves that slow you down. The second is like planting your feet in shallow water when the tide is coming in. Sure, it’s calm now, but the time will come when the force of the water will push you over. Of course, if you do something well, and you know why you prefer it to other ways, keep on. If it’s not the best way, it will be exposed.
For developers in our economy, demand far outpaces supply. One consequence is that you are likely to enter the professional arena without a mentor. You will be responsible for producing code before you’re ready. And though it may start out ugly, you can usually produce something that meets the requirements. But if that’s the case, you’re usually having to run to keep up. Maybe it’s hard to find time to continue learning. To continue learning, you have to incorporate it into your development process. If you’re going to continue to grow, you’re going to have to accept the risk to the projects.
This is where a lot of people would mention testing. Testing is the best way to maintain a degree of stability while remodeling the internals. There’s a catch 22 with testing. You must test the app to ensure reliability, but to test an architecture that’s evolving inevitably creates waste. Old tests that are disabled and kept in the repo just in case, as if they’re ever going to be turned on again.
The only argument I could make to help remedy it, is that comprehensive, end-to-end testing should be a priority over unit testing. Despite all the categories, all tests are basically the same. Just like a function, you put in some input and you get output. It doesn’t matter what happens in the middle. I would say if you’re trying something new, or you think something might change, don’t test it. If you have the time, use that time to test around it. Increase the scope of the test to a level with which you’re familiar. That could very well be at the user interface, not inside the code. I suggest that front-end developers begin with end-to-end testing that occurs at the user interface, manipulating clicks and such. How far you continue testing into the code is a matter of available time and confidence in how you’re doing things. My favorite tools for doing E2E tests are Nightmare and Jest, but I’m always up for trying new ways.
All this time and no mention of TypeScript. TypeScript, I hope to confirm, has one of the simplest and truest taglines I’ve ever heard, “JavaScript that scales”. That’s how it was introduced to me, in different words, by a contractor at work. “A JavaScript code base is not scalable,” he said. I think he’s right. I’ve heard of TypeScript a lot, lately in Ryan Dahl’s video, “10 Things I Regret about Node.js”, but I’ve never used it.
It feels very heavy, learning TypeScript while there’s a deadline over my head, but I suspect I could add it to the build system of a project. Then, little by little, I can experiment with features of TypeScript here and there. Before long, I may have added TypeScript as a skill and JS projects will forever be more stable. So before learning TypeScript, I’ll transpile a project to it.
Writing your apps as TypeScript apps, even though the code you write is JavaScript, removes the biggest impediment to learning, which is the lack of opportunity to use what you’ve learned. I once went to see Victor Wooten play at a library in L.A., and when asked how he learned to play bass so well, he replied that he would learn a little bit, and then practice, practice, practice, always back and forth. Learn a little, then practice a lot. Trying to learn TypeScript while your apps aren’t transpiling “.ts” files is like learning without practicing.
There’s a little bit more that needs said on a related topic. Project managers, and managers in general, need to give junior developers space to breath. Give them specific, unchanging, well thought out requirements, and require progress updates only often enough to ensure that the project is moving forward. Within the time between the updates, junior developers are going to be doing rewrites, changing very large portions of the code base, and doing very large pull requests. This is okay, even necessary. Teams that want to micromanage junior developers should do so through a pair programming system, pairing them with a more experienced developer.
