How to Jerry Seinfeld

How Jerry Seinfeld writes a joke:

[youtube www.youtube.com/watch

Very different from how I approach it. But, I love knowing how much goes into his craft and the degree to which he is particular about how he does it.

Typing code examples, it's like biking

If you want to learn from a piece of code, you should type it out, instead of just reading it. The value of typing code:

Typing code may be like riding a bicycle. I’m surprised how much more detail I see the first time I ride my bicycle over a road I’ve driven on, mostly because I’m moving slower but also because there’s an additional muscular dimension to the experience.

I love this bicycle metaphor. The slowness of biking engages my brain in an entirely different way than running or driving. Even the mechanical sounds are more pleasant; the consistent whirr of the chain is so much more calming than the revving up and down of a gasoline engine.

The value of typing code holds very true for me; I usually get very little by simply reading code in books and articles. But when I take the time to type it in and actually try to run it, I struggle with it more (not all code examples are perfect) and get more out of it. You should give it a try.

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.

Wherein I heart Code Climate

We’ve had Sifter’s repo hooked up to Code Climate for a couple months now and I’m really loving it. Garrett and I have both found it fun to kill duplication or refactor away complex code. A decent test suite enables this, but Code Climate is very much the compass that points you right to the trouble spots. The Code Climate blog is a great read too, consistently featuring thought-provoking ideas on how to think about making better code.

I love tools like flog and flay for quick smell detection. If you are like me and too lazy to configure CI and code metrics, Code Climate’s easy setup and awesome trending are well worth a look.

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.

Hit it, don't quit

How to be good at anything. In short: do it, get feedback, study how to improve, repeat.

Something I’ve found, through crossfit, is that if I have any strong suit it’s not quitting. Seems trite now that I write it, but it occasionally helps to state the obvious.

Once I’ve decided an activity is worthwhile, I’m pretty good at sticking with it no matter how silly I feel doing it. I’m not the strongest, the fastest, or the best eater. I’m not the smartest, the funniest, or the most charming. But I’ve made progress in life by showing up every day and trying to do a little better than the previous day.

The bottom line: pick a few things to do well, do them, and don’t quit.

You can't solve technical debt, you can only hope to contain it

Staring Down Technical Debt:

Technical Debt is an interesting phrase.   We all have a sense of what it is instinctively, but we rarely want to think about it.  If we think about it too hard, we feel somewhat oppressed by entropy.  All systems tend to toward disorder and software systems are no different. The big question that we all face is what to do about it. 

Systems tends toward disorder. Disorder is hard to reason about and risky to deal with, i.e. you’re likely to avoid dealing with it at all. But, most successful products have a system with more technical debt than you’d like at its center.

Increasingly, I think that the only way to confront technical debt and complexity is to contain it. Languages and tools only seem to help at the margin. Rigorously splitting large, complex, debt-filled systems into smaller, proportionally complex and debt-filled systems is the way to gain traction.

You can’t solve technical debt or essential complexity; you can only hope to contain it.

Needs better words

How much easier would Haskell be if its vocabulary wasn’t so deeply rooted in abstract mathematics? How many more people would immediately understand Cassandra if it just adopted the vernacular of row-oriented databases instead of overriding it with column-oriented semantics? Wouldn’t the programming world be better if every language didn’t call itself object-oriented?

So many programmer-facing things could be better if they had better names for concepts. The power of good naming:

Characters are cheap, confusion is costly. Let’s not make things harder for the programmers who come after us. Remember, this is just as likely to be ourselves in a few months. Let’s avoid using a name like prj when project is only four characters more typing. Anything that reduces reading friction in our code is a good thing.

The cynical view is, we are actively confusing and inhibiting ourselves when we use names that are too short, not clear, or outright wrong. The optimistic view is that there’s a progression we can take from not knowing what something should be named, to giving it an acceptable name, to using the naming process to discover better structures.

If you ever hear me say something “needs better words”, it means that I think the idea is right but the labels are wrong. A philosophical dialog may ensue, where I struggle to discover what the essence of the idea is. The end goal is a word that is concise, has the right connotation, and whose meaning is obvious and accessible to as many audiences as possible.

I love naming things.

The qualities of better code

What is 'better' code? Dave Copeland on the qualities readable, changeable code exhibits. Of the attributes he identifies, I think number of paths (ABC complexity) is the most important for reading code and fan-in/out is the most important thing to manage for easily changed code.

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.

Get in my ears, you dissonant chord

Petrushka chord. Two major chords played a half-tone apart. So, it sounds good, except it sounds grating. It's a motif throughout Stravinsky's ballet Petrouchka. Ergo, like everything Stravinsky, get in my ears! Listen to it and learn more about the chord from the awesome "Feynman of classical music" (I just made that up) Leonard Bernstein.

Dustin Curtis' recipe for doing

Do. Your short, sharp inspirational mantras for the week.

RubyConf 2012 notes

My notes, in a somewhat sketch-esque fashion, from RubyConf 2012. I hope they’re useful and/or amusing to you!

[gallery link=“file”]

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.

Marginal pennies and dollars

The give a penny, take a penny jar is a logical conundrum. It is not, on its surface, a rational thing. I have no data, but I suspect very few people who put money into them are doing so because they plan on taking money out later. A bank is different from a give/take a penny jar.

Personally, I put money in because I can and because I fancy myself not a jerk. The latter is what makes more rational sense. I put money in because it’s utility to me is marginal, but the utility of feeling better about myself is non-marginal.

In My Blue Heaven, Steve Martin plays a semi-reformed mobster in the witness protection program. He starts compiling a book of his truisms for living life. One is “it’s not so much tipping I believe in as over-tipping.” His character does this partially because he’s a little flashy, and partially, I think, because he has to be a likable protagonist.

I’d like to be a likable protagonist too, but I like over-tipping whenever possible for another reason. Pretty much anyone who works for tips is working really hard for every dollar they make. An extra dollar here or there is trivial to someone with a desk-job like myself, but less trivial to tip-earners who are technically paid less than minimum wage. An extra five or ten percent on a single tip won’t change their life, but it probably doesn’t hurt either.

I like making people’s day better with laughs and smiles, but I’m not above buying a tiny fraction of a better day for someone else. Marginal pennies and dollars add up.

Ruthlessness and fighting for it

You Are Not Ruthless Enough:

Being ruthless to yourself means every time you say “oh, I’ll just open up this internal bit over here…” use that moment to give yourself whatever negative feedback you need to go back and write the correct interface. Imagine the bugs you’ll get later. Give yourself a 12 volt shock through your chair. Picture the sleepless nights chasing down an issue that only happens for that one guy but it’s the guy who signs your paycheck.

I dropped this in my drafts folder months ago and came back to it today. It’s still something I need to hear. Get it working, and then ruthlessly edit and refactor until it’s code that won’t cause you to cringe when others bring it up.

In improv and code, I’ve recently come across the notion that there are things we need to fight for. Fight, not in the sense of conflict, but in the sense that there is an easy or natural way to do something, and then there is the way that maintains our sense of pride and quality. Not necessarily the “right” or high-minded way to do something, but the way that does not leave us feeling compromised as a creative person.

Your homework is to write down the qualities important to you, the ones that make you proud of your work and happy to share it. Then work from this checklist every day:

  1. Write the code, rehearse the scene, play the song, etc.
    2. <li>Decide whether it expresses your qualities.</li>

<li>If it does, ship it. If it doesn't, edit ruthlessly until it does.</li>

Rinse/repeat/tell everyone about it.