Beautiful Code

The code which is understandable, maintainable, robust, decoupled and neat can be called as beautiful code. Many may definitely argue with me, for the justification of the definition. The bigger questions here is not what the definition of Beautiful Code, it’s about how do we learn to take our code in direction of Beautiful Code.

A simple human nature is when we understand a concept we embrace it without conflict. For instance every programmer understands conditional “if“. So when it is in your code you don’t feel alienated but when you find it spread all over the code block you feel so frustrated. We may conclude a stage of beautiful code looks like, code must be easy to understand and easy to change. See I mentioned the word easy.

Here are few tactics to sharpen our skills, understand our code and embrace to change.

  1. Learn & Practice Test Driven Development period
  2. Create the written one page goal of beautiful code standard your team considers to be good enough. Thus creating clarity in achievable goal.
  3. Make a list of coding style changes you want to see in your teams code e.g: No single letter variable or Code should read like English. Compile a list of 10 items. You can use any method to conclude but make sure everyone contributes to the list.
  4. Learn new technical skills every week. This could be as simple as using a keyboard shortcuts, implementing new language feature, or implementing design patterns. The key is that it must go into production code. Make it a part of daily routine.
  5. Give a small token of appreciation on daily achivements thus creating a growth culture. It could be as simple as clapping in a stand up meeting for a team member.

Happy Coding!

Go Code Refactoring

Code refactoring is must have skills in our tool box.

Wikipedia gives below mentioned definition

Code refactoring is the process of restructuring existing computer code without changing its external behavior.

There is a classic book on Refactoring by Martin Fowler.

The topic is vast when there is a whole book written. I am trying to mention 3 easy steps we took in our recent project to get started:

  1. Renaming variables and method names. In all the modern IDE there is a feature of renaming the variables and method names. It’s safe because it will not break your compilation and still guarantee your code will be read better. The code is better from the time you do your first rename.
  2. Delete all commented code. It is self-explanatory. An excuse given is I may need the code in future. You can get your code back by using source control system, So use source control system to archive your code. Thus reducing the lines of code you don’t have to browse through your code at all.
  3. Extract method is one of the handy ways when your method starts growing huge. If we us the help of modern IDE it has the feature to do it safely. We have to be careful but IDE will help us in a great extent. This technique will also help in reading your code better.

Happy Refactoring!

Past Decade blogs

I wanted to blog since long back may be around 2007, as I had many experience to share. It is very hard to start something which is not in your comfort zone, I procrastinated to blog. The discomfort was my poor skills in English grammar and my spelling mistake. But finally I pushed myself and started using my commute time for blogging using WordPress for android. So I generally collect the content while travelling and format it on my Laptop.

Now, since I am pumped up as I shared it with few of my friends. I am motivated to take a faith of leap and do something extreme with blog posting. I am planning to write 3 blogs per month for my past whole decade. Now there may be lot of questions but my idea here is I had many experience in my life’s archives.

I will try to explain few of the tactics I will be using during this process:

  1. I will go through my email archives.
  2. Chat with my old colleagues.
  3. Share about my weekend projects.
  4. Write about my trainings and meetings.
  5. Client side experience.
  6. Check my twitter feed.

This seems to be a huge commitment but I believe it’s worth the shot. Now, let’s create a Backlog for this project by doing some math

  • I am targeting 36 blogs for a year which is till October 2012.
  • Half hour for each blog post comes to a total of 18 hours.
  • This is roughly 3 working days or rather 1.5 weekends.
  • So now my big Goal looks manageable for at least 3 days.

The work has not yet started still I feel well in control. The key here is time boxing,  a concept from agile development process. My current velocity is 12 blogs per day or 6 blogs half day. I might also need to do retrospection after 3 days of work. The big goal is to hit 10 years from now that is till June 2004 when I started my career. So, the total blog count is 333 (Nelson in cricket) and 36 targeted above is the sub set if 333.

I will complete my decade of work experience in June 2014.

Happy blogging!