found drama

get oblique

Category Archives: Code

Shell scripts, JavaScript pedantry, CSS fixations, Java debugging, and the rest of the polyglotism.

on Allspaw’s “On Being A Senior Engineer”

by !undefined

On Being A Senior Engineer:

Essential reading from (surprise!) John Allspaw. Not a new post by any means, but so relevant you’ll think it was published yesterday. It’s a great reminder that what puts the “senior” in “senior engineer” is not knowing 10 languages, or having done 10,000 deploys – it’s having maturity, and perspective, and caring and concern for the peers on your team. Or as Allspaw puts it:

Being able to write a Bloom Filter in Erlang, or write multi-threaded C in your sleep is insufficient. None of that matters if no one wants to work with you. Mature engineers know that no matter how complete, elegant, or superior their designs are, it won’t matter if no one wants to work alongside them because they are assholes.

Seriously. File this one for later and come back to it once a year.

Zakas: no accidental standards

by !undefined

The bunny theory of code:

Nicholas Zakas writes this post underscoring the reasons to emphasize only checking in code that you understand:

In my current role at Box, I’m famous for repeating the phrase, “no accidental standards.” We don’t accept that things are “the way” just because they pop up in a couple of places. When we see this happening, we stop, discuss it, and either codify it as “the way” or disallow it. We then update code appropriately before it gets too far. Through automation, code reviews, and code workshops, we are able to keep an eye on the code and make sure we’re all on the same page.

Sharp’s 3 Phases of a Code Review

by !undefined

The Gentle Art of Patch Review:

Recently recommended to me by a friend, this post posits that effective code reviews have three phases. First: is the proposed idea even “good”? (Is it consistent with the project’s aims? Does the feature add value?) Second: is the architecture correct? (Stay out of the weeds; keep the feedback high-level.) Lastly: is the patch polished? (Now is the time to unleash your inner pedant and invoke the iron fist of the style guide.)

Sharp argues that this style of code review benefits the maintainers, the contributor, and the community around the software project. It allows for the right level of feedback to happen at the right time, and because of that, it avoids problems with people getting (for example) over-invested in a patch that isn’t appropriate to the project, or else getting discouraged because of nit-picky feedback right off the bat.

“a good thing being able to configure a framework”

by !undefined

The Future of the JavaScript front-end framework:

More/less the same drum getting beaten by so many right now (see also: the Joreteg’s announcement about Ampersand, although this opinion piece is probably a better illustration of the theme) – and by that I mean: “Go ahead and provide an all-inclusive framework, but be modular so I can swap out the parts I need.” Which is great, but I would say misses a big point: discoverability of those modules. Say what you will about Spring’s role in the Java eco-system, but its worthwhile to align with a single trustworthy starting point. Part of what’s missing from the “framework fatigue” discussion is just that – that our “big frameworks” only provide a relatively thin slice of what our whole app needs and we’re in “contrib” (and/or plugin, and/or mixin, etc.) hell for everything else. This glosses over the BIG-Big frameworks of a few years ago (e.g., dojo, ExtJS, YUI), but the point stands.

(A version of this previously appeared as my comment on Prismatic.)

Nash on Joint Cognitive Systems

by !undefined

Ghosts in the machines:

It feels intuitively right: computers are better at plugging through repetitive information very quickly, humans are better at context-specific, qualitative judgments about that information. But the problem with this approach is that day-to-day tasks in the world we all operate are not so neatly composable in this way — we are constantly moving between a variety of tasks that could be more easily done by either machines or humans.

Hits on a lot of good points. Implicit here (viz., not called out) is the fact that if DevOps is about increasing the humanity of designing, implementing, and managing big systems (and make no mistake: that is what it’s about) then the notion of Joint Cognitive Systems becomes very important. “Divide and compensate”, MABA-MABA approaches arguably just turn the operators into slaves of the automators automation, and potentially make things even more chaotic.

birds-eye view of JSPM and Babel for ES6

by !undefined

Building with AngularJS, JSPM, Babel, Gulp and ES6:

Unfortunately, it’s a very birds-eye-view of putting these pieces together, but it’s still worth checking out because it gives a glimpse of what it might be like. The AngularJS-specific bits offer nothing new (and frankly feel a bit out-dated), and I’m still just lukewarm on Gulp — but what’s particularly interesting is the combination of JSPM and Babel, and how that empowers developers to start using ES6-style JavaScript today.

re: Slatkin on PPK on client-side templating

by !undefined

One Big Fluke › Experimentally verified: “Why client-side templating is wrong”:

By Brett Slatkin (“One Big Fluke”).

If you followed PPK’s AngularJS post

from January (and his follow-up

client-side templating post

), then this is a worthwhile reply in its own right — and somehow I missed it when it ran.

Whereas PPK argues largely from a position of principle, Slatkin throws experiments and data at it, and while he arrives at different conclusions, he’s also gracious about the whole thing, drawing the conclusion thusly:

The take-away here is to choose the right architecture for your problem.

What’s good about this post is that he dug deep into this problem, cut it up a bunch of different ways, and remained open to the possibility that either approach might “win”. Which isn’t to say that his experiments were perfect (if some flaws aren’t obvious to you then check out the comment thread where several “improvements” are enumerated) or that there isn’t some speculation going on, but we have some good applied science here to give us a sensible picture.

Two important things here though:

First, it’s hard not to read Slatkin’s post as a refutation of PPK’s. This is unfortunate because, dogmatic though his tone may be, PPK offers up plenty of good points that you should consider when making these choices for your application. Whether you like AngularJS or not, whether you think client-side templates are a good fit for your problem or not, these thoughts are at least worth mulling over.

Which leads to my second point: it’s my sincere hope that people go with Slatkin’s real take-away, and that development teams have the discipline to look at their application, to analyze the data it’s producing about their audience etc., and to think about their goals for the future — and to design and build their applications with those data in mind. It’s entirely too easy to cargo cult decisions from posts like this one (and/or from PPK’s) and just assume that you got it right because you read something compelling from someone smart. By all means take their data into consideration, but no one else’s data is meaningful to you.