Readit NewsThis may be an unpopular opinion, but here we go. It depends on how you define "startup". There are two common definitions, and people confuse them all the time and don't make clear what they are talking about. 1. A VC-backed company whose primary goal is exponential growth with a small chance of an outsized return. 2. A profitable business.
If your goal is to do the first, then luck will play a large role. That's why VCs have portfolios of companies. It's nearly impossible to make predictions about which startups succeed, but if one of their companies does, they win (note that they don't care if it's your company or not). As a result, VCs push their companies and founders towards making risky bets. Those bets involve a large amount of uncertainty and randomness. You either win big, or you lose.
If your goal is to build a profitable business not focused on exponential growth or VC-sized returns, then luck plays a smaller role. That's because you are not forced to make those large risky bets. You can take more calculated risks with slower growth while focusing on profitability. If you win, you are not going to win as big as in the first case, but your chance of winning in some way is higher. Of course, there is always uncertainty in life.
Note that I've focused on financial returns, which may not be what you (should) care about. For example, your chance to fail is high in the first case, but you since you are involved with more "successful" people you will likely learn and build a network along the way that can set up you for future success. You are more likely to "succeed" in the second case, but you may not build much of a network or stretch yourself. Similar arguments in the other direction can be made for mental health or stress levels.
I recommend reading "Fooled By Randomess" [1] on the topic of chance
[1] https://www.amazon.com/Fooled-Randomness-Hidden-Chance-Marke...
great points
> If your goal is to build a profitable business not focused on exponential growth or VC-sized returns, then luck plays a smaller role.
a bit of background. I started Android development at 12 and published a few apps on the app stores. Tasted the fun of building one's own business and earning money by myself. I have always dreamed of building the next big thing.
I think now I'm slowly realising that building the next big thing is really difficult. It might not even be something I'm aiming for any more now that have better insights on the workings of exponential growth. The stress and luck involved reminded me of this college situation I'm in.
> I recommend reading "Fooled By Randomess"
gonna give this a read. thanks!
Value to customer and technical complexity of the solution are independent variables. I can't tell you how many times customers at huge groups with an army of engineers have been delighted and excited with functionality that took an engineer two hours or an afternoon to implement. At some point, the engineers who tagged along were flabbergasted by the lesson: "Of all that we showed, they were impressed with this?"
>Possible practices/skills I've identified so far include: Clean/Idiomatic Code, Test Driven Development, Design Patterns, CI/CD, Agile, UX Design.
None of that matters if you're working on the wrong problem. You'll have beautiful code with 100% coverage that's full of creational/behavioral/structural poetry that go into a tight CI/CD pipeline through many agile sprints and great stylesheets. Only in a coffin. None of this matters if you don't get the "job to be done" right. Maybe as a Kata to beat imaginary or compliant adversaries and stay fit.
I wrote something a couple of days ago here: https://news.ycombinator.com/item?id=25367011
Perhaps I would rephrase my initial statement as: 'I often feel that my technical inexperience means I can't readily translate my planned solution for the customer's problem into a quality product through code.'
> None of that matters if you're working on the wrong problem.
100% agree with this.
To share a personal example, I was building a system to provide medical workers feedback on whether they wore personal protective equipment correctly. The hospital wanted us to use computer vision/machine learning to automate their checking process. But when we went on-site, we realised that our camera setup, which provided workers a 360 view of themselves so that they didn't need to awkwardly turn to check their behind as they had to do with regular mirrors, was far more valuable than whatever machine learning model we had built. The real problem was actually how could we make it easier for people to wear PPE so that fewer mistakes would be incurred and thus less checking required.
I haven't managed to read all your posts but this one stands out to me: https://news.ycombinator.com/item?id=20356222. The practices you mention are all areas I want to grow in. In that PPE project, as I tried to onboard other developers, things like a lack of documentation and spaghetti non-modular code made it difficult to keep up with the pace of growth we needed. So my hypothesis is that being in an environment (BigCo or other Startup) where practices are being well-used to deliver a product will stretch my capabilities so that I can better execute on my own/in my own team.
In your list of suggestions, how would you prioritise what practices to learn? Or is it about identifying issues in whatever project I'm currently in, having the backlog of potential practices in mind, and then figuring out in real-time how to apply those practices to improve your product/processes