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'

Interns: Taking off the training wheels

My intern team has been working for several weeks now on our new website. We have already completed one deployment to production and are finalizing our second one. We started with a plan to release often adding small bits of functionality as we go and so far that plan has been working really well. We already feel like we have accomplished a lot because we have completed many of our project's requirements and should easily be able to complete the rest giving us time to do even more than just the original requirements. One of the things I have had some difficulty balancing has been how much to lead the interns and how much to let them figure out on their own. In deciding what our team process should be and how we should allocate our time, I think it was important for me to do more leading. I saw some deficiencies in how we were currently working and brought up some ideas for how we could address them. We had moved into spending all our time just working through stories and did not

My idea for Hearthstone to add more deck slots

Recently someone asked the Blizzard developers for more slots for decks in the game Hearthstone. The response was that they are talking about it and looking into it, but no decision has been made yet. One of the concerns over adding deck slots is that it could complicate the UI for Hearthstone and make it more difficult for new players to understand. I have what I think would be a good solution to add more deck slots without increasing the learning curve for the game much if at all. First I would take a look at the current selection screen for starting to play a game. It defaults to showing the decks that are custom built by the player if they have any custom decks, and there is an option to page over to the basic decks. This basic deck screen is perfect for how I would change this process. Instead of having 2 pages of decks, 1 for basic and 1 for custom, you would just see the select a Hero screen. Then once you selected the Hero you wanted, you would see all of the decks that