21–30 of 228 posts
There's not a lot in Clean Code that I wouldn't recommend to most programmers.
The solution is more and better tools.
Only problem is, they are few and far between... (in my 10+ years in the industry, I've worked with only 3 people who I'd put into this camp)
Earlier quoted context omitted.
I never understand why Martin gets the kind of attention he does. As far as I can tell, the only significant achievement he's done for the technical community is the Agile manifesto. Outside of that, he's a typical consultant in that he's got books, training courses, etc. However, I have yet to find a significant publicly known project he's been involved in where he's had to put his principle into practice.
There's definitely two types of very well known speakers. People who have worked on some really notable project. Linus Torvalds, David Heinemeier Hansson, Joel Spolsky and so on. I know these people are worth listening to because I can see that their code is a success. Then there are people who I have no idea what they have ever written at all. Robert Martin, Martin Fowler and so on. I don't know if I should listen t…
I've thought for a while the real solution to bad software is simple: hire intelligent developers who care Only problem is, they are few and far between... (in my 10+ years in the industry, I've worked with only 3 people who I'd put into this camp)
What should be avoided if possible is the hero developer; the risk there is that the hero dies or moves on and leaves behind unmaintainable work.
Earlier quoted context omitted.
In fairness, Joel Spolsky has done a lot of great work as a founder - founding Stack Exchange being the most notable — but is any of his personal work open source? We don’t know how well written his code is. Twitter is successful but their code has reputation for being horrible.
It's not open source, but he led Excel development didn't he? I can use that and appreciate that it's good quality software so I want to hear about how he managed that. I don't know if I'm just ignorant, but to be honest I have no idea if people like Martin and Fowler can program at all or not!
Bob is more of a theoretical, philosophical guy it seems.
The problem is that the more tools you add, the more mistakes you make in the tools. This is the same debate we had previously about formal methods. They don't eliminate errors, they just move them to the testing systems and where there are several the gaps between them. Communication becomes more difficult between the people involved and you rapidly start looking for the Chief Programmer Solomon who knows everything…
One guy likes doing things in way, other does not.
Ignore.
Earlier quoted context omitted.
I never understand why Martin gets the kind of attention he does. As far as I can tell, the only significant achievement he's done for the technical community is the Agile manifesto. Outside of that, he's a typical consultant in that he's got books, training courses, etc. However, I have yet to find a significant publicly known project he's been involved in where he's had to put his principle into practice.
There's definitely two types of very well known speakers. People who have worked on some really notable project. Linus Torvalds, David Heinemeier Hansson, Joel Spolsky and so on. I know these people are worth listening to because I can see that their code is a success. Then there are people who I have no idea what they have ever written at all. Robert Martin, Martin Fowler and so on. I don't know if I should listen t…
I'm usually pretty skeptical of Uncle Bob's stuff, but in this case I think that both Hillel and Bob are a little right. Tools do make a difference, as Hillel says, and can be used to mitigate risk. The key word there is mitigate , though. Bob is right in that the root cause of that risk is a lack of discipline. Such risk will persist, mitigated by tools or not, so long as that lack of discipline persists. I think th…
I think you could have stopped after "Such risk will persist".
An engineer working on a project has far more control over what tools are used in the project than over the discipline or attention level of whoever is working on this project in three years. I don't see Hillel as arguing that we should give up on trying to improve discipline, but that we must expect to sometimes fail. Changing tools is pretty easy in comparison to changing cultures or incentives, and as a bonus, you can do it immediately, rather than hoping to respond when necessary.