Engineering Is About More Than Code

Curiosity is what drives engineers, and is equal parts curse and companion. An engineer isn’t limited to development or operations. An engineer would be a problem-solver in both areas, probably more. Curiosity is a surprisingly rare quality in people, even in technology.

If you want to know how something works, take it apart and observe. My first digital systems disassembly was a Sony Discman in 1989. Whatever I did, I fixed it. The feeling was powerful. It just took me 25 years to realize that there are many broken things in the world and to prioritize which one’s I involve myself with. Understanding the problem is crucial.

This is how I approach many conversations, navigating purposely and politely until there’s a useful reframing. People aren’t things, so be kind, be sensitive, and be patient. When you engage, learn about their biggest challenges, how they approach things, and what drives them. Just start with that.

[If my 80’s discman was still around, it would be like “yup, those were the days”. My 8086 XT clone next to it would splutter out some op codes. My Mega Man game watch would be waterlogged and stuck in a loop. Which all lead me to the next action…]

Put things back together again so that they work, hopefully, better than before. It’s just courtesy. In commit-worthy code that’s called hygiene. In conversation, that’s called maintaining a shared view or vision. Do these things enough and you’ll find that the way to a common goal is easy easier than with clutter obscurring your journey, and for others’. When you can row in the same direction, you get to your destination a whole lot faster.

Put it with other things to see where it doesn’t work. That’s integration and it’s not always easy, especially if it’s your own code or new auto-scaling configuration that causes unforeseen things to blow up. Get to know what your thing does before and after you put it out in the wild. Be honest with yourself and others about the time this takes.

There are some things you can take apart, and some things you can’t. If you can’t or if it’s too much effort for not enough value, move on to another learning tool, but remain committed to your goal. In the light of fundamental flaws in how we think about security, privacy, and basic human welfare right now, seek something you’re proud and grateful to do. [There are some very worthy things happening in Boston right now.]

CTO vs. CIO: How many tech “corners” do you really need?

Have you ever thought about what “departments” really means? The word “department” starts with another word: “depart”. Stop, think, continue reading.

Technical Chief Officer’s Dilemma: Departments and “Agency”

Are you in a situation where you honestly need people who purposely segregate themselves into groups that start with a departure from each other, rather than a congregation of ideas, people, and purpose?

If you are responsible for a technology “department”, you are responsible for a “failure”. #explain

Consider a geometric line, the most efficient way to connect one point to another. If only people were that easy. Get enough of them together and you start having to group them into manageable departments. IT, Development, Operations, Finance, Sales, Marketing, Management. Business lines to make things easy, right?

Departments are “Depart”-ments

Wrong. Department f*ck screw things up. Drawing lines isn’t a good thing unless if it’s to connect people with each other. They distract people from the simple truth that businesses who succeed are filled with people who instinctually understand that they are all on the same path, together.

Consider a geometric shape, the triangle. A line plus one point, an important point, an entire dimension. What good does it do to add another point beyond that? A square? Another department? Finance? HR? Marketing? Why?

I’m minimizing, I know wonderful, necessary in finance and human resource. Apologies to them, it’s just to make a point.

Only the Right Lines Need to Be Drawn

People who work with very large organizations know this inside out. Enterprises, government agencies, financial institutions. Corporations. The more lines there are, the more overhead and lack of progress there is. Sure, there’s stability, structure, fortitude; but the further we get away from connecting point A to point B in a straight line, the less efficient we are.

Truly effective business starts with figuring out how to define things with the least number of lines. Communication, organization, collaboration all benefit from simplifying how many lines are drawn. #karma

More reading:

[Talk] API Strategy: The Next Generation

I took the mic at APIStrat Austin 2015 last week.

A few weeks back, Kin Lane (sup) emailed and asked if I could fill in a spot, talk about something that was not all corporate slides. After being declined two weeks before that and practically interrogating Mark Boyd when he graciously called me to tell me that my talk wasn’t accepted, I was like “haal no!” (in my head) as I wrote back “haal yes” because duh.

I don’t really know if it was apparent during, but I didn’t practice. Last year at APIStrat Chicago, I practiced my 15 minute talk for about three weeks before. At APIdays Mediterranea in May I used a fallback notebook and someone tweeted that using notes is bullshit. Touché, though some of us keep our instincts in check with self-deprecation and self-doubt. Point taken: don’t open your mouth unless you know something deep enough where you absolutely must share it.

I don’t use notes anymore. I live what I talk about. I talk about what I live. APIs.

I live with two crazy people and a superhuman. It’s kind of weird. My children are young and creative, my wife and I do whatever we can to feed them. So when some asshole single developer tries to tell me that they know more about how to build something amazing with their bare hands, I’m like “psh, please, do have kids?” (again, in my head).

Children are literally the only way our race carries on. You want to tell me how to carry on about APIs, let me see how much brain-power for API design nuance you have left after a toddler carries on in your left ear for over an hour.

My life is basically APIs + Kids + Philanthropy + Sleep.

That’s where my talk at APIstrat came from. Me. For those who don’t follow, imagine that you’ve committed to a long-term project for how to make everyone’s life a little easier by contributing good people to the world, people with hearts and minds at least slightly better than your own. Hi.

It was a testing and monitoring track, so for people coming to see bullet lists of the latest ways to ignore important characteristics and system behaviors that only come from working closely with a distributed system, it may have been disappointing. But based on the number of conversation afterwards, I don’t think that’s what happened for most of the audience. My message was:

Metrics <= implementation <= design <= team <= people

If you don’t get people right, you’re doomed to deal with overly complicated metrics from dysfunctional systems born of hasty design by scattered teams of ineffective people.

My one piece of advice: consider that each person you work with when designing things was also once a child, and like you, has developed their own form of learning. Learn from them, and they will learn from you.

 

Quality Means Not Accepting Crap

Software. Hardware. Things. Opinions. Places. Excuses. Ideas.

Anyone can produce a cheap “affordable” solution. But details matter. How many cheap plastic things have broken in your hands unexpectedly, and were entirely disappointing in that moment?

My AirBnB is not that. I knew “quality” when I saw it. You can tell someone lived in this thing and made it convenient for them, then handed it off to you. That’s quality, making something that meets your own standards, then giving it to someone else.

WP_20151117_005

I travel a lot, enough to know what matters on a trip. Leg room on the plane. Working wifi. Power plugs, everywhere. Politeness. Clean bathrooms. Details matter.

Conversely, a $300/night hotel room only to have plugs too far away from the bed, lamp toggle buttons that take so much effort to push that you push the lamp over, light switches that are harder to find than Carmen Sandiego; the annoyances all add up too. The lights in this camper that I’m staying in are easy to use and don’t cause me to cuss.

WP_20151117_010

Same with software, details matter.

Quality software comes from people using their own product, living in it, fixing its flaws, and asking others how their experience with it is. In the tech industry, we call it “dogfooding” your own product. Believe me, it works.

People intrinsically know “quality” when they experience it. They pick up a phone, it’s heavy and solid, they think “that’s quality”. Conversely, they close a car door and it rattles or sounds hollow, they think “that’s cheap”. Even the sounds shipped with your mobile phone help to engineer your perception of the quality of the device.

Quality is in the details.

Oh, and BTW, I’d also rather put a constraint on myself not to over-drink and stumble into a $450/night on-premise room way too late at night to wake up on time the next morning. I have business to attend to. Knowing when to quit starts with looking at a ridiculous estimate and just saying no:

airbnb-1-fail

So, even at only 3 nights, this would have cost $1,350 just for a room I would be spending around 4-6 hours a night in, and not getting all the charms of an outside shower and condensation on the windows each morning. The AirBnB alternative for all three nights, just 60% as compared to JUST ONE NIGHT AT THE SHERATON!

airbnb-2-win

I should have remembered to check the crime overlay though, but Uber is a cheap solution to that problem:

airbnb-3-crime