The Clean Coder (2)

Today I read some more of the The Clean Coder by Robert Martin. Here's a few more of the things I've been learning about being a professional developer.

Stay out of "the Zone"

The hyper-productive state of mind, known as "the Zone", is highly sought after by much of the development world. Many developers will put on headphones as large as the side of their head, isolate themselves, or take whatever other measures necessary in order to get in "the Zone". However, Uncle Bob argues that this state of mind is not as productive as claimed. He claims, "It's really just a mild meditative state in which certain rational faculties are diminished in favor of a sense of speed." The main argument is that the code written while in "the Zone", will suffer in quality and have to be written again. This is because the decisions made while in this mind set will not be mind with quality in mind, but decisions will be made that favor completion and maintaining velocity. It is similar to highway driving. Most drivers lean back, flip on the cruise control and let their minds wander. While in this mindset, most drivers aren't focused on driving defensively or being cautious, they are focused on not slowing down or breaking their cruise control, therefore they are more dangerous to themselves and those around them. The same applies to coding in "the Zone". Everyone's code is in danger.

Working Under Pressure

Uncle Bob opens this section with a quick comparison of how surgeons and developers act under pressure. Surgeons act calm and collected, stick to their disciplines and training, and act professionally. Developers usually act like a two year old who just got his toy taken away from him. This is obviously not professional. If you want to be taken seriously as a professional, we must throw out the attitude, stick to our disciplines and act professionally. This does not mean that we put in 80 weeks, coding until 2AM. This will not get more done, but create a mess. This mean that we manage our time better, write more tests, and pair programming to avoid wasting time on debugging.