Honest to a Segfault

I know what you're going through — I've done it all before.

The market is teeming with products that purport to help you meet your badassery quota.

First you do the shakes. Then, you go with the bars that say they're infused with the good stuff, but just seem to leave a slightly corrugated taste in your mouth. Finally, you're droppin' hard-earned dinero on a facility that you don't need or a professional badassery trainer whose appointments you desperately wish you could cancel.

But I'm here to tell you don't need to shell out cash-money to become more badass, my friends. Not anymore, thanks to the beauty of open source, the ES6 plans wiki page, and our delightful SpiderMonkey technical staff who are standing by to receive your calls for mentorship.

Allow me to explain.

Badass begets badass

You may have seen Badass JavaScript: self described as, "A showcase of awesome JavaScript code that pushes the boundaries of what's possible on the web." Check out their badass year in review if you haven't. (Some of the stuff that the interwebs has done with JavaScript even has @NeckbeardHacker envious.)

It probably won't surprise you, but do you know what those folks love? JavaScript evolution. There's nothing quite so refreshing as a fresh-squeezed JS language feature that removes that irritating itching-burning sensation. Sets that do what you mean! String repetition that you can use without copy/pasting from your last project! Inverse hyperbolic sine that you can use for... your... math! (Again, all of this is in the ES6 plans.)

I, for example, have wanted String.prototype.startsWith very badly, to the point that I've started washing people's window panes against their will as they exit highway 101. Around here, odds are that a programmer sees my sign and implements the thing just to stop me from bothering them again. (A little tactic that I call SpiderGuerilla warfare.)

So what are you waiting for?

I know, you're probably already quite beefcake, but here's my three step plan:

1. Watch the SpiderMonkey hacking intro.

2. Pick out a bug from the ES6 plans.

3. Come talk to great people on irc.mozilla.org in channel #jsapi (for example, cdleary, jorendorff, luke, or whoever else is in there) or comment in the bug — tell them that you're on a quest to become even more badass, describe a bug that you're interested in taking, and give a quick note on what you've done with the engine so far — for example, walking through the video in step 1! We'll find you a mentor who will get you started on the right track.

Don't miss out on this exclusive offer — SpiderMonkey contribution is not sold in stores.

In fact, if you act now, we'll throw in an IonMonkey shirt (or another Firefox shirt of equivalent awesomeness) and publish a blurb about your feature in Mozilla hacks. Of course, you can also have yourself added to about:credits, providing that's what you are into.

This one-of-a-kind offer is too ridonk to pass up. Just listen to this testimonial from one of our badass contributors:

I started contributing to SpiderMonkey and now I can write a JIT compiler from scratch in a matter of days. BEEFCAKE!

—@evilpies [Liberally paraphrased]

See you in the tubes!

"Whoa, Billy reviewed a one-meg patch to the hairiest part of the codebase in just two hours!" [*]

It's pretty easy to identify what's wrong with that sentence. The speed of a review is not an achievement. Billy could have literally just checked the, "yes, I reviewed it" button without looking at the patch.

... but an empty review looks pretty bad, especially as the size of the patch grows. So maybe Billy padded it out by identifying two hours worth of style nits and asking for a few comments here and there. In any case, the code quality is no more assured after the review than before it.

Conventional wisdom is that it's economically prudent to do good code reviews: finding defects early incurs the lowest cost, review has a 'peer pressure' based motivation towards quality improvement, and review creates knowledge redundancy that mitigates the bus effect. In research literature on code review, effectiveness is typically measured as "defects found per KLoC". [†] However, this dimension ignores the element of "time per review": I'm going to argue that time to give a good review varies in the complexity and size of the modifications.

Now, one can argue that, if Billy does anything more than ignorantly checking the little "I've reviewed this" box, he has the potential to add value. After all, code isn't going to be defect-free when it comes out of review, so we're just talking about a difference in degree. If we assume that truly obscure or systematic bugs won't jump out from a diff, what additional value is Billy really providing by taking a long time?

This is where it gets tricky. I think the reason that folks can have trouble deciding how long reviews should take is that we don't know what a review really entails. When I request that somebody review my patch, what will they try to suss out? What kind of code quality (in terms of functional correctness and safety) is actually being assured at the component level, across all reviewed code?

If you can't say that your reviews ensure some generally understood level of code quality (i.e. certain issues have definitively been considered), it's hard to say that you're using reviews as an effective tool.

Aside: even with clear expectations for the code review process, each party has to exercise some discipline and avoid the temptation to lean on the other party. For mental framing purposes, it's a defect-finding game in which you're adversaries: the developer wants to post a patch with as few defects as possible and the reviewer wants to find as many defects as they possibly can within a reasonable window of time.

A few best practices

From the research I've read on code review, these are two simple things that are supposed to increase defect-finding effectiveness:

Scan, then dig.

Do a preliminary pass to get the gist of how it's structured and what it's doing. Note down anything that looks fishy at a glance. Once you finish your scan, then do another pass that digs into all the corner cases you can think of and inspects each line thoroughly.

Keep checklists.

One checklist for self-reviews and one checklist for reviews of everybody else's stuff. I've seen it recommended that you scan through the code once for every checklist item to do a truly thorough review.

The self-review checklist is important because you tend to repeat the same mistakes until you've learned them cold. When you make a defect and it gets caught, figure out where it fits into your list and make a mental and/or physical note of the example, or add it as a new category.

Having a communal checklist can also be helpful for identifying group pain points. "Everybody screws up GC-rooting JSString-derived chars sometimes," is easily codified in a communal checklist document that the whole team can reference. In addition, this document helps newcomers avoid potential pitfalls and points out areas of the code that could generally be more usable / less error prone.

Here's another nice summary of more effective practices.

I'm personally of the opinion that, if you find something that you think is defective, you try to write a test to demonstrate it. The beneficial outcomes of this are:

• You end up with a test that can be added to the suite, even if no defect is found.

• You gain a greater system-level understanding of how to trigger behaviors in the questionable area, giving you an even better understanding of the context for the patch you're reviewing.

• If it was unclear to you while reading the patch, you know it requires clarification, either via more expressive code or an appropriate comment.

I think in an ideal situation there are also linter tools in place to avoid style nits altogether: aside from nits masquerading as legitimate review comments, automatically enforced stylistic consistency is nice.

Footnotes

There's a spectrum for the working compatibility between two people.

On the far left of the spectrum, there's negativity. You hate the other person's guts, and can't work with them at all. There's some personality conflict (which could simply be, "That person is an asshole") or some impasse that would require psychotherapy to bridge.

On the far right of the spectrum, there's chemistry. Effectively, you want to have their technological babies. You finish each other's... that's right, sandwiches. Or sentences. Or parser combinator libraries. When you stumble with a task or concept, that person is there to pick you up with a how's-it-going or whiteboard marker, and that's a two way street. You work together like the badass components of a emergently-more badass machine. Bio-digital jazz, man.

And smack dab in the middle, there's plain ol' compatible. This is like the "friend zone" of the working world. It's fine, and you can go on that way indefinitely, getting things done at a reasonable clip, but it probably doesn't get the creative juices flowing. You're scheduled to meet at a waypoint instead of bushwhacking away at the thicket together.

It takes time, effort, and luck to find people that you have working chemistry with — they're understandably rare. The effort has to start somewhere, though. Maybe it's a good exercise to imagine a person that you're just working-compatible with: if you bore to them your technological soul, might you get something going on?

We care about our craft. We're totally smart and get things done. No question.

But "smart and gets things done" has to have some kind of spectrum associated with it, right? There's at least a "smart" dimension and a "gets things done" dimension.

An easy question to ask is, "Am I overthinking?" (This is especially easy to ask if you're overthinking.)

We often quibble about how to get things done better [*] in terms of practicalities, but it often feels like people who ignore the long tail of practicalities achieve greatness with the least effort.

If you had to pick one, would it be better to over-think or to over-do?

(My advice: don't think about it too much.)

Footnotes

Latest in the, "People problems are hard, I'm glad I just program computers," set of thought processes. If you have thought-provoking anecdotal data points, your comments are welcome!

There's a confounding and contentious dynamic in programming between collaboration and concentration. This goes beyond just individual and team efficiency — it's also about finding a balance that lets you enjoy and grow your craft.

There are certainly times that you want to hunker down in an LCD-monitor-adorned sensory deprivation chamber and do some badass debugging, find all the corner cases in that nasty algorithm, or suss out all the invariants in a complicated system.

But, on the other hand, there are certainly times that you need to write code during a flurry of peer interaction. If you're ramping up on a new system, the thirty seconds it takes you to ask another human being a question and receive a solid, well-informed answer usually trumps the hours you'd spend reaching the "same" conclusion. With less certainty. Oh, and you actually missed the trap everybody else already knows about, so you actually figured it out wrong.

The extent of the dichotomy is clearly not limited to these examples. It's easy to think of times you've had to pepper somebody with questions as well as times you wanted to hole up in a cave to get some code done. For my systems programming experience I'd hazard a guess that it's around an 80/20 split between concentration and collaboration.

So, it's interesting to ponder: if you were building a team, how would you structure the work space or work activities to enable collaboration when it was necessary, but enable concentration in the common case?

I suppose it's doubly difficult because you also want your team to feel empowered — capable of seeking out collaborative help when they need it in order to get things done and make progress, but also empowered to cordon themselves off and have at it.

I can pretty easily find research that involves hospital workers in the early 1990s, but I have to imagine that a team of brilliant systems programmers is a different beast altogether.