Learning TypeScript Deeply – Weeks 3-50

I didn’t spend the 47 weeks since my last post deeply learning TypeScript. At least not all of them. So, here is what happened on the TypeScript front in the last year.

Execute Program

I finished the TypeScript course and while I found it a little basic, I loved when it made me review my recollection and understanding of what I have learned so far. Revisiting ideas from months ago was precious and I feel it helped me solidify my rarely-used TypeScript knowledge.

Another great thing about ExecuteProgram is that the author is adding more content over time and now I have few more lessons to go through 🙂

Gutenberg Pull Request

There’s nothing like applying your knowledge in practice, especially in public. After I had learned a little bit more about the language, I started a pull-request in Gutenberg to add types to an innocuous module – wordcount.

Few months and several revisions later, the pull request was merged. What did I learn from this experience:

  • The pull-request review experience confirmed how much learning in public can accelerate learning. Having to reply to feedback from real people gave me the motivation to dig deeper in the documentation to defend my claims.
  • The difference of adding types to an existing codebase versus designing code with types in minds became super obvious. I spent most of my time figuring out the balance between adding types that make some semantics sense and matching the current functionality. Another battle was deciding how much of the existing runtime checks to leave.
  • I learned a lot from the dedicated reviewers: Andrew Duthie and Jon Surrell. There were quite few links in their responses. It’s not easy to tear down somebody’s code and I am super lucky they did 🙂

Programming TypeScript

I love a good programming language book. It adds the extra breadth that one may not reach in the early days of using a new language. It’s hard to get a glimpse of all language features or to get a feeling about what are some idiomatic solutions of common problems through a tutorial or an online course.

Programming TypeScript was a solid into to the language. If you already have a good understanding of JavaScript and its ecosystem and would like to learn TypeScript more than superficial level without getting deep into the internals, Programming TypeScript is a great choice. It offered:

  • in-depth explanations of how the language works and how is it different from JS without being overwhelming to a novice TypeScripter;
  • the right amount of reference materials – enough that I reread a couple of chapters, but not too much to make book bulkier and outdated quickly
  • reasonable amount of examples, especially those of advanced type scenarios – without them this part would be quite abstract.

If it were me, I would lose most of the jokes, they were cliched at best. But you may like them, who knows…

Oh, and the book did not assume much prior experience with type systems, which also made it friendly to the typical JavaScript developer.

What’s Next?

I hope my next update will be in less than a year from now 🙂 Armed with the knowledge from Programming TypeScript and Execute Program, I will try to find (initially small) ways to contribute to the growingly typed codebases in Gutenberg (new WordPress editor and JS framework), Calypso (WordPress.com JavaScript and TypeScript UI), and maybe Redpop (Tumblr’s new TypeScript UI that’s not open-source yet). Knowing I will get quality constructive feedback from my colleagues is a big motivator even if I often get things wrong the first time 🙂

Learning TypeScript Deeply – Weeks 1 & 2

It’s been two weeks since the kick-off and it’s time for a quick report.

Execute Program

I spent most of my TypeScript time in Gary Bernhardt’s Execute Program interactive TypeScript course:

  • The UX of the course is really well-done.
  • The contents are addictive, because it’s tiny bits of information and I never felt blocked or thinking too much.
  • The “core loop” could be better designed – while I was never blocked, I was rarely actively challenged, too. I wish the tasks were more advanced and that, at least sometimes, required some additional research.
  • The course uses a learning method called space repetition – there must be a gap between learning something new and exercising or reviewing to make sure we have really committed to memory. Great idea, though given the basic material, it was probably as annoying as it was effective.

Still overall, I am still enjoying it and I am close to the end:

Programming TypeScript

In addition to the course I started reading Programming TypeScript. Since I spent most of my time on the course, I haven’t progressed much with the book. Another reason for slow progress has been a 2½-hour long yak shaving – once I reached the section on tsconfig.json (page 11/12 :)) I couldn’t help but “peek” at the documentation, then one thing lead to another, I thought jsonfig.json was a typo, so I almost submitted a PR to an internal project, then climbed up the stack to tsconfig.json and various ways people use TypeScript – either as purely a type checker (noEmit) or about the various options for configuring it for a legacy codebase. Of course, composites and more advanced config topics weren’t spared from my “research”.

Honestly, I missed falling in a super deep rabbit hole like this and it reminded me how useful “accidental learning” can be in the long term – how many dots can one connect without even realizing. Having a solid understanding of the config file already helped me when I casually tried to understand how the TypeScript infrastructure at work works.

What’s Next

Since the course will be over soon, the questions is what are next steps. I will most probably focus on finish the “Programming TypeScript” book (especially if I get it on the Kindle), but other ideas are welcome, too.

Stay safe and see you in a week or two (here, not in real life, that would be the opposite of staying safe).

Learning TypeScript Deeply – Kick-off

In the past several years work has taken me closer to the realm of people and their problems than to shifting bits. For a nerdy programmer like me, it has taken a sustained learning and rewiring to be reasonably effective in a role different from writing code. A more management role has also meant that my learning focus is different and while I have been following technical developments very closely (especially in the JavaScript world), have helped with a lot of technical decisions, have read a ton of code, and even have written a non-trivial amount, I haven’t learned a programming language deeply for several years. Maybe since Clojure & ClojureScript in 2013–2015.

Six years is startlingly long time given my previously dense learning history. I am not sad – change is the only constant and I have enjoyed the people challenges as much as the purely technical ones. Still, the lockdown in combination with the realization that the problem-solving and regular surprises involved in learning a programming language are something that brings be a lot of joy meant it’s time to choose the next language.

Why TypeScript?

I have dabbled with TypeScript before, even wrote a few thousand lines worth of a hiring stats visualization system that ended up abandoned. But this experience was closer to a deterrent of learning more about the language than helped. Here are my reasons for picking up TypeScript:

  • The dichotomy of having the same codebase and same patterns exist in either typed or untyped form are every alluring. I am super curious what will be the effect on gradual typing on my thinking about problems.
  • After years of using generic (even if powerful) tools for my languages of choice, the first-class TypeScript support in VSCode is exciting.
  • People. I don’t know much about the community (yet), but I have enjoyed previous work by Anders Hejlsberg, like Delphi and Turbo Pascal. He’s still number one contributor, which is impressive. Last, but not least, Stefan was excited about it 🙂

How?

My learning strategy is usually to often alternate between top-down approach (first principles first, high-level knowledge) and bottom-up (low-level knowledge, often trivial). This often means alternating between a book, paper, theory, principles on the subject and a lot of hacking, tinkering, trying things out, doing, digging into source code, learning how something works in detail.

Here are the resources I have on my short-list and I am starting with them tonight:

Follow further progress and learnings here 🙂

What are your favorite TypeScript resources? Should have I picked something else?

Lessons Learned in Software Development

Solid, timeless, and buzzword-free software development advice by Henrik Warne.

Henrik Warne's blog

Here is my list of heuristics and rules of thumb for software development that I have found useful over the years:

Programming bookshelf

Development

1. Start small, then extend. Whether creating a new system, or adding a feature to an existing system, I always start by making a very simple version with almost none of the required functionality. Then I extend the solution step by step, until it does what it is supposed to. I have never been able to plan everything out in detail from the beginning. Instead, I learn as I go along, and this newly discovered information gets used in the solution.

I like this quote from John Gall:  “A complex system that works is invariably found to have evolved from a simple system that worked.”

View original post 1,428 more words

Book: Creativity, Inc.

Problem-solving at its best. The problem at hand is how to build a sustainable creative culture:

What had drawn me to science, all those years ago, was the search for understanding. Human interaction is far more complex than relativity or string theory, of course, but that only made it more interesting and important; it constantly challenged my presumptions.

The book follows the path of Pixar, Inc. Along the way Ed Catmull (one of its founders) both reveals the core of what’s needed for few hundred people to work together to build a great product and shares a lot of tactics that either did or not work for Pixar itself.

If you work or play with groups of people of two or more, I would recommend you have a look at Creativity, Inc.

P.S. You might also want to check out Dave Martin’s 36 Things You Might Take Away From “Creativity, Inc.”

How To Read Self-Help Books

Here are my rules for successfully™ reading self-help books. Like a self-help book, those rules work for me, but they may not work for you.

  1. I am OK if 99% of the book isn’t at all helpful. Since self-help books are written to improve the most basic and important areas of our lives – health, love, family, work, time, happiness – even if I get one habit or one sentence out of the book, it might be a worthy addition to my life.
  2. I automatically disregards any even semi-unrealistic-sounding claims in the book. Just disregard, skip, forget. For example: YOU WILL LEARN (in less than 30 minutes each):How to lose those last 5-10 pounds. Or […] reveals a step-by-step pathway for living with fairness, integrity, service, and human dignity. Or Learn the six ways to make people like you, the twelve ways to win people…
  3. I ask a lot of questions to myself: Why does this technique work? For what kind of people does it work? Would it work for me? Why would it work for me? How hard would it be to try it?

Self-help books are harmful only if we believe in what they say, not if we use them as a motivation to think deeper about how we operate and why we do the things we do.

Ten Years Since My First Open-Source Contribution

Ten years ago Ryan Boren committed to the WordPress open-source project a two-line change I had suggested. I wasn’t ecstatic, but there was this warm feeling of being useful.

Screenshot of the commit message

In the next few years I regularly contributed to WordPress. Not too much, but often. What kept me around wasn’t programming itself or the hard technical challenges, but three other reasons: being useful,  the safe path to learning responsibility, and that everybody was so nice.

I contributed translations and code for the internationalization infrastructure (affectionately known as “i18n”).  Translators rarely know much about code and since a lot of the developers were from English-speaking countries they didn’t know much about encoding, unicode, or how to make texts easy to translate. I was in the lucky intersection of both and that exact place made me useful.

Our jobs often make us work hard to achieve great things together and it’s worth it. But they often fail to make us feel useful in the simplest ways. Not as a part of a big machine stomping ahead, or a part of a great team changing the world, but just as person helping another person with their problem. I helped translators with their formatting problems or developers, who had been struggling with encoding bugs for days. I wasn’t assigned to fix those problems, the fact that it was a human on the other side just felt good.

Then people started to notice. In about a year I became the maintainer of the internationalization corner of WordPress. Now I had responsibilities. But those were responsibilities with training wheels – vague and weak expectations, even vaguer schedule, all the freedom in the world, an easy way out (“I am busy at my day job” works wonders). My task was simple, but I started to understand what it’s like when people depend on you. At the time I was a junior developer at my job and there was always somebody looking over my shoulder and making sure I was making progress. It wasn’t like that with WordPress. If I wanted internationalization to be covered before a release, I had to take the initiative or it wouldn’t happen and many people would be left unhelped.

Motivation and responsibility aren’t usually part of the “contributing to open-source” conversation. And yet, that’s what I learned from my first years of working with WordPress. Most of my programming I learned elsewhere, but contributing to WordPress boosted my soft skills – I learned to write better, I learned to deal with (and ultimately help) random people on the internet, I learned to manage a project, without giving assignments, I learned to be motivated for the right reasons.

Less than three years after my first contribution, I joined Automattic. It is one of the biggest contributors to WordPress and the company behind WordPress.com. I have been working there ever since (more than seven years now), because the culture was built around the same open-source values. We strive to help people for all the right reasons.

I don’t know if you’ll be as lucky as me, but contributing to open-source projects seems worth the try.

What I am Reading Lately

Schedule regular check-ins with your direct reports, so that giving feedback — both negative and positive — becomes a normal part of the weekly routine.

Everything You Need to Know About Giving Negative Feedback by Sarah Green for HBR

Before you begin to write, do you have any pre-game rituals or practices?

Given I write several thousand words each day, there’s no room for “pre-gaming.”

The “game” IS the ritual.

Here’s How Maria Popova of Brain Pickings Writes, interview by Kelton Reid for Copyblogger

Most jobs are mediocre. Most people’s work is mediocre. Most products and experiences are mediocre. Most lives drift to mediocre. When you rise above the mediocrity, people will notice.

Thirty Things I’ve Learned by Nick Crocker

Lois wholly or partially created some of the most exceptional and memorable ads in history. For better or worse, behemoths of consumerism such as Tommy Hilfiger, Jiffy Lube, ESPN, MTV, and many others have ingrained themselves in American culture because of his indelible campaigns. The qualities that set Lois’s work apart from that of today’s advertising industry are a) his stuff was unapologetic and transparent about the fact that it was selling a product, and b) he used ideas to hawk products rather than the other way around.

Geoge Lois, interview by Rocco Castoro for Vice