Between The Code

thoughts on coding and everything in between

Tag Archives: craftsmanship

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/

Advertisements

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?

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.