Semantics/Empathy

People argue about words all the time. In the past two weeks, I’ve participated and watched as nerds unproductively tried to convince each other that they are incorrectly using the words bijection, hypermedia, and dependency injection. Nerds easily fall into this trap because many of us are fascinated by knowledge, sharing that knowledge, and teaching that knowledge.

Arguing about words is fun. Arguing about words is practically useless.

Semantics are good

Words are a tricky business. An overused, overloaded, or ambiguous word isn’t particularly useful. “Synergize”, “web-scale”, or “rockstar” are mush words that don’t convey much meaning anymore. It’s tempting to think that encouraging others to be judicious in their use of words and mind the specific context and meaning of their statements could move the needle in making the world better.

On the other hand, human interaction is fidgety. We all have differing experiences, so the way we think and feel about things can vary wildly. You might say “we should pivot our business”, remembering the time you did so and took the company in a much better direction. I might hear you say “pivot” and think about all the abuses of the word in startup discourse or all the companies that have “pivoted” and still failed. Even though we are thinking of the same definition of “pivot”, we are thinking different things.

Semantics are good for getting two people in the same mental ballpark. I can say “web framework” and expect you to know I’m not talking about dogs, tacos, coffee, or compilers. You and I may differ on what a web framework is and what it does, but at least we’re both thinking of things that help developers build web-based applications. We may not be talking about the same thing, but we’re close.

This is why I think strong semantics are interesting, but not a silver bullet. Very rarely have I solved a problem by applying stronger semantics to the words used in the discussion of the problem. Never have I solved a problem by telling someone they are using the wrong semantics and that they should correct themselves.

We can argue about words all we want, but it’s not getting us any closer to solving the real problem. The problem we started talking about before we decided to have a side argument on the meaning of a word.

Empathy is better.

Empathy is a better tool. When someone misuses a word, I stop myself and think, “OK, let’s allow that one to slide. What are they really trying to say?” Rarely does someone misuse a word on purpose. It’s more likely they know it in a different context; discovering that context and matching it to your own is how the conversation moves forward.

If you say “we need to pivot our web commerce company to a web framework consultancy”, I may not know precisely what you mean by “pivot”, “web framework”, or “consultancy” but I can get on the same page with you. You think we need to change directions and that some services-oriented business based on helping people build web applications is the way to move forward. Armed with that, I can ask you questions about why we need to change directions, what that web framework looks like, or how we would change ourselves to a services-oriented company. It’s not as important that you get the words right; it’s important that we find a way to talk about the same thing.

Words are fun, but what’s useful is to figure out what the other person is thinking or feeling and talk to that. Setting aside the tension of telling someone they’re wrong, it’s not productive. I’d rather talk about how we can make better programs or better understand our world than foible over the meanings of a few words.

Words are a lossy representation, they can’t possibly ever connote the full meaning and nuance of any idea of interesting size. Don’t get caught up in skirmishes about the marginally important details of semantics. Use words to show others what you’re thinking and guide them towards your understanding of the problem and a proposed solution.

A decentralized web is hard

The Web We Lost, on the web of ad-hoc, bottom-up social networks before the pendulum swung fully towards centralized networks like MySpace, then Friendster, and now Facebook, Twitter, and friends. I’m glad Anil Dash is pointing out that great things were happening before social networks were massively financed operations and the delightful things that were different when people ran the system from the bottom up.

Owning and operating your data is obviously better than letting someone trade on it. But, there are missing pieces for users:

  • Where do I host my corner of the social network? Putting content on the web without someone else to run it is still strictly nerd stuff.
  • How do I find my friends? The advantage of a centralized network is its easy to make global observations, like analyzing social graphs for recommended links.
  • What are the checks against bad actors? Comments and trackbacks were fantastic for weblogs, until spammers figured out how to turn them into toys for boosting pagerank.

I don’t think any of these are insurmountable. But, decentralization is hard! Can we pull it off? I’d love to see it happen.

Focus-mode considered harmful

I have, at times, been a practitioner of turning off notifications, superfluous applications, and other distracting computer softwares so I could “get things done”. Sometimes it works! However, I have come to suspect that perhaps it is obscuring a greater problem.

I’m just not focused.

Maybe my task is tedious, my project is poorly-defined, or I don’t have a thread to pull on in order to get started. Whichever it is, the world’s greatest distraction-free, focus-enhancing software isn’t going to fix it.

What I really need is something imminent. A show-and-tell with my team, a milestone to deliver, an item to cross off a list, something to publish for the world. I need a goal and it really helps if I need to achieve it in the next few hours.

Yesterday, I worked for a couple hours towards a show-and-tell with my team. I had Twitter, Campfire, and Rdio open. One or more of these are a possible distraction. But, I knew none of them was going to make my demo better, and so even though I flicked over to them occassionally, I flicked back immediately and got back to work.

No one wants a deadline, but a date and an expectation can prove more useful than I had previously thought.

Ideas for living and creating differently

Try thinking about living and creating a little differently today. Advice for beginners: push through the shortcomings of your early work until your ability catches up with your taste. Slow down, lead life at a slower pace every now and then, it’s good for you. Stop telling us how much everything sucks; not everyone makes the same decisions and trade-offs you would when they create something.

Gimme clarity

Wise pal Brain Bailey, along the way to writing about Woody Allen, perfectly articulates my challenge in thinking about how a team should work:

The combination of clarity and freedom is what makes work a joy; one without the other is where you find frustration. When you have great freedom, but an incomplete understanding of the goal, you’re likely to invest hours of effort in a futile attempt to hit a target you can’t see. You know this is the case when you see revisions requested again and again, or products that are perpetually delayed.

On the other hand, a clear goal with little freedom in how to achieve it produces uninspired work by dispirited people. The lack of freedom is experienced as a lack of trust and confidence. People in these environments will eventually seek out new places to work.

Personally, I oscillate between attributing failed projects to too much freedom or not enough freedom. It’s not about that at all. It’s about the balance of that freedom and clarity. If I’m given freedom without clarity, I run off and invent something interesting but impractical. If I’m given over-constrained clarity, I get discouraged.

(Freedom is a funny thing on teams and projects. I have a lot more freedom than I usually think, but I’m still very conservative in acting on that freedom.)

I recently asked my team lead to give the team I’m on a stronger direction in which to go. We already had most of the freedom we needed. We talked over how we could proceed as a team and came up with a direction that was useful for the other teams around us and not so far afield from our current momentum as to discourage us. My morale immediately doubled and I think our team did some good excellent work once we had that strong direction.

Whether you’re managing yourself, managing a team, or managing your manager, asking for clarity is a thing I you should do!

The feel of a commented program

Opening a nicely documented source file is like opening a well-designed, nicely printed book. The main text is obvious, but the side-notes are there to help you when you aren’t quite catching where the author goes or when the author wants you to go read up on something else for context.

Opening a file that needs few comments is like opening a notebook. It’s the raw form of an idea. A few people can pull this off, distilling a program down to its essence.

Both are charming in their own way. The challenge is to know when you’re producing a book and when you’re writing in your notebook. Write for yourself first, then edit it up or down for the reader.

Some productivity winners

Three things that are making me more productive lately:

  • Pick a thing and do it. Whatever you want to accomplish today, do it immediately after you wake up. No social media, no food, nothing. Work on it for 30-60 minutes and then get on with your day. I’d mentioned this before, but I fell off the horse and needed to get back on.
  • No visible clocks. Not in menubars, not in toolbars, not on walls, not on screens. I totally perceive time in a different way when I’m don’t perceive each minute as it passes.
  • Pre-work pep talk. Before I sit down to do something, I talk myself through how I’m going to solve the problem, what the scope of this session is, or think through how I want to structure the thing I’m making. If I do this, I’m much more likely to stay on task, shrug off roadblocks, and avoid distracting myself.

Go forth and crush it.

Sit on the fence between abstraction and practice

Theory and Practice is about a fence. It’s tempting to steer all the way towards the abstract, academic side, or all the way towards cutthroat practical side. Some of the most intriguing, productive people I’ve known sit on either side. Both sides like to accuse the other of not producing results, but that’s subjective. An academic’s results are wholly different from a practitioner’s results.

On occasion, you’ll run into someone who can actually explain complicated theory stuff to you in an accessible way. If you find someone like this, make sure to hold onto them closely, as they’re really rare. But they can help provide you with some insight that will really boost your productivity, without having to invest all the time in figuring out all that wankery that the priests of theory love.

This is a really nice way of explaining why someone like Richard Feynman is awesome. He was equal parts discoverer and explainer (plus another equal part mischief). This is exactly the thing I aim to achieve when I write here, make code, or present at conferences. There’s a whole bunch of ideas that aren’t in practice but, presented and packaged properly, can help move a lot of practitioners forward while recognizing the work of academics and nudging them to keep working in that area.

A lot of good things come out of connecting the people on opposite sides of the fence. Sitting on a fence isn’t exactly graceful, but sometimes it’s the only way to move ideas along. Don’t be afraid to eschew purity or pride for progress.

Pop discovery/rediscovery

Programming is like pop culture in the sense that Blondie gets reinvented every decade and every decade client-server computing is rediscovered. But it’s also like pop culture in that every once in a while something radically new, like hip-hop or STM, appears and eventually is absorbed into the mainstream of the pop culture. I’m ok with that.

Know a little hardware

Consider:

  1. Google’s intricate and massive data center operations, wherein Google is not only leading the pack in building distributed computing and database infrastructure, but building massive operations to run those systems.
  2. “People who are really serious about software should make their own hardware.” Alan Kay, creator of Smalltalk, object-oriented programming, and many other things that are good in your software development life, said that.

I think Alan Kay’s quote could be rewritten for modern times to say, “Those who are really serious about large applications should make their own datacenters”. Assembling hardware, putting it into racks, putting the racks into data centers, and building out your own data centers are the analog of building your own hardware for software service companies these days.

You probably don’t need expert-level knowledge of these disciplines to write software today (e.g. I know diddly-squat about how packets find their way through the modern internet). You will, however, have a leg up if you’re aware of the possibilities and know how to take advantage of them. Even if you’re building applications with modest capacity needs, knowing how to set up a failover database and when to pay for physical hardware instead of virtualized hosts is a thing that will make your customers and clients happy.

More concisely: when it comes to running your software on hardware, one size does not fit all; know how and when to tailor your application to the hardware, no matter what size your application wears.