2021 Reading
Links to articles I read in 2021 with a few notes to remind me of the topic.
January
Estimates vs Actuals
- Story points can be more useful for showing amount of uncertainty than actual time estimates.
- “The problem isn’t that you aren’t good at estimation in general, but that the work has too much risk, uncertainty, delay, and interruption. We can’t estimate our way to predictability.”
Technical Debt Isn’t All Bad (Usually)
- “Often, technical debt sold the software to allow you to have a job.”
- “Strategic technical debt can bring you key wins at times that you can pay back later.”
February
Stop Swiss Cheesing Your Calendar
- Schedule blocks of time dedicated to getting non-meeting work done.
Technical Debt as a Lack of Understanding
- Code should be reorganized to reflect new understanding that didn’t exist when originally created.
- “You can’t expect people to be productive in something that was a culmination of rushed code, poorly understood requirements, and shortcuts made by people who no longer work there.”
To Everyone Who Asks For ‘Just A Little’ Of Your Time: Here’s What It Costs To Say Yes
- “You can only hand so many hours of your day over to other people before there is none left. Even if there are some left, you may have lost the clarity, the energy and the capacity to do anything with them.”
- “Time? Time is our most irreplaceable asset - we cannot buy more of it. We cannot get a second of it back. We can only hope to waste as little as possible. Yet somehow we treat it as most renewable of all resources.”
March
When costs are nonlinear, keep it small
- Batching many changes together into a single large deploy increases the risk of the deploy and makes it difficult to pinpoint which change caused a problem.
May
Why Senior Engineers Hate Coding Interviews
- “They take a ton of prep time to nail… They push senior engineers to work differently… They don’t really test what you’ll want them to do once hired… They send a bad message…”
Becoming a High-Performance Software Engineer
- “An engineer’s day-to-day work… is an expected bar from all software engineers. To stand out and create a major impact requires more… such an engineer is someone who aims for excellence and to create an impact beyond their own individual work.”
- Be engaged in meetings by being an active participant.
- Own the feature you work on by ensuring information is accurate and nothing got missed.
- “[Small or micro-refactors] should be performed constantly and so as to not delay our feature delivery time… In other words, align the areas of code you touch to high coding standards.”
- “To stay relevant and excel, a high-performing engineer should always be passionate about learning and broadening his or her knowledge.”
June
Always be quitting
- Act as if you might leave soon. This encourages writing more documentation and sharing knowledge with others.
- “By being disposable, you free yourself. You make it easier for yourself to grow into a higher-level role and you make it easier for yourself to change the projects you work on.”
Friday Facts #366 - The only way to go fast, is to go well!
- Taking time to have a good base layer of code and consistently writing tests allows faster development.
July
[Part 1] The problems with MVPs in legacy replacement
- “Your existing system/process and all the tools, workarounds, and shadow IT that people have put in place to get their job done is the MVP. Your main goal now is to learn from it.”
[Part 2] The problems with MVPs in legacy replacement
- “Given what you generally have is a fully functioning system, anything less than that is likely to be perceived incredibly negatively.”
- “[SPV or ‘shortest path to value’] is a way of decomposing the needs of the new system(s) into a roadmap that aims to get valuable ‘chunks’ of functionality into the hands of users as soon as possible and with as minimal an impact on their existing work as possible. And then to follow that with the next valuable ‘chunk’ as quickly as possible so that people are reassured that they are not losing functionality overall.”
August
Four Ways of Writing Thoughtful Code to Think Less
- Write honest code. Use common terminology that accurately describes what the code does.
- Get to the point. Write concise code that is minimal and easy to read. Organize files and functions to group related code.
- Keep with conventions. Staying consistent within a project makes it easier for developers to contribute.
- Leverage existing libraries. These libraries are often community tested and reviewed, and might already be familiar to others.
Defense Against the Dark Art of Estimation Bargaining
- Bargain scope, not time.
- Break down estimates of work to show why that number was chosen.
- “As you learn, revisit your estimate. As it changes, convey that back. Remember, we’re all just guessing until we’re done with a project, so be humble.”
September
How hard should I push myself?
- “It’s great to push yourself—but you should be paying attention to the signs that tell you that you need a break.”
- Methods to manage stress include: increase your sense of predictability, create outlets for frustration, and increase social support.
The True Meaning of Technical Debt
- Technical debt is “the natural result of writing code about something we don’t have a proper understanding of.”
- This does not give justification for writing poor quality code with intentions to improve it later.
- The debt can be reduced by spending more effort on design, or the debt rework can be explicitly planned for.
October
Achieving accessibility through simplicity
- “The hard truth is that you just have to make your website simpler and easier to use — for everyone.”
- “Investing in accessibility makes your service better for everyone.”
What to learn
- Rather than learning too many things, specialize in what you are good at.
- “People tend to overestimate how much something working for them means that it works for other people, making advice generally useless because it doesn’t distinguish between advice that’s aptitude or circumstance specific and generalizable advice.”
November
Migrations: the sole scalable fix to tech debt
- Derisk - Start by migrating several of the more difficult projects.
- Enable - Automate migrating the majority of the easier projects. Provide tooling and clear documentation for performing the migration.
Developer tools: extend your reach (with some work)
- When you need to focus on the tool itself, it takes away time spent on the actual work. Learning your tools better can reduce this time.
- “I become a better developer by extending my own abilities, by getting familiar and comfortable with more tools.”
Is tasking developers with creating detailed estimates a waste of company money?
- “Yes, it is because software engineering involves messy discovery of a solution in the complex, abstract environment of code and changing requirements. Those detailed estimates are difficult to come up with and are mostly wrong because there is discovery of both coding constructs and requirements that needs to be done throughout the project.”
- “Instead of spending time on questionable estimates, Software Engineers should be focused on creating valuable software that supports a sustainable business!”
- “Use historical information to guide your high level estimates for future projects.”
December
Code is a Coastline
- “The distance from here to a new feature gets longer as you get deeper into the details.”
The Mortifying Ordeal of Pairing All Day
- Pair programming all the time can be draining and cause burnout. It has many benefits, but when forced to occur all the time it is overwhelming.