Skip to main content


While reading, Test Driven Development: By Example , by Kent Beck, I came across this list of reasons why fear is bad for a developer.
  • Fear makes you tentative
  • Fear makes you want to communicate less
  • Fear makes you shy away from feedback
  • Fear makes you grumpy
I feel like you could add another one to the list that would sum up all of the above:
  • Fear is the mind-killer
It's funny that the items written specifically about programming can be summed up really nicely in a fictional story about the desert. Its also a completely great way to look at how fear affects a programmer, it will literally kill their mind.

Developers work on computers with keyboards writing code all day, but their mind is where their value is. If their mind is not in the right place, they are not going to be nearly as  productive and effective as possible. So as a company that employs developers, your goal should be to make their lives, at least their work lives, as free of fear as you can.

How would you limit the fear that a developer feels at work? Well look at what takes up the majority of their time and see if there are way to streamline that, are there things that can be simplified. What is the the worse things that could happen and what can you do to prevent that from happening?

Here are some of the things I have seen that cause fear in developers and how I think they could be helped:

Fear of deployment

Insufficient testing and rushed to production code leads to bugs, and many times very bad bugs that can prevent the users from using the system. There really isn't a much worse feeling than going home knowing that something that has barely been tested is going to production that night and you are almost certainly going to walk in first thing in the morning to a broken system with everyone expecting you to fix the problem.

I would try to alleviate this fear first by making sure things are tested more thoroughly. If your customers are waiting on a feature and getting it into their hands as soon as possible is important, how is giving them broken code a good solution? I would enforce a mandatory waiting period on new features and keep those changes in a staging/testing area that you can have your internal users work against. If your internal users use the system enough, this waiting period might only need to be 1 or 2 days. If your support team can't log into the system because of a bug that was created, they will find it before it reaches real customers and you can then fix it.

Next I would look at finding a way to publish while developers are in the building rather than in the dead of night. Sure if you push to production at 2am, you might not have many users on the system, but you probably will at 8am before anyone can get a fix in place. If you publish at noon and you cause an outage for a lot of users thats not great either, but at least then you can get to a fix immediately rather than 6+ hours after the change. To go along with this, you should probably have a single button, immediate rollback button. Have your change waiting on one server that is not available to the public. Swap to that server for production with the new changes. If something breaks immediately, you can switch back to the regular production server in virtually no time.

Fear of New Code

If your system is not well architected and is difficult to add new functionality to, it is going to make developers afraid of adding new code. If you have certain things that alway need to be done in a specific order, abstract those pieces out of the way so that new code can go in without worrying about if it is in the correct order. Don't force dependencies where it isn't needed. Pass only the parameters that are needed into a function. Use contractors that accept the information that class will need to complete its work rather than passing the same parameters through multiple function calls.

Use existing, well-known, libraries and tools rather than creating your own. Why spend time trying to reinvent the wheel if you can go out and get an open-source wheel? If you can find an open-source solution for your problem, you can even make changes to it if necessary to fit your specific needs rather than writing all new, untested, unproven, likely-to-be-broken code to solve a problem others have had. More than likely, no matter how good your team is, if there is an existing library or tool you can use it is going to work better than what your team can come up, and even if you could make something better, how much time, effort, and money is it going to cost for you to do it? Just use what others have already created and focus on what you can do that is specific to your system.

Fear of Changing Code

If your code base is not well tested, it is going to be difficult to make changes without breaking things. Not being able to safely change code is going to make any development more difficult, which will foster an environment of fear. Not being able to refractor code safely with tests will also lead to not refactoring, which will lead to having a code-base full of poorly designed classes. It will also lead to creating new classes rather than modifying and extending existing classes because you will be afraid of changing the existing class and break things.

Obviously developing with TDD will prevent this fear as you will have tests from the beginning that will allow and even encourage refactoring. If you do not have tests in place because your system has been built without tests in the past, you should pick a place to start and add automated tests. Try to build up a collection of tests where possible. Start designing your system to be testable. Encourage your developers to learn how to write tests, and how to write code that is testable. Wrap your system in a blanket of safety that will allow your developers the freedom to grow themselves and your system.

Fear of the Deadline

No one is ever going to allow a developer to work on a project until they feel like it is perfect. Chance are that code will never get to perfect, but putting arbitrary time constraints on changes aren't going to be a good way to get the best out of your developers either. If you have a hard deadline for a project, it should be communicated to the developer well in advance and in terms like, "We need to have this done by May 1st." Not something like, "You have 1 hour to complete this."

Forcing a developer into making a change in an incredibly small time frame is going to immediately screw up their ability to think through the problem. They aren't going to look at it and make sure they are doing the best thing to fix the bug or fix it in a way that will prevent another bug from popping up. They are going to think, "Oh Crap! I have no idea what the problem is, and by the time I figure it out I will be half way to needing to have it done." Then they will do the fastest thing they can do come up with to get the problem to go away without any thought to the overall system.

Instead you should probably treat your developers like adults and expect that they will be able to get their work done in a reasonably fast timeframe. If you let them know up front what your general expectations are for how they should work on different issues and let them go to work, they will probably get things done much better and still just as fast without adding a layer of stress. If they get stuck on a problem they are going to be more likely to seek out help from others in the team and get the problem solved faster than if the only thing going through their head is that they need to get this done already.


Popular posts from this blog

Converting a Large AngularJS Application to TypeScript Part 1

I work on a project that uses AngularJS heavily. Recently we wondered if using a preprocesser like CoffeeScript or TypeScript for our JavaScript would be beneficial. If our team is going to switch languages, we would need to be able to convert existing code over without much pain and we would have to find enough value in switching that it would be worth the conversion. I had read an article that stated that because TypeScript is a SuperSet of JavaScript, you could convert a plain JavaScript file to TypeScript by changing the extension to .ts and not much else would need to change. I wanted to test out this claim, so I took a file that I was familiar with, an Angular Controller, and tried to convert it to TypeScript to see how much effort it would take and then try to figure out where we would benefit from using TypeScript. This is what the controller JavaScript file looked like to start out with: ( function () { 'use strict' ; angular .module( 'app'

Gamify TDD

I like it when things that would not normally be associated with games add concepts from games as a way to incentives you to accomplish things. Why simply go for a run if you can have an app that will track you and give you a gold star if you do better than you did the last time? Why go to the coffee shop that only gives you coffee if the other one will give you points that you can redeem for free drinks eventually? I was recently introduced to C odeSchool , an online training system similar to PluralSight, it has video courses and challenges you can take to prove that you retained what the video taught. CodeSchool also adds badges and tracks to your learning, so as you complete a video and its challenges you get a badge. Complete a collection of courses within a specific discipline and you become a master of that discipline. Some of these incentives are not tangible and really don't mean much in the real world, but they tend to work for me. If I start working towards a large g

Converting a Large AngularJS Application to TypeScript Part 2

In part 1 I was able to take an Angular controller written in JavaScript and convert it to a TypeScript file while doing very little to change the code. In this post I am going to explore transitioning that same controller to actually use the features provided in TypeScript. This is how I left off my controller: declare var angular: any; (function () { 'use strict'; var controller: any = function($scope){ ... } angular .module('app') .controller('controller', controller); controller.$inject = ["$scope"]; })(); While performing the translation from JavaScript to TypeScript, I would make sure at every step that the functionality I expected still worked, so if anything I did broke the system I would change it back and try again with another approach. Also if something seemed like it worked too easily, I would break it on purpose to make sure I wasn't getting a false result through browser caching a previously working