|
Tuesday 23rd January’s issue is presented by Quotient |
 |
Take Action To Build The Most Productive Engineering Teams
Get customized actions to improve your engineering team’s productivity, using data from both systems and developer perspective.
Powered by the SPACE framework, Quotient gets your engineering team the right data and recommendations to build a high-performing, happy, and productive team.
Run developer surveys, analyze your team’s experience, and get actionable insights. |
|
|
Navigating Ambiguity — Will Larson
tl;dr: “Navigating deeply ambiguous problems is the rarest skill in engineers, and doing it well is a rarity. It’s sufficiently rare that many executives can’t do it well either, although I do believe that all long-term successful executives find at least one toolkit for these kinds of problems.” Will shares his playbook and approach here.
CareerAdvice |
 |
|
3 Questions That Will Make You A Phenomenal Rubber Duck — Dan Slimmon
tl;dr: Dan’s 3 favorite questions to ask when someone is stumped on a complex problem: (1) “How did you first start investigating this?” This helps us regain perspective as our focus shifts from one thing to another to another. (2) “What observations have you made?” This helps recall some of our observations. Since there are many - small and large, interesting and boring, relevant and irrelevant - we tend to not hold all of them in our head. (3) “If your hypothesis were wrong, how could we disprove it?” People get a single idea in their head about the cause of the problem, and this encourages them to shake that idea for others.
Management |
|
|
The Research On What Makes A Great Manager Of Software Engineers
tl;dr: Engineers and managers rank the top attributes of engineering managers, and their relative importance. Researchers at Microsoft evaluated how engineers and managers relate and differ in their views, and how software engineering is different from other jobs in the perceptions about what makes great managers. The best managers (according to engineers) are those that create a positive environment, enable autonomy, and present growth opportunities. These factors are often more important than just being technical.
Promoted by Quotient Leadership Management |
|
|
The “Errors” That Mean You’re Doing It Right — Jason Cohen
tl;dr: The following “errors” are the natural by-product of good decisions and a necessary side-effect of success, and celebrated as such. The first 5 are: (1) Re-adding features/bugs you removed from the backlog. (2) Pivoting a strategy just after creating it. (3) Refactoring infrastructure after growing 10x. (4) Adding words because messaging was too terse. (5) Adding back features you removed.
CareerAdvice |
|
|
|
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."
— Tom Cargill |
|
|
A Developer’s Second Brain: Reducing Complexity Through Partnership With AI — Eirini Kalliamvakou
tl;dr: “As we look to empower developers with AI tools, we inadvertently integrate AI deeper into the way developers work. How do developers feel about that? And what are the most impactful ways to introduce more AI into workflows? We recently conducted 25 in-depth interviews with developers to understand exactly that.”
AI |
|
|
The 10 Types of Authorization — Graham Neray
tl;dr: RBAC isn't an authorization model — it's a collection of authorization models, and you can apply more or less granularity for roles depending on the needs of your application. Learn about the 10 types of authorization and go a level deeper than the standard abstractions of RBAC, ABAC and ReBAC.
Promoted by Oso Management Guide |
|
|
The Scary Thing About Automating Deploys — Sean McIlroy
tl;dr: Sean delves into the complexities and strategies of automating deployments at scale, focusing on how Slack transitioned from manual oversight to using their automated tool for deployment processes in a high-change environment. “When people talk about continuous deployment, they’re often thinking about deploying to systems as soon as changes are ready. They talk about microservices and 2-pizza teams (~8 people). But what does continuous deployment mean when you’re looking at 150 changes on a normal day? That’s a lot of pizzas…"
DevOps Process |
|
|
How We Migrated Our PostgreSQL Database With 11 Seconds Downtime — David McDonald
tl;dr: “Our source database is about 400GB in size. It has about 1.3 billion rows, 85 tables, 185 indexes and 120 foreign keys. It is PostgreSQL version 11. On a usual weekday, we do somewhere in the region of 1,000 inserts or updates per second, plus a similar number of reads.” The DB is relied upon to send millions of important and timely notifications each day, from flood alerts to updating users about their passport applications.
PostgreSQL |
|
|
Sensenmann: Code Deletion At Scale — Phil Norman
tl;dr: “What if we could clean up dead code automatically? That was exactly what people started thinking several years ago, during the Zürich Engineering Productivity team's annual hackathon. The Sensenmann project, named after the German word for the embodiment of Death, has been highly successful. It submits over 1000 deletion changelists per week, and has so far deleted nearly 5% of all C++ at Google. Its goal is simple (at least, in principle): automatically identify dead code, and send code review requests to delete it.” Phil discusses its logic.
Scale Process |
|
|
|
Data Engineering Zoomcamp: Free Data Engineering course. Diagrams: Cloud system architecture in Python code.
Spotube: OS cross-platform Spotify client eliminating need for premium.
System Design Primer: Learn how to design large-scale systems.
TaskWeaver: Agent framework for planning & executing analytics tasks.
|
|
Click the below and shoot me an email!
1 = Didn't enjoy it all // 5 = Really enjoyed it
1 … 2 … 3 … 4 … 5 |
|
|
|