The Software Ark: Issue 7
Quote of the week
All life is an experiment. The more experiments you make the better.
- R W Emerson
Articles
Building quality software
What distinguishes a great engineer got me thinking of building quality software and growth in general and there are a couple of take-aways that I've had.
The first thing is the idea of a 10x developer. They exist, but they're a lot more rare than they seem to be. I've only seen maybe one so far. I've seen a developer push through a change 10x faster than someone else, but it's usually because of their familiarity with the system as opposed to some innate 10x skill differential. And by no means is that 10x skill differential a requirement to build a high-quality product. You don't need great engineers, you need good engineers given the space and time to produce high quality artifacts.
The second thing that struck me was on doing the hard things first - "tackling the monkey". It's a natural anthesesis to bikeshedding, and in every project I reflected on, I learnt the most when I worked on the things that didn't seem like they'd pan out. I personally prefer to call this the "spike and stabilize" approach: you do a proof-of-concept to ensure it's viable and then you go off and build the rest. The "spike" was where the learning was, not as much the stabilization.
The third was on treating coding like an art form - like you would painting or music. You just have to do it, and you have to care about it - that's it. You'll suck to start with, but you'll get better over time. As with all craft forms, you'll slowly build out a unique identity. You might be a brutalist who prefers following YAGNI with extensive documentation. Or you might be that person who enjoys going out of their way to write "idiomatic" code tailored to the language they're in, almost like poetry. Or maybe you spend your time on requirements, launch-plans, metrics, and code is just a means to an end. Ultimately all that matters is that you care about your craft and that you care about getting better at it.
The last is setting up your environment to support betterment. It's running personal experiments (like documentation-driven-design), and asking for feedback; it's constantly reading to expose yourself to different points of view; it's trying to optimize for peak performance by taking care of yourself.
In one word: Kaizen.
Structuring a team
Sometimes, even as an IC, you've got to think about how teams are structured. It could be because you have a sudden influx of new engineers and managing quality is hard. Or maybe the software distributed across two teams might not make sense and you want to move software from one team to another, or maybe introduce a new team in the middle. Or perhaps you want to support faster innovation: you have an A-team exploring a domain and a B-team coming around behind them productizing their experiments (happened frequently in AWS, but I'm not a fan of this). Nonetheless, you've got to know how to structure a team. Below is what I consider to be the 3 main factors.
First, there's team size. You don't want it to be too small which leads to no predictability in output and so no trust in delivery. Over time, the team will be pushed towards doing grunt work, which then leads to attrition. Too large, and not only is it hard to manage, but you also don't have a comprehensible domain. 20+ people writing software adds up to a lot of changes even in a week. Amazon indexed highly on 2 pizza teams which averaged to around 5-8 people, which seems to be around the sweetspot at other companies as well. Also important is who makes up that team: a bunch of back-end devs building a website-UI is going to be a bad time.
Second, the team needs to own a good chunk of work with clearly defined stakeholders, if not a mission. We often call this a bounded context, or a domain. This could be a part of a larger domain, but you still want clearly defined boundaries. This allows the team to fully "rule their fiefdom" - they need to provide a consistent interface to the world, but their internals are their own.
Third, you get the team to have skin in the game. Having a little bit of pressure acts as a forcing function to innovation. For example, if you need to grow 2x in one half, you can't do that if your pipeline's breaking every day so you have to fix that ASAP! Setting some goals for the team helps a bunch. Not too aggressive because if people feel their goal are unachievable they'll just clock out. But not too easy either.
Even if you've got this right, there's still a lot of little tactical things you need to do to help a team be successful. Foster a safe environment, weed out bad actors, etc. Despite doing this the team might just tread water, in which case you've got to go debugging.
Links
- Why is self-hosting a static site so hard
- Signal's going all in on "BigTech is bad"
- Beginners guide to DB indexing
- Getting useful feedback from a colleague
- A4 is the perfect paper size
- What is the role of management
- Cognitive loads in programming
- Nobody ever got fired for choosing React
Your moment of Zen
The worlds most beautiful bookshops - now I want to go work from there!
