Adam.Kahtava.com / AdamDotCom

My idea of professionalism continually changes.

As an entry level developer I thought professional meant:

• talking incessantly about technology (hiding my personal life behind shop talk)
• dressing up for my cubical (wearing polyester dress pants, cotton dress shirts to work, and occasionally ties)
• focusing on things that can be proven (giving little concern to interpersonal relationships or the general untestable messiness surrounding softskills)
• writing the FASTEST CODE EVER (I was sidtracked with premature optimizations)
• I tried to be a programming machine (working 29 hours a day)
• becoming an Microsoft Most Valueable Professional (MVP)

Those ideas were skewed and I was probably running the risk of becoming a bit of a douche.

Today I think professionalism means:

• being comfortable in your own skin
• being able to delegate tasks within a team
• being an effective member of a team (not participating in gossip, back talk, or other activities that erode a team)
• being transparent
• maintaining a work / life balance
• choosing the best tool for the task

It’s funny how experience can change perspectives. I wonder what my definition of professionalism will be in five years?

Behaviour Driven Development (BDD) generally makes use of Mocks, Unit Tests, or specialized BDD Specification Frameworks like RSpec, MSpec, NSpec, JBehave, NBehave. View the list of other BDD frameworks here and read more about BDD here: A New Look at Test Driven Development.

Now, I’ve been finding Behaviour Driven Development fascinating in a geeky kind of way (kind of like functional programming languages, and programming paradigm debates), but BDD has left a gnawing uneasiness in the back of my mind - generally this mind chewing begins when I’m missing the bigger picture or when something just isn’t right. I got a chuckle out of Spolsky’s writing as he discusses specification frameworks:

the geeks … focus on things they can see in the code, rather than waiting for the users to judge. They’re programmers, so they try to automate everything in their life, and of course they try to automate the QA process. This is how you get unit testing … In order to mechanically prove that a program corresponds to some spec, the spec itself needs to be extremely detailed. In fact the spec has to define everything about the program, otherwise, nothing can be proven automatically and mechanically. Now, if the spec does define everything about how the program is going to behave, then, lo and behold, it contains all the information necessary to generate the program! And now certain geeks go off to a very dark place where they start thinking about automatically compiling specs into programs, and they start to think that they’ve just invented a way to program computers without programming.

Now, this is the software engineering equivalent of a perpetual motion machine. It’s one of those things that crackpots keep trying to do, no matter how much you tell them it could never work. - Talk at Yale: Part 1 of 3, Joel Spolsky

Hehehe… Anyhow; I need to cut this post short. My DIY Nuclear Fusion Reactor and perpetual motion machine are calling my name. Errrr… I mean, I need to continue working through the RSpec book and playing around with other specification frameworks, because there’s always value in learning something new.

Eric Evans provides this interesting commentary while he discusses refactoring targets:

When you encounter a large system that is poorly factored, where do you start? In the XP community, the answer tends to be either one of the these:

1. Just start anywhere, because it all has to be refactored.
2. Start wherever it is hurting. I’ll refactor what I need to in order to get my specific task done.

I don’t hold with either of these. The first is impracticable except in a few projects staffed entirely with top programmers. The second tends to pick around the edges, treating symptoms and ignoring the root causes, shying away from the worst tangles. - Domain Driven Design, Eric Evans

I can think of many times where developers (myself included) have really just been gold plating under the guise of refactoring, or other times when refactoring activities contributed superficial cosmetic changes while the real mess lies beneath - getting to the root of the problem requires significantly more time and work than we’re often allocated and the cosmetic changes give us a sense of motion without moving. Then there are the occasions where seemingly superficial refactorings lead to an insightful break through.

Of course Evans isn’t suggesting that we stop refactoring altogether, instead he suggests that we think about what we’re refactoring, and that we focus on the parts of our software that provide the most value - in the context of Domain Driven Design this would be our Core Domain.

In Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans shares his extensive development and consulting experience as he outlines his approach to software development and design using Domain Driven Design (DDD). Evans’ writing style is easy to read as he maintains a comfortable conversational tone while pragmatically guiding us through the many patterns and concepts that encompass DDD. However; be-warned the concepts that lie within are occasionally dense, abstract, but ultimately enlightening as Evans’ forces us to look at development from a new perspective.

It’s also fair to mention that this book has been charged as being just another patterns book, and while I can see this perspective, some of the concepts do come across as being overly abstract without clear implementations (code) to reference, but this books is much more than another patterns book. As a developer you don’t want to overlook this book, it’s an insightful snapshot into the mind of an experienced developer. From my experience the concepts and patterns surrounding Domain Driven Design frequently crop up in Service Orientation, MVC/MVP structured Web Applications, Object Orientation, Test Driven Development, Model Driven Development, and other modern staticly typed best practices. If you do find yourself grasping for more concrete implementations then you’ll want to read Jimmy Nilsson’s Applying Domain-Driven Design and Patterns: With Examples in C# and .NET book too - Nilsson’s book provides many code examples while directly referencing Evan’s text.

I highly recommend this book, it’s a great reference to have alongside Steve McConnell’s Code Complete, Facts and Fallacies of Software Engineering by Robert Glass, and the Martin Fowler blessed books too.

A group of us reread this book as part of The Calgary Book Club. View my review on Amazon.

I ran my first half marathon this past weekend. Finding training resources online was difficult so I’m passing on the advice that I found useful.

How to train for a half marathon:

• Ensure you can maintain 30 minutes of moderate running at least a month before your running date (this is the most important step)
• One month before your race, run 18 kms (6 easy, 6 moderate, 6 hard, don’t worry about how long it takes)
• 7 days later run 20 kms
• 7 days later run for 90 minutes hard
• 7 days later run for 60 minutes at a moderate pace
• 1 day before the race run for 20 minutes at an easy pace

The week before the race you should be feeling lazy, lethargic and ready for the race - you’ve tapered correctly. Tapering leads to improvements in running economy and muscle strength. Learn more here Tapering For a Marathon.

Other tips I picked up:

• If you’re planing on taking gels or sports drinks during the race then make sure to take them while training
• Don’t mix sports drinks and gels - take one or the other or you’ll get end up getting sick (like me)
• Bring Advil or Tylenol with you
• Avoid fiber foods 2 days before the race (you don’t want to visit the portables)
• Add more carbs and salt to your meals the week of the race
• Have your last big meal 10 hours before the race
• Have your breakfast 2-3 hours before the race

Running with 3000+ people for the first 16 kms was an amazing experience, after the 18 km mark I was questioning my sanity, and when it was over all the race participants were on top of the world. I highly recommend doing a half or full marathon. I raised some money for Team Diabetes and managed to finished under 2 hours.  Next year I’m doing the full. Look me up in the 2009 HSBC Calgary Half Marathon Results.