3 ms·

The phrase "optimize for iteration" feels like something you do when you don't know what you're doing. They say experienced developers spend most of their time

The phrase "optimize for iteration" feels like something you do when you don't know what you're doing. They say experienced developers spend most of their time thinking, vs. writing code, and so with inexperience you don't have the tools to eliminate iterations in your head.

nostrademons 8y ago
In a startup, by definition you don't know what you're doing. Once you know what you're doing, it's not a startup, it's an established business. Once everybody knows what you're doing, it's called an industry. It's usually fruitless for a startup to chase after problems that everybody knows how to solve, because somebody has already solved them, probably better than a small team of junior developers can. Experienced developers spend most of their time thinking because experienced developers tend to work in fields where at least the problems are known, as well as some best practices for solutions. That's how they got to be experienced, after all. But this is also why experienced developers, when they choose to found startups, often end up with B2B startups that slot into an existing industry structure, not startups that end up defining the industry. (Source: experienced developer now founding a startup and wrestling with just how little all that experience matters when it's not even clear what problems will dominate the industry or if the industry will even come to exist.)
- saagarjha 8y ago
  The tools for making a mobile application is something that I consider to be "solved", except in some very specific cases. If you are a startup, you are likely innovating in something that is not making apps, so I do not agree that you "don't know what you're doing" in this area.
  - nostrademons 8y ago
    The article states that the product was initially solely web-based, and for a good reason: they expected the majority of their traffic to come from content-based SEO. That's the kind of product insight that can and should drive technology choices and might drive it away from "solved" mobile development practices. (Having used react-native-web for a project once, I also question whether it actually would've improved things: the HTML generated by react-native-web is terrible for SEO, and they might never have gotten to the point where they had users asking for a mobile app if they'd gone this route. Hindsight is 20/20 and often forgets about obstacles on the path.)
geofft 8y ago
"Experienced" and "effective" aren't necessarily correlated. I have worked with a handful of experienced developers who have been writing C and shell scripts since the '80s and have gotten really good at writing C and shell scripts like it's still the '80s. If you ask them to build something you can operate with an SRE team instead of with a sysadmin one (and not even in those words), they get very confused. So you give them problems where you can use their very specific experience very well. Both inexperienced and experienced developers can work effectively in problem domains where there is no clear path to a solution, and where even the problem itself is underspecified and changing. It takes some practice to figure out how to work effectively in such an environment, but at some point you run out of opportunities to have gained deep practice because the problem is too new.

nostrademons 8y ago

In a startup, by definition you don't know what you're doing. Once you know what you're doing, it's not a startup, it's an established business. Once everybody knows what you're doing, it's called an industry. It's usually fruitless for a startup to chase after problems that everybody knows how to solve, because somebody has already solved them, probably better than a small team of junior developers can. Experienced developers spend most of their time thinking because experienced developers tend to work in fields where at least the problems are known, as well as some best practices for solutions. That's how they got to be experienced, after all. But this is also why experienced developers, when they choose to found startups, often end up with B2B startups that slot into an existing industry structure, not startups that end up defining the industry. (Source: experienced developer now founding a startup and wrestling with just how little all that experience matters when it's not even clear what problems will dominate the industry or if the industry will even come to exist.)

saagarjha 8y ago
The tools for making a mobile application is something that I consider to be "solved", except in some very specific cases. If you are a startup, you are likely innovating in something that is not making apps, so I do not agree that you "don't know what you're doing" in this area.
- nostrademons 8y ago
  The article states that the product was initially solely web-based, and for a good reason: they expected the majority of their traffic to come from content-based SEO. That's the kind of product insight that can and should drive technology choices and might drive it away from "solved" mobile development practices. (Having used react-native-web for a project once, I also question whether it actually would've improved things: the HTML generated by react-native-web is terrible for SEO, and they might never have gotten to the point where they had users asking for a mobile app if they'd gone this route. Hindsight is 20/20 and often forgets about obstacles on the path.)

geofft 8y ago

"Experienced" and "effective" aren't necessarily correlated. I have worked with a handful of experienced developers who have been writing C and shell scripts since the '80s and have gotten really good at writing C and shell scripts like it's still the '80s. If you ask them to build something you can operate with an SRE team instead of with a sysadmin one (and not even in those words), they get very confused. So you give them problems where you can use their very specific experience very well. Both inexperienced and experienced developers can work effectively in problem domains where there is no clear path to a solution, and where even the problem itself is underspecified and changing. It takes some practice to figure out how to work effectively in such an environment, but at some point you run out of opportunities to have gained deep practice because the problem is too new.