tl;dr:Nicole advises on how to make our code inherently more understandable: (1) Remember your audience i.e. what will other maintainers be expected to know. (2) Isolate the highest complexity. If something is complicated, pulling it into its own unit, such as a module or function. (3) Read it with fresh eyes a few days later. (4) Integrate any code review comments by updating the code and comments. Nicole also discusses how to leverage documentation.
tl;dr:“It feels like I'm the only one with glasses on! Getting a handle on this situation is a really important skill and there are a few good techniques for it. There's also a meta-problem here which you need to learn to handle if you want to enter leadership roles.” Nicole discusses how to approach this situation with your manager, potentially reconcile perspectives with them, and lean on peers.
tl;dr:“Over the years I've come across a few books that I really strongly recommend to everyone, but in particular, to people who want to advance on the technical track. Here are my favorites, along with why I like them!”
tl;dr:“If you aim for 100% code coverage, you're saying that any risk of bug is a risk you want to avoid. And if you have no tests, you're saying that it's okay if you have severe bugs with maximum cost.” Nicole presents us with a way to think about how much code coverage is enough. You need two numbers: (1) The cost of writing tests. To get this, you have to measure how much time is spent on testing. (2) The cost of bugs. Getting this number is more complicated. You can measure the time your team spends on triaging and fixing bugs. The rest of it, you'll estimate with management and product. The idea here is just to get close enough to understand the trade-off, not to be exact.
tl;dr:Nicole argues that software engineers, who often estimate tasks using abstract points, should instead estimate directly in units of time. "When we look at large pieces of a product roadmap, we typically need a ballpark understanding of the time and cost." Estimating in time offers clarity and avoids the indirectness of using points as a proxy for time. However, Nicole acknowledges potential pitfalls, such as misuse of time estimates by external parties.
tl;dr:Nicole discusses the balance between innovation and using proven technology. The central argument is that while innovation is enticing, it's often more practical and efficient to use established technologies. The author notes, "Most of the time, the problems you run into while doing your work are mundane." Proven technologies offer benefits like robust documentation, established ecosystems, and familiar concepts. However, Nicole also acknowledges situations where innovative tech is necessary, stating, "With the bleeding edge, you are going to get cut, but sometimes that's necessary."
tl;dr:Nicole’s process involves six steps, each of which she expands on: (1) Identifying the symptoms. (2) Reproducing the bug. (3) Understanding the systems. (4) Forming a hypothesis about the bug's location. Instead of randomly searching through the code, the author suggests forming a hypothesis about where the bug might be located. This narrows down the search and makes the debugging process more efficient. (5) Testing the hypothesis. (6) Fixing the bug. "If you don't understand the bug behavior, you have no hope of knowing if you've fixed it or not."
tl;dr:Software teams should prototype or create a "first draft" of code for new features and then discard it. Prototyping allows teams to anticipate issues and understand the full complexity of a new feature. Despite seeming wasteful, this approach actually saves time by preventing unforeseen problems during the development process. However, it's essential to discard the prototype code to keep the process efficient and the codebase clean.