[currymj]

if you're developing code for a large codebase with stable requirements in a company with good engineering practices, and your work output is the working code itself, it's hard to see that it would be very useful.

if you have to glue together multiple unfamiliar APIs and packages, maybe even seeing a couple new ones per day, you often throw away your code, and your work output is something else with writing code only a means to that end, it hugely speeds things up even accounting for debugging the frequent cases where it's subtly wrong.

this latter situation is more common than many software engineers realize.

[skydhash]

> if you have to glue together multiple unfamiliar APIs and packages, maybe even seeing a couple new ones per day, you often throw away your code,...

Maybe take the time to be familiar with them? I think that is a description of an unhealthy job. It's like asking an average mechanic to handle optimizing for an f1 car in day 1, then asking him to improve the endurance of a rally car the next day! Then telling them the main point is to market the sponsors, so no need to be perfect.

[currymj]

i don't think the car analogy is good because cars are expensive to build and maintain, usually are used more than once, and it's very bad if they crash. these properties are true of some software but not the kind of software i'm talking about.

maybe a better analogy would be if you travel to new cities a lot, and have to navigate, you don't want to memorize a map of all the city streets and learn in detail the transit schedules on each rail and bus line, you just care about a few routes a few times. and Google Maps can make your life a lot easier. on the other hand if you lived in that city, it would quickly become pointless to take out your phone all the time to plan a commute to work.