RWDevCon Inspiration Talk – Craftsmanship by Chris Wagner

At our recent RWDevCon tutorial conference, in addition to hands-on tutorials, we also had a number of “inspiration talks” – non-technical talks with the goal of giving you a new idea, some battle-won advice, and leaving you excited and energized.

We recorded these talks so that you can enjoy them, even if you didn’t get to attend the conference. Here’s our next talk – Craftsmanship, by Chris Wagner – I hope you enjoy!

Transcript

Craftsmanship. What do you think of when you hear that word?

Maybe what an artisan or an artist does, or maybe a skill in any craft? If that’s what you were thinking, then you were spot on with the definition according to some.

If you’re like me, you’re not very good at precise definitions. Maybe you’ve pictured an image in your mind instead. When I think of craftsmanship, I envision:

Clean lines

Attention to detail

Things created with passion

I want to tell a story about the first time that I recall noticing craftsmanship with regard to computers.

When I was a teenager, I started building computers and I would piece together different parts that I could afford or things my Dad had lying around the house, and it was fun. I was proud of what I was doing. It was rewarding.

I became pretty good at what I was doing, at least others assured me that I was, and it wasn’t long until people started asking me for help with their computer problems. One time my Dad came to me and he said that his friend needed help with his computer.

Mind you, most of what I had learned at that point was from my Dad, so in hindsight, there was no reason he needed me to help him. He could probably do it on his own. This was probably one of those fatherly lessons you don’t realize occurred until later in life.

Anyhow, his friend had just bought a top tier Alienware computer.

Now this was late 90s or early 2000s, so it was a big deal. These things were expensive.

What he needed help with was transferring the files from his old computer to the new one.

My Dad and I decided we’d pull out the old hard drive, put it in the new computer and do the transfer that way. Not many people had networks back then and they were pretty slow to be honest.

We cracked open that old computer. I can’t remember what it was, maybe a Packard Bell or a Compaq, and it was a mess.

Not just a dusty mess, but the wiring inside looked no better than something that I had built before myself, but that was normal, right?

We got the drive out and it was time to open up the Alienware tower. We weren’t prepared for what we were about to behold.

In Awe Of The Alien

We didn’t even need a screwdriver. It had thumb screws on the back. Pretty neat. No more stripped screws. The side panel just slid right off, revealed the components that you needed access to. Wow!

After carefully removing the side panel and revealing the internals, I’m pretty sure we both gasped.

Holy Craftsmanship Batman!

Holy Craftsmanship Batman!

It was gorgeous. At first glance, I don’t think we even saw a cable. Everything was cleanly routed and zip-tied in place.

It was very clear that somebody had made a deliberate decision that these computers would be built with craftsmanship.

It’s Hard To Find the Time

This brings me back to my part about this computer being expensive. Things of high craftsmanship intrinsically cost more to make.

To make great things, you must have great skill and a great amount of time.

Today, I’m here to inspire you to continue or to start practicing and exuding craftsmanship.

In almost every case, when we start a new project, we set out to do the right things or fully unit test or just not that again. We have green pastures, the sun is bright, and the world’s our oyster.

Then comes crunch time. It’s time to ship, the deadline’s approaching, your significant other has told you for the last time it’s time to leave, they’re pulling out the driveway, and you’re frantically typing that last line of code.

Whatever it may be, oftentimes we forget about what we set out to do. We get overwhelmed and we rush ourselves.

Then, we let the cows into our green pastures, they eat all the grass and shit everywhere.

But you’ll clean it up later, right? Right?

Yeah, I didn’t think so.

As programmers, it’s easy for us to let our code get sloppy because the end user will never see that source code anyway. As far as they know, the code is a bunch of incoherent symbols and squiggly lines.

I would argue that this is the driving factor for the level of apathy that I’ve witnessed when it comes to writing beautiful code.

Finding The Time Is Worth It!

There’s a biography that came out about four years ago called Steve Jobs and I’m sure most of you are familiar with Steve.

He had an unwavering stance on quality and craftsmanship, and in the biography he attributes that to his adoptive father. He says:

–Steve Jobs

The parts you couldn’t see. Sounds like our jobs, right? We’re constantly working on the parts that nobody’s going to see.

The people that built that Alienware computer were working on the parts that most people wouldn’t see.

Do you know what happens when you focus so much energy on the parts that no one sees?

That energy is amplified on the parts they will see.

Your pride for the resulting product is also amplified. You’ll be proud to show people what you’ve done and you’ll be confident in what you’ve done.

Have You Experienced Bad Code?

Some of you may be indie, you aren’t working on a team, or have an inherited project before, but for most I suspect that you have. You’ve walked into somebody else’s code before and you probably looked at it and asked yourself, “What the heck?”

Let’s enjoy this one for a little bit.

for (NSInteger i = 0; i < 3; i++) {
  switch(i){
  case 0:
    label0.text = title0:
    break;
  case 1: 
    label1.text = title1;
    break;
  case 2: 
    label2.test = title2;
    break;
  }
}

It's a for switch loop. Makes sense, right? :P

Sometimes you've inherited a project that won't even run without some voodoo scripts you had to find yourself, or some tribal knowledge that you had to hunt around the office for.

How many times have you run across a class with a single method, it's 200 lines long and it's 200 columns wide, you know the ones that look they're playing Flappy Bird if you turned it on its side?

The people that wrote those things are by no means dumb. We've all been there. You're quickly prototyping something and you try new things until it works. I don't' see anything wrong with that.

Where things go wrong is when you don't go back and clean up what you've created and encapsulate that logic into small, easy to consume pieces that you can test.