Codefol.io

A few months ago, a CTO at a conference asked me, “how do you encourage a blogging culture at your company?” I’m a reasonable fellow to ask. Not only have I written a huge amount for AppFolio’s engineering blog and encouraged other AppFolio engineers to do so, I also did something similar at OnLive with even more success. By “more success” I don’t mean the blog was more popular (it wasn’t,) but that about half the posts were written by engineers other than me, which is the hard part. Writing a lot is all well and good. Getting other people to write a lot is an accomplishment.

The hard part isn’t getting a few posts started. The hard part is blogging with any regularity. And it is hard. But there are some things you can do to make it easier.

career

I’ve been fortunate to work in DevOps and with great Ops folks in my career, including doing enough of that work to get a feel for it. The tools are fun and it’s nice to be able to do basic tasks, but the incredible, invaluable thing was just watching how experienced OpsFolk responded to different events.

It’s not just the smooth, immediate way that they handle warnings and outages, though that is impressive. It’s also their basic understanding that new features, even features meant for robustness and resilience, are basically trouble. It’s not that an undisturbed system will necessarily keep working… But a system you disturb will invariably develop problems of some kind. Deployments tend to break things, and deploy-free weeks like holidays tend to be downtime-free.

But the important part isn’t the fact that they’re right. The important part is seeing a completely different attitude toward the software we write. Our way is valid for what we do, their way is valid for what they do, but it gives us completely different principles (that is, “unwritten rules that underlie everything we say and do”) about software.

Just like “everybody else has an accent,” it feels like everybody else has a mindset - our mindset is just “the right thing.” But seriously, what are the unwritten rules in software development?

And it’s not even just Ops or DevOps. There are a lot of mindsets in the world, and developers are just one of many.

If we’re the fish in the bowl, what does the water look like?

And what would the opposite look like? If software developers get our superpowers from this mindset, what superpowers do other folks get from very different mindsets?

favourite

Steve Martin has a great autobiography about his comedy career called “Born Standing Up.” Like many comedians, he’s a smart guy and has great advice about practice and improvement. You can get most of the same thing from this interview, if you take time to read it.

He talks a lot about his early comedy and how it just doesn’t quite work (he’s right, it doesn’t - go back and watch.) He has some really interesting new ideas, but he doesn’t yet understand the important old ideas. He wasn’t good at physical comedy yet, his timing was off, he was clever but not consistent. He knew it wasn’t working and he wanted to say, “but wait, let me explain my theory!”

I’m a software engineer. Is it just me, or are there an awful lot of us whose pet theories don’t quite work, and when we’re called on it we say the same thing?

Until you have the fundamentals right, your new ideas mostly don’t work.

technique

It’s fun to write about different ways to practice coding. But “how to practice” only gets you so far - at some point you have to actually do the practice.

There are a lot of neat programming exercises in the world. This is an example of one I call a “coding study”, and I think it fits my definition of a good exercise.

A coding study is like an artist’s life study, but for code. You’d normally pick your own design. But this is meant as a simple introduction, so I’ll suggest a little more than usual.

The theme today: ivy on a window. I’ll refer to the picture below repeatedly in this post - have a look, then scroll back here as needed or save a copy locally.

One hard thing about exercises is that you need different habits for them than for production code: you’re not trying to write polished, production code. Instead, you’re trying to learn as fast as possible. So at the end, I’ll talk about some intentionally weird things I do in this code and why.

technique codingstudy favourite

(You can see the five-minute video version of this post on YouTube.)

I’m an old-school programmer. I’ve been doing this for 30 years. I worked for over a decade in C and C++, often on operating systems and device drivers.

If you ask, “how do I get better at programming,” I’m supposed to tell you:

• you should learn C (or C++ or assembly) — a language that works like the computer hardware does
• you should write code that directly messes with the hardware, preferably an operating system
• you need to learn the highest-performance languages because otherwise what will you do if your code is too slow?

These are all terrible advice.

And they’re all variations on a different, wrong idea: that you should learn about computers and software past all the abstractions, “all the way to the bottom.”

That’s also terrible advice. Let me tell you why.

technique favourite

Here’s a difficulty of coding exercises: many teach you nothing after the first time you do them. So you have to find new ones if you want to learn.

It’s the same reason you don’t learn much by just learning all the “gotcha” job interview questions - there may be a secret to it (advance two counters until they meet! fourteen per floor minus one per drop!) but it’s not a very interesting secret, or a secret you’ll use much later.

Good secrets usually show up in packs, not alone.

Here’s a “pack secret” like that - just the first of a big group: “a good exercise is one you can do over and over and get something useful out of it each time.” Here’s one of its pack: “good exercises are never just about the specific situation.” And another: “good exercises work even if you switch them up a little.”

technique

There is a technique of writing software - that is, actually writing code. It’s a distinct, separate skill from creating or analysing algorithms, or doing up-front design or agile project planning. It’s also a distinct skill from any particular library or language or paradigm (like functional, OO, etc.)

It’s not really taught much. It’s pretty hard to teach directly.

I believe strongly that you need the right kind of practice - careful, mindful practice. I’m writing a book about that, and writing related principles on my blog. I’ve found some techniques that work, and I’d love to share them with you. You can also sign up for my email list to get an email class about this. And I have a topics page about it.

Today’s principles: practice with a single idea in mind; practice with a time limit.

technique

In most projects, the first system built is barely usable….Hence plan to throw one away; you will, anyhow. - “Fred Brooks, The Mythical Man-Month”

Sometimes it’s a superpower if you take and use good advice that most people don’t follow. But there’s nearly always a reason they don’t. So you need to figure out why other people can’t, so that you can.

Here’s one of my favourites: rewrite once and throw the first away because you will anyway.

From Fred Brooks’ The Mythical Man-Month, one of the oldest books about getting software written, to Chad Fowler’s keynote about “Legacy” in software, you can find many years’ of expounding the virtues of rewriting our software - in a careful, controlled way. Keep in mind that Chad Fowler is also the guy who wrote the series telling you to never do The Big Rewrite.

So, okay, there’s some subtlety to it. What’s the right way to do it?

technique

I often teach developers for my job, so I collect fears. Most teachers do. Your grade school teacher probably told you that you had to pay attention to boring math and/or history so that you could get a job (and not, by implication, live in a van by the river.)

So when I hear the same fear a lot, from a lot of different people, I pay attention.

I’ll bet that you don’t think you know “The Computer Science Thing” well enough. New folks like Boot Camp grads think so. So do recent college grads. And not-so-recent college grads. And veterans who “haven’t been keeping up.”

technique favourite

I recently moved to Inverness, Scotland from California. When I tell people that, the question I get most is, “why Inverness?” (The second-most is “why would you leave California?” ...

personal