• Designing Delivery: Rethinking IT in the Digital Service Economy “This pragmatic book introduces a transdisciplinary approach to digital service delivery. Designing a resilient service today requires a unified effort across front-office and back-office functions and technical and business perspectives.” - I really enjoyed reading it.

• How to get engineering teams to eat their vegetables “Good teams share control. They demonstrate they actually are listening, care when someone is flustered or upset, defer to the judgements of the people on the team, and treat the concerns of others as our own. Good teams demonstrate empathy.”

• Restful API guidelines “The purpose of our “RESTful API guidelines” is to define standards to successfully establish “consistent API look and feel” quality.”

• Growing Your Tech Stack: When to Say No “When you do accept a technology into your stack, make sure it has an owner. Spread knowledge through pairing, documentation, and communication. Make responsibility explicit and set aside time for maintenance, upgrades, and reassessment.”

• Being A Developer After 40

“In our industry, every technology generates what I call a “galaxy.” These galaxies feature stars but also black holes; meteoric changes that fade in the night, many planets, only a tiny fraction of which harbour some kind of life, and lots of cosmic dust and dark matter.

Examples of galaxies are, for example, .NET, Cocoa, Node.js, PHP, Emacs, SAP, etc. Each of these features evangelists, developers, bloggers, podcasts, conferences, books, training courses, consulting services, and inclusion problems. Galaxies are built on the assumption that their underlying technology is the answer to all problems. Each galaxy, thus, is based in a wrong assumption.”

• The quiet crisis unfolding in software development

“I’ve noticed a quiet crisis unfolding in software development leading to low quality applications, unhappy employees and unhappy users. Silver bullet solutions keep creeping into our awareness (Scrum, anyone?) and predictably keep letting us down.

This is almost entirely the fault poor management — or perhaps it should be called fad management”

• The Most Dangerous Word In Software Development

“When you hear the word “just” being thrown around, dig deep into that statement and find all of the assumptions made within it.” – it is dangerous to assume things without reflecting on it first

• Mobile Web vs. Native Apps or Why You Want Both

An interesting reflection on the different use cases for mobile web and native apps, and why one might need both. tl;dr: Mobile Web is great for reach, Native for engagement.

• It’s a Bystander Problem

“It’s other men who have the power to create social consequences. It starts with refusing to be a bystander by calling things out. Ultimately, if men stopped working with, hiring, and funding those men who behaved badly, the effects would be dramatic.”

• Good CEOs aren’t busy

“As you start to grow from a tiny startup into something that resembles a more mature company, your #1 priority becomes surrounding yourself with incredible leaders who can do their jobs better than you ever did. You delegate more, question less and start to see the big picture.”

• Netflix & brilliant jerks: “Some companies tolerate them – for us, cost to effective teamwork is too high” (and a lot of other insights in the team culture netflix had a few years ago)
• Brilliant Jerks? Bring ‘Em On!: “If a brilliant jerk is someone who simply questions the answers and rejects the status quo, by all means, he should not only be kept, he should be rewarded.” – response to the comment above. When and what kind of jerk might be good to have around in the company
• Silicon Valley Lies And Those Who Tell Them: “But the media has played up an untrue connection between successful leaders and their occasionally dysfunctional character and demeanor. Being more like Gates or Jobs doesn’t require that you emulate some of the worst behaviors you’ve read about them.”
• The Hardest, Shortest, Lesson Becoming a Manager: “There’s something we all talk about in becoming a manager – and that’s the process of writing less code. We bemoan it because it’s hard to let go of that part of our identity. But also because it’s so quantifiable. (..) If you team needs a manager more than they need an engineer, you have to accept that being that manager means that you by definition can’t be that engineer. I know some people manage both, but you need to decide if you’re going to suck at one which one that will be.”
• How to hire: “We should not be afraid of False Positives. We can quickly fix a False Positive hiring decision. (..) For those of you questioning the morality of fast iteration of new hires please consider the alternative: we deny people opportunity for fear they won’t succeed or we keep people in roles where they won’t be successful.”

• Mockbox: A free “in-browser SMTP server simulator”. Basically, a dumbed down version of Mailtrap without signup and free.

• Tech leads: Circles of responsibility: Tech leads should have skills from three different core competencies: A classic developer skillset, some insights as a systems architect, and obviously team/leadership skills. This graphic is nice to orient oneself where someone currently is, where to improve.

• Engineering ladder: I really love this approach to standardize and formalize the various aspects of “seniority” of engineers. There are several situations where such a standardized approach could help: During 1:1s to discuss with an engineer where and how they can improve, to assess ranking and title during job negotiations, and most important as a tool to move from subjective biased employeed “judgements” to a more objective approach.

• “Success at Work, Failure at Home”: Food for thought: How work and family life affect each other

• (DE, Werbelink)Mindfuck Job: Okay-ish book highlighting some mechanisms that you might use to block yourself in your job development, and how to get past them.