CLI Stack

Multiple people also asked about my CLI experience and what it is since it seems so powerful. My CLI stack is as follows:

• The terminal is Warp - I have written about it on my Newsletter
• The shell I use remains Fish which is easily the best switch if you coming to more shells from Windows, which is how I got to it, and after almost a decade… I still love it
• The prompt I use Starship. Warp has a lot of options but Starship can respond to your machine, and the folder to give even more power. Plus mine has the Pansexual Flag colours, which brings me so much joy.
• I make use of Fzy for CD autocompletion

This is the first in the second act of the trio of sections that this series has, and it focuses on what it is like to be a software developer. When I first wrote this, I did it for a university talk and thought the advice on what it is really like to be a software developer might help the students understand what they will find and get successful faster. Since I have been consulting and speaking to many people, I have realised that there are developers at every level who do not know these things and some, especially very talented and senior, feel they are there to sit alone and churn out “perfect code”… and they are wrong.

If I were to distil what software development is about to a word, it is tradeoffs. We are always making tradeoffs, and in terms of what those trade-offs are, it is just 3 things: Capacity, Time and Features. Very simply, if you want to change one - you need to change at least one more of them and sometimes two others.

I have always liked visualising this as a semi-rigid triangle with each being a side of the triangle.

Time

The time aspect is probably the easiest to think about; it is how long it will take. This can be viewed as the whole project, but also can be viewed down to individual tasks.

Capacity

This used to be called People and Resources but we should always remember that People are not resources; and when we think of this as People or Resources we miss the nuance of this.

When working with this triangle and talking about the costs of a project, capacity often aligns nicely with people, so if you want to lower the costs this is an obvious one, that means you would need to increase time (i.e. how long it will take) or decrease features. Capacity though is not just about costs; for example, if you have a single developer you might feel you can move capacity… but it can be changed.

Are you context-switching a lot? That has an impact on capacity. Are they doing a lot of maintenance work? again, impacts capacity. Even the modern view that scrum has failed, is in part a realisation that the cost of scrum is directly on the capacity side without a greater or even equal impact on the time side.

Even how psychologically safe your environment impacts this because a higher-stress environment lowers the capacity for your people to deliver.

Features

Finally is features, this is not only what the software does but how it does it. Do we build a feature in a way that meets the needs now or also ones that we foresee coming in a feature months? Those are effectively two different sizes of the same thing; i.e. features is not one-to-one to the stories or epics in your backlog.

Features also incorporate quality, observability, and non-functional requirements (FYI Donald Graham’s DevConf talk is a must-watch on non-functional requirements… so checkout the DevConf YouTube for when it comes out. A feature you create with shitty code versus great code has different sizes here.

Tradeoff

Now that we have the triangle and we understand the trade-off, it comes back to our initial rule that our job is not about coding. Yes, the triangle has aspects of coding but our goal is to ship a solution and to do that successfully, it is the identify what will impact the trade-offs, and find solutions to that. If you can do that, you will be way more of a successful developer and, importantly, the code you do write will be code that matters… not just a bunch of electrons sitting idle on a disk.

What can you control about this?

1. Avoid the “it’s not my job” view, the goal is shipping software which is used. That is a team sport and if you can help achieve that but doing something outside your comfort zone, it is worth doing.

2. Finally, while remembering the triangle - also remember Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

.

Last week I presented a session at Escape Conf on what is new and awesome in JavaScript development! It will be up on YouTube in the near future but for now, if you looking for the slides, notes or anything… you can grab it below!

The more I work with startups, the more I realise 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 into that. 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 to 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 realise we are gardeners or farmers. We prep the fields, plant, collect data on the growth, adjust the fertilisers 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?

1. 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.

2. 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.

3. 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 which 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, and 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 they led the work in their team to ensure it never happened again. Their work then rolled out to the rest of the organisation over the next few months. Ultimately the entire organisation improved from that.

This absolutely speaks to building a safe organisation for making mistakes, which leads to success. There is more coming on how to build safety in teams coming in the series, so I won’t cover those.

Rather what I want to share today is about how to build knowledge, and unfortunately, it is a work to build knowledge. 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 anything other situation? Obviously, the safety of the environment matters, but it is also taking time to step back, with diverse views and discuss it, and find the learnings.

What practical tools do we have to help with this?

• Do your sprint retros!
• Norm Kerth wonderful retrospective prime directive is something to be said every time you take time to review a sprint or every time you review an incident.
• When you have an incident, take time to do a blameless correction of error (or post-incident review or post-mortem). The best I’ve ever seen is the AWS model. That article is so detailed and covers an amazing tool which you can use not just in a CoE, but in many situations, and that is the 5 Whys

In short, failing in a safe environment where learning is an action and not just a statement on a company’s values can lead to powerful improvements and you can help that by building blameless cultures and ensuring that learning 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.

What worked?

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 which was at one point not happening cause of budget concerns, turned out to be amazing and that was badge hacking. It was wonderful to see people with ribbons or art or other stickers on the badges.

Thanks

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 honoured they chose to do all that work and spend all that energy in exchange for a jacket and some dinners.

How to count DevConf years?

1. It is the 9th calendar year, as it was started in 2015
2. We have run it 8 times in Gauteng which (since I am in Cape Town) includes Joburg
3. We have run it 7 times in Joburg proper, as in 2023 we ran it in Pretoria
4. We have run it 6 times in Cape Town.

This week on the Tech That Rocks newsletter, I share about Warp! It is an amazing terminal that is a major productivity boost for any one! 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 other’s 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 cause it is the title: constant verification.

As software developers, there is a lot we can do ourselves to get to a known state, for example: unit tests (know the state locally), having test environments (know the state when testing), making sure we have a CI pipeline that is repeatable (know the state is not influenced by builds), and making sure we have observability baked into our code (know the state in production).

Also like in tip 1, we can benefit from working with others, especially QA. It is no surprise that my most successful projects have always had a QA engineer in the team. Their entire job is to know the state and to share that!

Finally, when looking at your own approaches to work, what can you do yourself to practice constant verification?

First assume others have different info, and not that others are wrong. I cannot tell you how often this has saved me from looking like a jerk or missing out on a key piece of knowledge. Let others talk, ask questions to understand why they think something or are suggesting something and often you will uncover more info than you had before.

The second aspect you can do as a software developer is to realise your job is not coding. Your job is the entire lifecycle of software development, from figuring out what to build, how to build it, how to maintain it, how to fix it, how to EVERYTHING.

And finally, something which 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, so that is what this is. It won’t ever be a long post, and it won’t always be about software development (though today 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 is probably powering the backend of all your favourite things. Node.JS is awesome, but it is 15 years old and these last 15 years have seen amazing low-level and high-performance languages come along. It also has seen how we have changed our approach to large-scale JavaScript development.

Bun attempts to use that to make 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 so fast with new projects too thanks to templates.

I took a few projects and just dropped Bun in and they all just worked. I got major performance improvements FROM DAY 1. Bun has some additional APIs you can switch to, which will replace the Node.js ones and give you even more perf… but that is optional. It is not just runtime either, it is package management. I went from 30+ seconds for npm i to sub-2 seconds with bun i. It is really tech that rocks.

The short view summary for me is, that while Deno (another TTR) is what Node.js would be if it was built today, Bun is what Node.js would be if it was built 15 years ago with the tech of today. If you are building from scratch today consider Deno or Bun over Node.js… but if you have solutions today 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 for me is the category I feel encompasses the items that people like Jim McCarthy and Fred Brooks did not cover because they were not 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 were not 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 was not a white male until almost a decade later. Since then, I have worked on massively diverse teams and what has become clear is 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 which matters more.

I wish I could tell you an awesome story about how I learnt this, or give data that validates it, but I can’t… not because I do not know them, but because the amazing Claire Wood did just that in her talk Pink Hardhats and other Anomalies, which like with the Jim McCarthy talks, is one I watch yearly. It is amazing how powerful diverse teams truly are and she can tell the story, and give the data better than I could ever do.

While I was languishing in monocultures in the early 90s, a movement which would be called Scrum was starting to take shape with it becoming a professional standard in 2009. Scrum was not a revolutionary idea, in fact, it 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 come out of 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) but it was not until it was formalised in 2009 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 are 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, and ultimately fail. This does not mean locking that team in a room away from everyone else, they need a broad context and to know how they fit into the grand plan… but their goal should be as tight as possible. I have 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, and so you need to let them figure out what is the best way to organise themselves to do that… and that may mean trying different methodologies, or having different ways of working across different teams as their goals are different. All you can do, is to empower that team with the right support, and authority to do what is needed. What I have found helpful in this regard, and again I steal from Scrum, is just drop titles.

Titles are what consultants use to charge more for someone or to help one’s CV look more impressive than it is. Titles do not 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 me to the final factor in the team, that the team who builds the software also owns the software… this includes shipping and fixing it. This is not a new idea, in fact Amazon was talking about “You build it, you run it” in 2006. When I worked at AWS, I saw first-hand 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 so simple to do, 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 which may 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; something I have not discussed yet. Changing jobs is a natural part of your career and one you will do multiple times, and to help you have success in being in 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.