Write, Audit, Publish.
Technical people need to learn creative consistency
Pushing “SEND” on a finished article feels incredibly gratifying. For technical content like I create, it represents the culmination of a lot of work. Some people make it look easy, and that perception keeps other people from doing it. We look at our output and the time we have and think there’s not much need because others are already pushing out content every day.
Creating technical content is not about becoming an influencer or a professional writer. It is about codifying your knowledge and learning to communicate your technical perspective to a broader audience. The written word is the foundation of knowledge and a skill at risk as we outsource it to AI. More than ever, writing is needed.
I remember in grade school, there was a day we called Career Day. It was where you dressed up as the thing you wanted to be when you grew up. You’d have kids showing up in football gear, ballerina outfits and astronaut suits. It got pretty elaborate, depending on what your dream of growing up looked like. I remember my Career Day in 2nd grade vividly (I was 9 at the time). I woke up, brushed my teeth, got dressed, grabbed my backpack, put a pencil in my left ear and walked out the door. When I got on the bus, all the kids took the liberty of using Career Day as a day to dress up in costumes. Sure, a lot of them were related to different careers you might choose. But I’m not going to give the kid dressed up as a pirate a pass. Come on man.
I walked to my friends and took my seat. One of them looked at me and asked what I was supposed to be. I pointed to the pencil in my ear and said “An Author.”
Growing up in rural America in the early 90s, I was that era of Millennial that knew about the internet but it wasn’t as ingrained in our lives like it is now. Email was not common yet and computers were considered a hobby, not a requirement. We spent a lot of time in school working on handwriting. I was taught how to write in cursive (WHAT???) and all my school work was handwritten. We kept journals and read physical books. Thinking about it now, it’s shocking how little screen time I got.
Yet, I was obsessed with technical things. I loved writing stories first and foremost. I liked to create worlds and communicate them. But I was obsessed with the details. I enjoyed reading authors whose writing style was verbose but poignant. I found that the best writers in this fashion tended to be sci-fi and fantasy authors. When you are creating a world no one has seen before or describing a technology completely outside the scope of most people’s reality, you need to be extremely detailed. You have to put the person reading it right in the scene of the book. They have to feel like they can visualize this theoretical, made up world you have envisioned. Great authors did this in other genres, but I was a young boy in the 90s and sci-fi or fantasy was my go-to.
By fourth grade I was reading Isaac Asimov’s “I, Robot”. This wasn’t a novel but a series of essays about Asimov’s predictions of where robotics was headed. I have half a mind to come back to it to read again and see just how close he was. There have been a number of writers, especially post WWII, who took the liberty of predicting different kinds of technology. George Orwell’s book, 1984, does a pretty incredible job at predicting Twitter (15 minutes of hate), Cell Phones (telescreens) and even AI slop (there is a machine that automatically generates music and literature for the masses known as the Versificator). J.R. Tolkien’s book “The Hobbit” along with “The Lord of the Rings” creates an allegory around the future of industrialization that I don’t think has been matched to this day.
Back to my Career Day choice. I held onto the idea of being an author for quite a while. For my 10th birthday I asked for a typewriter (go look that up if you have no idea what it is). I adored that typewriter. I loved the keyboard interface. It was so much faster than writing and there was the satisfaction of watching the mechanism move back to the other side of the page so I could start writing another line. I knew instantly that this was for me. I wrote every day, even if I had nothing to write about, for a year straight. That chapter of my life came to an abrupt end the day my father brought home a Commodore 64.
The computer is one of the greatest inventions in human history. I put it up there with fire, the wheel and the combustible engine. It satisfies multiple sensory needs like sight, touch and sound. It also magnifies our imagination in ways we are still discovering. I was the only child allowed to touch the new computer. My father primarily used it for video games, but I also learned it could run other software. I was fascinated by how it worked. The typewriter was fully mechanical. I could open it up and see how everything worked. I could fix parts that got stuck. With a computer, it was totally different. I couldn’t open it up and even if I did I would have no idea what was going on. From that day forth my early desire to be an author was stamped out. I was now obsessed with video games and software.
Reflecting on that backstory, I have a question that has been swirling in my head for the better part of the last year.
Why should we, as technical people, feel like creative output should be a goal?
I consider myself a technical person more than an artistic person because I do not engage with ideas at an abstract level. I like to build things and deconstruct them. I break down complicated ideas and build approachable worlds around them. In many ways I take from my favorite sci-fi writers. I try to impress upon another person why they should care about a deep technical subject that is completely outside their scope of reality. Most of the time I am the person I’m trying to impress. Creating something like a Youtube video or a Substack article about a subject or technology I’m not familiar with forces me to focus on what needs to happen to get something off the ground. It requires me to build something functional that communicates value to an audience.
Technical people excel at understanding and internalizing technical subjects like system design, data structures and algorithms, memory management, and Object Oriented Programming. We find ways to use these tools in our work and consider it a success. But achieving Senior positions requires less technical efficiency and more communication and decision making.
I’ve been surprised to see experts in a technology or subject struggle to explain their thinking to a broader audience. It’s not that they don’t understand the answer. They don’t know the best way to communicate it. When you have a deep technical subject like Deep Learning or memory pointers you have to be precise in what you choose to communicate. Otherwise you’ll lose everyone but the few who understand the subject as deeply as you do. Doing this properly requires practicing how to make decisions about what to say to have the greatest impact. Understanding the outcome of your words versus the tangible outcome of code is a completely different problem space. Communication like this is not a technical exercise. It is a creative one.
I recently spoke with a data startup CEO about a webinar they were hosting. They planned to use Agents to code in real time. Vibe coding in real time has a lot of landmines, and they asked if I had any suggestions or best practices. I had done a handful of YouTube videos where I used Claude to write code and learned a number of things. I told him my top 3 most important tips for pulling off live vibe coding.
Use a faster model like Haiku to reduce response downtime
Create context files (skills, rules etc) to help the Agent generate consistently
Write a script for the vibe coding workshop and practice, practice, practice
The last one was the most important. When you are demoing a product, you want to create a universe for that demo. Not just a project you understand or one that will have a “wow” factor. The demo should exist in a scripted world that has been defined. Different scenes should play out in a way that takes the guesswork out of what you expect will happen and what you expect the audience will take away from it. I cannot believe how boring so many demos end up. Not because they are not centered around an interesting topic. But because they are always thrown together by a technical person who writes a script and then just “wings it”. There is very little flow, multiple hiccups and a rather disappointed audience.
Writing regularly is at the heart of improving this part of your technical game. It helps you speak more clearly on a subject and it also helps you learn a subject. I was oblivious to how a Lakehouse worked this time last year. I had looked at the Apache Iceberg docs and simply could not wrap my head around what the value proposition was. On top of that, implementation overhead for Iceberg made it a nonstarter. I was trying to figure out how something that was so difficult to implement could have so much hype. Why should I even care about a Lakehouse?
Then came DuckLake. Like all things in the DuckDB ecosystem, there was an emphasis on having an approachable interface. Its announcement was rather sudden but I felt that maybe this was my chance to get to the heart of what a Lakehouse was. I decided to try out their quick start. I also decided to record the whole process of me trying it for the first time and put it on YouTube. This video did surprisingly well. It turns out people like watching you toil through a new tool in the same way they would. You are going through it for them so they can see what they should actually do. So this process both helped others understand DuckLake but also helped me to understand it. Being able to get the simple quick start off the ground pushed me to try to go deeper into the technology. But this time I wanted to write about it. One of the perks of writing over making a video is that you have the time and space to mess up and try things. Ultimately, writing is the creative output of trial and error. I was forced to organize the area of DuckLake I wanted to look at and I had to make it flow. My goal with my technical writing is to create something I feel like I could use and refer back to. And I’m happy to say it succeeded there. I regularly refer back to my DuckLake deep dive article for specific commands and detail as it is more concise than the DuckLake docs.
I loved the feeling of publishing that DuckLake article and it went over well with the technical audiences. But it still felt like a fluke. I told myself I had only one good article in me every month or two. I was sure I wasn’t good enough at writing to be able to keep up with all the other people out there cranking out great stuff. But I found that I was just making excuses for myself. I was avoiding the painful process of having to build this muscle up the right way. Through daily exercise and pushing through even when you really don’t want to do it. My DuckLake article was a lot like my exercise routine. I’d go have a great workout and feel awesome, then the next day feel a little sore and tell myself to “give it a day”. Then that day would be a week, then a month. And a month later I’d go have a great workout and start over again.
That’s not a way to build muscle or improve your health. It’s through the daily commitment in any way you can manage (literally just went and did 40 push ups after writing this). Writing out your thoughts is different from coding. With coding, you usually know where you are going. With writing, the universe is massive and you could go anywhere. It tends to leave you confused and frustrated to a point that you stop until “inspiration hits”.
But just like working out, you must find a way to write daily. The creative juices won’t feel like they are there most days, which is why you need to learn to kick yourself out of bed and hop onto that computer, tablet, phone or pen and paper. We tend to believe that if we are going to write something then it must be for someone else. But much of what we write won’t be meaningful. We just write. And then eventually something comes out of it. This is so much different from coding. Code gives us the means to an end. Writing is about building a skill for an unknown outcome. For something you will create a day, week or month from now. Something that may push you much further and faster ahead than working on data structures and algorithms.
Hi, my name is Hoyt. I’ve spent different lives in Marketing, Data Science and Data Product Management. Other than this Substack, I am the founder of Early Signal. I help data tech startups build authentic connections with technical audiences through bespoke DevRel content and intentional distribution. Are you an early stage start up or solopreneur wanting to get creative with your DevRel and distribution strategy? Let’s talk!