Archive by Author

Coding Kata: Practice Time for Programmers

4 Sep

Before I came to Fortigent, I spent two decades as a musician and educator.  Training for a career in music often starts


in elementary school.  I joined the school band, learned to read music and played an instrument.  I continued on through middle and high school.  I learned to practice, to perform in front of an audience, and to listen to music.  I continued through college, learning music history, music theory, and to teach music.  I started reading music educator’s magazines and blogs.  In my senior year, I spent months student teaching in a classroom with a master teacher, practicing everything I’d learned.  By the time I got to my own classroom, I didn’t feel completely prepared, but I’d had real, hands-on experience in a professional setting.


So how did I get from teaching music to being a software engineer at Fortigent?  I started programming text-based adventures in BASIC on my Commodore 64 as soon as I was tall enough to reach the programming manuals on my father’s bookshelf.  For years, I programmed little games or small applications, but didn’t actually decide to get a formal technical education until I was on maternity leave from teaching and had some time.

Going from music to programming was a bit of a shock.  I took classes, talked to my professors, did programming projects, and read blogs about software engineering.  This college experience was really different from the first, however.  ProjectThe two things that I really missed in the computer science degree were practice and that final student teaching-like internship.  I found myself a part-time, volunteer position with a videogame company as I entered my final stretch of college classes.  I learned a lot about teamwork, source control, and how to work and navigate in a large business application.  The other programmers were helpful, but I was still lacking the one-on-one experience that I’d gotten as a student teacher.  I also had not learned to practice.  At the time, I thought of the programming projects as practice, but those projects were nothing like the practice I had done as a musician.  There was no repetitive improvement or long term reflection on a set of exercises.

Soon after I got to Fortigent, someone gave me Bob Martin’s (usually known as Uncle Bob) book The Clean Coder.  As I read through the book, the chapter on practicing really hit home.  Uncle Bob wrote about how many software engineers never really learn to practice.  How can someone be a good programmer if they don’t know how to practice and don’t have a master teacher working closely with them?  “Perhaps the best way to acquire ‘Design Sense’ is to find someone who has it, put your fingers on top of theirs, put your eyeballs right behind theirs, and follow along as they design something.”  (  While I’ve been doing a little bit of this at work (the programmers here at Fortigent don’t seem at all shy about me standing over their shoulder asking questions while they program), this is not the same as programming what they are programming.

About a decade ago, programmers started talking about practicing.  Dave Thomas mentions sitting at his son’s karate lesson watching the children perform kata.  The students followed the movements of a master teacher and would perform these same movements at home as practice.  As Dave Thomas was watching the students learn their kata, he had been experimenting with a small coding exercise, doing it several different ways, trying to make it more efficient.  It hit him that a small exercise such as what he was doing was very similar to the practice movements the students were performing. ( Just as in Japanese martial arts kata, the purpose of a coding kata is to practice.  A coding kata is a small set of exercises that encourage trying out different combinations of coding techniques in a practice environment.

To me this feels like when I would go through a piece of music with my college trumpet teacher – he would play a line of music and I would play it back to him trying to get the same sound, inflections, and tone as he did.  As a software engineer, I have been going through the kata of the software engineering community, trying to get a feel for good programming.  Sometimes I will try an exercise on my own several times, seeing if I can improve upon my code each time.  Other times I will find a video of someone else doing the kata, so I can learn from how they program.

powerpointAt The Rockville .NET Group (RockNug) meeting on September 11, 2013, I will be sharing part of one kata I’ve found particularly useful, Roy Osherove’s String Calculator Kata.  I found it to be a great introduction to Test Driven Development.  I’ve watched several people’s online videos of the kata being done in several languages, using several unit testing frameworks.  I felt that his kata imparted to me the idea of working incrementally and solving problems as simply as possible.  As I worked through this kata, I read comments left by other readers, which really gave a sense of getting to hear what people were thinking while doing the kata.


I’ve been developing a sense of how to write tests before code, I’ve been learning to work incrementally, I’ve been learning to refactor my code, and I’ve been striving to think of simpler solutions to problems I encounter.  I’ve also been learning technology basics such as how to use a testing framework, keyboard shortcuts, and all the wonders of Resharper.  I have found several good resources and kata about refactoring legacy code, and this is where I plan to focus next.  I believe this will provide a good starting point for testing and refactoring legacy code that I will be working with shortly.

Reflections on Custom Report Development

3 Jun

As a junior software developer in my first few months out of school, it’s exciting for me that a product that I worked on has reached the end client.  Creating a custom report page has been a long process, but a great experience.

A month ago, I was assigned the development of a new report page, the Snapshot Portfolio page.  It was to be a quick overview of a portfolio, showing the portfolio’s activity, rate returns, allocations, and growth information.  I was provided with a mockup and a meeting to review the requirements of the page.


For the next two weeks, I coded charts and tables to match the mock up as closely as I could.  I tested the new page on portfolios spanning several companies.  On Friday that week, I prepared several reports showing the new page and demonstrated my work to members of the development and consulting teams.  Reactions to the initial version of the new page were very positive, and helpful feedback, suggestions, and enhancement requests resulted from the demo.  Even though co-workers had hinted to me that a mockup is only a stepping off point of any new page, I admit to being surprised at how many changes were requested after I’d matched the mockup so closely.


One of the most challenging elements in the development of this page was the creation and fine tuning of the growth chart.  Although a simple chart in excel, coding the component (which included two charts each on two axes, three sets of labels, and a legend) proved to be a challenge.  In the progression of the chart, the color scheme was changed several times, the bar styles were changed, the axis labels were changed, and at one point the chart values were even displayed normalized!  Throughout this process, I had my fingers crossed that my next color combination would be the winning one.  Frustrating though it sometimes was to have my early color choices called psychedelic, in the end, the final color choices looked great.



Over the course of the next week, I completed the requests for enhancements and changes I’d gotten at the demo and from later emails from the consulting department.  The page was ready to be deployed for Advisor testing.

Once deployed, we started getting instant feedback from advisors.  Although a “snapshot” page was originally requested, advisors saw the page’s potential to display more customized information to be consumed at a glance.  Requests started pouring in for more options.  As well as showing high level investment segments, advisors wanted to be able to show more detailed segments.  They also wanted to control the number of benchmarks displayed.  One thing that upset me during this portion of the project was receiving a request that I just could not implement.  One firm wanted some very large asset names displayed and I found I physically could not fit the long names in addition to the other required page information.  I however, managed to squeeze several extra characters in.

When all of these changes were implemented, the final page looked like this:

final page

Although I am now working on other projects and the page has been available for several weeks, it continues to change and grow.  I recently implemented a parameter that will allow an advisor to hide the allocation chart.  Since finishing this page, I have worked on several more page customizations.  Some of the page customizations have involved me editing existing pages, which always includes the risk of breaking pages that are currently working.  I think if the practice of making customized and customizable pages is to continue we will need to make changes to how our pages are created.  It feels like there is a lot of risk involved in making changes to a heavily used page and that to mitigate this risk I have needed to duplicate a lot of code.  I feel like the recent parameterization of the pages is a great step in keeping customizable pages a viable offering.  I imagine as more innovations make our report engine even more flexible,  I will soon be working on many more customizable pages and custom enhancements to current pages.