Leadership-for-Developers.md

When You're Not a "Manager": Leadership for Developers

Blogs/Websites

• awesome-geek-podcasts - a very long list of engineering-related podcasts in several languages.

• Practicing Developer - by Gregory Brown, author of O'Reilly's "Programming Beyond Practices."

• The Ultimate List Of Developer Podcasts - by John Sonmez. Includes the Changelog, the Simple Programmer Podcast, Developer on Fire, and dozens of other podcasts for software developers, organized into topics/sections.

Software Craftsmanship

• Active Learner — How Developers Keep Learning - by Dennis Nerush. Takeaway: "the kind of developers we want to hire and be part of our company and our teams ... are not expert beginners and they are not necessary real experts. But they are aware of what they know and most importantly, what they don’t know. They are on the path to someday become real experts. To go in this path they cannot rely only on what their job teaches them and 'out of the box' just working solutions—they must actively learn."

• The Clean Coder: A Code of Conduct for Professional Programmers - by Uncle Bob Martin. A practical guide for how to become a software craftsperson.

• Empathy - The Hidden Ingredient of Good Software Development (video) - by Daniel Bryant. Takeaway: "When gathering requirements and performing business analysis, it is obvious that the ability to experience from within another user/customer/being's frame of reference is a valuable skill, but the same can be said when writing code. If we follow Martin Fowler’s train of thought where 'any fool can write code that a computer can understand. Good programmers write code that humans can understand' we can see that empathy is at the heart of this skill."

• The Five Dysfunctions of a Team: A Leadership Fable - by Patrick Lencioni. Takeaway: lack of trust and commitment, fear of conflict, avoidance of accountability, and inattention to results will prevent your team from gelling and performing. This book uses a narrative/fictional case study to make its point about overcoming the five dysfunctions.

• The Future of Programming (video) - by Uncle Bob Martin. Takeaway: A history of software development, with context on how developers have solved problems in the industry and where the profession's going.

• Getting Feedback - by Allison (Sheren) McMillan. Takeaway: Ask your teammates for feedback so you can continue growing and developing. Includes short lists of questions you can ask.

• Giving and Receiving Great Code Reviews - by Sam Jarman. Takeaway: "[A]s a submitter, plan, tell the story, and use the review as a learning experience. As a reviewer, slow down, check carefully, automate as much as you can and take the opportunity to improve your team."

• Habits vs Goals: a Look at the Benefits of a Systematic Approach to Life - by Farnham Street. Practical advice about focusing on forming habits—which promote continuous improvement—instead of achieving goals, which have an endpoint.

• Programming Beyond Practices: Be More Than Just a Code Monkey - by Gregory Brown. Covers all aspects of being a leader-developer besides writing code, from prototyping to improving processes.

• The Software Craftsman: Professionalism, Pragmatism, Pride - by Sandro Mancuso. An honest, engaging book that covers all imaginable aspects of being a craftsman, from playing an active role in shaping customer value to avoiding technical debt. Part of the Uncle Bob series.

• Speed in Software Development - by Michael Dubakov. Takeaway: "Software development pace / productivity / speed is a complex, interdependent and multifaceted concept. It has no easy solution. You can’t shout at people “work faster!” You can’t blindly cut corners and focus on value added activities only. The only solution is to think deeply about the company, development processes, people, tools, etc. Build a model and think."

• Start from Square Zero: Hidden Habits You Need for a Successful Career in Tech - by Andrea Goulet. Takeaway: Stop calling yourself "non-technical," pick a guilt language instead of a shame language, get comfortable with discomfort, mind the confidence gap, and acknowledge your biases.

• What Can Developers Learn from Being on Call? - by Julia Evans. Takeaway: Based on a Twitter thread begun by Charity Majors, this post suggests that being on call helps you to learn what kinds of production problems are common and uncommon; understand what needs urgent attention; design reliable systems; build in monitoring and diagnostics early; understand the parts of the system that aren’t yours; gain confidence in your judgement; make minimum effective change; learn about distributed systems and consistency and race conditions, and become a better developer.

Teamwork

• 9 Attributes of Successful Development Teams - by Rebecca Dodd at GitLab. Takeaway: Great teams automate everything, are meticulous about documentation, use collaboration tools and integrated platforms, version control everything, make it easy for everyone to contribute, spend time on side projects, make code review collaborative, and are allowed to be creative.

• Makers and Menders: Putting the Right Developers on the Right Projects (deck) - by Andrea Goulet, CEO & Co-Founder of Corgibytes. Takeaway: Makers and menders each have valuable roles to play in development. Focusing too much on making leads to maintenance, "legacy code," and technical debt; mend as well to reduce your overhead.

• Re-structuring a Growing Team - by Jean Hsu. Takeaway: Identify why you're reorganizing, understand what it means, and execute. Includes a plan for conducting a team reorg so you can prepare for your own.

• What Determines How Collaborative You'll Be? - by Ron McFarland. Takeaway: Four scenarios that illustrate the factors influencing your level of openness.

Technical Debt/Managing It

• A Crystal Ball to Prioritise Technical Debt in Monoliths or Microservices: Adam Tornhill's Thoughts - by Daniel Bryant. Takeaway: a summary of Thornhill's QCon London 2017 talk, which covered "methods to identify 'hotspots' of code complexity and churn; the benefit of continually evaluating the suitability of the architecture for the current system, for example, by examining 'temporal coupling' of components or microservices; and that the cost of inter-team coordination can often be learned from examining the social metadata associated with code commits within a version control system."

• A Seamless Way to Keep Track of Technical Debt in Your Source Code - by Philippe Bourgau. Takeaway: use TODO comments as a good starting point for tracking technical debt.