Along with the GOOS Book, @mfeathers's book & @thejayfields's book, it had a huge influence on me on how I approach Dealing with Legacy Codebases & Large Test Suites
1️⃣7️⃣ GOTO 2012 - Scaling Yourself by Scott Hanselman (@shanselman)
→ Link:
Don't know How to Scale Your Impact & Influence as an Engineer (inside and outside your company)?
This talk is the best definition I found on how to be a 10X engineer.
1️⃣8️⃣ Agile 2012 - Creating Maintainable Automated Acceptance Test Suites by Jez Humble (@jezhumble)
→ Link:
1️⃣9️⃣ DevTernity 2017 - The Long Road by Sandro Mancuso (@sandromancuso)
→ Link:
I read Sandro’s book in 2014/2015 and many of his ideas had a huge influence on my career, especially his views around ownership, hiring and professionalism.
2️⃣0️⃣ Agile India 2012 - Programmer Anarchy by Fred George (@fgeorge52)
→ Link:
I came across this talk when I was at @thoughtworks in an internal mailing list. We (myself included) were allergic to management & titles and this was challenging both.
How a new & much simpler approach called 2-Sigma Observability can massively reduce the number of false positive alerts & uncover some undetectable issues
2️⃣2️⃣ You Are Burned Out And Don't Even Know It by @HealthyGamerGG
→ Link:
It should be called “Debugging Burnout” and should be mandatory to all managers.
Most people that talk about burnout have no idea about what actually (scientifically) causes it.
Those are talks that I shared the most with peers & leaders in different companies I passed. I hope you've found this list helpful.
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.
Senior Engineers understand that when a product manager asks for some cost estimates on their features, it shouldn't be about handing them a list of 17 numbers. "1 week, 7 weeks, 13 weeks, 4 weeks.."
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.
2️⃣ Working Effectively with Legacy Code by @mfeathers.
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 wish we had a concise guide for Software Engineers & Eng. Managers "Shapes" as @ravi_mehta did for Product Managers on his canonical piece "What’s Your Shape?"
While we don't have that, I was thinking about adapting my 4 Ps model to be that. Thoughts?
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.
“I don't think organic ramp up is acceptable. It's lazy. It's the difference between being uncomfortable and confused for 3 weeks, or for 6 months.”
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):
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."
2️⃣ A concrete expansion of many of the ideas raised on Career Narratives by Emmanuel Goossaert @emgosr on “What Paths After Senior Engineer?”