October 31, 2006

"I could be so much better"

It seems to have become a common phenomenon to explain how much more you could do, how much better results you could produce, how much more talent you could expose... if you were only given the chance.

Stop whining and get to work. I'm not doubting you at all - I've struggled all my work life to carve myself a role that allows me to fully leverage my personal talents and to work the way I want to. I think I've come pretty close now, but it has taken several intermediate positions, some political work and most of all, swift, well-planned and courageous moves - including giving up or turning down a few management positions.

Proper casting - that is, the matching of people's talent and the requirements of different roles - is a key element of an organization's long-term health. Your manager should do everything he/she can to put your abilities into use and maximize your motivation. On the other hand, you are the specialist when it comes to your dream role, and it's just possible that casting isn't your manager's forté either. You are the one who should actively pursue your ideal job.

If you've done everything within your power to lobby your ascension to the dream role where you'd actually be at your best but still can't reach it, you have exactly two choices: Swallow your pride and become a content average worker - or change the scenery. I recommend the latter, as life is a bit short to be wasted. But do remember the realities: It's not like the next company were much more likely to automatically cast you correctly just based on your interview. Be sure to work hard enough so that you really know you've done everything you can.

Much of today's work life is total chaos in a positive way. Most of the things you want are available for grabs, but often you must stretch yourself - not just once, but for years. Selfish gain-seeking won't work for long, but balanced and responsible plans tend to execute more smoothly. Spineless worms will end up doing what they're given - active participants in their social environments tend to end up in the chooser role. Get out there and be the change agent!

Posted by Jouni Heikniemi at 09:15 PM | Comments (2) | General

October 29, 2006

Why CS students should do TDD

If you are a Computer Science student, take heed:

When you're about to take on an assignment that takes more than two hours to implement, do Test-Driven Development. (that doesn't mean you couldn't use TDD in smaller assignments if you feel like it)

First of all, what is TDD? It is a philosophy that encourages you to create runnable tests before you write code that they test. Of course, the tests won't even compile, but the mere act of writing them forces you to think about your code and its interface - "How would I go about using this B-tree class I'm about to implement?".

TDD documents often refer to sophisticated unit testing frameworks to support automated testing, but forget about that for now. Focus on the testing. Write console applications that do stuff like if (MyTools.Sum(3, 5) != 8) throw new Exception("Sum is incorrect.") for all your relevant methods. If you write more complex stuff, such as a linked list, write tests that insert some items and then read them out, verifying that everything works as you expected.

Now, why?

  • You're about to write code that you're unfamiliar with. To be honest, it is likely you have never written an application of this size with this technology before.
  • You have a desire to get rid of the application as soon as possible. This means that you, probably a reasonably inexperienced programmer, will make many mistakes in a hurry. It also means that every uncovered bug will slow you down seriously.
  • University-level assignments in particular often require an academic pedantic attitude. Such attention to detail is often best left to a computer. You couldn't check for all the details anyway.
  • If you're implementing your first data structure / algorithm / whatever, it is likely that you're partially copying your code out of examples and text books. Doing that, you often skip a critical step in understanding. That slip won't save you time, trust me. Doing TDD will force you to understand what you're coding, which will save great amounts of time at a later phase.
  • Since just writing tests will be somewhat boring (at first), TDD will encourage you to test the application more often. And passing even a minimal test suite will encourage you to code more.
  • Unit tests tend to pinpoint errors rather exactly (at least compared to C++ segfaults and other hard-to-debug exceptions).
  • Assignments often require documentation and testing (eww!). It's easier and considerably less frustrating a task when done during the coding. And saves a lot of late-deadline hassle, by the way.
  • Good unit tests score well.

So: Write a small chunk tests, then write (or copy/paste) code. Fix the code until the test passes. Then repeat until you're done. If you discover bugs not uncovered by your tests, write a test that fails because of the bug before fixing the bug. That way you'll never fall for that particular trap again.

Most of the reasons above can be used to argue for unit testing in professional programming as well. However, students should consider TDD doubly because: a) TDD saves lots of personal time and students suffer from no corporate friction to offset the savings, b) they are generally unfamiliar with what they're doing and c) they lack the general experience required to guess the location of errors, thus resorting to time-consuming WriteLine-style debugging.

If you try it and like it, learn to use a proper testing framework. It's easy when you already have the TDD mindset ready, and any automated testing environment will make your coding yet easier - even when you move up to professional coding one day. And yeah, it looks good on your CV. And we need more programmers that have been trained to think about testing and their mistakes right from day one.

Posted by Jouni Heikniemi at 10:40 PM | Comments (0) | Misc. programming

Flux

As the fall progresses, some changes are beginning to affect my life. Finally, one might say! The most important of them is the fact that I'm slowly getting into the job I'm supposed to do. I've been the Chief Software Architect at our company for half a year now, but much of what I've been doing has still been linked with the past and the strains of everyday projects, thus leaving much of the real company-wide architecture planning into a side role.

That, I hope, is now changing in a more permanent way. The project tide is slowly turning away from me, and my focus - as well as the focus of my closest colleague, Sami - will now gradually shift more fully to the more generic productivity and technology issues within the company. What does this mean? In practice, we have three focus areas:

  • Company-wide technology strategy and product architectures
  • Discovering, supporting and teaching best practices in the company's current implementation projects
  • Software development processes, agile methods in particular

While all of this has been in our agenda for the last half a year or so, the forthcoming changes should provide us time to actually realize some of the thoughts we've come up this far. We expect it to be both fun and productive.

On another note, my fiancee Riikka is starting her new job tomorrow as a System Designer in TNS Gallup, a Finnish branch of TNS Global. All of this is new enough not to have made its way even onto her home pages ;-)

Flux indeed!

Posted by Jouni Heikniemi at 08:47 AM | Comments (3) | General