Ten Principles for Growth as an Engineer by Dan Heller:

“These are the most important lessons that I wish I had learned ears earlier than I did; I sure wish someone had sent it to me when I was 22.”

1. Reason about business value: Reason like a CEO. Understand the value of your work to your company, and take responsibility for reasoning about quality, feature richness, and speed. Your job isn't just to write code; your job is to make good decisions and help your company succeed, and that requires understanding what really matters.

2. Unblock yourself: Learn to never, ever accept being blocked; find a way by persuasion, escalation, or technical creativity. Again, your job isn't just to write the code and wait for everything else to fall into place; your job is to figure out how to create value with your efforts.

3. Take initiative: The most common misconception in software is that there are grown-ups out there who are on top of things. Own your team's and company's mission. Don't wait to be told; think about what needs doing and do it or advocate for it. Managers depend on the creativity and intelligence of their engineers, not figuring it all out themselves.

4. Improve your writing: Crisp technical writing eases collaboration and greatly improves your ability to persuade, inform, and teach. Remember who your audience is and what they know, write clearly and concisely, and almost al-wavs include a tl;dr above the fold

5. Own your project management: Understand the dependency graph for your project, ensure key pieces have owners, write good summaries of plans and status, and proactively inform stakcholders of plans and progress. Practice running meetings! All this enables you to take on much bigger projects and is great preparation for leadership.
6. Own your education: Pursue mastery of your craft. Your career should be a journey of constant growth, but no one else will ensure that you grow. Find a way to make learning part of your daily life (even 5 minutes/ day); get on mailing lists, find papers and books that are worth reading, and read the manual cover to cover for technologies you work with. Consistency is key; build habits that will keep you growing throughout your career.

7. Master your tools: Mastery of editor, debugger, compiler, IDE, database, network tools, and Unix commands is incredibly empowering and likely the best way to increase your development speed. When you encounter a new technology or command, go deeper than you think you have to; you'll learn tricks that will serve you well again and again.

8. Communicate proactively: Regular, well-organized communication builds confidence and goodwill in collabor-ators; knowledge-sharing creates an atmosphere of learning and camaraderie. Share knowledge, and set a regular cadence of informing stakeholders on project goals, progress, and obstacles. Give talks and speak up judiciously in meetings.

9.Find opportunities to collaborate: Good collaboration both increases your leverage and improves your visibility in your organization. Advancing your craft as an engineer requires you to have an impact beyond the code you write, and advancing your career requires, to a certain degree, building a personal brand at your company Cross-functional projects and professional, respectful collaboration are critical to both.

professional and reliable: Think of yourself as a professional, and act like one. Come to meetings on time and prepared, then pay attention. Deliver what you say you will, and communicate proactively when things go wrong (they will). Keep your cool, and express objections respectfully. Show your colleagues respect and appreciation. Minimize your complaining; bring the people around you up, not down. Everyone appreciates a true professional; more importantly, it's the right way to behave.

I've read 500+ books and accumulated 55.000+ notes & highlights over the last ten years. 99% of those books were non-fiction & mostly around Software Engineering.

Below are The 22 Technical Books that Impacted my Career the most ➕ their highest-density chapters & pages.

🧵



1️⃣ The Software Craftsman: Professionalism, Pragmatism, Pride by @sandromancuso.

Why do we need Technical Engineering Managers?

Below is a list of Lesser-Known Reasons why we need More Technical Engineering Managers:

1- Prevent team members from underperforming due to a lack of opportunities! How? 👇

🧵 Failing to identify if the task/feature/problem at hand is complex enough to require a Senior or a Staff Eng (or if a Junior Eng can do it) leads to teams overloaded by overqualified engineers that frequently step on each other feet.

I have interviewed 300+ Senior Engineers, Tech Leads & Engineering Managers over the last 10 years of my career.

Here are the most actionable tips I learned on how you can do better on Behavioral Interviews as EMs/Staff+ and also some common pitfalls:

🧵🧵🧵 1. The STAR format is like a Three-Course Meal:

• The Situation/Task is the Appetizer,

• Your Actions are the Main Course,

• The Results are the Dessert, the cherry on top.

Don’t overfeed the interviewer at any point, otherwise…

Remote Pair Programming Good Practices: A Thread.

Found the slides of a presentation that @qcoding and I gave to the entire CTO Org at Amex two years ago when we were both there.

Thought it had a lot of great stuff that could still be useful to others.

Why not share?

🧵 Remote pair programming:

Outline:

1. When to do it,
2. When NOT to do it,
3. Practical Tips on how to do it,
4. Recommended tools,
5. Additional references.

But first, let's start with WHY to do it.

0. Why to do it

WHY?

Will Larson (@Lethain) has written two books (An Elegant Puzzle & Staff Engineer) & many articles about Career Growth for Engineering Leaders. I have read all of them!

Below are his Best Pieces of Advice for a Remarkable Forty-Year Career in Tech.

↓↓↓ 1️⃣ Collect People. Not Jobs, Companies, or Frameworks.

Collect People? WTF?

Jobs don't last forever, but your career and the people around you in the industry do.

It's uniquely valuable to start to reflect & collect people you admire and genuinely love to work with.

As a manager, it isn't your job to train people. You’re not a trainer!

This isn't lack of empathy.

We all love to help people.

Yet our time is limited.

Improving your top performer by 10% is worth 10x more than improving your bottom performer by 10%.

It's leverage! Source: @scarletinked as insightful and as precise as always on accomplishing more with less effort.

A Couple Decades of Unlearning — Lessons on the Path to Director:
scarletink.com/couple-decades…

Last week I shared that @xdg's piece on Mentoring Engineers was one of my favorites.

Here is why. Highlights:

Mentors should operate at 3 levels:

1️⃣ Goals - Figuring out what they really want
2️⃣ Situations - Handling the unfamiliar or difficult
3️⃣ Skills - Getting promoted

🧵

https://twitter.com/thiagoghisi/status/1617250051302248449

1️⃣ GOALS: Telling someone what they should want isn’t as powerful as helping them discover it for themself.

Goals are most meaningful when they are deeply understood.

The best goals come from within.

I've read thousands of articles over the last 20 years in Tech.

Agile, Career, Distributed Systems, Engineering Management, Metrics, Programming, Testing, Types...

Below are The 22 Articles that Impacted my Career the most ➕ my main highlights from each one.

🧵🧵🧵 1️⃣ On Software Rewrites: "Things You Should Never Do, Part I" by Joel Spolsky (@spolsky).

→ Link: joelonsoftware.com/2000/04/06/thi…

~2013: It heavily influenced me probably 10 years back and explains a lot about why I’m not a big fan of “Green Field Projects.”

As we begin a new performance cycle, here is something to think about to really grow career-wise: Staff Projects.

Projects that are considered complex and important enough that the person who completes them has proven themselves as a Staff+ engineer.

Here are a few examples: 1) Projects that you’ve worked on that have spun off into their own dedicated teams.

That’s usually a great sign of a Staff Project.

The Seven False Hopes of Software Management (1987).

Each one reaches out with an attractive fallacy that leads nowhere.

As long as you believe them, you’re going to be reluctant to do the hard work necessary to build a healthy & productive culture.

🧵 1️⃣ There is some new trick you've missed that could send productivity soaring.

People like to learn, and to improve. The line that there is some magical innovation out there that you’ve missed is a pure fear tactic, employed by those with a vested interest in selling it.

B.S!

If you've recently been laid off, you’re preparing for interviews, trying to get promoted or just setting career goals for 2023, check this out:

I went from 3k to 16k followers on LinkedIn in 2022 and here are My Top 10 Posts that had 3M+ views & I’m sure will help you👇

🧵 1️⃣ Don't overfeed the interviewer!

My very best advice on Behavioral Interviews & The STAR Method to Engineering Managers & Staff+ Engineers interviewing to the Big Techs.

It even got an awesome share from @Lethain and a comment from @alexxubyte.

Link: lnkd.in/eKQMbkQH

How to Build a Strong Career in Tech.

2019, I gave a talk.

2020, I wrote an article expanding the talk.

2021, I recorded a podcast distilling the article.

2022, I gave an interview talking about growth as an EM.

2023, I'm sharing my favorite ideas about career 👇

🧵🧵🧵 1️⃣ Part I - Definition of Career Success

What do successful careers in tech have in common?

Impact of their ideas on a large number of people directly or indirectly.

Success = Impact & Influence!

🧵 The Engineering Career Progression Function:

https://twitter.com/thiagoghisi/status/1279890984466370567?s=20&t=gKnagZ5FshB_POwkf1L-jg

I've watched 1000+ Conferences Talks over the last 20 years in Tech. I used to watch one every night after dinner for years.

Below are The 22 Talks that Impacted my Career the most ➕ my main highlights from each one.

🧵🧵🧵 1️⃣ Øredev 2011 - Sleeping with the enemy by Gojko Adzic (@gojkoadzic)

→ Link:

"The new mission of QAs should be teach programmers to collaborate, own quality together, automate tests or checks together."

Back in 2011, this was controversial. I 💚 it.

Senior Engineers understand that the highest value of code reviews isn't about ensuring high-quality code.

They know that code review is about teaching & learning how to do better engineering. Senior Engineers understand that a design review (the same applies to RFCs) isn't only about making the best design.

It's about walking through the tradeoffs in the design, asking the right questions, and ensuring that all tech folks involved understand why choices were made.

I've read 500+ books and accumulated 55.000+ notes & highlights over the last ten years. 99% of those books were non-fiction & mostly around Software Engineering.

Below are The 22 Technical Books that Impacted my Career the most ➕ their highest-density chapters & pages.

🧵 1️⃣ The Software Craftsman: Professionalism, Pragmatism, Pride by @sandromancuso.

ICs need to “know their shape”.

Eng. Managers need to know their shape & all their ICs shapes.

Directors need to know their shape, their Managers shapes & their most impactful ICs shapes.

So they can fit their teams together like puzzle pieces.

Otherwise… 🧵 Without a thoughtful approach, Teams will end up unbalanced.

Unbalanced teams will ship unbalanced products at an unbalanced cadence with unbalanced levels of quality, autonomy & ownership.

I read a lot about Engineering Management. Of all writers I found this year, @scarletinked has been by far the most consistently insightful with 100% down-to-earth & actionable tips.

This piece on How to Onboard Yourself in 3 Weeks at a New Job is a clear example of that!

🧵 When moving to a new team, there are a few key elements to learn before you can provide value:

1- The product you're working on,
2- The partners you'll work with, and
3- The systems behind the product.

This paper "Momentum Theory" by Patrick Franklin (a former Eng. Leader of mine) is so good and has so much history that it could easily become a @stevesi's "Hardcore Software" post.

Rule #1: Always attach to existing momentum.
Rule #2: New systems must link to momentum. @stevesi All sources & credits to Patrick (that doesn't have a Twitter account):

linkedin.com/in/patrick-fra…

If I could combine Three Articles that I re-read recently (along with a few visuals) into One Thing that could make your head explode and your self-reflections & career conversations to grow exponentially in effectiveness, I would pick the following three:

🧵🧵🧵 1️⃣ The initial provocation by Will Larson on Career Narratives.

> "I have slowly but increasingly come to believe that there is much more opportunity outside career ladders than within them, and by including those opportunities you'll make and feel more progress."

Took me a while to understand why I was so unhappy at Apple, but I finally got to the bottom of it:

1) The overall sense of Mission & Vision was lost.

2) I didn’t feel inspired neither by my leaders nor the culture, nor by coworkers.

3) Apple is seeing: Process > Content.

🧵

https://twitter.com/thiagoghisi/status/1553758374633693186

Don’t get me wrong, I love execution and honestly I think I’m pretty good at it. Yet nobody feels inspired or challenged by execution by itself.

https://twitter.com/thiagoghisi/status/1490737617008087040