A common argument for joining a startup is to work on something meaningful — taking on risk, lower pay and longer hours to work on a fulfilling mission.
A similar reason is used to argue you shouldn’t join a startup. Most startups aren’t making the world a better place, and it’s just a job, stick with something less risky, better paid and more comfortable.
It’s true most startups aren’t changing the world. Often, the product is valuable but boring — a successful SaaS tool makes the lives of its customers easier, but it’s not world-changing. Sometimes the mission is downright bullshit — elevating the world’s consciousness anyone?
If the mission isn’t meaningful, are startups worth it?
Best practices are, despite the name, not universally good.
Many best practices in programming don’t meet the definition. They spread not based on merit or evidence but thanks to authority bias and social utility. As they spread, they lose nuance. As they lose nuance, they become easier to evangelise. Combined with lack of experience, they can lead to cult-like behaviour.
Think of an engineering team that got obsessed with a best practice, like test-driven development or writing user stories, to the point of detriment. Many developers have fallen into that trap, myself included.
In automated software testing, the default approach among developers is bottom up, and the aims are high coverage and working software.
This approach misunderstands the goal of testing and often fails to deliver on the goal of reliably shipping working software.
The idea of the bottom up approach is that you use tests to show that individual parts are correct, that they integrate, and that your system is correct as a result.
This approach leads to the typical test pyramid with many tests for small parts at the bottom (unit), fewer tests of larger parts in the middle (integration) and even fewer broad tests at the top (end-to-end). The tests at the bottom are small and quick and the tests at the top are broad and slow.
Being a tech lead in an empowered product team is not a purely technical role. In addition to your typical engineering duties, you are a part of the product manager/tech lead/product designer trifecta and you collaborate on product decisions.
In this post, I want to talk about how the tech lead role is different and what I consider essential to being successful in it. I’m drawing on my own experience of being a tech lead as well as the experiences of my product manager friends who helped me see it from the other side.
Collaborating on product as a tech lead means you need to work together with your product manager and designer to discover and solve problems for your customers.
You ensure, as partners, that the features you build are valuable (your customers will find them useful), feasible (you can build them), usable (your customers can use them) and viable (they work for your business). To do this successfully, you have to combine your unique expertise and collaborate closely in an environment of trust.