Decision Impact

I think a critical part of building an empathetic engineering culture is understanding decision impact. This is a blind spot that I see happening a lot: a deliberate effort to understand the effects caused by a decision. How does adopting X affect operations? Does our dev tooling support this? Is this architecture supported by our current infrastructure? What are the compliance or security implications of this? Will this scale in production? A particular decision might save you time, but does it create work or slow others down? Are we just displacing pain somewhere else?

What’s needed is a broad understanding of the net effects. Pain displacement is an indication that we’re not thinking beyond the path of least resistance. The problem is if we lack a certain empathy, we aren’t aware that pain displacement is occurring in the first place. It’s important that we widen our vision beyond the deliverable in front of us. We have to think holistically—like a systems person—and think deeply about the interactions between decisions. Part of this is having an organizational awareness.

Tech debt is the one exception to this because it’s pain displacement we feel ourselves—it’s pain deferral. This is usually a decision we can make ourselves, but when we’re dealing with pain displacement involving multiple teams, that’s when problems start happening. And that’s where empathy becomes critical because software engineering is more about collaboration than code, and problems have this natural tendency to roll downhill.

The first sentence of The Five Dysfunctions of a Team captures this idea really well: “Not finance. Not strategy. Not technology. It is teamwork that remains the ultimate competitive advantage, both because it is so powerful and so rare.” The powerful part is obvious, but the bit about rarity is interesting when we think about teams holistically. The cause, I think, is deeply rooted in the silos or fiefdoms that naturally form around teams. The difficulty comes as an organization scales. What I see happening frequently are goals that diverge or conflict. The fix is rallying teams around a shared cause—a single, compelling vision. Likewise, it’s thinking holistically and having empathy. Understanding decision impact and pain displacement is one step to developing that empathy. This is what unlocks the rarity part of teamwork.

via DZone Agile Zone http://ift.tt/2p9E6zx

CSSReference.io is a gorgeous visual guide to CSS

CSSReference.io is a gorgeous visual guide to CSS

The best way to learn CSS is through trial-and-error. You’ve got to write code in order to learn to be a coder. That’s the simple truth of the matter. But it’s always nice to have a helping hand guide you through the often confusing and contradictory technology used to style and illustrate webpages, which is where CSSReference.io comes in.

This site is a comprehensive reference guide to the CSS properties you’re most likely to use. There are a lot of these, like the authoritative and (justifiably) respected Mozilla Developer Network. But what separates CSSReference.io from the pack is that it’s actually rather beautiful.

 

Each property is accompanied with an illustration that shows how it works, which I imagine will take away a lot of guesswork for beginners. There’s no bullshit either. Each one is explained in refreshingly straightforward terms.

cssspec

Some CSS properties are used to animate elements shown on the page. This is a relatively recent inclusion, and was introduced with CSS3. CSSReference.io actually shows these in action, rather than just telling you how they work.

cssanimation

It’s free, and you can check it out here. If you, like me, prefer to learn about things from a dead tree, I’d also highly recommend Jon Duckett’s HTML and CSS, which is a similarly delightful reference guide to the technology.