Christian Peters

One of the great things about TDD is that it gives you a framework for how to approach coding problems and really how to approach work. You follow a pattern that has been proven to work by countless others. You start by proving the smallest piece of the code that you can and you work your up, bit by bit, to solve the entire issue. It sets you up for success, and makes solving complex problems easier because you don't have to worry about the entire thing. You can focus on a much simpler problem and solve that. But you have to use it, ALL THE TIME! It shouldn't be something that you only use once in a while or when you feel like it. It shouldn't be something that you fake by writing a few, relatively meaningless, tests after you have completed your work. You shouldn't claim that writing out the tests first will take too long, and then follow up your work by throwing together some tests. Start with tests and build up as you go. Trust that the system will work, follow th

Previously I described what fear can do to a developer and how a company can build an environment that will allow their developers to not have fear. Today I thought I would look at what a developer can do for themselves to remove fear. Fear of not being good enough It seems to me that we as developers have a tendency to look at other developers and think that we do not match up to them. We don't correctly evaluate our own value so and assume that we don't have a lot of value or that no one would want to hire us because we aren't good enough yet. This fear can lead us to not realizing that we are more valuable to our current employer and that we should be treated as such, wether that is salary or benefits or vacation time or the ability to work from home, we don't think we are good enough to ask for the things that we want and the things that would allow us to be more happy at work. It can also lead us to not look at other job opportunities that may be better for

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 wo

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