In no particular order
Some thoughts loosely based on the theme of technical management in a startup environment. Don't take any of this as hard-and-fast advice - it's based on my personal experience and comes with the caveats that implies.
You ain't gonna need it
Developers like developing things. More specifically, they like developing new things. Left to their own devices, developers have a tendency to build many more things than is strictly necessary, in ways that are more...
Hire for talent, not cost
A few reflections on the various ways of building development team capacity, from hiring freelancers or an agency to hiring staff. Based on my experiences working in bootstrapped startups and as a freelancer - this is not necessarily good advice for a well-funded high-growth firm!
Tedious box ticking or vital back-covering?
Aside from internal documentation (which is very important) there are two main kinds of documentation that require attention from the tech lead in a startuppy environment.
The single best way to write code good
I'll start with a definition in case there's anyone reading this who isn't familiar with professional coding practices. A code review is a bit like a peer review in academia. One or more people check code that's been written by someone else, with the aim of ensuring the code is of good quality.
It takes less time than you think
Over the years, I have become more and more convinced of the business and technical sense of co-designing new products and features with input from customers (or potential customers). Often known as design sprints, Google Ventures has published detailed guidance on how they carry out the process. It's well worth reading.
Getting a great user experience from a good product
Documentation - so often an afterthought in the development process and so often seen as users accepting defeat. There's a lot of subjectivity in this space, not least because of the variation between products and users. Some can legitimately be expected to RTFM before using a product - others should be able to dive...
Wisdom from grugbrain.dev
It's quite rare that I read something on the internet and agree with every word of it. grugbrain.dev is an exception. The original is written in a "caveman" style which I quite like, but it makes the content a little harder to digest, so (with a little help from ChatGPT) I've translated and summarised it here. If you like this...
(You will anyway)
Fred Brooks, in his 1975 book "The Mythical Man Month" makes a lot of sensible points that are still true today (albeit some of writing is quite gendered and could do with an overhaul). On the subject of estimation, he suggests planning to throw the first version of software away ... on the grounds that you'll probably bin it anyway, so you might as well plan for...
By simplicity, I mostly mean readability
For those that aren't familiar, refactoring is like tidying up your code. It’s the process of restructuring existing code without changing its external behaviour. The goal is to make your code simpler, cleaner, and more readable. This can have a huge impact on the...
You can have too much of a good thing
Before any code goes into production, a set of automated tests should be written and those tests should all pass. Where appropriate (e.g. front-end changes) there should also be a manual check that things work as expected and look right on a range of screen sizes. Where code interacts with existing code or the data layer, the tests for those should also all pass. If...
An opportunity to impress, or cut your losses
In any business, things sometimes go wrong. You should of course try to prevent this, but in the real world sh*t happens. It's often a stressful time for the technical team and for anyone in a customer facing role. It helps to remember that most people (at least in a B2B setting) have been on...