3 ms·

Somehow people are reading a strange, opposite conclusion from this headline. See the "30m to reproduce a days work" argument. What TFA says is that the writin

Somehow people are reading a strange, opposite conclusion from this headline. See the "30m to reproduce a days work" argument. What TFA says is that the writing of the code is not the most valuable part of this process, but that does not mean that the code itself is of little value. The fact that writing the code is "easy" once the solution is found does not mean code is of little value! This article shows that code is extremely valuable since it codefies exactly the business logic, design, and hard work of problem solving. It's the map leading through all the challenges to a business solution. It's a shortcut and a working tool. It's the whole point of having expensive software engineers doing difficult design work. Your clean room argument is spot on.

6510 1y ago
Thinking about it, the encoded business logic also becomes hard to change. Perhaps like writing prevented language and stories from evolving. Encoding it might be the final version. I got stuck a few times when the business logic got overly fuzzy. If you have 10 people and 50 small tasks with each task taking between a and b minutes in some strange distribution where b might be 3xa. If task 1 takes more than c minutes task 2 is likely to also take longer while task 3 will be easy. Unless it is full moon then task 2 will take less time and 3 more. On the factory floor the guy to plan this would also know how fast each employee is with each task and that employee 1 has a hangover on Monday, 2 goes to the gym on Thursday and 3 has to babysit before the night shift. But now we are going to have an app to plan this???