found drama

get oblique

Author Archives: !undefined

About !undefined

Syndicated content from the !undefined Tumblr blog where Rob Friesel posts items related to software engineering, user interface/experience design, and Agile software development. Lots of JavaScript here.

thoughts on that “Do We Need CSS Anymore?” post going around

by !undefined

The Debate Around “Do We Even Need CSS Anymore?”:

As with just about all approaches in software, there’s no one-size-fits-all solution, and for any given development team, they’ll need to come to their own conclusions about the trade-offs. Personally, I think the “do it all in JavaScript” approach seems like a short-sighted optimization. From the component-based perspectives like we’re seeing with React, I can see why you’d want to bundle style changes to the components — but my gut says this is a slippery slope that prioritizes developer ergonomics over all other concerns.

Consider battery performance on mobile, for example — I’d put even money that mobile browsers have been tuned for CSS performance with respect to power consumption, but there’s probably a lot more overhead in managing JavaScript changes and then having to repaint with all those low-level styles applied at the element level. (To be fair: this is a hunch, and I have no data to back this up, nor have I been able to find any in my admittedly brief and shallow search.)

Keith J. Grant’s “stop pretending” point is a legitimate claim, and regardless of which of the big front-end frameworks you’re a fan of, you’ll find that they’ve all embraced some flavor of this by now. However, I remain skeptical of the wisdom to put all the eggs in that particular basket. I still see a lot of value in keeping these concerns separated… to the extent that you can separate them at all.

“…they will go off and work in the integrated development environments…”

by !undefined

What Is Code? If You Don’t Know, You Need to Read This:

They will do their standups. And after the standups, they will go off and work in the integrated development environments and write their server-side JavaScript and their client-side JavaScript. Then they will run some tests and check their code into the source code repository, and the continuous integration server will perform tests and checks, and if all goes well, it will deploy the code—perhaps even in August, in some cloud or another. They insist that they’ll do this every day, continuous releases.

Read every word. Every one of those 38,000 goddamn words. Even if it takes you 6000 hours.

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.

“I’m just listening and conserving energy”

by !undefined

On Conferencing While Introverted:

Introverts often listen more than they talk in conversations, and the less energy they have, the more quiet they’re likely to get.

Talks specifically about how conferences (though enjoyable) can really wring out an introvert. True stories that translate right back to the rest of our daily lives. (Where “our” is the rest of us introverts.)

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.)