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.