Maurice’s selected thoughts.

You should never ask a geek what they are doing. Why? Well let us say for the sake of argument that you are not a geek. You are walking around and you see someone you know. They are a known geek. Let us also assume that the geek is using a computer. Now here are a few scenarios.

Scenario One

Non Geek: “What are you doing?”
Geek: “Well I’m reading Joel’s Blog, updating my blog, working on some code to translate a model in Java to a Matlab file, Googling for more information on Ruby and how it compares to Objective-C since I know Objective-C and would like to know more about Ruby, browsing through several RSS feeds, catching up on a few newsgroups, and answering a few important emails. Oh, and I’m also working on my server it needs an updated security certificate, there is an security update I want to install after todays backup runs, and I’m thinking of installing Postgres but I may just stick with MySQL. I don’t know, they both have strengths so I’ll probably use them both for different projects. Oh, I’m also researching a few different machine learning packages I want to look in to using as part of a project.”
Non Geek: “What?!”
Geek: “Never-mind, I’m just working.” Thinks: That doesn’t really do it justice though. I’m actually having a lot of fun. I can’t believe I get paid for this. HHHHAAAAAHHHHHAAAAAAAA!!!!
Non Geek: “OH! I see. So maybe I could ask you a question I have about Word?”
Geek: “I use LaTeX.”
Non Geek: “Do you mean latex? What does that have to do with Word?”
Geek: “Please stop talking to me.”

Scenario Two

Non Geek: “What are you doing?”
Geek: Last time I talked to Bob he asked me some stupid question about Word. I don’t even use Word. How can I avoid that? “I’m just working on the X project.”
Non Geek: “Oh, yeah. I hear that’s going to be huge for the company.”
Geek: “yep”
Non Geek: “So, I was wondering if I could ask you a question about Word?”
Geek: “I use LaTeX.”
Non Geek: “Do you mean latex? What does that have to do with Word?”
Geek: “Please stop talking to me.”

Scenario Three

Non Geek: “What are you doing?”
Geek: Last time I talked to Bob he asked me some stupid question about Word again. I don’t even use Word, he ought to know by now. How can I avoid this again? Maybe if I just sit real still and pretend I didn’t hear anything.
Non Geek: “So, I was wondering if I could ask you a question about Word?”
Geek: “I use LaTeX.”
Non Geek: “Do you mean latex? What does that have to do with Word?”
Geek: “Please stop talking to me.”

Scenario Four

Non Geek: “What are you doing?”
Geek: Last time I talked to Bob he asked me some stupid question about Word again, and I keep telling him I don’t even use Word, he ought to know by now. He must be the densest idiot in this office. How can I avoid this again? I thought if I just sit real still and pretend I didn’t hear anything he would go away. Perhaps antisocial behavior will work. “Please stop talking to me.”
Non Geek: Laughs “You’re a real card you know. Crack me up everyday. So, I was wondering if I could ask you a question about Word?”
Geek: “I USE LaTeX!!!”
Non Geek: “Do you mean latex? What does that have to do with Word?”
Geek: “F??? OFF!!! I’m an engineer not IT. You want to know what to do with Word. You f???ing type! It is not rocket science! You just f???ing type in Word! That is all you do!”

Scenario Five

Non Geek: “What are you doing?”
Geek: Screams “I USE LaTeX!!! RTFM MOTHERF???ER!!!” and begins beating Bob in the head with the 25 pound lead-acid battery scavenged from his uninterruptible power supply.

Conclusion

So if you are not a geek I would recommend you stop asking us what we are doing. Unless you really want to know and can appreciate that we don’t care about Word or what ever other application you are having a hard time figuring out. Those questions should likely be addressed to IT and then only after you’ve tried to figure out the problem for yourself. Remember non-geek. Software engineer does not answer questions about applications, software engineer writes the applications. Unless you are talking to the software engineer that wrote Word, they probably don’t know that much about it because there are better tools that are not as user friendly.

Test-driven development (TDD) has been seen as an aspect of the Extreme Programming (XP) methodology since the rapid growth of XP mind-share in the early 2000s. This view has begun to change as more developers are trying TDD even without a commitment to XP. Here I’ll talk about just a few of the important things you should and should not do when developing with TDD.

DO: Use your test case to capture the design of the software. If you do you WILL uncover design flaws before they are coded into your system. Oh yes, you do have design flaws, you just have yet to discover them.

DONT: Write just this one line of code that is not tested. If you do you violate the testing cycle. The test must fail before it can pass.

DO: Make small changes to tests and code. This minimizes change between test runs. Then if you find a problem it was likely introduced in the small change.

DO: Think about ways that the test you are writing code to should fail but doesn’t. If you find one stop writing code and write the test.

DONT: Write tests for things you do not need to do today. No dead weight! If you do you bloat your tests and your code.

DO: Use configuration management, even if you work by yourself. It will save you time and heartache eventually.

DO: Refactor! This should include removing code you no longer need. No dead weight! Philosophically refactoring is the acceptance that you are better at doing your job now than you were before, or that time and observation have given you more insight to a problem. Which leads to …

DONT: Think you can’t do wrong. If you do TDD is not for you. You will not refactor. You will not write tests for things you know you can do right without them. You will not benefit from the efficiency introduced by practicing TDD. You will not be able to work in a team that uses TDD or XP. In short your intellect no matter how large you believe it to be is no match for the combinatorial explosion of a complex system, and this system WILL eat all of your time.

These are the best practices I have learned from doing TDD. There are likely some other interesting ideas missing here but these stand out to me as being simple guidelines that keep me to the correct philosophy for doing TDD. In fact the last one pretty much sums up the reasoning behind TDD for me. All the best practices of TDD follow from not thinking I am always correct.

Most methodologies are designed to compensate for human fallibility. TDD just happens to have several measures for working around our faults as developers, and all we need to do to benefit from it is follow the simple process outlined for TDD.