Not true. Kent Back’s 3X is a much better take, test and good practices for what is high risk and hard to change, move fast for most of it on the rest to try to find that black swan as soon as possible.
Yes, I do feel this time is different and that I am a top-notch coder (I feel more comfortable sounding like a jerk when on hackernews), 1 year later into my startup, codebase is big, but I’m actually coding faster than ever, as foundation code is more and more complete.
One of the huge reasons for it beyond the right architecture is type safety. Someone that was well seasoned in strongly-typed FP but is now pragmatic can move incredibly fast with enormous safety by just adding the most cost-benefit type strictness, and being flexible on where it doesn’t pay off.
Oh man. You can write tests after the fact. I have done it sucessfully many times. I write something to see if its viable, if it is I find the repetitive parts and break them up to functions or components in which you can unit test. Later you can also write end to end tests for all the important flows.
TDD is just a way of doing things but it's not faster. It's testing for testings sake. Why should I write a test if I don't have a single paying customer yet? Unless its something massively important, like money or health data there is just little incentives.
There are thousands of successful technical startup founders and early employees that would disagree with the content of this article.
The truth is that, it's actually totally fine to accumulate some amount of technical debt and to ship some buggy code if you're still early. Speed matters. Of course this will change if you're later stage or if you're in an industry where you must be very careful (security, healthcare, gov, etc).
> Is your code somehow less important than that account’s spreadsheets?
Shout-it-from-the-mountain-top "yes!"
The code should just get you through a demo, or securing the next round of financing.
The accountant can't cut corners, because they and other people could go to jail.
But the idea that prototyping in software is not a valid practice is laughably wrong.
Where you do go wrong is if the people only know how to prototype and nothing else; they can't get rid of the prototypey bits and evolve it into solid production in which all traces of prototyping are gone. Multi-talented mega-begins which know numerous methodologies wouldn't be in this boat, right?
> as if any bug is acceptable
Windows still crashes in 2024, yet we can't get rid of it.
This article buries the lede with a bunch of horrendous strawmen. The actual thesis is that software craftsmanship should be applied in the same way at all stages of a company. This is a very dangerous line of thinking that has killed many a startup staffed by experienced who engineers who are working in large scale systems and teams. I've seen it many times, and TBH it's not just an engineering problem, it's that people who have only worked in large companies don't have a real sense of what is truly essential, and so a huge percentage of their practices are effectively cargo culted over without any real reflection.
In the case of engineering, you need to apply a lot of judgement based on the situation that the company is in—how much runway, how much traction, actual product goals, etc. You must keep things as simple as possible at all times to optimize for future optionality as you search for product-market fit. All code is a liability, and you must fight tooth and nail against any individual who is getting ahead of their skis in terms of losing focus on the next thing needed to prevent the company from dying. The absolute worst thing you can do is bring some journeyman engineer and don't give them enough scope and ownership to satisfy their brain capacity or you'll end up with ridiculously over-engineered systems that impose a huge velocity tax for what needs to be a very lean and agile phase. I say this disclaimer first because 99% of people in tech trying to do a startup will fail by trying to do too much too soon, and have no intuitive sense of how narrow the tightrope from 0 to 1 success really is.
Of course that doesn't mean you shouldn't focus on code and system quality. Absolutely you should have tests, but you should apply serious judgement onto the nature of the tests in light of your best predictions about the future. You should think about what code is foundational, and what decisions may be one way doors, but not obsess over leaf nodes and experiments that are just as likely to be abandoned or scrapped as they are to be built upon. Making these calls is tough—no one can predict the future—but long tenures in fast growing code bases helps. Seeing the impact of ones decisions 2, 5, 10 years down the line is eye opening, experience is useful here as long as one still thinks from first principles and doesn't just rely on rote practices because they are comfortable.
rchaves ·18 days ago
Yes, I do feel this time is different and that I am a top-notch coder (I feel more comfortable sounding like a jerk when on hackernews), 1 year later into my startup, codebase is big, but I’m actually coding faster than ever, as foundation code is more and more complete.
One of the huge reasons for it beyond the right architecture is type safety. Someone that was well seasoned in strongly-typed FP but is now pragmatic can move incredibly fast with enormous safety by just adding the most cost-benefit type strictness, and being flexible on where it doesn’t pay off.
Show replies
sagolikasoppor ·18 days ago
TDD is just a way of doing things but it's not faster. It's testing for testings sake. Why should I write a test if I don't have a single paying customer yet? Unless its something massively important, like money or health data there is just little incentives.
Show replies
joshdavham ·18 days ago
The truth is that, it's actually totally fine to accumulate some amount of technical debt and to ship some buggy code if you're still early. Speed matters. Of course this will change if you're later stage or if you're in an industry where you must be very careful (security, healthcare, gov, etc).
kazinator ·18 days ago
Shout-it-from-the-mountain-top "yes!"
The code should just get you through a demo, or securing the next round of financing.
The accountant can't cut corners, because they and other people could go to jail.
But the idea that prototyping in software is not a valid practice is laughably wrong.
Where you do go wrong is if the people only know how to prototype and nothing else; they can't get rid of the prototypey bits and evolve it into solid production in which all traces of prototyping are gone. Multi-talented mega-begins which know numerous methodologies wouldn't be in this boat, right?
> as if any bug is acceptable
Windows still crashes in 2024, yet we can't get rid of it.
dasil003 ·18 days ago
In the case of engineering, you need to apply a lot of judgement based on the situation that the company is in—how much runway, how much traction, actual product goals, etc. You must keep things as simple as possible at all times to optimize for future optionality as you search for product-market fit. All code is a liability, and you must fight tooth and nail against any individual who is getting ahead of their skis in terms of losing focus on the next thing needed to prevent the company from dying. The absolute worst thing you can do is bring some journeyman engineer and don't give them enough scope and ownership to satisfy their brain capacity or you'll end up with ridiculously over-engineered systems that impose a huge velocity tax for what needs to be a very lean and agile phase. I say this disclaimer first because 99% of people in tech trying to do a startup will fail by trying to do too much too soon, and have no intuitive sense of how narrow the tightrope from 0 to 1 success really is.
Of course that doesn't mean you shouldn't focus on code and system quality. Absolutely you should have tests, but you should apply serious judgement onto the nature of the tests in light of your best predictions about the future. You should think about what code is foundational, and what decisions may be one way doors, but not obsess over leaf nodes and experiments that are just as likely to be abandoned or scrapped as they are to be built upon. Making these calls is tough—no one can predict the future—but long tenures in fast growing code bases helps. Seeing the impact of ones decisions 2, 5, 10 years down the line is eye opening, experience is useful here as long as one still thinks from first principles and doesn't just rely on rote practices because they are comfortable.
Show replies