Eye of the Storm

Sometimes developers are overworked. As more and more time-sensitive tasks are thrown their way, good developers will still do their best to meet their deadlines. They will work harder, faster, and even put in some extra hours because they care about their work. However, when there is so much work do be done that, no matter how hard they try, there is no possible way for them to meet their goals, something unexpected happens. Like a switch, the hopelessness becomes undeniable and, right in the middle of the crisis, developers will lose all sense of urgency. It’s analogous to the eye of a hurricane. As the storm hits, the weather conditions get worse and worse until, right in the center of the storm, there is a sudden, eerie calm.

​ Assessing Aptitude

​I have sat through too many interviews where the candidates claimed to have plenty of experience and they were even able to rattle off good answers to all of the technical questions, but then, when I would ask them to actually write a short program to solve a simple problem, they were totally unable to do so. Sometimes the contrast was downright shocking. Situations like this make two things readily apparent. First, requiring candidates to write actual source code as part of the interview process is crucial. Second, standard technical questions are not always effective.

The reason that such a stark contrast can exist is because most technical questions test for knowledge rather than aptitude.

Incremental Illustrations

Have you ever noticed how an explanation with a whiteboard is often more clarifying than even the most meticulously designed chart or illustration? Even when there is no audience participation, a whiteboard explanation can be immensely more valuable than any professional presentation with the same information. It's certainly not because the chicken-scratch of the presenter on the whiteboard is more understandable. And it's not because the hand-drawn diagrams are more accurate or recognizable. So what is it about a whiteboard that makes the complex so understandable?

Code-Fiddlers

This article is one in a series. See the introduction here.

Everyone is driven by a desire to succeed, but for some, success does not come through superior skill or intellect; for some, success comes through will-power and determination. In the field of software development, such people can often be described as code-fiddlers. There was a time when I looked down on code-fiddlers, but I've since come to realize that they can perform better than me in some ways. To the untrained eye, code-fiddlers are hard to spot. They are able to meet goals and create working products just like everyone else, but we engineers understand the big underlying difference.

Code-fiddlers, you see, don't really know what they are doing. Okay, that's a bit extreme, but at its heart there's some truth to it. They obviously have some clue about programming. They know enough to be able to get their code working, but they don't fully understand why or how it works. You may be thinking that sounds absurd--how could anyone write complex functioning software that they themselves don't understand?! If you are incredulous, let me assure you, it's absolutely true. I have worked closely with many developers over the years that fit this very description. At first, I didn't believe it either. I still don't fully grasp how code-fiddlers manage to pull it off, but I assure you, they do. Perhaps it will make more sense by way of a metaphor...

Making Meetings Count

I've heard it said that there is nothing worse than endless meetings. I almost completely agree. Having constant meetings is exceptionally counterproductive, but to say that there’s nothing worse is to exhibit a slight ignorance. It’s not the worst thing. Having no communication is even worse. So, if both extremes are bad, then what is the proper balance?

I propose that the question is not one of balance, but rather, it's one of quality and kind. If the communication is important, and the most appropriate mode of communication is chosen, then it's almost impossible to have too much of it. The answer is not to focus on how many meetings you are having or how long they last. Rather, the answer lies in making sure that you are only communicating the things that are actually important, and in making sure that you only have meetings when meetings are the most appropriate method for communicating those ideas.

The Average Lifespan of a Crisis

Have you ever asked your team to kick it into high-gear for an extended period of time in order to meet some major challenge?  Let me guess what happened…

They rose to the challenge!   Everyone stayed motivated, focused, and maybe even put in some overtime!  Great strides were made towards completing the goals.  But then after a week or so, that high-gear began to slip.  All that motivation and focus dwindled away.  A few weeks later you looked back and wondered if the project was any farther along than it would have been if you had just kept the status-quo.  

How did I know?  Because it always works that way.  "Why," you ask?  Well, it’s not because all developers are lazy.  Allow me explain.

Hiring by Personality-Type

As I have elaborated in some of my previous articles, the underlying personality of a developer should be of chief concern to you. Depending on the types of products that your team develops, you should have a desired ratio of personality-types among your engineers.  For instance, if you run a contracting service that develops websites for businesses, you will likely want a higher ratio of solution-providers on your team. If you develop pattern-recognition image-processing libraries, you likely want a higher ratio of puzzle-solvers.  Before hiring a new developer, you should seriously consider the type of developer of which you are currently most in need.