SWLW #497: Negative Engineering, The dark side of transparency, and more

Heya,

As always, below you can read my best findings for the week. If you want to support my work or join SWLW community in Slack - scroll down to the bottom of the email to see how.
 

This Week's Favorite

​​Business Value, Soccer Canteens, Engineer Retention, and the Bricklayer Fallacy
11 minutes read.

"When you get paid to make decisions, you are being paid to exercise your judgement exactly in the ways that can’t be justified within easily measurable and well-defined metrics of value. If your judgement could be quantified and systematised, then there would be no need for you to be there to make those judgements. You’d automate it." -- Ian Miell with an important post on the challenges of building sustainable software organizations. Apply the same judgment when reading this post and discuss it with your teammates. What did you take from it? Where can you use it? Where do you disagree?

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Product [sponsored]

 Promote your product on SWLW and reach over 29,810 leaders 

Culture

I Was Born in the Wrong Country
1 minute read.

My humble effort to help you start the weekend with a smile on your face.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


What Is Negative Engineering?
5 minutes read.

"Given the choice of reducing model development time by 5% or reducing time spent tracking down errors by 5%, most companies would naively choose model development because of its perceived business value. But in a world where engineers spend 90% of their time on negative engineering issues, focusing on reducing errors could be 10 times as impactful." -- While I don't like the term "Negative Engineering" Jeremiah Lowin offers (Defensive Programming is better), this mindset is critical. Share it within your company, with emphasis outside of the engineering department. They should understand why it's a worthy investment even if it "only protects existing value."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Engineering Levels at Honeycomb: Avoiding the Scope Trap
7 minutes read.

I love the 2nd tool presented by Honeycomb about "Growth framework based on scope & ownership," as I think this one image captures the progress of engineers well. It will be interesting to see their full version once it's available, but these 2 "tools" they shared already provide good food for thought.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


The Dark Side of Transparency
8 minutes read.

Fascinating post with examples of how too much raw information (wrapped nicely as "transparency") can backfire. Where would you put the line? Where do you think you or your company should be more transparent? Where do you think it's harmful?

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Jobs [sponsored]

Front-end Team Lead @ Next Insurance
Next Insurance is hiring a leader for a great Front-End team, building a user-centric application that is influencing thousands of small businesses.
 

 Looking to hire for your team? Promote your open positions on SWLW! 

Peopleware

How to Disagree
6 minutes read.

This essay by Paul Graham should be required reading not only as a citizen of the internet but also at work. As companies produce more internal written knowledge and have many conversations going on with tools like Slack, learning how to disagree is critical to creating a safe environment.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


I Make a Living Solving Problems. I Realize There's Roughly 5 Levels of Difficulty. I Use That as a Way to Allocate My Energy Accordingly.
4 minutes read.

KimSia Sim with helpful framing and classification of the type of thinking you should apply when dealing with a new dilemma. It may feel trivial, but I've seen (and done myself) overcomplicated solutions to simple dilemmas. Which type of dilemmas you're mostly facing with? 3? 2? Having many 4-5 type dilemmas often requires different expertise, so it's easy to mistake it as 3.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Readability: The Optimal Line Length
5 minutes read.

Follow Edward Scott's guidelines for your internal documentation, marketing website, or API documentation for your customers. It's incredible how much it can reduce the mental load of the reader and help them better understand the content.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

And finally, inspiring tweets...

@fortelabs: Writing is not a result of thinking. Writing is thinking.

@kelseyhightower: This idea that you have to be an expert before you can share your thoughts or opinions is a tool gatekeepers use to discourage people from looking behind the curtains.



p.s. if you're interested in joining SWLW's Slack channel, simply reply to this email and let me know. If you're leading a team, consider writing your Manager README (it's free) or getting my e-book and interviews Leading Snowflakes: The New Engineering Manager's Handbook. You can also support me by becoming a SWLW Patron. Thank you ❤️




Keep reading, keep learning.
-- Oren Ellenbogen.