TK
It was an interesting read about how software engineering works at Google. There are some things that are particular to Google itself (problems and scale) but most of the topics mentioned I already saw as a process or best practice working in the industry.
It's an interesting resource for newcomers and people who didn't have the chance to work in companies that are solving difficult technical and scalability problems.
I liked that it's a fast-paced book. Divided into topics and easy to digest. Some of the topics, like LSC, are very Google's (scalability) problem, and maybe it's not that useful for most of the companies in the world. But the overview on culture, tools, and processes were all interesting to me.
For me, there is doubt that Elon is a special and very different person. I liked that the book painted him not only as a visionary solving real humanity's problems but as a human being that's always learning, improving, failing constantly, and very passionate about interesting problems and the space.
A very interesting book if you intend to follow the technical leadership track and are not really into management. This is a career I want to follow and helped me have a clear understanding of how staff+ engineers can operate in an organization.
Each engineer's story was a little different because each organization requires different skills to solve their specific problems, but the ones that caught my attention were related to engineering sponsorship, technical vision & strategy, a lot of collaboration, and leadership.
Most of the stories and content are in Will's blog: https://staffeng.com
The book is very easy to read, clear, and practical. I felt like reading a bunch of cool blog posts (I got to know later that the author had written some great posts as well and turn that into this book: jamesclear.com).
The idea of the book is to break down goals into systems. And systems into habits. And habits into atomic habits.
The small behavior on a daily basis will compound and have an extraordinary effect on your life. We make good habits clear, attractive, easy, and satisfactory. And make bad habits invisible, unattractive, hard, and unsatisfactory.
I focused more on advice like ‘little bets', capturing career capital, deliberate practice, having control over your work, and organizing a mission-focused career. I also think we can benefit both from the passion and the craftsman mindset he talks about. My concern was regarding putting these mindsets against each other over using both to have an accomplished career.
The main idea of the book is to present the idea of deliberate practice, a way to purposefully practice your craft to gain mental representation and become an expert in your field. The concept is simple:
- Well-defined specific goals, not just repetition.
- Focused, full of attention practice.
- Get out of your comfort zone.
- Monitor your progress.
- Figure out how to maintain your motivation.
You design the learning process to learn how to do the craft, learn the mental representations that experts use in this field, and design a feedback loop (the regular cycle of try, fail, get feedback, try again, and so on is how the students will build their mental representations.)
The book has plenty of research and examples. It's a bit repetitive, but I like the idea of reinforcing the concept and make me think and rethink my ways of learning throughout the book.
I've been reading this book for 3 years now and it had different values for different moments in my career. As a new grad (or as a junior software engineer), the first time I read this book, I saw it with a lot of great tips and started applying in my career. The second time I read this book I was a more senior engineer and had a lot of different experiences in my career.
Reading this book for the second time was like remembering good examples from my career and things I could apply in some moments.
For new engineers, I think this book can be very valuable. Senior engineers, though, probably had these experiences before, but I think it can also be valuable for them as well. By the way, we are always learning.
So here are the notes I liked and documented while reading this book:
## Dedicate time to develop a new skill
At Google, engineers have the 20/80 rule, where they can spend 20% of their time investing on innovation activities, personal projects, or learn new skills.
- Think of using 20% of the time to make investments that will make you more effective in the long run.
- Think of adjacent disciplines related to your core role. eg. product engineer learns product management, user research, frontend engineering. You can find adjacent disciplines to enrich your knowledge.
- Using the time to master the programming language that you use: focus on developing a solid grasp of the advanced concepts, read one or two good books, use platforms like exercism to receive feedback on your code.
- Send Pull Requests to everyone you feel you can be benefited. Feedback on the code is really important to improve your coding skills. The feedback on the code can also start an interesting discussion about the language, clean code, system design, etc.
- Use the time to discuss software design and architecture.
- Have no fear jumping into code you don't know: fear of failure hold us back. New codebases can be challenge at first, but we can always learn something new reading code.
- Use the time to study new technologies: programming languages, frameworks, tools, etc
- Read books: learn from lessons and mistakes of others. Re-apply knowledge without having to start from scratch.
- Join discussion groups: a group of people to discuss and talk about a specific topic.
- Attend talks / meetups / conferences. Maintain relationships
- Follow blogs / Write posts
- Build side projects / do what you love: hone your skills and do something that interest you.
## Prioritize Regularly
There will always be more tasks to do than you have time for. Working on one task means not working on another. This is why prioritization is so important. Some tasks will have more impact and more value (business or engineering value) than others. It's important to sort these tasks.
- List everything you need to do to start prioritizing: “the human brain is optimized for processing, not for storage.” - David Allen, Getting Things Done
- Sort tasks by leverage: Estimate work by percentage of impact (0.1%, 1%, 10%, 100%) and the time each would take to implement (hours, days, weeks, months). With this visibility, we start to understand how we can prioritize by value and effort/time.
- Focus on what directly produces value: “when you get the important things right, the small things often don't matter”. At the end of the day, what matters is how much value you've created. Don't try to get everything done. Focus on what matters - and what matters is what produces value. This value can be a business value like increase percentage of conversion in the landing page. Or it can be an engineering value like refactor this module, because it was a tech debit and will make the software easier to maintain and the developers more productive.
## Productivity Engineering
We can always improve the developer experience and productivity.
- Use the Checklist Manifesto by Dr. Atul Gawande: adoption of checklists has drastically reduced errors in fields after fields. eg. Pilots with pre-flight checklists. Surgeons with operations checklist. ToDo list for a feature implementation, from database design to backend to frontend, and automated tests.
- Protect your schedule: engineers need longer and more contiguous blocks of time. Focused time, called by flow by psychologist Mihály Csíkszentmihályi. Flow is a state of effortless concentration so deep that they lose their sense of time, of themselves, of their problems. When possible preserve larger blocks of focused time in your schedule.
- Limit the amount of work in progress: it can be tempting to try to tackle many things at once. When we fragment our attention too much, we end up reducing our overall productivity
## Invest in iteration speed
To improve the iteration speed, we need to basically improve the engineering cycle. From when the engineer gets a new task to shipping it to production. When the iteration speed is fast, we take business opportunities and we learn faster.
- Move fast to learn fast: The faster that you can iterate, the more that you can learn about what works and what doesn't work. With the “Move fast and break things” mantra, Facebook is a brilliant example of why investing in iteration speed is such a high-leverage decision. Many new employees ship code to production in their first few days. Facebook's culture emphasizes iterating quickly and focusing on impact rather than being conservative and minimizing mistakes. When you move too slowly trying to avoid mistakes, you lose opportunities.
- Invest in time-stamping tools
- “I've found that almost all successful people write a lot of tools. A very good indicator of future success of the first things a person did on a problem was to write a tool.” - Bobby Johnson, former Facebook director of infrastructure engineering.
- “if you have to do something manually more than twice, then write a tool for the third time” - Raffi Krikorian, former VP of Platform Engineering at Twitter.
- The time-saving tools also scale with team adoption. A tool that saves you one hour per day saves 10 times as much when you get 10 people on your team to use it. That's why companies like Google, Facebook have entire teams devoted to improving internal development tools.
## Master your programming environment
To improve your experience developing software, mastering your coding environment is essential to be productive.
- Get proficient with your favorite text editor or IDE: figure out the workflows for efficient file navigation, search, replace, auto-completion. Learn and practice.
- Get familiar with shell commands: use grep, sort, uniq, find, wc, awk, etc.
- Prefer keyboard over mouse: moving our hands back and forth from the keyboard to the mouse takes time. Many applications offer keyboard shortcuts. This an opportunity for optimization.
- Automate your manual workflows: as a rule of thumb, once you've manually performed a task three or more times, start thinking if it would be worthwhile to automate that task. Example: setup a hot reload for frontend development. When you update the HTML or CSS files, it would automatically update the browser.
- Test out ideas on an interactive interpreter: Python, Ruby, and Javascript have interpreters available to test your code. Use it to build confidence that your program behaves as expected. The REPL is a very good tool to test our code and consistently get feedback.
## Measure what you want to improve
To see if our work is having a real impact, we need metrics.
Google, for example, use metrics for the quality of the search
- Dan Russel, tech lead responsible for search quality at Google, explains that user happiness is correlated to “that sense of delight”. Example: when a user query 28 euro to usd and automatically converts it to you.
- Steven Levy: the best indication of user happiness is “long click”. When someone clicks a search result and doesn't return to the search page, or stays on the result page for a long time.
- A good example of the frontend world is the performance metrics for the browser. Google created the Web Vitals, the way to measure user experience related to web performance.
- What you don't measure is important as well: most call centers asses the performance of customer service representatives using their “average handle time”. Reducing this metric saves costs because employees handle more phone calls per day. But this was not something that Tony Hsieh, Zappos CEO, actually want to optimize for. “This [metric] translates into reps worrying about how quickly they can get a customer off the phone, which in our eyes is not delivering great customer service.. we just care about whether the rep goes above and beyond for every customer”.
- Internalize useful numbers: Percona can audit your database and show how well it's performing. They internalize useful numbers as how slow queries are, number of connections, so they can benchmark a particular system's performance. The knowledge of useful numbers provides a valuable shortcut for knowing where to invest effort to maximize gains.
## Instrument everything to understand what is going on
Monitoring errors and system reliability have a huge importance in software engineering.
- Jack Dorsey, Twitter Co-Founder, told that one of the most valuable lessons he learned years at Twitter was the importance of instrument everything. “For the first 2 years of Twitter, we were flying blind. We had no idea what was going on with the network. We had no idea what was going on with the system, because we could not see what was happening”. After Twitter engineers started monitoring and instrumenting their systems were they able to identify problems and build a much more reliable service.
- Adopting a mindset of instrumentation means ensuring we have a set of dashboard that surface key health metrics and that enable us to drill down the relevant data.
## Validate your ideas early and quickly
Sometimes we have ideas to make the product or the software better, but we are not sure if it really works. Validate your ideas early and quickly to see if it is worth the time and effort, if it can be improved.
- Iteration provides opportunities to validate new ideas. Iterate quickly to validate quickly.
- Little efforts to validate if it is worth doing large implementations. It can be a very small implementation to see if the idea works. It can talking to a more experienced engineer to see if you are not forgetting anything. It can be presentation for the team explaining the change you want to do. It can be a ADR (Architecture Decision Record). Find ways to get feedback.
- Reduce risks by breaking the project in small pieces. When you have smaller pieces, you have more control and less risks of doing the wrong thing or doing much more than the expected. This idea works well when refactoring a legacy codebase. Refactor very small pieces, run the tests, and see how the system behaves.
## Balance quality with pragmatism
As software engineers, we always need to strive for quality. Sometimes we don't control over the quality because of a deadline or any other issue in the project. But we always need to find opportunities to the best work possible, but with pragmatism.
Implementing an abstraction that will take 2 days but will improve the software quality and make developers productive is a good idea. Implementing an abstraction that will take a month can be a signal to not do it now.
The idea is to write down the tradeoffs and find the balance in our decisions.
- Manage complexity through abstraction: it solves the hard problems once and enables the solutions to be used multiple times.
- “Pick the right ones (abstraction), and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely to fit in without extensive reorganization. Pick the wrong ones, and programming will be a series of nasty surprises; interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make”
## Activities where automation can help
- Validating that a piece of code, an interaction, or a system behaves as expected
- Detecting spikes in the error rate
- Checking code to ensure it conforms to style guidelines
600 pages of one of the geniuses of history. But Leonardo was a genius not only because of his accomplishments but also because of the process of his results. Obsessed with details, respecting the facts, trying different experiences to prove his hypothesis, and just following his curiosity. He is an artist, an engineer, an architect, a theater producer, and so many more different things. This book tries to capture all nuances and details about his life and how he was really different.
I come from a place that I'm pretty familiar with TypeScript before reading this book. But it was a great experience learning more about this language in depth.
The first chapter was awesome in a way that the book shows more about language than simply about the syntax. It talks about the relationship between JavaScript and TypeScript, how does the structural typing works, the differences between the type and value spaces.
The second chapter talks more about how TypeScript can improve the developer experience together with a code editor.
The following chapters are about how we can use types to be more effective.
I used this book as a reference to write my long-format essay about A Mental Model to think in TypeScript (https://leandrotk.github.io/tk/2020/07/a-mental-model-to-think-in-typescript/index.html).
I really recommend this book for beginners and experienced developers.
I've been reading this book for 4 years now. Usually, Algorithm books are not the type of book that you read from front-to-back in one seat. It works more like a reference book. You are curious about Binary Search Tree, you get the chapter, read the theory, understand the concepts, and try to implement it. The book has all this experience, from theory and concepts to Python implementations and exercises to practice. I'm not sure if the authors use the Python best practices or clean code. Some bits are just difficult to understand.
This book was recommended by a very talented friend, but it took 2 years to start reading this piece. At first, the title seemed too magical, but I liked how the author deconstructed what it is like to be an Original person. For each chapter, he talks about the story of a successful person mixed and supported by social researches by his and other brilliant researchers' experiments. Even though all the concepts behind his ideas made sense to me, I think it is really difficult to unpack the idea of all Originals (aka innovative and successful people) into a 200 pages book.
