Career Journey 1: Interviewing & Getting Promoted
Plus, the great dev-metric debate, why your notes app isn't making you a better engineer, productivity-killers, and more.
How do you become an engineering leader? Is it the right fit for your career? And if you do, how do you become a good one?
In this multi-part series on the career journey of an engineering leader, Dev Interrupted answers these questions and many more by inviting expert guests from the software industry to share their experiences, lessons, failures and triumphs as leaders. Whether you started your career today - or 20 years ago - this series has something for everyone.
In our first episode, host Dan Lines is joined by
, Director of Engineering at Nubank. Together, they explore the nuances of beginning a career as an engineering manager: from acing the interview process and securing a promotion to confidently navigating your first three weeks on the job.Join us for a series of real-world lessons and insights from top engineering leaders.
“The thing that trips most people us is people management. People are people, they have different types of problems. That’s the area that I’ve seen people go from being a manager back to IC more than anything else.”
Episode Highlights:
(3:45) "I think I'm ready to be a manager."
(11:30) Retaining your technical skills as a manager
(16:30) Misconceptions: moving from IC to manager
(23:00) Interviewing: Tips, tricks & ways to stand out
(34:30) Your first three weeks on the job
(40:30) Signals you're on the right track
The Download
The Download is engineering leadership content we’re reading, watching, and attending that we think you might find valuable.
1. Take A Side On The Great Developer-Metric Debate
Pop culture had Barbie vs. Oppenheimer this summer. For those of us who care about software development, we have McKinsey vs. The Pragmatic Engineer. To catch you up to speed: First, McKinsey published a report claiming to have found an effective approach to measuring developer productivity.
Reacting to McKinsey's report, seasoned professionals like
, creator of extreme programming, and offered insights from their extensive experience in the software engineering realm. Through their shared perspective, the authors highlight the dangers of reducing productivity to individualized metrics, rather than shared ones (spoiler: we agree mostly with Kent and Gergely).
2. Get Better ROI On Your Notes
Did you ever think that your note-taking apps weren’t actually designed to take notes you can really use? In this piece,
reflects on his experiences with various note-taking apps like Roam Research, Obsidian, and Mem, especially Roam's bidirectional linking feature, which was initially perceived as a game-changer.However, despite the advent of these tools and the introduction of AI enhancements, the core problem remains: information overload and incessant distractions from the internet are hindering true cognitive productivity. The piece suggests that while software can assist genuine thinking, which often requires undistracted contemplation, it might not be significantly improved by external applications.
This Download Is Sponsored By The Free “CTO Board-Deck Template: Slides You Can Use To Show Engineering Excellence AND Business Impact”
Business leaders want to know that engineering is:
Driving business results
Focusing on the right projects
Delivering on time
Download this deck template to streamline your engineering health update.
3. Remind Yourself Of What Kills Developer Productivity
Embarrassing fact: We’ll read anything anyone has to say on helping developers focus on building, creating and solving problems.
This piece from
argues that productivity-killers include constant interruptions from unnecessary meetings, the repercussions of accumulating technical debt, bureaucratic code review processes, micromanagement stifling creativity and decision-making, and more.Read: Top 7 Things That Kill Developer Productivity
4. Learn What Developer Experience Was Like In The Old Days
We spend a lot of time thinking about the future of developer experience. Someone on Reddit has taken time to ask the original OGs of programming what DX meant back in the days when computers could fill a room. A favorite note is that a single bug could take months to fix by a whole team.
Read: What Developer Experience Was Like In The Old Days
5. Implement 8 Project-Saving Code-Review Automations
Too often, the ideals of open source get mired in the realities of inefficient workflows. This piece from Ben Lloyd Pearson offers eight sanity-saving automations for the open-source community that can be implemented free and easily with gitStream - a workflow automation tool designed to optimize the code review process.
Read: The Top 8 Code Review Automations for Open Source Communities