I have to say it seems like just after I get done with a decent chapter I move on to the next and boom! You can tell that this is an Uncle Bob series book. I am so tired of hearing the word professionalism and professional that I want to puke. I am going to keep this chapter’s blog short. Maybe it is because I have been through a lot of the scenarios he talks about that I get irritated. This chapter is almost exactly like a chapter that Bob wrote in the clean coder. Never say I’ll try and get it done because the boss takes that as you will, don’t over exert yourself or you’ll get burnt out, you can’t code good at 3am, sleeping in the parking lot and getting a horrible nights sleep is a bad idea etc. I get that it is important to learn how to say no, and not commit to something you know you can’t deliver even if it means getting that nasty look from your boss or a guilt laden trip from hell. I just think it is over done in the series. I understand that important things need to be reinforced, but I think it is over done here. I will stop ranting now, because the book does have its good points, I just am not fond if certain chapters.
I do have to say that this book seems to alternate good and bad chapters to me. This chapter I thought was informative and had some useful stuff. I agree with these guys on their stance of having clean code and working software, or being a software craftsman if you will. He hits on many things in this chapter and something stood out to me right off the bat. He said that “some organizations believe that with a good management team, deep hierarchies, micromanagement, strict process and a large amount of good documentation and the project will succeed.” One other line was that many organizations see developers as lesser skilled than the higher qualified managers. He hit the nail on the head with those two statements. I have seen this in most every industry I have worked in. They always seem to forget that us underlings are the cogs that keep the machine turning. That is not to say that good management isn’t important, I just think there is a lot of backwards thinking and it is maybe because they pay the management ludicrous numbers and they need some way to justify it?
I also thought that his stance on working software is not enough was well done and very true. I think there are a lot of hacks in every trade that thinks that good enough is ok. I firmly believe that you should take care of your code like you are looking after your garden. It needs to be weeded and groomed and fed to ripen and blossom. It is like a living being it seems to me. Especially after working on the Ampath project and seeing how projects work and the communication and all of the collaborators working together. He says the cost of dealing with bad code can make companies less competitive and I agree. It reminds me of a saying my father used to say to me, “Don’t do it half ass because you’re just going to have to do it over again and it will take twice as long as if you’d just done it right in the first place.” I can’t argue with that wisdom as I found out the hard way a few times more than I care to admit.
Over all I really enjoyed this chapter and took away some things from it. I really hope that I don’t end up working for a company like some of the nightmares he was talking about. So much about Agile development makes sense and on paper is grand, I just hope that at least some of the methods are employed when I get out there.