. Last week, I presented a session at Escape Conf on what’s new and awesome in JavaScript development! It will be up on YouTube soon, but for now, if you’re looking for the slides, notes, or anything else, you can grab them below!
The more I work with startups, the more I realize how important this rule is—it does define the difference between success and failure. Very simply, your software is alive, and it is your job as a software developer to keep it alive. This starts with your DevOps strategy and investing in it. Having a build provides a heartbeat for the project, and when a commit breaks the build… it is like a flat-lined heart. The code in your repo should always be ready to ship; that heartbeat is the sign that it is ok.
The benefit of this is that it is the first step toward continuous deployment, which is the ideal goal. Once you have software running, it is still your responsibility to keep it alive. Stats show that 80% of the software development cost is accrued while maintaining the software. This blows my mind: if something costs R100,000 to build, it will cost R400,000 to maintain! So everything you can do to lower maintenance costs has massive benefits in terms of cost savings.
As such, I truly believe we need to change the view that software developers are builders and architects and rather realize we are gardeners or farmers. We prep the fields, plant, collect data on the growth, adjust the fertilizers, and eventually harvest… but that is not the end. We need to prepare the fields for the next season. The model matches how we work so well, and more importantly, reminds us of our responsibility to living systems.
So what can you do in your own life and team to improve this?
Ship early, ship often, and get feedback: The shorter your cycles of getting content out to your customers and users, the faster you will understand what works and what does not. We often think of this in the realm of shipping versions or deployments, but I have found that even testing benefits from this. Leaving testing to the end of a project is a way to slow it down. Start UAT in your second week, and you’ll find you will ship faster.
Focusing on maintenance is likely the best way to lower costs on a project. Anything you can do—from using services from your cloud provider to get better logs, more observability, and tools to help you debug and admin the system—is going to help.
Finally, the more risky a thing is, the more often you should do it. We solve risk, not by red tape but by doing it more and solving the issues that come up.
In 2017, I was working at AWS, and AWS went down... and went down hard. It was a tough night to be an engineer, and when the dust settled hours later, it turned out that it was caused by a typo. The amount of money lost by AWS—and, more importantly, their customers—that day was huge. One person was to blame. What would you do if you were Andy Jassy (CEO of AWS at the time) with that employee? Fire them? Demote them? No... nothing like that! That engineer was first supported, and then led the work in their team to ensure it never happened again. Their work then rolled out to the rest of the organization over the next few months. Ultimately, the entire organization improved from that. This absolutely speaks to building a safe organization for making mistakes, which leads to success.
There is more coming on how to build safety in teams in this series, so I won’t cover those details now. Rather, what I want to share today is about how to build knowledge—and, unfortunately, it’s a lot of work. I worked with a tech lead who told me, “Failing is the best way to learn”... and he was entirely wrong. Failure is not learning; failing is failing. So how do we build knowledge from failure—or any other situation?
Obviously, the safety of the environment matters, but it’s also about taking time to step back, gathering diverse views, and discussing it to find the learnings.
What practical tools do we have to help with this?
In short, failing in a safe environment—where learning is an action, not just a statement on a company’s values—can lead to powerful improvements. You can help that by building blameless cultures and ensuring that learning actually happens!
The 9th/8th/7th/6th year of DevConf, depending on how you count it... and what an amazing year! There was a strong demand that it should be called DuckConf going forward 😂. I can't commit to that, but I think Ms. Duckworth will be back in some way for 2025.
Feedback via the ratings is still coming in, but looking at social media, many, many, many, many, many, many people had an amazing time.
For me, something that was, at one point, not happening because of budget concerns turned out to be amazing—and that was badge hacking. It was wonderful to see people with ribbons, art, or other stickers on their badges!
DevConf is the combined work of many people, first and foremost, my partner in all things DevConf, Candice Mesk. I could not do this without her; her hard work is so much of this event.
Working hand in hand with us are Michelle, Judith, Tanya, Celeste, and the rest of the team from Fizz Marketing. They have handled the logistical side and allowed Candice and me to do this while having full-time jobs for years. This event is a success thanks to them.
Joining us for the first time this year as DevConf staff was Marié, who handled all the social media. This is a massively exhausting job to do on the days, and I am grateful to Marie for all she did this year!
DevConf costs a fortune to run, and ticket prices are kept as low as possible thanks to the sponsors! This event would not be possible without them—or it would have R10k tickets and no one would come... so the same thing.
Last but not least are the speakers themselves: they give up months to prep and plan talks, and I am honored they chose to do all that work and spend all that energy in exchange for a jacket and some dinners.
This week on the Tech That Rocks newsletter, I share about Warp! It’s an amazing terminal that’s a major productivity boost for anyone. The edition will take you 2 minutes to read and save you hours in the future, so check it out now.
All software is adding features to a known state — Jim McCarthy.
If you are starting out from scratch, the known state is easy… it is nothing until you add that first line of code. But, for me at least, most software I work on is not brand new. I have spent more of my time looking after, fixing, and enhancing others’ code… so how do I know what the known state of that code is? How do I know what the state of my greenfields project is with 1 line of code? No surprises—because it’s the title: constant verification.
As software developers, there’s a lot we can do ourselves to reach a known state—for example:
And, like in tip 1, we benefit from working with others—especially QA. It’s no surprise that my most successful projects have always had a QA engineer on the team. Their entire job is to know the state and to share it!
Finally, when looking at your own approaches to work, what can you do to practice constant verification?
Assume others have different info, not that they’re wrong. I can’t tell you how often this has saved me from looking like a jerk—or missing a key piece of knowledge. Let others talk, ask questions to understand why they think something or are suggesting it. Often, you’ll uncover more than you had before.
Realize your job isn’t just coding. It’s the entire lifecycle of software development: figuring out what to build, how to build it, how to maintain it, how to fix it… everything.
And finally, something that came up last time too: practice you build it, you run it!
Photo at the top is by Daria Nepriakhina.
Today I launched a newsletter, called Tech That Rocks. It is meant to be a short weekly article to introduce you to something amazing I found in the tech space, so hopefully it makes your life easier too! I would love it if you subscribe to my newsletter.
To give you an idea of what it is like, here is the first edition—enjoy!
Welcome to Tech That Rocks,** a weekly newsletter by me, who is YABWGWAO (yet another bearded white guy with an opinion). The idea of this newsletter is simple: I keep finding amazing tech, and it should be shared with more people—that’s what this is. It won’t ever be a long post, and it won’t always be about software development (though today’s topic is)—but any amazing tech. And if you find tech that rocks, let me know! You could be the author of one of these in the future!
Today’s TTR is Bun—a drop-in replacement for Node.js—you know the thing that’s probably powering the backend of all your favorite things. Node.js is awesome, but it’s 15 years old, and these last 15 years have seen amazing low-level and high-performance languages emerge. It has also reflected how we’ve changed our approach to large-scale JavaScript development.
Bun attempts to leverage that to create a drop-in, high-performance replacement for Node.js, and it does that so well—thanks to being coded in Zig (worth a quick search if you haven’t heard of it). It also bakes in TypeScript support, so no more tsc pain! You can be up and running with new projects in no time, thanks to templates.
I took a few projects and just dropped in Bun—and they all just worked. I got major performance improvements from day one. Bun has additional APIs you can switch to, which replace the Node.js ones and give you even more performance—but that’s optional.
It’s not just the runtime, either; it’s package management. I went from 30+ seconds for npm i to sub-2 seconds with bun i. It is truly tech that rocks.
The short summary for me: While Deno (another TTR) is what Node.js would be if built today, Bun is what Node.js would be if built 15 years ago with today’s tech. If you’re building from scratch today, consider Deno or Bun over Node.js—but if you have solutions running on Node.js, add a Bun migration ticket to your next sprint!
Each of the 14 points in this series is grouped into 3 broad categories, the first one being Modern Development. This is the category I feel encompasses the items that people like Jim McCarthy and Fred Brooks did not cover because they weren’t important at the time. The software development world has changed since their work—hell, it changed since I started working. When I began as a developer, the very first paying gig I got was in 1998, where I was asked to build a record management system. All I knew at the time was Turbo Pascal, so I built an amazing CLI tool with its own "database" (binary record types) to capture the data. It took me weeks of work, but it was feature-complete and amazing... except in 1998, who wanted a DOS CLI tool? A smart friend at IBM then used this fancy Microsoft Access to build out all the forms and use a "real database" in a few days. That met the need even better than I could. In both cases, though, we shipped a file on disk (literally—we burnt a CD to copy the files since flash drives weren’t a thing) and handed it over. Deployment was copy-paste, and updates... what were those again?
Not only did the tech and the ways of shipping change, but so did who I worked with. I didn’t work with a developer who wasn’t a white male until almost a decade later. Since then, I’ve worked on massively diverse teams, and what’s become clear is that there is no perfect model for a developer. Gender, age, education, work experience, sexual orientation, financial situation—none of it has been shown to have any benefit to the success of a developer on a project. Rather, it is the team as a whole that matters more.
I wish I could tell you an awesome story about how I learned this, or give data that validates it, but I can’t—not because I don’t know them, but because the amazing Claire Wood did just that in her talk Pink Hardhats and Other Anomalies, which, like the Jim McCarthy talks, is one I watch yearly. It’s amazing how powerful diverse teams truly are, and she can tell the story—and give the data—better than I ever could.
While I was languishing in monocultures in the early ’90s, a movement that would be called Scrum was starting to take shape, becoming a professional standard in 2009. Scrum wasn’t a revolutionary idea—in fact, the revolutionary idea came about in 1986, when two professors in Japan wrote a paper based on case studies about a new way of working that improved product development speed and flexibility.
Just a small aside: the fact that Scrum and later Kanban, both emerging from ways of working in Japanese business (with automotive businesses as a key part of it), just blows my mind. Maybe the next big way of working is happening there now, just waiting for you to go and write it up!
But back to Scrum: following that paper, multiple people were doing very similar things at the same time. I mentioned Jim McCarthy in the previous post, but also Ken Schwaber, Jeff Sutherland, John Scumniotales, Babatunde Ogunnaike, and Jeff McKenna—all were doing similar things (a case of Multiple Discovery). It wasn’t until 2009, when it was formalized, that it took off... and now, 15 years later, a lot of what Scrum said is still correct.
For me, this is about complexity. Scrum probably doesn’t matter if you’re building a DOS CLI record management system with a team of YOU, but when you have 150 developers building an eCommerce platform... you can’t run that like one team. You have to break it down into small, focused teams (8 to 10 people seems right, but smaller is better). That focus is vital—the more you ask them to do, the more (I’ve found) likely they will slow down, and ultimately fail.
This doesn’t mean locking that team in a room away from everyone else—they need broad context and to know how they fit into the grand plan... but their goal should be as tight as possible. I’ve seen teams of 3 developers running 1 service outperform a team of 9 running 3 services—even when those services overlap.
Now that you have this small team with a solid focus, GET OUT OF THEIR WAY! You have to trust them to ship code, so you need to let them figure out the best way to organize themselves to do that... and that may mean trying different methodologies or having different ways of working across different teams, as their goals differ.
All you can do is empower that team with the right support and authority to do what’s needed. What I’ve found helpful in this regard—and again, I steal from Scrum—is to drop titles. Titles are what consultants use to charge more or to help one’s CV look more impressive than it is. They don’t help ship software and just cause hierarchies and the ability to hide behind the title rather than dealing with issues. Everyone is a team member, and the team succeeds or fails—not individuals.
This also brings me to the final factor in the team: the team who builds the software also owns the software—this includes shipping and fixing it. This isn’t a new idea; in fact, Amazon was talking about "You Build It, You Run It" in 2006. When I worked at AWS, I saw firsthand the power of this. The teams I led all deeply cared about code quality and operational aspects. There was a huge focus not just on shipping but on keeping things working and delighting customers. These practices are simple to implement and add major value—but they start with ownership.
When I gave this talk, I wanted to have a practical action for each point too—just one thing that might help someone in the audience. Obviously, this post has a lot of advice on what to do, but the practical action I gave in my talk was about interviewing—a topic I haven’t discussed yet. Changing jobs is a natural part of your career, and one you’ll do multiple times. To help you succeed in being part of diverse and empowered teams, during an interview, ask to meet the team for a coffee before joining. This way, you can see if they meet your bar for what a great team is.
A few years ago, I was asked to be the keynote speaker at a South African university conference and speak to their software engineering students. It was the first time I had been approached to keynote, so I spent some time with the organizers to understand their goals and what to expect from the audience.
The university had reached out because they knew me from years before, when I used to give entertaining yet deeply technical talks on Microsoft tech—things like Server AppFabric, WCF, T4 templates—and other technologies that have since moved from cool to the graveyard where old tech goes to live out its end-of-life.
The university had hoped that I would bring that same "wow" and technical depth to the event, but I had two issues with it. First, the tech I was using then was the least entertaining—Java—and so I felt the "wow" I could bring would be limited. Second, this was a keynote—there were plenty of wonderful speakers during the day doing tech and only tech. The lack of diversity in the content spoke to me, and I realized I had been given the opportunity to deliver a talk I had always wanted to give.
Early in my career, I had discovered Jim McCarthy’s 23½ Rules of Thumb talk, which he gave in the early '90s for Microsoft Consulting Services on what it takes to deliver software projects, based on his time leading the Visual C team. I watched it over and over again, gaining insights that no one I worked with had, and it sparked a lot of my thinking—even today, I rewatch it every year. I’d encourage everyone to watch that talk, not only for the guidance but also to see how shipping software has changed since the days of disks versus the cloud (something we can only appreciate in hindsight). The ideas he proposed later became Scrum, and his talk remains one of the most inspiring I’ve ever seen.
That’s what I wanted to do—so I proposed a talk titled 14 things you need to be a successful software developer. Why 14? I have no idea, but I knew I needed a number, and I felt like maybe 10 of Jim’s rules could be dropped or combined with modern thinking (though I wasn’t entirely sure). But close enough is often good enough.
This led to a few months of planning, refining ideas, and pitching them to trusted advisors before delivering it as a keynote—with major success! Then it was presented at the Developer User Group, Microsoft asked me to do it at the Azure event, and an attendee later invited me to give it to their employees. In fact, a year later, the university came back and asked for it all over again. It has been one of my most successful talks.
A few years have passed since that amazing run of presentations, and I’ve gathered new experiences that might influence my thinking. I also want to push myself to write more blog posts, so I’ve decided to turn this into a series—breaking it down into individual posts to see how they resonate with different audiences. Hopefully, this will excite or inspire you. If not, I hope it challenges you. If you’re eager to see it sooner, you can check out the slides from my last iteration here.
I finished a project with a wonderful group of people, and part of that involved working directly with WhatsApp—unofficially, though—and through that, I think I’ve gotten a good idea of how it works (I could tell from metrics when their daily deployments happened… if that’s enough confidence). The design is brilliant and stupid all at once… but importantly, it’s not something I would have designed; so I thought it might be nice to share how I think it works.
Before we start, to be clear: I have no proof of this (except for a few thousand hours of working on it), and I’ve never spoken to anyone from Meta… this could all be wrong.
Let’s say Alice is sending a message to Bob. The message goes from her device to the WhatsApp server, where the metadata on the message is checked, and ultimately, the message is stored on their server. The message itself is encrypted—so if you could access the database of messages, that would be useless as only Bob can decrypt it. But the metadata is not encrypted. This does include information like:
This (I assume) is stored encrypted at rest on WhatsApp’s side, but if you could use their tools, it would be available to you.
WhatsApp now uses the established connection with Bob’s device and pushes the message to the device. The message and any attachments are now on the device, which responds to WhatsApp and initiates sending the second tick to Alice. At this point, WhatsApp removes the message from their servers.
This is why you cannot restore your messages from WhatsApp unless you have a backup—they do not keep them. This is so brilliant because it lowers disk space usage on the WhatsApp side and reduces the risk of a breach or someone asking WhatsApp for messages—because they don’t have them.
If you’ve ever used WhatsApp Web, you know that when you connect, you see all your existing conversations and messages—live info! Yet, I just told you that WhatsApp doesn’t have this info on their servers… so where does it come from?
They come from the device!
This blew my mind, but when WhatsApp Web starts, it uses the WhatsApp servers to establish a proxy connection to the device. The device then exports the data, and WhatsApp Web imports it—that’s how you get the data. (I also think Signal works the same way, because if you run a transfer to a new device, it needs to connect to the original device to ingest the messages.)
What surprised me—and is the stupidest thing—is that the export format for Android and iOS is different! In other words, what you get (and how many messages) depends on your device and the version of WhatsApp you have on it. This means WhatsApp Web needs to support multiple import formats because there’s no standardization.
Once the import is done, the source device can be turned off, and everything will still be available—which tells us that WhatsApp Web is storing all your messages in your browser (likely encrypted at rest).
One of the most common questions I got when I talked about my work was: “Isn’t WhatsApp end-to-end encrypted?” And it is.
There’s transport-level encryption—like TLS in your browser—and the message is encrypted in a way that only the recipient can decrypt. But once the message is delivered, it’s in plain text for a bit while it’s shown to the reader. It’s also encrypted for storage in a way that only the recipient can decrypt.
This means end-to-end encryption prevents a man-in-the-middle attack but does not prevent a man-at-the-end attack. A man-at-the-end scenario happens when you either:
How does this work with multiple devices? WhatsApp stores the message on the server until it’s delivered to all devices. This is likely why there’s a limit on how many connected devices you can have at once (5 at the time of writing). If you add a sixth, one of the others will be disconnected.
Are groups any different? No, they’re not. Again, the message seems to remain on the WhatsApp server until each member of the group receives it.
Do messages ever die on the server? My gut says yes—there’s some wording in WhatsApp about logging in every 30 days, but I never tested this. It would make sense that they should expire.
