Conversant (Premium)

Comedian Bill Burr decided to learn how to play drums in his 40s, a curiously late time in life to take on such a demanding activity, and one that has absolutely nothing to do with how he earns a living. By all accounts, however, he’s killing it, and despite his joking on the topic, he’s become well-respected as a drummer. This kind of success isn’t guaranteed, but for anyone who’s not a bright-eyed youngster with their whole life in front of them, it’s an encouraging reminder that we can learn new things later in life too.

I mention this now because I’ve spent the past several years—roughly the time since I co-founded Thurrott.com—reviving my programming skills, such as they are. I had come into this industry in the early 1990s with the goal of becoming a software developer. And when I became a writer, most of what I wrote about in the early days was developer-related. That quickly expanded into more general writing about Windows, Microsoft, and personal computing, but I remained active in software development until my sites were purchased in 2000 by Duke Publishing of Windows NT Magazine fame.

This background helped me in my conversations with Microsoft’s engineers, where it was quickly established that I had a deeper technical understanding of their work than most of the reporters and bloggers that they spoke with. And it helped me better frame the creation of technologies like .NET, web services, and Azure even though I was no longer writing and maintaining code by that time. Sometimes life takes you down certain paths.

That said, I never lost my interest in this topic, and I spent the intervening 15 years or so monitoring everything that was going on in the Microsoft developer space, especially, and also outside of Microsoft to a lesser degree. I never fully walked away from it.

But programming is like golf: you can’t just dabble in it from time to time, you have to actually do the thing and do so regularly. The trick was figuring out a way to integrate this activity into my schedule non-disruptively. People often obsess over saving time, but when you care about something enough, you make the time. For me, a big catalyst was my work on the Programming Windows series, which I’m now turning into a book called Windows Everywhere. That series provided a nice, nostalgic reminder of the software development work I had participated in with technologies like Microsoft BASIC, Visual Basic, Visual C++ and MFC, COM/DCOM/COM+, and more. And it was thrilling to work in the developer environments of that day again and, in some cases, bring my old code back to life.

But it was also a kind of amuse bouche, if you will, a way of greasing the wheels for what I was looking forward to even more: this series would give me the opportunity to experience the .NET and WinRT era technologies that I had only viewed from afar, had followed but not actively worked with. And if you read along as I wrote that series, you know that it triggered a two-year break in writing. I started the series in June 2019, actively wrote it until January 2020, and then took a two-year break before picking it up again in January 2022 and concluding it in May 2022. (It’s not “done” in the sense that I will be adding more content this year and covering what happened since the initial release of Windows 10 as well. But I digress.)

What happened during those two years? I wrote code, starting with the first generation of .NET technologies that included the VB.NET and C# programming languages, the .NET Framework, and Windows Forms. I created multiple versions of the same Notepad-style app, which I eventually named .NETpad, each using different combinations of languages, .NET technologies (where appropriate), and frameworks. And then I eventually put most of that on GitHub so that others could take the code, and do as they will. I was exercising a muscle that had long lay dormant and mostly unused. I’m not sure how many people learned anything from these projects, or how many professional developers politely held their opinions of my attempts. But this was huge for me. It was like rediscovering a lost love.

The Programming Windows series and the .NETpad projects were important to me personally because they gave me purpose, a reason to boot up and use Visual Studio, research whatever language, environment, or framework I was working in, and make things that worked. And it is the finding of this purpose that is the most difficult. As I’ve branched out from the .NETpad projects in a more private way, and have explored other developer technologies like modern JavaScript with React, Flutter, .NET MAUI, Swift and Swift UI, Kotlin and Jetpack Compose, and whatever else, I’ve found myself trapped in the same place I was during that 15-year hiatus. I’m interested in this stuff, I spend hours reading and watching videos, I do what needs to be done to get set up to actually write code, … and then I don’t do much real work. Time moves forward.

So I started the Small Bytes series, which I will continue whatever else happens. This was mostly about bridging the gap between the experimentation noted above and my desire to write about things I care about. But it has also given me an excuse—a reason—to explore developer topics you care about, too. And that satisfies an even more pragmatic need to ensure that what I publish is of interest to an audience, and not just to myself. It has given me a sense of purpose. And the result, as the series expands, will hopefully be useful to others.

But what is that audience? I see it as a group of people who are not programmers or software engineers who, whether they know it or not, would have a better understanding of an industry they care about greatly if they knew how the sausage was made. Who want to understand the how and why of these developer topics at a basic level. Many of us are frustrated when an app or Windows behaves erratically, but if you understand how things work—or should work—you will be even more frustrated. OK, maybe isn’t the best idea. But I digress. Again. It’s about being conversant in a topic. Though maybe that turns into expertise if it interests you enough.

Small Bytes scratches an itch, but it’s enough on its own. I still want to write code, to experiment with new languages, frameworks, and environments. The issue is finding a purpose there. Yes, I could continue writing new versions of the same .NETpad app over and over again, but that gets stale quickly. (That said, I’m sure there will be more.) And so I look for inspiration. Something that will occupy my brain and force me to the keyboard because I want to solve problems.

The issue is simply stated: it’s hard to find direction. But there are lots of resources out there that will help budding developers find that direction by assigning specific coding challenges and, ultimately, very specific app types to create, some of which are so well-worn and familiar that they’re almost canonical or archetypal. And I came across such a resource, which has inspired me to do more.

As part of my research meandering, I came across a video How to Learn Javascript in 2023 (From ZERO). Leaving aside the fact that JavaScript is actually spelled with a capital S for a moment, and that the host is whatever, there were a few interesting things in this video that I felt were worth sharing. First, that there are sites like Edabit with coding challenges that span languages and difficulty levels that can help develop your skills. And second, the host provided a (not terribly inventive) list of app types to work through as you gain skills. (In this case with JavaScript, though these things are language independent). I disagree with his ordering (from easy to hard), so I’ve reordered them here to Random quote generator, Rock, paper, scissors, and a Todo app in the easy category. And Calculator, Slideshow app, and Local weather app in the harder category.

A couple of points to that. First, that a Todo app is a classic first app for would-be developers, but the examples I’ve seen have always left out what I feel is the most crucial part, the backend service that saves the data for the user and lets them access it on any device. (This arguably elevates this project to the harder category, I know, but I’ve spent time trying to figure that bit out.) And two, it’s interesting to me that Calculator makes the harder category list when Stanford’s classic iOS Programming course, which started in Objective C years ago and now focuses on Swift, starts with a Calculator app. I always thought that course was difficult from the get-go though I’ve watched it many, many times over the years.

Anyway, if you’re interested in getting started in programming, these are solid starting points. But I’m sure there are other coding challenge resources. And maybe other app types that might be of interest to would-be developers who want something they can take on, no matter which skill level they’re at. If you do know of such things, please let us all know. What I found it a good starting point, but I’m looking to scratch that itch myself.

What form that takes is currently unclear. But I like the idea of future .NETpad-style projects, maybe smaller, maybe cross-platform, maybe recreated in different languages and frameworks. I don’t know exactly what I’d like to start here. But I want to write code. And I want to write about learning to write code. And I want this to be relevant to you.

Let’s see what happens.