I recently saw a blog post by Scott Hanselman that got me thinking about what it means to be a developer these days. That post was inspired by a plea from a young reader to resolve something of an identity crisis about whether they were “really a developer or just a good googler”. Hanselman was very respectful to the poster, I thought. He talked about how we all feel unworthy sometimes and suggested a skill-building regime of Code Katas, Project Euler problems and, well, programming without googling.
With all due respect to Hanselman, though, I’d like to suggest an alternative view. While following his recommendations would probably improve our coding fundamentals, these skills need to be used regularly to be maintained. If they aren’t often used in a practical setting, their main effect would probably be to make us feel more secure in our identities as programmers.
Why couldn’t we just say that, like most other professions, the regular, meat-and-potatoes work of a developer has significantly changed over time? We stand on the shoulders of giants, and we live in a commercial world that emphasizes efficiency. In such an environment, spending the extra time to re-invent the wheel whenever we want to design the next model of a Toyota sedan strikes me as rather counter-productive.
Don’t get me wrong. A solid understanding of development principles, technologies and syntax is certainly still crucial to the modern software developer. Without those, it isn’t possible to tell good code from bad code, or to correctly identify which blocks of code are most appropriate for tackling a given project. Using a sophisticated tool-kit that includes code samples, software development becomes less about individually placing each brick and more about selecting, trimming and placing more complex pre-fabricated materials.
It’s also important to be judicious about when you use existing code. Ultimately, developers are problem-solvers. When you present us with a problem, we break it into smaller pieces, and then look for the most efficient ways to address our needs. Often, existing software or code can fulfill at least some of those needs. If we make use of existing tech, we can then work out how the different modules might work together and get cracking on customizing, integrating and wrapping the various components into an elegant and coherent solution. The less time we spend building from scratch, the more time we have to integrate, polish and test.
You need to understand code to edit and customize it, but it won’t be surprising if our low-level skills start to fade from lack of use. What we are seeing, I think, is a global shift from low-level to high-level. Today’s development is often more conceptual than constructional, and I don’t think that change is necessarily a bad thing.
With all of that in mind, I think Hanselman’s suggestions about going back to basics are a great path to self-improvement that doesn’t necessarily sit comfortably with either this trend or a commercial imperative. Actually, they remind me of a lot of other admirable extra-curricular pursuits. Some people lovingly restore vintage cars in their spare time; others pursue physical perfection through diet and exercise; still others are enthusiasts who love using older technology like CB radios.
Honing your coding fundamentals is laudable, and understanding is crucial for good development, even when making heavy use of samples. Maybe, though, Code Katas are most at home as part of an after-hours self-improvement challenge.