For-Developers-Teamwork-TechDebt.md

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

Software Craftspersonship

• 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.

• Cognitive Biases in Programming - by Yash Ranadive. Takeaway: Be mindful of hyperbolic discounting (going for an immediate payoff instead of a delayed larger one), the IKEA Effect (Overvaluing your own solutions to a problem, and thus in contrast undervalue other solutions), premature optimization (optimizing before you know that you need to), planning fallacy (optimistically underestimating the time required to complete a task), and recency bias (placing higher value on recent events than ones that occurred further in the past).

• First Thoughts on Developer Gravity - by James Governor. Takeaway: A post that's a kickoff to future exploration, but already offers insights about "developer gravitiy" (where devs "live") and the importance of developer experience (which decreases with poor documentation, bug fixes and examples). "Developers are certainly not immune to the perception of momentum for environments they might target. Tensor Flow, for example, is seen as a hot technology. GitHub makes developer momentum more obvious than ever. 25k forks – sign me up! Developers want to adopt technologies than other developers find interesting. Herd mentality is a thing."

• Forget Velocity, Let's Talk Acceleration (video) - by Jessica Kerr. Takeaway: a Goto Copenhagen talk about acceleration: deliberate changes in speed and direction to do the most valuable work.

• 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.

• Health Score Metrics as a Software Craftsmanship Enabler - by Chong Wang. Takeaway: About LinkedIn's health score platform that "collects and presents craftsmanship-elevating metrics, and provides a framework for convenient extension."

• How Do I Convince...? - by Sandro Mancuso of Codurance. Takeaway: "One of the biggest mistakes we make as developers is to think that adopting certain practices is a goal that all teams and organisations should have. Technical practices and methodologies are a means to an end and not a goal on their own. They are the 'how,' not the 'why.' Before pushing a practice or methodology to a team or organisation, we should make sure that everyone understands the problem we are trying to solve - the 'why.' ... Don’t discuss practices. Discuss the value you would like to provide and walk backwards."

• How Do You Know Your Code Is Bad? - by Dinesh Babu. Takeaway: "When you write code, ask yourselves these questions: Is this code too rigid? Is it possible to change the internals of this module in the future without touching the code in other modules and other layers? Is this code too fragile? Will it be hard to find all the places to refactor for any changes in the future? Should this feature be reusable? If so, does this code depends on any unwanted modules or frameworks that can be avoided?"

• How to Level up as a Developer w/Scott Hanselman - by Niko. Takeaway: Fear and potential keep us from reaching our full potential. Learn how differentiate between doing the right things and doing things right.

• Keep a Changelog - Olivier Lacan. An entire website dedicated to the art of the changelog, with an FAQ and an aim to produce a better changelog convention.

• On Writing Tech Specs - by Chuck Groom. Takeaway: "A tech spec forces you to think through complicated issues and to get everyone on the same page. This helps to avoid wasting time on dead-end solutions or building the wrong thing."

• One Bite at a Time: Partitioning Complexity - by Kent Beck. Takeaway: tips on refactoring, code structure, and workflow.

• 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.

• Satisficery Engineering - by Paul Adams, Zalando. Takeaway: looks at the topic of "Push." How do we know when to push a team—and in which direction? Sometimes asking a team to deliver more is appropriate but, likewise, it can also be appropriate to give them a break. This article is about being mindful of these opportunities and their consequences.

• 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.

• Software Entropy Explained: Causes, Effects, and Remedies - by Adam Wasserman. Takeaway: "The primary goal is to create an awareness of software entropy because it is a factor in all forms of software development. Furthermore, we explore a means by which software entropy can be assigned a concrete value. Only by quantifying software entropy and observing its growth over successive releases can we truly understand the risk it poses to our current objectives and future plans."

• 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.

• Thinking of the Next Developer - by David Nimmo. Takeaway: "[C]onsider how little time it takes to break out the logic of your functions and make them more readable. Literally a couple of extra minutes of your time could save hours of other people's time when they look at your code next - in most cases the time will be saved immediately when your work goes through a code review."

• We are All Product Owners! An Impact Guide for Engine - by Eran Davidov. Takeaway: offers keen advice on how to measure impact, and what to measure.

• 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

• Agile Self-Assessment Game - by Ben Linders. Takeaway: playing the game enables teams to reflect on how they work together, discover how agile they are, and agree upon next steps they can take to increase their agility to deliver more value to their customers and stakeholders.

• Building a Delivery Team - by Bill DeRusha. Takeaway: How the edX internationalization team spun up quickly—team charter, communication, building a relationship with the product manager, being clear and focused about the project scope, and communicating. Includes links to articles about creating team charters.

• 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.

• Getting Better at Team Communication - by Roberto Dip. Takeaway: Tips based on experience for communicating better with individuals, teams and yourself.

• A Guide to Mindful Communication in Code Reviews - by Amy Ciavolino. Takeaway: How to be kind and constructive in code reviews.

• How Awesome Engineers Ask for Help - by Greg Sabo. Takeaway: Techniques for collaboration, such as clarifying what's expected of you, taking full responsibility for work so that you don't pass the buck, following up after getting answers, and showing appreciation.

• How to Build Ownership in Your Team – Case Study - by Michael Carr. Takeaway: Let the entire team to be involved in project inception, high-level backlog planning and prioritization; make teams cross-functional; be lean; and provide data so the team can understand the problem.

• How to Improve Team Closeness with Personal Maps - by Jürgen Appelo at M3.0. Takeaway: Personal maps and group exercises to develop them can enable members of teams to get to know each other as humans with interests and hobbies. The article points to tips and case stories for you to get ideas.

• Hyperproductive Development - by Jessica Kerr. Takeaway: "the most productive development happens when one person knows the system intimately because they wrote it; this is in conflict with growing a system beyond what one person maintains." The post offers suggestions for what teams can do.

• Incentivize Teams, not People - by Randall Koutnik. Takeaway: "Any programmer worth their salt is willing to help team members out when they’re in a pinch. Software development is a team sport, after all. Unfortunately, management can often completely miss the point and create perverse incentives that wreck a team’s cooperation and communication."

• 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.

• The New Work Order: Team Ingredients and Role Blending - by Heather Fleming. Takeaway: Use "team ingredients" to build teams that achieve maximum productivity and happiness.

• 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.

• 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.

• Scaling Your Software Becomes Increasingly Easier, but What About Scaling Your Team? - by Oren Ellenbogen. Takeaway: The five traits of a scalable team are 1. and aligned vision, 2. aligned, core values, 3. core values over individuals, 4. self-balance, and 5. having a sense of accomplishment.

• The Senior Engineer’s Guide to Helping Others Make Decisions - by Geeky. Takeaway: Lots of tips for mentoring junior devs on your team.

• That's Not Our Code - by Norberto Herz. Takeaway: "Keeping the right mindset and the correct culture is key in order to have an organization that understands their boundaries and when it is right to cross them." Hints at employing InnerSource, and addresses the conflicts and communication issues that can arise when autonomous teams are working in a microservices context.

• Thinking of the Next Developer - by David Nimmo. Takeaway: before moving on to the next coding problem, take the time to save hassle for the next person joining your team or working with your code.

• 25 Hints You’re Working on a High Performing Team - by John Cutler. Takeaway: Growth mindset, infrequent production issues, multidisciplinary collaboration, and 22 more signs.

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

What Is a High-performance Team? - by Richard Kasperowski. Takeaway: a brief post listing different metrics to measure the performance of different kinds of teams.

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.

• The Incredible Shrinking Time to Legacy. On Time to Suck as a Metric for Dev and Ops - by James Governor at RedMonk. Takeaway: "If we’re not running our own environments in house, operations disposability become increasingly realistic. Cattle not pets, for everything. But convenience and disposability always incur a cost."

• Paying off the Technical Debt in Your Agile Projects - by Nishi Grover Garg. Takeaway: "Just as you should not take out a financial loan without having a plan to pay it back, you should also have a plan when incurring technical debt. The most important thing is to have transparency—adequate tracking and visibility of the debt. Armed with the knowledge of these pending tasks, the team can devise a strategy for when and how to 'pay off' technical debt."

• Technical Debt: Adding Math to the Metaphor - by Donald Reinertsen. Takeaway: Explores differences between the usual financial debt metaphor for technical debt and what deferred work really means in product development. The main difference Reinertsen investigates involves the (missing) certainty of how much principal you gain and how much interest you will pay back (if at all).

• When Your Tech Debt Comes Due - by Kevin Scott. Takeaway: a compelling story about how LinkedIn rebuilt their architecture in two months, and involved their entire engineering team.