Disclaimer:
These are my unfinished, unpolished thoughts, bound to be revised and rethought. I publish them in the hope that they might spark your imagination and make you think, if only a little.
Sparks & motivation
This talk came about because a few things I’ve read and heard recently (particularly from Andy Hunt — see the link at the end) have resonated strongly with my own feelings that the software development community is, perhaps unknowingly, ignoring a few core skills. We tend to focus so much energy on creating, teaching, and learning new tools and methods that I think we may be losing focus on the other things that make us good software developers, namely our problem solving and design skills.
It’s not that tools are a bad thing — they are very important. But, does using Photoshop make me a designer? Does owning a wrench make you a plumber? So, then, neither does opening up Vi or starting up Eclipse really make anyone a software developer.
As Andy Hunt said in Pragmatic Podcasts: Andy Hunt on Pragmatic Wetware, “Software is developed in your head, and in the heads of your team members.”
Problem solving
I had a particularly interesting interview a short while ago. The first question I was asked, after introductions and obligatory handshakes, was to show how many snowflakes had fallen on Earth since the beginning of time. A dry-erase board and marker were the tools provided. At first their request sounded a bit odd, and it was a bit intimidating, but in retrospect it makes plenty of sense. A lot of what we do as software developers is break large, impossible-sounding problems down into smaller bits that are easier to understand and solve. Reassemble those pieces correctly and you’ll also solve the larger problem.
Tools or preferred development methodologies might have some impact on how you approach the task, but I think we’d find more similarities than differences. Consider that nearly all programming languages provide facilities for managing these smaller pieces. Whether they’re subroutines, functions, macros, or our favorites from OO (classes, methods, etc.), their purpose is to help you break things down into manageable chunks. Modern IDEs make it easy to manage large groups of files and dependencies.
Applied
It takes time to load up the context of a problem into your brain. And it only takes one disruption of the wrong type to blow it. To help the design process, I tend to:
- Talk through it with someone else, possibly away from our desks to avoid interruption.
- Put on headphones if I’m working alone in a distracting environment.
- Take short breaks to let ideas settle and when you hit particularly troublesome parts.
- Keep it simple. Resist the temptation to make things more complicated than they really need to be. Agile’s YAGNI concept falls under this idea, but is only one example.
Also, any code you don’t have to write yourself decreases the amount of information you have to load into your brain. Use libraries from CPAN, Ruby Forge, or wherever you prefer that have already been written and tested.
Design
Software developers actually do a lot of design work — we follow the same process as nearly any other designer:
- Analyze the problem with the customer
- Take the intended audience into account
- Create a solution
So, there is a lot of creativity involved. This is one big reason why I really enjoy being a software developer.
One interesting thing I’ve noticed is that we software developers don’t really test the usability of our code. I would love to see someone put together a serious usability test of a few different languages or libraries — I think we would learn a lot about ourselves and put some concrete evidence behind coding standards and best practices.
Applied
Differences of opinion are okay. In fact, they’re a major contributor to success in any design task. Agile development encourages this through pair programming.
A lot of the time, we and our fellow team members are the most significant users of the classes and modules we write. At the very least, it’s going to be another developer using it. Be kind to yourself and the other users — put some serious thought into how users will interact with your code. Maybe even do usability testing.
For more…
Pragmatic Thinking and Learning by Andy Hunt