Engineering at startups

• Software engineering at a startup is drastically different from engineering at a scaleup or a mature company. In two major ways- it needs to be iterative and highly productive.

An engineer at a startup

• Primary responsibility for an engineer at a small startup, your primary goal is to achieve PMF as-soon-as-possible if you’re in early stage; or help the team scale quickly if you’re in the expansion phase.
• You cannot afford to get engrossed in technical mumbo-jumbo but have to look at technology as just a mean to solve problems.
• This requires a lot of compromises from an idealistic engineering POV. You sometimes have to knowingly cut down on taking things to the high-standard that you think of.
• This doesn’t mean shoddy work, but just prioritising needs of your customers and team before your intellectual satisfaction.

Building at a startup

Below are some of my learnings to be highly productive over my few experiences of working with early-stage startups and helping friends out. This widely applies to startups barring the few that operate in very hardcore technical domains (like hardware or AI research).

• Be productive, not purist. Build pragmatic, simple solutions over idealistic, perfect ones. It’s easier to understand, operate and iterate over a simple system with fewer people.
• Choose boring technology over shiny, fancy stuff. Boring technologies have been out there for long and have been battle-tested. It’s easier to find solutions whenever you get stuck owing to usually huge communities and rich body of work.
• Premature scaling is the biggest startup killer. Scaling is fun but you don’t need it on day one, you’re just looking to survive. Non-scalable or sub-optimal solutions might seem immoral sometimes but maybe that’s what you need.
• Small tech footprint is kinda superpower that allows you to move faster, more reliably. Try to max out the tech that you’re using before introducing new things. Less moving parts you have to manage, easier it is to understand and work with a system.
• Consider reversibility when making technical decisions. Saying ‘Yes’ to something means living with it’s pros and cons; but saying ‘No’ just means ‘No’ for now, you can always come back to that question in future. Unsure decisions with low-effort irreversibility can be taken, but say ‘NO’ to everything else.
• Cut scope aggressively because you can only deliver so many things with high quality in a short time. Speed-quality-cost trifecta is like CAP theorem for managing things, you can’t get everything at once.
• Judicious use of debt is great. Take on some amount of technical debt, but very mindfully. But this cannot go forever else you’ll get bogged down just paying interests. Once you have some time, pay back the debts. Be a Lannister.
• Hire hackers over specialists in your early days. Engineering at a startup requires great amount of plumbing things together rather than solving for scalability or finding the perfect tech stack.
• Don’t write clever code. Clever code is usually complicated code; prefer simpler code. Explicitly stating something is cleaner than having implicit assumptions.
• Conventions and standards are not rules to be followed blindly. Adopt them where it suits your needs; discard where it doesn’t. Do whatever makes you more productive.

Inspirations

• Elon Musk deleting stuff
• Choosing boring tech reference
• Hackers and Painters