Software basics

Over the years I’ve learned that as a person who writes software, I tend to gravitate towards the basics. I enjoy doing fancy things, but time and time again… I come back to the basics. What’s curious is that I often observe the opposite in those around me. I’ve been around countless people who focus on the technical challenge, they focus on the hard stuff, and ultimately they struggle with the basics.

The way I interview people is tightly coupled to this theory. I could ask a candidate to solve some puzzle, use a recursive solution, describe the formal complexity of the problem and so on. Folks will usually do very well at these types of tasks. But what causes them trouble, is when I ask very basic questions. For example these types of questions are more likely to be of interest to me:

• “Let’s write a program that prints out the contents of a file.”
• “Without the aid of a fancy editor, let’s print ‘Hello world’.”
• “What’s the simplest possible regular expression to match foobar?”

The reason these insanely basic questions interest me is because usually they’re required to actually function on the job. While some candidates have much to offer in the way of math, algorithms or design - if they cannot write and ship software they will struggle .

Real life example!

I happen to be a person who likes animals, so much so that my wife and I decided to get chickens. We figured it would be a fun experience, good for the kids, and a fantastic way to get tasty eggs. The part that surprised me was the construction of the coop.

I put myself to sleep every night designing the structure in my head. How hard could it be? Eventually I found out there was a ton to learn, lots of science, and endless areas of actual engineering. The creation of the coop took much longer than I planned, and was far more fun than I expected! The end result was not too shabby:

But it wasn’t long after this that a I realized I could do better. Sure animals could live in there, but I had become a professional, I could do better. So after more bikeshedding, countless trips the hardware store, and plenty of tantrums, I wound up with this:

There was plenty of space, no fighting, room for more if we happened to want it. This thing is web scale:

There was no predator in the world would could possibly get in. I had thought of every possible contingency. Everything was accounted for. I even gave them a glorious place to scratch around and… well… be chickens all day long:

But I needed a place for them to lay eggs, and I didn’t want just any old thing. I wanted something engineered to perfection. Something with the correct size, correct tolerance, slope, it had to be perfect. These chickens would lay an egg, and it would magically roll into a perfect little slot where my little kids could get them safely and easily (without dealing with any chicken mess). The end result was again (over engineered) perfection:

But it didn’t stop there. I learned chickens like to sleep on roosts, which led to learning about boards strategically placed that would catch all their mess. It needed eventual protection from the wind, as I had tons of beautiful ventilation that would be too drafty in the winter. It was one fun problem to solve after another…

But a quick reminder what we’re talking about here…

When your job is to write software, it’s extremely important to understand your users - who will consume the software. If you build software that your users don’t want, you will not have a good time. Who were my users?

Yes, I was dealing with actual chickens here. So what happened next? I’ll tell you what happened next. Chickens do what chickens do. They dig the crap out of everything, so remember this?

Well one day I happen to notice this little problem here:

Those little buggers had completely dug away the foundation on 3 of the main supports, and were well on their way to destroying the rest. Basically what had happened was that my over engineered and over built masterpiece had it’s foundation destroyed by 8 little (relentless) chickens!

I had forgotten the basics

I was so excited to solve the fancy problems (like how to get an egg from a chickens backside directly to a place at the shoulder height of a 3 year old without getting poop on anything), I forgot to make sure the darn thing wasn’t going to fall over. It was epic fail.

So…

What are software basics?

I think the basics of writing software are as follows:

1. Setting up a personal computer suitable for development.
2. Writing code that does something useful.
3. Finding a way to test the code, even if it’s crude.
4. Generating some sort of deployable artifact from the code.
5. Deploying the artifact to a place that can run it.
6. Verifying the program is doing what it should, in the place it runs.

I appreciate that in some organizations one or more of these are not required skills. For example sometimes the person who writes code has no involvement with where it runs, or how it’s packaged. I also appreciate (and encourage) organizations having areas of discipline. Within these areas domain experts can recommend best practices, offer education, or directly handle aspects of the cycle.

Why is this such a big deal?

I find it the most useful and rewarding to work with people who are reasonably comfortable with these things (within their area of expertise of course). I think the most important reason why I feel this way is because it avoids what can otherwise result in a toxic culture. People lack basic skills for one of a few reasons:

1. They didn’t realize they needed these skills.
2. They realized they needed them, but tried and failed to achieve them.
3. They realized the importance but never made an attempt.
4. They don’t want to learn the basics because they shouldn’t need to.

It’s the last one that bothers me. For example sometimes a person can fall into a trap of feeling things like: “I’m sorry it’s not working in production, but it works fine on my laptop.” This is particularly troubling if the person has no interest in helping sort out the problem. Another common example is packaging and configuration, which are surprisingly challenging to implement well. It’s toxic to staff when people are simply annoyed they have to “deal with packaging”. My observation is that culture issues can ultimately result in a feeling of superiority, that a person is above needing to perform these basic tasks.

What’s the solution?

I personally think the solution is deeply rooted in attitude. I also firmly believe that attitude can be shaped. For example I’ve worked with lots of people fresh out of school. They have tons to offer, but are often missing one or more of the basic skills. From my experience they are eager to learn, eager to provide feedback, and optimistic about the future. This is the opposite of the ingredients required to make your culture toxic. This can also be contagious. When I hear people talking about the neat things they learned it makes me want to learn about neat things too.

The opposite problem is the one mentioned earlier. A person is lacking basic skills, and they have an attitude about it. They are frustrated by a task because they think someone else should do it, or they are frustrated by a task because they perceive (without history or context) the problem is purely caused by someone else’s incompetence.

Practically speaking the solution then comes down to two things:

1. Try to hire people who have good skills, and the right attitude. If they have awesome skills but a toxic attitude stay clear or you will pay (literally) for it later.
2. Foster a healthy culture.

How do you foster a healthy culture?

The best way to start improving the culture is to acknowledge that it’s ok to lack basic skills. People sadly will waste time over and over again because they lack basic skills. An example of this might be version control. People who understand the basics of scm can usually move much faster than the those that don’t. If people feel comfortable verbalizing this weakness, they can more likely shore it up and improve their own performance.

The next thing is to start rewarding the behavior you want to see. When people collaborate and help each other, find a way to reward them. Conversely when someone avoids collaboration don’t reward them.

The final thing (and this might surprise you), is to correlate behavior with intentions. For example if one person has started to collaborate more because they know it’s rewarded - but they don’t want to… this is extremely useful information. You can motivate people as much as you want, but it’s much more practical to motivate those who ultimately want it. Once you’ve established what your healthy culture looks like - let folks who disagree self select out of the business.

I wanted to fix the basics

Going back to the silly example of my chickens. I had completely dropped the basic need for a solid foundation. I could have easily blamed the wet Seattle weather, the sandy soil, or the chickens themselves (though that would have been to admit defeat) and basically have a bad attitude about the whole thing. But I wanted to have a good foundation. I didn’t want to blame anyone and I didn’t want someone else to fix it for me. I saw my error and I wanted to fix it. And so that’s what I did :)

So if you are lacking basic skills, try to improve them. If people around you lack basic skills, be encouraging and help them do the same. If you work with people who suffer from an attitude issue about the whole thing, do your best to set a good example, and be patient :)

The astute reader will note the eggs are not in the back chamber.

Once all of the birds have been trained to use the nesting box, I’ll replace the chips with a silicone pad, and then they’ll roll into the chamber for easy access by my kids. Always be iterating!