3 ms·

Or perhaps you should read the message instead of looking (and shooting) at the messenger. By the way, I do not own his books at all. None. So... Uncle Bob do

Or perhaps you should read the message instead of looking (and shooting) at the messenger. By the way, I do not own his books at all. None. So... Uncle Bob does not have anything that supports his skill and authority? Just because he worked with clients building internal apps or back-end b2b apps does not mean he has not done anything. If you want to use his software or check his code maybe you should try FitNesse (http://en.wikipedia.org/wiki/FitNesse http://en.wikipedia.org/wiki/FitNesse). I'm not his biggest fanboy nor I care even a slight bit when it comes to TDD, BDD, Agile or whatever. But this guy has written books since '95 and he's doing a darn good job and the customers are happy (check his ratings). http://www.amazon.com/Robert-C.-Martin/e/B000APG87E/ref=sr_ntt_srch_lnk_4?qid=1322365740&sr=8-4 http://www.amazon.com/Robert-C.-Martin/e/B000APG87E/ref=sr_n... While other "consultants" preach Agile processes, Uncle Bob focuses on writing code. Code darn it. Not processes or steps or standup meetings or burn-down chart. C.O.D.E. While others preaching OOP with re-use crap, Uncle Bob made a stand with SOLID and "Object in real world is not the same with Object as program". Actual implementation as opposed to re-hash the same old "theoretical" stuff. Check out his Craftsman articles: http://www.objectmentor.com/resources/publishedArticles.html http://www.objectmentor.com/resources/publishedArticles.html (click the Craftsman, I can't give you the URL). All code. On the other hand, I met tons of developers that write code only for themselves and not other, developers that have huge ego and did the heroic crap, developers that write code without even inline documentation, developers that don't have any professionalism or whatsoever just because they thought that "Hey, Linus never care any of these craps". Let's keep in mind that great programmers like Linus is just 0.01% while others that try to emulate him failed miserably. So yeah, I chose Uncle Bob over Linus when it comes to educating others since 95% of developers are below average (yes, I'm harsh. I could be one of that 95% as well for all I know). If Uncle Bob can push that number down significantly. I'll be much happier. PS: Have you actually look at the article that this HN thread link to? Tell me, what's wrong with Uncle Bob's latest book? All the suggestions are good. Uncle Bob pretty much advised developers to become better. Those 9 points that the blogger pointed are what happening in the real world: developers are crappy in general and that is due to their own character and attitude : "I just want to hack some code the way I want it to be, to hell with the rest". Guess who's going to clean that sucker's code?

Silhouette 15y ago
I'm sorry, but you seem to have read something in my post that was not there and then attacked a series of straw men. You asked about listening to teachers without a track record and reading their books. I gave an argument that some people aren't worth listening to/reading, including the author in question here. Tell me, what's wrong with Uncle Bob's latest book? All the suggestions are good. I only bought his previous book (which is part of the reason I have a very negative view of Martin's work) but picking on some of the points in the article here that jumped out immediately: It is important to remember that you don’t own the code, but rather the team does. The degree to which collective code ownership by an entire team might be better than having more specialist roles is still an open question. Over time, teams slowly grows better and better as well, resulting in team members will eventually know each others strengths and weaknesses. Another great theory. It usually gets some cute title like "forming, storming, norming and performing" in the management textbooks. What the article (and, I am therefore trusting, the book itself) glosses over is that many teams never reach the performing stage in practice. When coding you should always aim to cause no harm in your project, by always aiming to get the error rate as close to zero as possible. This is done by simple writing tests. Tested code gives you more confident about your work, knowing the fact that what deliver is at top class and checked against errors. The list of loopholes in pro-TDD arguments and the number of fallacies perpetuated by TDD advocates would fill at least a chapter of a book. To say that whether TDD is beneficial is an open question is putting it mildly. Moreover, describing someone who doesn't buy the TDD hype as "unprofessional" is simply a crude ad hominem attack, which by the way targets almost all professional developers who do in fact work on software with bug rates an order of magnitude or more better than the industry average. According to Robert C. Martin, if you work 40 hours a week, you should spend around 20 additional hours enhancing your own profession. Ah, yes, I remember the management research about this one. It definitely showed that sustaining a 60-hour work week in a creative field was the best way to maintain performance, and found no negative consequences that quickly led to a net performance loss and ultimately to burn-out of the worker. As a professional developer, you should know that being a software developer is a very intellectual and exhausting job. It is important that you don’t overwork yourself, but rather find a balance in life with your job. Hang on a minute... Yep, we really did just talk about spending 60+ hours per week on work-related activities and then segue into the importance of getting enough rest. If your superiors refuses to listen to you and does not take no as an answer, you should think about going one step higher. Even though going over someones head might feel uncomfortable, in the end it will deliver the best possible outcome for all involved parties. If your superiors refuse to listen to you, it is their problem. If they do listen to you but then choose not to follow your recommendation, it is also their problem. Either way, you can if necessary ensure that your objections have been properly recorded, but it's almost certainly not your job as a software developer to second-guess a management decision and start playing levels of management off against each other. What happened to keeping a level head in a crisis and to being a team player?

Silhouette 15y ago

I'm sorry, but you seem to have read something in my post that was not there and then attacked a series of straw men. You asked about listening to teachers without a track record and reading their books. I gave an argument that some people aren't worth listening to/reading, including the author in question here. Tell me, what's wrong with Uncle Bob's latest book? All the suggestions are good. I only bought his previous book (which is part of the reason I have a very negative view of Martin's work) but picking on some of the points in the article here that jumped out immediately: It is important to remember that you don’t own the code, but rather the team does. The degree to which collective code ownership by an entire team might be better than having more specialist roles is still an open question. Over time, teams slowly grows better and better as well, resulting in team members will eventually know each others strengths and weaknesses. Another great theory. It usually gets some cute title like "forming, storming, norming and performing" in the management textbooks. What the article (and, I am therefore trusting, the book itself) glosses over is that many teams never reach the performing stage in practice. When coding you should always aim to cause no harm in your project, by always aiming to get the error rate as close to zero as possible. This is done by simple writing tests. Tested code gives you more confident about your work, knowing the fact that what deliver is at top class and checked against errors. The list of loopholes in pro-TDD arguments and the number of fallacies perpetuated by TDD advocates would fill at least a chapter of a book. To say that whether TDD is beneficial is an open question is putting it mildly. Moreover, describing someone who doesn't buy the TDD hype as "unprofessional" is simply a crude ad hominem attack, which by the way targets almost all professional developers who do in fact work on software with bug rates an order of magnitude or more better than the industry average. According to Robert C. Martin, if you work 40 hours a week, you should spend around 20 additional hours enhancing your own profession. Ah, yes, I remember the management research about this one. It definitely showed that sustaining a 60-hour work week in a creative field was the best way to maintain performance, and found no negative consequences that quickly led to a net performance loss and ultimately to burn-out of the worker. As a professional developer, you should know that being a software developer is a very intellectual and exhausting job. It is important that you don’t overwork yourself, but rather find a balance in life with your job. Hang on a minute... Yep, we really did just talk about spending 60+ hours per week on work-related activities and then segue into the importance of getting enough rest. If your superiors refuses to listen to you and does not take no as an answer, you should think about going one step higher. Even though going over someones head might feel uncomfortable, in the end it will deliver the best possible outcome for all involved parties. If your superiors refuse to listen to you, it is their problem. If they do listen to you but then choose not to follow your recommendation, it is also their problem. Either way, you can if necessary ensure that your objections have been properly recorded, but it's almost certainly not your job as a software developer to second-guess a management decision and start playing levels of management off against each other. What happened to keeping a level head in a crisis and to being a team player?