For-Developers-Teamwork-TechDebt.md

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

Software Craftspersonship and Teamwork

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

• Are You out of Alignment? - by Camille Fournier. Takeaway: "Getting into alignment with the company is often a challenge for senior ICs because it requires a major change in focus. The hardest part is now identifying the right problem to solve, instead of solving the hardest problem. If you want to be able to find interesting work and also work on important things, you generally have to go find the interesting important things yourself. This requires that you to talk to a lot of people and listen to their problems, and then place a bet on a solution to one of these problems that will actually both be feasible but will also be seen as important."

• Can Metrics Be Used to Take Back Control of Your Software Delivery? - by Juan Pablo Buriticá. Takeaway: A straightforward, thorough post on different types of engineering metrics that teams can apply to measure their effectiveness meaningfully. Highlights Dr. Nicole Forsgren’s Accelerate as an influence, and also questions velocity as a meaningful metric in that it can be easily gamed. “The primary lesson I took from deploying delivery metrics was the importance of trust. For metrics to be successful, I needed my team to trust my intentions and embrace the strategy presented to them, especially when I didn’t have too many answers on the actual results we’d get.“

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

• 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 - by Olivier Lacan. Takeaway: An entire website dedicated to the art of the changelog, with an FAQ and an aim to produce a better changelog convention.

• Lead Developer Career Guide - by Shelley Benhoff. Takeaway: Learn the skills you need to be a lead developer, with expert advice on mentoring teams, handling clients and project managers, and keeping your head in emergencies.

• Notes to Myself on Software Engineering - by François Chollet. Takeaway: Lists of points on the development process, API design, and software careers. "Productivity boils down to high-velocity decision-making and a bias for action. This requires a) good intuition, which comes from experience, so as to make generally correct decisions given partial information, b) a keen awareness of when to move more carefully and wait for more information, because the cost of an incorrect decision would be greater than cost of the delay. The optimal velocity/quality decision-making tradeoff can vary greatly in different environments."

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

• Own Your Tech Career: Soft skills for technologists - by Don Jones. A book that teaches you to approach your career with planning and purpose, always making active decisions towards your goals.

• Post-Commit Reviews - by Cindy Sridharan. Takeaway: “An alternative to pre-commit reviews is post-commit reviews, which lets a developer merge changes to trunk, and address reviewer comments in follow-up pull requests. In many ways, post-commit reviews offer the best of both worlds: developer velocity is not sacrificed at the altar of waiting for an approval, and reasonable concerns get addressed in short order by the developer in follow-up commits.” Includes guidance on how to overcome challenges.

• 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 Senior Engineer’s Guide to Helping Others Make Decisions - by Geeky. Takeaway: Lots of tips for mentoring junior devs on your team.

• The Software Craftsman: Professionalism, Pragmatism, Pride - by Sandro Mancuso. Takeaway: 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.

• Starting Up Security - by Ryan McGeehan. Takeaway: a collection of infosec resources to help teams manage risks. Includes post-mortems, risk assessment tools, and more.

• Think Like a Software Engineering Manager - by Akanksha Gupta. Takeaway: A book about the skills you need to hire, train, and lead a successful software development team.

• We are All Product Owners! An Impact Guide for Engineers - 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.

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

• High Output Management for (Non-managing) Tech Leads - by Andrew Hao. Takeaway: Framed within a reference to Andy Grove's High Output Management, this covers how tech leads can be effective. "Collaborate closely with your management counterpart to develop and contextualize these indicators ... output indicators, quality indicators, in-process inspections."

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

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

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

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

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

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

Managing Technical Debt

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

• Technical Debt Is Like a Tetris Game - by Jonathan Boccara. Takeaway: "If you’re asked to make a fix that will compromise the quality of your code, you can explain that it’s like placing a Tetris block at the wrong position. You can do it, and if you’re not too far into the game you won’t lose right now."

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