Code katas are simple exercises that are meant
to be repeated. They are great for learning a new language or tool. The
goal is to learn something, not to complete them. In fact, if you don't
finish a kata that is perfectly normal as long as you take something
Its navie to actually think this but if a system has been in
production for say five years, expecting to reproduce it in five
weeks is not possible. You may be able to get 80% of the core
functionality done, but the …
I a certainly not a skilled or expert front end developer. While I'm
more than capable of creating pages I lack any design magic to make them
look half decent. Despite this one area where improvement can be made is
in my markup itself.
Some of the best lessons you can learn are from failure. I figured a
series on mistakes I've made in the past would highlight where I went
wrong and more importantly what to remember going forward. These real
life examples vary from my early days of programming all the way …
Try and define legacy code. Working Effectively With Legacy
states it is simply code with no tests. This is an almost perfect
definition, however it is quite easy to have code that is covered by
automated tests, yet is still considered to be legacy. Poor quality, or
missing test …
Spikes are one of the best ways to aid the design of software. In some
cases spike solutions can open more questions than they solve. The use
of a technique known as Best of Breed can assist when this arises.
Rather than producing a single spike, produce several. Either
For a long time my work life balance has gone through phases. Some weeks
I would spend hours after work writing code. This would exceed to well
beyond midnight in some cases. This phase was not sustainable but it
appeared to be the norm.
A recent post about architecture from Uncle
got me thinking and talking about a typical day in the life of a
developer. It's well worth a read. In fact at the time of writing this
reply there are 347 retweets and 288 likes - of which I was one of …
I've programmed many games - each one was special in its own way. One in
particular stands out early in my university studies, a top down
shooter. It was not graphics, gameplay, or sound that made it stand out
however. It was the lesson it taught me about software development.
Production code is dirty. Dirty may be the wrong word however. Complex
could be more suitable. Unlike code that is not yet in production, it is
weathered, proven, and full of edge cases including numerous bug fixes.
After some time this build up of additions can cause the code to …
Tasking is core part of XP, Kanban, Scrum and other software development
methodologies. It is required when more than one developer is working on
a feature. I consider it to be the most wasteful part of the development
process as practiced in the mainstream.
Striving for consistency within a codebase is a good thing. I'm very
much someone who believes in applying a consistent formatting style,
patterns and practices. However there are two sides to this view.
One colleague used to hate different apps that used different
frameworks, styles and conventions. This is a …
I'm a fan of pair programming. I owe a lot of this practice to my
improvement early on in my career. I define pair programming as two
developers working on a task using one or more machines at the same
I have had some excellent pair programming sessions. I …