Learning In Public
As I wrote when I introduced Skriptble Press, I've started a publishing company and a digital publishing imprint with the goal of learning, thinking, and teaching in public. While that introduction was about the company itself, this article is about me and why I'm doing this.
I truly think on the page. I write millions of words per year and I find myself the happiest when I’m chasing down some knowledge and learning something new. When it comes to computing, I’ve found that there are few people who are dedicated to not just learning in public, but also willing to go through the struggle of learning enough to teach others. When it comes to learning, so much material out there doesn't meet readers where they are. This is important for a positive learning experience, however it's incredibly difficult to do through writing. Meeting people where they are is often done in person, through workshops and classrooms. Those are fantastic mediums for learning, but they are rather challenging to scale. If we can instead use the power of the written word combined with the interactivity of digital experiences, perhaps we can meet readers where they are with our writing.
Computing is deeply embedded into our lives. Essentially everything that we do involves a software system, sometimes dozens or hundreds of them. They can be direct, like when you you wake up in the morning to the light vibrations of your smartwatch, and indirect, like the CAD systems that were used in the design and manufacture of the door you open to leave your home each day.
While we’ve added more and more software to our lives, the things that run that software look nothing like they did even a couple decades ago. Twenty years ago you could point to a box, call it a computer, and you would be generally correct. But now if you point at the modern equivalent of that same box, you aren’t so right anymore. Sure, we call that thing a computer, but it’s actually made up of a whole bunch of smaller, extremely complex and general purpose, computers. So why do we call the box the computer? Why isn’t one of the smaller computers inside the box the computer? And if we’re saying that a computer is actually made up of a bunch of smaller computers then why is this particular box the computer?
We didn’t have this problem in the past because computers were rather large, but now they are absolutely tiny. This has had some pretty large implications on the world, and the world of software has pretended that relatively little has changed.
We need to fix this, but what I’ve realized is that the current structures don’t work for learning about this new world. The reality is that all computing is distributed systems and we need to fully embrace that fact. This isn’t something where we can just replace bits and pieces of the way that we learn or the way that we think about computing, we need to dig far deeper than the surface level. Our assumptions about computers, from what they are to how they work, are incorrect. Further, it requires a great deal more effort for someone to unlearn something and learn something new than it does for someone to learn the something for the first time, so the path toward understanding what computers are is going to be a rough one.
We need to provide people with the entire space of knowledge to explore. We need material to teach them as if they know nothing all the way through to teach them as if they are already an expert. We cannot pull them along a singular path and expect them to give up what they’ve already invested their time and energy into. They will fight back, and fight hard. Instead, we must allow people to wander, finding their own path to the destination of knowledge.
There’s a quip that Kevlin Henney makes in some of his talks about the idea of a roadmap and how we tend to represent them. Within most companies, when they talk about a roadmap they aren’t talking as much about a map as they are about a road that they are planning to take. A roadmap, conceptualized as an actual map, would have where we are now, where we’d like to be, and many different paths and routes that we could choose to take. When it comes to learning, we care that someone has acquired the knowledge, not the path they took to acquire it. We should provide several paths for people to take.
All of this is to say that I’d like to try something new. No, not something new, something different. I’ve always known that I would be an author, it’s something that’s just part of who I am. I doubted and questioned whether that would be the case when I found myself drifting away from the fantasy and fiction writing that I enjoyed so deeply, especially when I found myself enjoying the challenge and the joy of building software. Looking back, it’s quite clear that what I was struggling with was my dislike of having a single medium to express my writing in, that being the written typographic word.
Over the last decade, I’ve found myself wandering the path of distributed systems, frustrated along the way at how challenging they are to build, how sparse material to learn about distributed systems is, and how it felt like we, as an industry, were only exploring this one tiny corner of what is a much larger space. As I began to explore more of the distributed systems space I found myself struggling to unload the plethora of assumptions that I had accumulated over the years. I found myself becoming more and more exhausted trying to convince those around me that distributed systems were wonderful things to be embraced and would lead us to better software and better products. That we should not be afraid of distributed systems. That we should not attempt to avoid them. Most of the time, I failed to convince people, and I burned out, over and over again.
What I eventually understood is that I will not be successful within any one organization, attempting to convince one group of people that they should embrace distributed systems. I needed to take a different approach.
So six years ago I decided that I didn’t want to be a software engineer anymore. Instead, I wanted to be a writer. And it’s taken me those six years to understand what that actually means. There's still more to explore but I have most of it figured out.
One of the authors I enjoy reading is Simon Sinek. In his book The Infinite Game he talks about having a just cause. Unlike a mission statement or a goal, a just cause is a vision for the future, and importantly, one that that is impossible to attain but one that inspires us to chase after it anyway. It's important to have a just cause because an impossible to achieve goal helps orient you in the right direction, it helps remind you of where you want to go. Business is an infinite game, there’s no such thing at winning or losing at business. Sure, you can measure spans of time and say that for this finite period of time you won, or for this finite period of time you lost. But that’s not business itself, it’s a snapshot of business. The real game of business has been going on for thousands of years, and it’ll continue for thousands more. It is an infinite game, and the only options are to either continue playing or to stop playing. An impossible goal is a perfect fit when you’re playing an infinite game. This isn’t to say that this just cause must remain the same forever, but you do need to have one.
I have a just cause, a vision that's not just something I want to chase after but also something I believe will inspire others. That just cause is to:
Empower people to build better lives through invisible and seamless technology.
There are two parts to this just cause. The first part is broad, empowering people to build better lives. Much of the statement hinges on the word better, which I don't define because it's something people must define for themselves. What a better life is for one person is vastly different from what a better life is for someone else. It's about the autonomy of people deciding what a better life is for themselves and empowering them to go build that better life. The second part is a constraint. There are many ways to empower people in this way. For this just cause, it is through technology. But not just any technology, through technology that is both invisible and seamless.
Invisible not in the sense that it cannot be seen but that it is not noticed. A good example of invisible and seamless technology that you likely interact with every day is indoor plumbing. Specifically, the faucet and sink. Rarely does one actually see their faucet and sink, they are parts of the background of their lives. We interact with them often but we do not think about the fact that we are interacting with them. The faucet, sink, and the entire plumbing system is also seamless. The system that provides drinkable water out of the faucet is quite different from the system that carries the used water out of the sink. These two technologies fit together in such a way that they are seamless. Sometimes we see the seams, like when the drain in a sink is sized a little too small and can't carry the flow of water out of the faucet away quickly enough causing the sink fills up with water.
Invisible and seamless technology isn't necessarily small scale either. In the example of indoor plumbing, there are gigantic systems at play with many different actors involved to keep the entire thing running.
Too much of computing and software is both extremely visible and you can see far too many seams. When that random, unintelligible error pops up on your screen, you see the seams. But you also see the seams when a countdown clock app tells you a train is arriving at the platform and it's not there, or when your point of sale system doesn't integrate with your accounting system properly. Software has become the domain of restarting the entire thing when things go wrong and hacking things together to get desired results. It shouldn't be this way.
But where does all of this start? What is the first step I can take toward this goal? In proper yak shaving fashion, I believe it's to teach the world computing, and specifically to teach the world distributed systems computing. To do that, I want to learn the whole stack of computing, from the transistors up.
How do all of these pieces fit together? Well, I’ve known for my entire career that I would eventually build my own companies. I told myself initially that I wasn’t starting right away because I wanted to learn from companies that already existed, but in hindsight it’s more that I didn’t know why I wanted to build companies. I didn’t have a clear vision, I didn’t have a just cause. Now I do have a vision and a just cause. The next step is to find a path from where I am today, to the place where I can actually build that invisible and seamless technology. Getting there will require two things: funding and knowledge. It would be nice to acquire both of those things using the same method. This is where we come back around to learning in public.
I know a lot about computing and distributed systems, which is a great place to start. Much like how achieving a black belt in many forms of martial arts is a point of beginning, I understand that the knowledge I’ve accumulated has led me to the start of this journey. There is so much to learn. So instead of doing all that learning in private and on my own, occasionally publishing some articles to share what I’ve learned, and then figuring out some other way to raise capital to fund the companies that’ll chase after that just cause, I want try this path that allows me to do both at once.
So that’s what I’m doing. I’ve started a publishing company, and through that I will think in public by producing two publications. The first is a digital garden called The Shaded Garden. This is where I’ll publish more frequent and less polished content, meant to leave a trail for others to follow as they go on their own journeys of learning. The second is a digital publication called Shaded Nuance. This is where I'll be teaching in public. The content will focus on computing and distributed systems, but do so by meeting readers where they currently are before guiding them toward knowledge. Meeting the experts where they are is rather easy, they already understand the concepts and speak the jargon, but meeting novices where they are is much more challenging, and I intend to do both.
Thank you for your time and I hope you'll join me on this journey to think, learn, and teach in public. I'm still getting things setup. You can find me @skriptble on most of the common social media platforms. In the near future, I'll be setting up membership subscriptions, but if you want to start supporting now, you can do so via my GitHub Sponsors profile.