GrokFu

There is a single tester on our team. The depth of her knowledge and her attention to detail astounds us most days. She knows the edge cases, the strange behaviours and the places where our code and the real world don't quite agree with each other. There is definite truth to the saying that if you want to know how a system works, ask the testers! Something that she has taught me is that there is a vast difference between what I consider to be working code and what she considers to be working code.

Developer working is a rosy view of the world. Usually it means that the code works under some nice conditions. We assume the user has behaved sanely, the OS is in good shape, the machine is up and responsive etc. Tester working is a much tougher place to be. In tester working the end is nigh and all hell has broken loose. The user has decided to put all spaces in every field and delete our config files. The OS is a custom version that we've never seen before and the machine only responds twice a day.

Being pegged as someone who talks too much has a devastating affect on your interactions with others. When people think you talk too much it goes way deeper than they just feel like you should utter fewer words per minute.

In their minds what you say has been devalued. Filtering the quality statements from the surplus ones is too much effort so everything you say is presumed to be garbage and should be ignored. Your voice gets turned off because it distracts and is worthless.

This is incredibly difficult to recover from. How can you convince someone that you have valuable things to contribute when they won't listen to what you have to say? In the workplace you can never be influential, never lead effectively or be consulted on important decisions because everybody has turned you off. It is imperative to play the communication game according to the rules that human nature imposes in order to avoid this situation. There is a Listening Formula to follow and when you break it it triggers others to associate you (subconsciously) with speaking too much.

The formula for how much time you should listening is not as simple as it should be. In a perfect World it would look like this:

% of time to spend listening = 100 - (100 / number of people in the conversation)

So if there are 5 people attending a meeting each person would spend 80% of their time listening and 20% speaking, but this is not how it works in reality.

Every communication has an implicit hierarchy underpinning it, you are further up the totem pole than I am or I'm higher up than you are or we are about the same level, and that has to be factored into the equation. When you are leading a meeting, for example, you are entitled to speak a little more. When you are an intern learning your trade you must adjust to listen more and speak less. Interestingly if you don't speak as much as you should, given your status, you can be considered meek, not assertive enough or someone not to be trusted!. 

Awareness of this formula not only saves you from being tarred with the "speaks too much" brush but it shows that you know how the hierarchy works and earns you the appropriate respect. When you know this rule exists you can take advantage of it. Speak at the very limit of what is allowed or even push over that limit ever so slightly so you raise your profile slowly but effectively. You will be seen as assertive, strong, positive because you have put your views across but played within the rules.

I am lucky enough to have landed my dream job. The work is rewarding and challenging, the food and foosball are free and the people are smart, incredibly smart, and as such everybody is a high performer.

When you combine this sort of high performance culture with human nature you get some strange behaviour. In particular you get an environment in which free thought, creativity and progress is completely reliant on the individual's ability to fight the "Lizard Brain" as Seth Godin and others call it. In my workplace I have to pluck up the courage every day to be honest when I don't understand something. My Lizard Brain says run away (pretend you get it), or attack (blame someone else) whenever we discuss something I don't understand because it interprets that situation as a threat. Everybody else is smart so if I show weakness I might get blamed, ridiculed, or fired.

But I've got to say it, so does everybody else, because if we don't then the safety harness which allows us to perform so highly and create some awesome things, disintegrates into fear of looking stupid. People start pretending, they start limiting their ideas to "good" ones and the environment stagnates.

That's why this type of workplace is so hard to find, so difficult to maintain and so important to protect. It is all based on faith, and that is an extremely delicate thing. It only takes one or two people who give into the Lizard Brain to destroy everything. I've found that my workplace maintain this culture by being incredibly picky when interviewing, always prepared to fire someone who doesn't fit and having the patience to grow slowly.

Six months ago my fellow dev and I were handed a new project to work on. We had just started to work together, our domain knowledge was zero, and 50% of us (me, that is) had zero experience of C#. The significant risk that this formula involved was obvious, especially on the faces of our project manager and the division head.

Something special was required. Luckily this guy would not shut up about this. Dependency inject he said, unit test he said. Having both experienced projects where the thought of changing code struck fear into our very hearts, we were up for giving it a go.

It started slow, that much is true. Writing one to two lines of test harness code for every line of "real" code is hard to accept. It's counterintuitive given the business pressures you are under. Test code can be so simple that it feels worthless. Of course thing.Increment() returns thing+1, what else would it do?!

I felt that too, and often, but sticking with it (thanks to the support of the team as a whole) brought with it a significant reward. It is between doubt and boredom that magic happens.

Communication

Unit tests allowed a clear and concise communication of intent. For us this meant that we could compensate for some of our lacking in domain knowledge by increasing our ability to converse about the state of the code. I could easily point to a test to explain a problem I was having, instead of being stuck for words.

Code Quality

Code rot starts instantly. Having tests from the beginning allowed us to make sure that once the code was correct, it stayed correct. For a project where there were no gurus to save us this was incredibly valuable. Without unit tests to help us, plugging one hole would spring a leak elsewhere and we would almost certainly have ended up racing to the bottom as deadlines approached.

Knowing when we hit the Target

One pivotal component had to store and sort data on disk. We didn't know how we would do that at first so we came up with the interface for the component and an in memory implementation. The tests for this interface acted as a target for us to hit when it came to implementing the on disk component. Once our on disk implementation passed the same tests we knew that our work was done and it satisfied the same criteria!

Testability gave us Flexibility

Making something testable through dependency injection means that it is also flexible. Having gone through this process we were able to port our application to multiple new DB platforms, each one taking roughly two days to complete. Each solution depends on the very same engine, we just had to write the custom pieces to be injected. Testability means being able to mock out parts of the system easily, those mockable parts make your system ultra-flexible.