The boring designer chases the right idea over their idea every time. They respect their team and will try almost any idea (whether on a whiteboard or in Sketch or in code) that gets thrown their way. Instead of arguing about whose idea should win, the boring designer tries all the ideas and even elevates others’ ideas in the process. The boring designer abhors groupthink and being told “yes.” They consistently request feedback and new ideas. And as a result when they feel super passionately about their own idea, the team listens.

Cap Watkins, The Boring Designer

So many of these points translate (or apply directly) to lots of other leadership roles, technical or otherwise.

77:19 Thy way is in the global environment.

Reblogged from King James Programming
The truth of the matter is this: you are woefully unprepared for a career in management, and you are unaware of how badly unprepared you are.
Resource Handling in Spring MVC 4.1 from Rossen Stoyanchev

Cool stuff presented by Brian Clozel and Rossen Stoyanchev at SpringOne last week. The tl;dr version would be “Rails-style asset-pipeline stuff for SpringMVC” — but it looks like it goes a bit beyond that. Should provide some nice solutions to static asset and resource management for Spring-based applications, and timely as Spring Boot gains traction.

The fundamental problem with viewing JavaScript as the new VM is that it creates the illusion of control. Sure, if we are building an internal Web app, we might be able to dictate the OS/browser combination for all of our users and lock down their machines to prevent them from modifying those settings, but that’s not the reality on the open Web.

Aaron Gustafson, A Fundamental Disconnect.

This isn’t (just?) FUD around JavaScript and web apps, it’s the reality. And this is the timbre of so many posts over the years: that you have no control over the ultimate runtime of your application’s interface and therefore [fill in the blank].

And so we’re left in this weird never-never land where we can’t really spend all the resources that we need to ensure that we’re reaching (literally) everyone, but neither can we justify rubber-stamping a “best in WebKit (on top of modern hardware)” banner as a way of coming in under-budget. There’s the notion that you can just follow a couple of best practices and be just fine but this doesn’t really acknowledge that not everyone doing front-end development is a Front-End Developer.

To Gustafson’s point about Hanselman’s point about JavaScript deployment basically being a VM… I wouldn’t say that he’s being unfair. After all, Hanselman is a smart guy and I must imagine that he’s making these statements in a sort of Inspired Visionary way. But at the same time… yes, calling the browser a VM is over-selling it a bit. And for all the reasons that Gustafson spells out.

Tags: JavaScript