SOLID design
FIRST-rate tests
Virtuous code
I understand the "just get it done mindset" because there is a lot of learning, thinking, and doing behind those three simple links. It is daunting. Any developer who can sling code could become considerably better at coding and more desirable as a teammate if he would learn and apply these concepts in his daily work, but it won't happen overnight.
Jeff and I built these 3x5 cards and simple explanations on the web site, but we don't pretend that you can live on these sound bites alone. The cards tell you what the words mean, and that's a good starting point (better than winging it), but the part that matters most is the part that won't fit on a card, the part where one practices.
I like the word "practice." Wherever you are writing code today, it is practice. You are expected to apply principled development and get better, but even if you are slap-dash hacking things together, you are building your mental habits and your reputation. You could have a reputation for overdesign, poor quality, quick hacks, and spaghetti coding. You could choose a reputation for steady progress, high quality, and code that makes next week's programming easier than this week's programming.
However daunting, it's doable. If we put a little of SOLID, FIRST, or the Virtues into our work today, we begin practicing principled development. This practice will deepen our understanding of principles and retrain our mental reflexes. Eventually our reputations will improve. We'll have some iffy moments along the way, but becoming a great programmer takes time.
The exciting part is that it can be done, we can do it, and a bunch of people have spent the time to outline it for us. This is what excites me about agile in a flash, where we can build references to the works of other software developers to further build our skills. Feel free to print some of the cards, post them in your workspace, and use them to retrain your programming habits. Drop us a line to let us know how it's going.
Even simplifed, it's daunting... but even daunting, it is the way forward.
Do you mean that the first question a new team member asks about the source code shouldn't be "Did they run this through a commercial code obfuscater before they gave it to us?" (Someone near and dear to us actually ask me that once...) The guy who replaced him looked at the same program and actually thought I was playing a trick on him, you know hazing the new guy? It broke my heart to tell him that really was the source code for the project.
ReplyDeleteShutter... like a trip down the rabbit hole.
Wally:
ReplyDeleteMaybe that's the question they *should* ask if the code looks like that. Over time I'd expect that to get better, but I remember how daunting things like renaming variables were without decent tool support.
I have sympathy for underdeveloped toolsets and legacy code, but I have become a pretty solid believer in building a better next week if we want to have a better next week. I'm a testing/renaming/refactoring machine these days.