No Pain, No Gain – Code Katas

Code katas are not a new concept at all, but my recent participation in daily katas has compelled me to consider how valuable they really are.

I won’t bore everyone with the technical definition of what a kata is; a kata is basically a specific thing you do repeatedly in order to improve in that area.

For me, no matter what it has been that I have had to practice (studying, playing the violin, coding, etc) it has always been painful & difficult, especially in the beginning. But that’s kind of the point isn’t it? If it were easy, then I wouldn’t need the practice. It seems to me that there are some people out there for whom certain things just come naturally, but, as tempting as it may be, we can’t let ourselves get caught up on the abilities of some in such a way that it distracts us from using regular practice to improve ourselves. Instead of comparing our abilities (or lack thereof) we need to just work hard at getting better if we really want to be good (dare I say the best we can be?) at our craft.

Maybe you stumbled upon this blog post because you don’t know how to do a code kata, or because you need some encouragement continuing in katas, or perhaps you have lost all interest in regular, consistent practice – here is just a bit of advice I would have given myself before my first code kata:

1. Don’t quit & don’t make excuses. Sure, it will be hard and frustrating (or boring) sometimes, but the point is to get practice – that’s it. So just do it, and keep doing it.

2. After coding a problem kata to its solution, scratch it and start over from the beginning. You just might come up with a better way to do it or if nothing else, you will get practice with how quickly you can put it back together again.

3. Code kata for a maximum of 30 min. Keeping it in short sprints will help you get faster, it will force you to get & stay focused, and also gives your brain a break & a chance to work on something else.

4. Do a code review after you are done with your practice time. Have a co-worker or colleague open your solution and talk through what it is doing. Having to be accountable for the code we write helps us to learn and keeps (or makes) us humble.

5. Try something new – a new problem, a new language, a new code reviewer, no mouse – anything to mix it up and stir up any area that needs improvement. It is also a good way to avoid boredom.

6. Take constructive criticism and learn from it – let go of anything else. Constructive criticism seeks to teach you the better way, but any other negative or derogatory remarks or feelings do nothing to help you out so learn & move on.

7. Don’t be intimidated by the exercise. Don’t feel like you should know it all right away – that defeats the point of the kata. Of course you won’t have the best solution right away. We practice so we can learn and get better.

For those of you who want to continue improving your development craft here are a few kata websites my team and I have used. If you know of other sites, please share them – or come up with some of your own! Happy coding & good luck!

http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue

http://content.codersdojo.org/code-kata-catalogue/

http://codekata.pragprog.com/

http://12meses12katas.com/

C# and Manual Transmissions

 A very common (and sometimes heated) discussion among developers is: “Which is better – C# or VB.NET?” Answers that I have heard have ranged from “VB has a great ‘spell-checker’” (not kidding, that is a real reason that a developer gave to our team) to the statement that “Its the one I work with the most.” In my opinion, the best answer I have heard so far that sums it all up is: “Coding in C# makes you a better programmer.”

 

Of course, this reason is most certainly arguable and sounds very subjective, and there are lots of other good reasons, but I think that one sums it up the best. Perhaps more than half of those who would read this post will already be disgusted with me for making such a statement and might not even read further. But for those of you who like a good debate, by all means continue reading so you have a fuller context with which to either agree with me or flame me at the end! I am certainly not going to attempt to prove that C# makes better developers, but it is at the very least thought provoking. In fact, I wonder if we asked a group of developers from each side with the same basic skill level to take a short quiz, which ones would write better quality code – the VB or C# programmers? But again, that is not what this post is for.

 

So why do I think that C# makes me a better programmer? I liken it to how driving a manual transmission makes a me (and most likely anyone) a better driver. I think that manual transmission cars encourage people to be better drivers because there is much more attention to detail required throughout the entire drive time.

There is less opportunity to fall asleep at the wheel when you have to push and pull and coordinate feet and hands than when you only have to move one part of your body a very small distance.

You also have more control over the car and how it operates because there is more of you involved in driving. Your brain is forced to coordinate several things just to get the car moving forward not to mention making split second decisions.

There are also several things a manual transmission does that indicate whether or not you are doing the right thing – the sound of the engine is different, the way the car moves (or lurches) forward or backward, and even gas consumption is an indicator of how well (or poorly) you are driving. Since you are the one controlling all these things, the only way the car will perform better is if you drive better.

 

Coding in C# has done much the same things for me as driving a manual transmission. It has encouraged (sometimes forced) me to be a better coder because of the attention to details that are required.

When you are forced to think about the names you give things because the mere spelling of that name could cause problems, it is harder to “fall asleep” coding. You have to state explicitly that you are ending a coding thought or what type of variable you are getting ready to declare or whether a variable should be available for the whole project or just the class you’re working in. Sure these seem like small details, but when we are forced to be more involved in our code, we will become better developers just by having to pay closer attention to minor details that make a big difference.

C# also seems to force us to the level of thinking that asks “Are my variables declared properly? Are they initialized? Are they being used and spelled correctly? Should this method actually be private?” etc. It seems like C# starts off believing that you, the developer, know what you are doing so you should tell your code how you expect it to work instead of your program trying to intuit what you meant to code. On the flip side, VB seems to begin by thinking that you might not know what you’re doing so it will try to figure it out for you. That makes lazy developers and sloppy code.

 

I began my coding career working with VB and I appreciate how it helped me get started and how much it has improved over the past seven years that I have been working with it. However, as I have grown as a developer I have found it less and less sufficient to accomplish my given tasks and more and more cumbersome to actually use. In fact, a colleague of mine the other day said it well I think “VB stands for Verbose.” But whenever I’m in a C# project, I have no problems figuring how how something is supposed to work whether I wrote it or not and I am able to write code that looks better, works better, and is more efficient by paying attention to the details.

 

I welcome your comments. What has been your experience? Which language(s) do you prefer and why? Is there a language that has made you a better developer?

Practical Troubleshooting Advice

It may be more glamorous to develop new code, but troubleshooting is something we all will have to do at some point. While it may not be as much “fun” at times, learning to troubleshoot well can serve good purposes as well such as making us better at our craft (if we are paying attention). Here are some points of advice that I have found helpful in getting to the root of a problem in a timely manner. This list is certainly not complete, and I welcome any additional points others of you have found helpful.

 1.      Know the starting point. This is more than just having the error or bug report. You need to pay attention to the details about the problem. If you are getting an error message while debugging, don’t just skim it, read it carefully. The same goes for any error – pay attention to the information given. If the problem being reported is from a user, you will most likely have to do some detective work to figure out you true starting point. Know your users. Who is reporting the error? What were they doing when they got the error? Do as much information gathering as you can before you start troubleshooting to find and fix the problem which leads me to tip 2.

 2.      Reproduce the error. If you can reproduce the error following all the same steps the user followed you will have a lot more information to work with and you will know where to start debugging. Keep in mind in reproducing the error what the environment of the user was at the time they got the error – the steps they took,  their setup at the time of the error, and what they expect to see are important.

 3.      Take the reported problem seriously, especially if it has happened more than once. Don’t fall into the trap of “that always happens” or “that person is always saying something is wrong”. When you start thinking that way, you may possibly miss a real issue and then have to stay late to fix it! And don’t let that kind of thinking blind you to the real solution.

 4.      Don’t make assumptions. If you think something is happening but don’t have the proof for it, you are much more likely to miss the real solution to the problem – then you will have wasted time researching the wrong thing and of course the problem with remain unsolved.

 5.      If you are debugging code, be purposeful about your breakpoints. Breakpoints should be placed in logical locations and if you have done the work of tips 1-4 you should have a better idea of where it makes sense to place breakpoints. If you find yourself stepping through multiple methods and more than one class, think about whether or not you really understand the problem and if you have enough information. Revisit tip 3 – have you reproduced the error first?

 6.      Be familiar with your debugging tools. Some languages of course may not have rich debugging tools so you might have to get “creative” with things like inserting output strings or select statements to let you know what is going on throughout the process. However, don’t miss out on free tools that are out there! If you find yourself thinking there should be a tool to help you debug, go search for it. It might even be that your development environment already includes these tools but they aren’t immediately apparent so again, ask for a little help from the community.

 7.      Ask for help. If you have people on your team that are more familiar with the application, don’t spin your wheels for more than 30 minutes before asking them. They just might have some great knowledge you need. There are also great tools on the internet like Google, Stack Exchange (previously Stack Overflow),  MSDN, user groups & forums, etc. You have to have a good grasp on your problem of course so before you jump into using the internet to solve all your problems, make sure you have taken a look at the tips prior to this.

 8.      If you think you have found the answer – re-verify. Take a second look at why you think this is the solution. If it sounds like what you think is going on is an impossibility, it just might be! Are there assumptions you have made? If so, go back and prove them. Think about how to explain the solution – can you put it in simple enough terms to give an “elevator pitch”? Can you explain it to your boss and answer all the questions he will have? Also use your development environment to try to apply your solution and see if the problem goes away. This of course should only be attempted if you have been able to reproduce the problem first!

 9.      Do better! Once you have found the source of the problem, have verified it and rid yourself of assumptions, look for how the code can be improved, not just fixed. If you have time, re-factor mercilessly! If you don’t have the time, at least take the opportunity to make small improvements rather than quick patch jobs. You don’t want to have to come back to this next month and fix what you fixed!

10.  Document. I can hear the moans and groans from the other side of this blog posting, but before you fall on the floor in a pretend coma the kind of documentation I am talking about is just to detail in a work item or knowledge base somewhere what the problem was, how you found the source of the problem and what you did (or are doing) to fix it. This documentation should be specific, have enough detail to provide good context, be short enough to fit into about two paragraphs (or less. If you happen to be the one to have to go back to this later, you will be glad you took 5 minutes to document your troubleshooting! Just think how quickly all this troubleshooting would have taken if you would have had this documentation from the start!

Creativity & Asking the Right Questions

Developers need to be creative – it is a must. A developer  is more than just someone who slings code. A developer combines their coding abilities with their ability to think creatively to come up with good solutions to meet business needs in a timely fashion.

Sometimes the business may have some kind of idea of what they want, but until you, the developer, build it, they are not completely certain. As many of us know, this can lead to drastic, sometimes discouraging changes in projects. However, we cannot let that slow us down and rob us of our creative solutions to the problems the business presents. Yes, the project you are working on might get scrapped at any point in time, but rather than throw up your hands in frustration that your masterpiece was rejected, why not think about it positively – at least you are getting to spend your time coding!

The other side to that might be that the project you are working on doesn’t get scrapped but every time you provide a solution, the business comes back asking for something different or further modifications. Again, don’t let it discourage you! This is a chance to get better. If we pay attention when that kind of thing happens, we can learn to anticipate what the business wants and eventually help to lead them to the requirements determination instead of being dragged along behind only experiencing the after affects.

Part of learning to anticipate what the business wants and becoming a better developer is learning how to ask the right questions. Notice I said the right questions. It is tempting when we get discouraged (especially when we are trying to be creative) to give up and just start asking very broad questions like “what do you want here?” “what do you want this control to look like?” “what should that report look like?” Those questions are not the questions of a creative developer engaged in what they are doing and eager to give the business a solution they take pride in. Those kinds of questions are a sign of a developer who can quickly become a burden and who is called on less and less to participate in writing new code and more and more is given the menial, uninteresting, lacking in creativity, support items any “code monkey” could handle. This is not a place you want to be. Developers must maintain their creativity in order to maintain their edge.

Another mark of a creative developer is one who is always trying to find another way to do things. Whether it is learning to use a new tool to make you a more efficient coder, or coming up with a solution that might sound a bit unconventional, these traits are what help to build great companies, perhaps even your own if you are so motivated.

So what are the “right” questions? If you are a developer, you already have the ability to think  creatively about a solution, you may just need to exercise a bit of confidence and put yourself out there in order to keep the project moving forward. Back to what the “right” questions are, think about what you would expect your boss to answer in response to your questions about specifics. Think about how you would answer your questions if you were the boss. After you think about these two things, there are fewer questions left unanswered and you are able to start building your application. The right questions then become questions driven by what you already have in place such as “Is this what you’re looking for?” or questions related to specific business rules instead of just “what do I do?” kinds of questions. There are lots of pieces you can build without specific direction. Be creative! Start somewhere. Is there a risk you might get it wrong? Sure. But, even if you are way off base, you have shown initiative (that’s a word that gives your boss the warm fuzzies!) and you have given yourself the opportunity to grow as a developer, perhaps you will have even learned something new in the process. That is worth the risk!

A developer is more than a coder. Good organizations want developers, not just coders. Develop the ability to use your analytical skills with your creative thinking skills to meet the needs of the organization in a valuable way. Be a better developer.

Developer-Think

You’ve heard of group-think? The “tendency of the members of a group to yield to the desire for consensus or unanimity at the cost of considering alternative courses of action.” (http://www.businessdictionary.com/definition/group-think.html)

I think in the world of software development we have to be careful not to engage in “developer-think”. What I am calling developer-think I am going to define as the tendency of a developer or group of developers to disregard effective and real value-added design and development for the sake of what makes sense to them.

When presented with a new project, it can sometimes be challenging for the developer to stay focused on the task at hand. Mind you, I am not saying that features should never be added to the project! If the feature can be added without costing more than the value added it could be considered. However, if the developer wants to add the feature to increase the coolness factor, or to make it conform to a particular coding practice, or to just blindly do whatever the user requests, it would be better to leave it alone or at least give it some additional thought time first.

My boss actually has a very realistic point of view here “The faster you can get your project released, the less time the customer has to come back with questions or changes that will put the project behind schedule.” I think more developers should think that way! There can always be a phase 2 or 3 or whatever, but a project that is scheduled to take three weeks that turns into six months has some serious issues! Before you pass the buck, consider that it very well may be due to “developer-think”: not understanding the end user’s needs and requirements, over complicating a solution, feature creep without value added, and I’m sure we could think of more!

Some developers are very intelligent people who develop brilliant pieces of code in only a few hours. These brilliant developers, if not careful, can add complexity, and within a group who respect and admire their work, those same brilliant developers can easily lead the entire group into developing a security access application for a nuclear power plant instead of the requested simple login screen for a blog (just example).

Some developers are so focused on thinking analytically and logically they forget to think about the way the users leverage the application and in the worst cases of course, completely and purposefully disregard the users. But they don’t seem to remember that without the user, they just have an application that no one uses! I have been in places where users didn’t want to have anything to do with the developers or anyone in I.T. and as a result the projects are either very difficult to complete or hold no interest what so ever. Everyone who wants to work in that environment raise your hand! No takers? Huh. Maybe we should treat our users as a valuable asset to our work. For those developers who don’t like users, maybe its time to take this sage advice (slightly modified) “Keep your friends close, and your users closer”.

A third pitfall developers fall into is adopting a “cool” new coding practice without counting the cost. We have all read or seen something new and cool that either would make our lives easier or would be awesome to implement in our current application. Sometimes, with the right project and the right time allotment, we can actually implement some of those enhancements. However, the danger is in getting off target and making the project run a little late (or a lot late). This could lead to more time for user feature requests, open the door for visible possible enhancements, or just simply slow down the work of your team. Again, sometimes its worth it, but the cost needs to be counted first. In a good, agile shop, developers should be ready to release early, release often, and continue to keep the projects moving forward.

A good group of developers recognize these behavioral tendencies within their group and will work together to help each other stay away from these pit-falls. How can you tell if your team has succumbed to “developer-think”? Start with some of these evaluative questions: How agile is your shop? How long does it take you to release a fully tested medium-to-large sized project? What is your relationship like with your users? Do they value you or talk bad about “I.T. people” every chance they get? If those questions can be answered positively, you are probably on the right track already, but remain vigilant and keep them positive.