3 ms·
I didn't get the feeling that the author disagreed that programming has a crafty nature. But since building software also has some engineering aspects, he is po
by mekoka 6y ago
I didn't get the feeling that the author disagreed that programming has a crafty nature. But since building software also has some engineering aspects, he is pointing out that you (as an organization or project leader) could wait for the graduates that you hire fresh out of uni to mature into accomplished "craftsmen", or you could just observe what has already worked for others, based on evidence and mindlessly apply those patterns. The mileage may vary on your returns from the latter approach, but it will likely be cheaper and will remove some uncertainty from your projections.
Speaking as someone who has observed the kind of massive technical debt you can incur from letting your programmers mature one mistake at a time and ten reinvented wheels later, I would certainly not be too quick to dismiss the proposal.
> "The labour of the cognitariate is the means of production of software systems"
I fail to understand why you would disagree here. That sentence to me means that producing software systems requires brain work. Whether thinking, designing, coding, testing, debugging, reviewing, it's all part of the "labour of the cognitariate". Compiling isn't.
- aard 6y agoYou have a valid point here. Maybe I was too hasty to judge the book by it's summary. From other comments, it sounds like this book takes a pretty reasonable approach. I am frequently skeptical of efforts to show the "one true way" of programming, because it usually results in some poorly vetted process being forced on my at work. So, I was probably too quick to jump to conclusions. It actually sounds like this book is good about showing that a lot of our current assumptions about good process are faulty. The point I was trying to make about the "labour of the cognitariate" was that developer doesn't really produce software, they create the blue-print for the software (source code), and then compilers or interpreters produce the actually software. It may seem like an overly semantic point, but I think it is an important distinction to make. It changes they way you think about software development.