A few years ago, I hired a new developer. This developer was what I considered green in all aspects of software development, meaning that he had no experience in writing software. I'm pretty good at spotting potential, so I took a shot on hiring him. It's turned out pretty well.
I've been thinking lately about how to advance his skillset even further. I started him off using the Karate Kid mode of working for me on some projects. I use the “wax on/wax off” type of learning process. You know: repetitive task-based work. He's gotten very good at this and now it's time to advance his skills to another level. I got to thinking about some of the stories/concepts that have helped me over the years and here they are for you, too.
Write It Down
One of the most important lessons I learned early in my career was to actively journal my work. For the last 20+ years I've used a combination of Mead and Moleskin journals to keep track of my meeting notes, coding experiments, and work efforts. Keeping notes has been a great mechanism for locking knowledge into my grey matter, as well as being able to recreate in my mind what I was thinking when working on a project.
One-Page Requirements
Early in my consulting career I worked with a mentor named Jerry Whiting. Jerry owned a company called Azalea Software that sold barcode fonts. From time to time, Jerry received requests for work that he offloaded to my fledgling consultancy.
Jerry had a basic rule: If it cannot be described on one page, it cannot be done.
I adopted that concept in my consultancy and have used it ever since. Requiring a written description places a burden on the requestor to think about what they're asking for. Don't get this wrong, this is not the entirety of the documentation but it sure helps establish a well thought-out start to a project.
Always Run Your Code AT LEAST ONCE!
If you've coded for more than five minutes, you know what happens when you violate this rule. Here. Let me refresh your memory:
“I'm going to make this quick change and push it out to the server. Hold on–Here we go!” (In Texas this is where we say," Hold my beer.")
BOOM ! SYSTEM FAILURE EXTREME!
You then spend the rest of the day kicking yourself for violating that most basic of rules. Always run that code AT LEAST ONCE.
Comment Your Code
This concept is very important. Today's “in vogue” idea on comments is that they are unnecessary. I say BULL! I leave comments in code so that I better understand the intent of the code I'm looking at. These comments aren't useful in the days immediately following the creation of the code but they're very valuable months and sometimes years later. And they're priceless when someone else comes along and wants to make a little change.
Three Basic Coding Tenants
Early in my programming education, I was given a set of concepts that has been locked into my cerebral cortex for many years now. They may seem simple and obvious but also they serve the purpose of clarifying rudimentary principles that all programmers need to understand.
In all programs (regardless of language), there are three basic ways that code is run:
- Code is run one line at a time.
- Code can branch and run other lines of code one line at a time.
- Code can loop and run lines of code in a loop.
Now take a minute and digest this simple and easy set of concepts. They make a lot of sense don't they?
What We Really Do for a Living
For many years, I've been describing what do for a living in a simple set of terms:
- We write data.
- We read data.
- We update data.
- We delete data.
At some point, someone codified this in a simple acronym: CRUD (Create, Read, Update, and Delete).
Sharpen Your Axe
“My apprentice, come here and let me tell you the tale of the two woodsmen,” said the master. “Two woodsmen enter the forest to harvest the bounty of the woods. Each woodsman was of equal height, strength, and skill, and possessed axes crafted by the realm's most honored blacksmiths. Every hour, the youngest of the woodsman left the clearing for a 10-minute break. After a full day's work both woodsmen returned home to rest before another day's harvest.”
The master turned to his prot�g� and asked, “My apprentice, which woodsman do you believe cut more wood?”
Proudly, the young apprentice said: “That's easy! The one who took no breaks obviously cut more wood”
The master laughed out loud at the apprentice's quick retort. “You have much to learn, my young apprentice. You see, the woodsman who took time to sharpen his axe was able to cut more wood.”
This parable is one of my favorite stories. It encapsulates one of the most important concepts for pursuing software development as a profession. Being a good software developer requires you to constantly sharpen your axe. When dealing with tech, this means reading articles, attending conferences, attending user groups, giving talks at user groups, watching videos, and experimenting with new tools and techniques. All of these items are methods for keeping that axe sharp.
And Grasshopper, because you bought this magazine, your axe is just a little bit sharper
