Briefly state your (2-5) core priorities that represent your primary areas of focus and the targeted business impact. Also include your critical indicators of success for each
-
Lower the barrier of entry to adopting and understanding TypeScript. Will validate by re-requesting feedback from the community a second time like issues #31983 and hopefully it should be a new set of problems.
-
Provide resources for people wanting to improve the TypeScript community. Validated by seeing more meetups, conferences rely on infra we provide.
-
Make it easier to people wanting to build tooling around TypeScript. Some of this can be think this can be validated by making a community survey and comparing to internal feedback. I have some personal docs, and ideas in the website overview but would be good to get overall ideas.
-
Make contributing to TypeScript easier, and reduce the amount of work maintainers need to do. Validated probably by the number of open PRs, and the number of external contributors per release.
-
Provide transparency into the TypeScript team. I don't think this one can be easily validated, in part because the TypeScript team does a great job already, perhaps a community survey on whether people feel like they grok what's going on.
Consider your overall impact to the business through: Your key individual accomplishments, your results that built on the work, ideas or efforts of others, your contributions to the success of others and the resulting impact of each area
-
TypeScript documentation papercuts - ranging form OSSing the site, accessibility updates, to merging and maintaining hundreds of community PRs across the different sample repos. This eased work on the core team, improved our documentation and gave others a chance to share some ownership. The more ways we can help folks find their own answers, the more time the compiler team can work on features.
-
Website Roadmap - Providing a long-term look at how we can get TypeScript's documentation to be considered one of its greatest assets. Structured into smaller incremental chunks which provide value at each step. I've regularly solicited community feedback, talked with other Microsoft documentation teams, maintained ties with the in-house design team and UX/AX teams to understand best practices and expectations.
-
Playground v2 - Upheaval of the interactive learning and sharing aspects of the language, offered tooling to make reviews easier by offering a link so people can try their changes in isolation. As an external engineer using TS a lot, the playground felt like some of lowest hanging fruit for easily improving docs and making it easy to help each other - unlike other parts of the website roadmap this was a safe place to focus while getting consensus for the full roadmap. Validated in the number of playground links everywhere in twitter/reddit/discord, and the number of feature request issues we get on the website.
What could you have done differently for even greater business impact?
-
Learn the Compiler - it is definitely a long-term business impact goal because there are just a lot of TODO items where you can hit those goals with internal fixes. Prioritising it is tricky though, because it's not a greater impact when there are so many other things which can hit those goals also. However, I have bugs assigned and they provide a great map around the codebase.
-
Accept Ownership Early - about 3-4 months in I came to the conclusion that I should not look for approval to get things done, but instead provide a constant and steady stream of easy to understand updates as things progress, offer long-term visions to others and provide regular space for feedback. This took a while to figure out, in part because I came in with the expectations of a lot more large-company bureaucracy than was actual reality. I could have started more critical path work earlier.
-
Pair More Often - this is my regular feedback to myself, I am still in a frame of mind where I consider asking to pair more of a nuisance to others. I've been on the other side of this, and I know that I loved getting the requests because sometimes the best way to know you know something is to teach - and their fresh insight on existing problems can be super valuable for long-term perspectives.
-
Invest more In Automating For Others - There's some good low hanging fruit that folks like Ryan and Wes are doing that I could take over (Definitely Typed automation, PR automation, build maintenance) which I should have a lot of background for and understand the domain. I have a tendency to over-commit on things like this but it does free them up to work on the real hard things that their years of experience can pull off,
What are your key deliverables and the expected business impact for the upcoming period?
( I'm assuming 6 months as the periods )
On the web side: The deliverables are all of the comments in #31983 addressed and most of the Website roadmap being done.
- TypeScriptLang.org v2 shipped - the website with mostly the same handbook
- Infrastructure for TypeScript guides/tutorials/migration paths
- Infrastructure for communities to build off
- Community more invested in contributing to TypeScript docs
My stretch goals are to have an internationalization story for the TypeScript documentation, it pains me how much of the programming culture is dominated by English only - we can help the community fix that by providing solid infrastructure. Being able to understand Brazilian Portuguese means I can at least validate that language as a trail run.
I'd like to feel like a one of my deliverables will be being a reasonably competent engineer in the compiler. Confident enough to discuss problems when pinged on issues, and to be able to livestream my bug-fixes and feature work.
What will you do in the upcoming period to learn and grow? Consider the experiences or skills you would like to build for your growth and development
L&G is an interesting one, I do this every day in the team by trying to read most comments and issues on the TypeScript issue tracker and everything I touch relating to the compiler is a lot of learning and growth. The unique constraints on documentation and infrastructure provided by both Microsoft and the domain of a programming language are fascinating and constantly running in a background thread in my mind. I don't really see a ceiling there.
The prompt for this question talks to long term career goals; mine is to make JavaScript a more solid, dependendable and welcoming developer ecosystem. This is actually a personal goal, but it very conveniently aligns with TypeScript's because I believe working on and around TypeScript is one of the best angles for doing that. I've taken on many roles in my previous job, depending on the needs of the teams at the time but the TypeScript team is much more stable that my previous job. I am happy to work and improve JavaScript on a daily basis. I don't have future career plans other than doing that.
I have appreciated Orta's work enhancing the playground. In particular the ability to try out PRs as playgrounds has helped catch bugs and drive enthusiasm around the private fields PR.
Orta is good at embodying the design goals of TypeScript. His meme slide regarding dropping expression features in favour of TC39 standards was particularly on point. This helps build faith and confidence in the future of TypeScript.