What I Read This Year - 2020
The title is self explanatory, but these two posts give context.
Books
AI Superpowers: China, Silicon Valley, and the New World Order
- Training deep learning models requires more of a brute force method than innovation; well suited to China’s supposedly higher quantity but lower quality of software engineer compared to the US
- China has lax data privacy and protection regulations so they can collect more data and use it more freely
- Since the Chinese tech startup culture is more intense and with less IP protections, only strong business, not the best ideas, survive
- Though the West has a head-start, Government backing of AI projects in China make it highly appealing and in a position to outpace the rest of the world
Code Complete
- Have plan before starting work. If requirements are constantly changing, efforts are wasted having to constantly context shift and multi-task
- Focus on standards and consistency. By knowing what’ll happen, and having expectations for what should be done in routine scenarios, you can save your energy for more challenge problems
- Code is read more than it’s written. By making it clear and concise, you can spend more time solving harder problems
- Be firm, but flexible. Being too rigid can hamper creativity, hinder inquisitiveness, and hinder creative or new ideas
- Be ego-less, accept that you don’t (and probably) won’t know everything and focus on solving problems
Deep Work: Rules for Focused Success in a Distracted World
- Deep Work: “Professional activities performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skill, and are hard to replicate”
- Shallow Work: “Non-cognitively demanding, logistical-style tasks, often performed while distracted. These efforts tend to not create much new value in the world and are easy to replicate”
- The Deep Work Hypothesis: “The ability to perform deep work is becoming increasingly rare at exactly the same time it is becoming increasingly valuable in our economy. As a consequence, the few who cultivate this skill, and then make it the core of their working life, will thrive”
- Busyness as Proxy for Productivity: “In the absence of clear indicators of what it means to be productive and valuable in their jobs, many knowledge workers turn back toward an industrial indicator of productivity: doing lots of stuff in a visible manner”
- When you work, work hard. When you’re done, be done: “Decades of work from multiple different subfields within psychology all point toward the conclusion, that regularly resting your brain improves the quality of your deep work. When you work, work hard. When you’re done, be done”
- The Four Rules of Deep Work
- Work Deeply - Make rules, rituals, and routines to make it easier and more automatic to get into deep work
- Embrace Boredom - You need to think about how you concentrate outside of work as well, so be comfortable with not being stimulated (email inbox, smartphone notifications) all the time
- Quit Social Media - The quintessential example of shallow living.
- Drain the Shallows - Reduce the effect of low-values tasks like replying emails, making phone calls, and attending meetings by batching them together or at predetermined times
Prediction Machines: The Simple Economics of Artificial Intelligence
- Prediction: Machines are good at consistency when compared to humans, and even marginal improvements are substantial since they can be replicated over time
- Decision Making: Ideally, the more data and input you have, the better a decision you’ll make. This is true for machines, but not for humans since we’ll be overwhelmed or take to long. But humans are good at intuition, which machines (at this time) lack
- Tools: Automation won’t take over entire jobs overnight, but instead different aspects of a task
- Strategy: For a business to see a good RoI on AI, it has to be prepared for it. If current prediction and forecasting methods are outdated, than AI solutions will clash with the status quo
- Society: Society isn’t ready for the inequality that will arise from broad AI adoption. While some will reap massive benefits, others will suffer due to no fault of their own
Return on Investment (ROI) for Usability
- tl;dr - If you invest 10% of a project’s budget on research-based UX, then your ROI will be 85% - 135%.
Test-Driven Development By Example
- Test-Driven Development Patterns: Have a core ‘TODO’ list of what you know you’ll have to test, tests should run independent of each other, and test data should make it obvious what the use case is
- Red Bar Patterns: Tests help you better understand the system with what they test with their coverage, and how they test with their implementation
- Testing Patterns: Break down larger tests into smallr ones, use mock objects to cover corner cases, and don’t be afraid to stop when a test isn’t working. Then you’ll know where to pick up on later
- Green Bar Patterns: Write the simplest code to pass a test. It’ll provide a psychological boost, and will show where more difficult parts are
- Refactoring: Remove duplication, break up large functions, separate refactoring from changes, and automate as much as possible
The Big Nine
- G-MAFIA: Google, Microsoft, Amazon, Facebook, IBM, Apple
- BAT: Baidu, Alibaba and Tencent
- In the West, technology is used for a commercial advantage first, and the societal impacts are considered secondary
- But AI advancements won’t happen in a vacuum, so they’ll have to be adaptable to stay relevant
- In China, technology is used for control and order, which is backed and supported by the government. And they’re protected from outside competition and oversight
- In both scenarios, the long term effects of decisions made now aren’t considered. The next few decade will be a critical time for shaping the idea of how to control AI for the betterment or eventual destruction of humanity
The DevOps Handbook
- The Three ways
- Enable fast left to right flow of work from Ideation to Customer by making work visible and reducing batch sizes (WIP)
- Enable fast and constant flow of feedback from left to right at all by seeing problems as they occur
- Create culture of high-trust that supports a dynamic, disciplined and scientific approach to experimentation and risk taking
- Ron Westrum’s three types of cultures
- Pathological - Large amounts of fear and threat. People hoard information, withhold it, distort it for their own good. Failure is hidden.
- Bureaucratic - Many rules and processes, so departments can hold on to their “turf”. Failure is judged.
- Generative - Actively seeking and sharing of information to improve the organization. Responsibilities are shared, and failure results in reflection and a desire for understanding.
- Possible Constraints
- Code deployment: Automated deployments are faster than what people can do, and removes human error
- Test setup and run: Automate tests so you can do deployments safely
- Overly tight architecture: Loosely couple components, so changes are safer, testing is easier, and productivity is increased
- How Resources are Wasted
- Partially done work: Loses value as time passes
- Extra features: Add complexity and effort to testing and overall understanding
- Task switching: Time and effort lost context switching
- Waiting: Testing, clarification, or deployments all slow down feedback loops
- Hand-offs: Usually need additional communication to resolve ambiguities
- Manual Processes: Slows down feedback loops and introduces human error
- Heroics: Staying late and working odd hours affects an organization’s morale
The Managers Path
- You need to demonstrate performing at the next level, before being promoted to the next level
- Have regular 1-on-1’s to allow regular, private communications about expectations and how they are or aren’t being met
- When providing feedback, by starting with what’s positive, others will be more perceptive on how to improve
- Those to be promoted to manager shouldn’t be judged on their individual contributions, since the next level is about how they can help other achieve
- Leaders should focus on making a fertile environment so their team can do great work
- Delegate to lighten your load, and to show that you can trust your team with important tasks
- With all the time you invest in finding a new hire, you should spend even more time mentoring them, and clearly communicate what it takes to succeed
- Shield your team from as much as possible so they concentrate on their work. But don’t shelter them, they need to know the context of what’s going on
The Phoenix Project
- Improve your laterals
- Deployment (left-to-right): Business -> Development -> Operations -> Customer. This can be done by reducing or removing barriers between each, and limiting the work in progress.
- Feedback (right-to-left): Make a faster and tighter feedback loop so you can better adjust, adapt, and overcome quickly.
- Know the 4 Categories of Work
- Planned Work: New features and enhancements
- Internal Projects: Tooling improvements, production migrations, mostly pertinent to the team but transparent to most everyone else
- Changes: Something driven by feedback that becomes planned work, like a feature change or request
- Unplanned Work: A bug escalation or other emergency/outage
- Lastly, unless their is a failure nothing will change. Why do something different if everything fine?
The Pragmatic Programmer
- Don’t make excuses and or look to the outside when aiming blame, take ownership and resolve the issue. Sign your work and take pride in it.
- Know the Broken Window Theory, so as to avoid normalizing bad quality, and clean as you go to improve the quality of a product
- Be a catalyst for change through example, instead of standing on high and pointing out how others are wrong
- Technical knowledge has an expiration date, continually invest in yourself and make learning a habit
- In the same way a carpenter works with wood, a SWE works with text. Know your tools, maintain them and your skills. Adopt tools that help you, and stop using those that don’t.
Working Effectively with Legacy Code
- The initial paradox: To better understand code, you need to test it. But legacy code wasn’t written to be tested
- To make the code more testable it needs to be decoupled, but decoupling can break functionality
- Always refactor before rewriting. Rewriting can be costly, not operate the same as the original system, and leave out unknown functionality
- When refactoring 1) Test before and after to ensure it operates the same and 2) automate as much as possible with linters and static analysis tools
- If a rewrite is required, don’t try to develop a new system in parallel with maintaining the old system. Instead, slowly replace parts of the old system so the transition is transparent
- Documentation was written for a reason, and your first line source of information. Read what’s available and keep it up to date as changes are introduced
- You don’t have control of what’s already been done with the legacy system, so have a standard for new code to ensure quality moving forward