Skip to content

Favorite Quotes

"...by designing architecture with reversibility in mind, changes will be less costly."By Fundamentals of Data Engineering
"...expecting data scientists to know about infrastructure is like expecting app developers to know about how Linux kernels work"By Designing Machine Learning Systems
"...having a clear articulation of what is the problem first often helps us come up with better solutions.""Introduction to Machine Learning in Production" Course by DeepLearning.AI
"...positive thinking can blind us to the possibility of terrorist attacks or medical emergencies and deter preparation. Negative thinking allows us to consider disastrous scenarios and act to prevent them."By Fundamentals of Data Engineering
"...teams get overly exuberant with shiny object syndrome. They feel compelled to reach for the latest and greatest technology fad without understanding how it will impact the value of the project."By Fundamentals of Data Engineering
"...the swiftest way to grow a company is to grow its people"Serverless Development on AWS
"Accountability has its role, but it’s much more important to understand the problem at hand and try to fix it directly than to create process-driven accountability."Staff Engineer: Leadership beyond the management track
"Adding manpower to a late software project makes it later."Brooks's Law
"Adoption and usability of your tools are much more important than raw power. A powerful tool that’s difficult to use will get a few power users, but most folks will pass it by."Staff Engineer: Leadership beyond the management track
"Agile Is Not a Noun; Agile Is How You Do Things"By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"A good idea is an orphan without effective communication."By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"a leader being open about their mistakes will make it easier for everyone else to do the same: it’s a big boost to the team’s psychological safety"—The Staff Engineer's Path
"a leader being open about their mistakes will make it easier for everyone else to do the same: it’s a big boost to the team’s psychological safety"—The Staff Engineer's Path
"Alert fatigue is a real phenomenon, as discussed previously in this chapter. Alert fatigue can be demoralizing—nobody likes to be awakened in the middle of the night for something outside of their responsibilities. It’s also dangerous—being exposed to trivial alerts can desensitize people to critical alerts."By Designing Machine Learning Systems
"All data is unbounded until it’s bounded."By Fundamentals of Data Engineering
"All too often, it’s easy to criticize a prior team’s work and decisions, but it is far better to dig deep, ask questions, and understand why decisions were made. Empathy and context go a long way in helping you diagnose problems with the existing architecture, identify opportunities, and recognize pitfalls."By Fundamentals of Data Engineering
"A lot of people confuse architecture and tools. Architecture is strategic; tools are tactical."By Fundamentals of Data Engineering
"Always make the other person happy about doing the thing you suggest."How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"Always prioritize requirements over building something cool."By Fundamentals of Data Engineering
"Always remember that demonstration defeats discussion."By Fundamentals of Software Architecture
"Always take small, deliberate steps, checking for feedback and adjusting before proceeding."By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"always try to use the person’s name during a conversation or negotiation. Not only do people like hearing their name during a conversation, it also helps breed familiarity."By Fundamentals of Software Architecture
"An investment in knowledge always pays the best interest."Benjamin Franklin
"Another effective negotiation tactic when negotiating with a developer or trying to convince them to accept a particular design or architecture decision they disagree with is to have the developer arrive at the solution on their own."
By Fundamentals of Software Architecture
"Any fool can try to defend his or her mistakes—and most fools do—but it raises one above the herd and gives one a feeling of nobility and exultation to admit them first."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"Any technology decisions should be driven by the value they’ll deliver to your customers"
By Fundamentals of Data Engineering
"a person usually has two reasons for doing a thing: one that sounds good and a real one."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"A quote I love from Seneca is “Luck is what happens when preparation meets opportunity.”"
Staff Engineer: Leadership beyond the management track
"architects should strive to design architecture to be as iterative as possible. If you can make changes to the architecture more easily, you can stress less about discovering the exact correct thing in the first attempt."
By Fundamentals of Software Architecture
"architecture is independent from the development process"
By Fundamentals of Software Architecture
"Architecture is the what, why, and when. Tools are used to make the architecture a reality; tools are the how."
By Fundamentals of Data Engineering
"A reassignment from the technical ladder to a corresponding level on the managerial one should never be accompanied by a raise, and it should be announced always as a "reassignment," never as a "promotion.""
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"As a leader, you have a responsibility to make the implicit explicit. It’s not fair, but if a junior person asks these questions, the team may sigh and say, yes, obviously we thought of that. If an expert asks, team members learn that they should include explicit answers to these questions in their design documentation"
—The Staff Engineer's Path
"as an architect, pay close attention to developer flow and be sure not to disrupt it by calling a meeting. Flow is a state of mind developers frequently get into where the brain gets 100% engaged in a particular problem, allowing full attention and maximum creativity."
By Fundamentals of Software Architecture
"A series of numbers might mean nothing to you, but visualizing them on a graph might reveal the relationships among these numbers. Dashboards to visualize metrics are critical for monitoring."
By Designing Machine Learning Systems
"A show of interest, as with every other principle of human relations, must be sincere. It must pay off not only for the person showing the interest, but for the person receiving the attention. It is a two-way street—both parties benefit."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"Ask for the meeting agenda ahead of time to help qualify if you are really needed at the meeting or not."
By Fundamentals of Software Architecture
"Ask yourself, “If I’m asking a what or when question, what action do I take next?” If the action is repetitive, it is a candidate for automation. Why look at a report to determine whether to take action when you can instead automate the action based on events as they occur?"
By Fundamentals of Data Engineering
"A small sharp team is best—as few minds as possible."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"As many life coaches would tell you, focus on the present. You should choose the best technology for the moment and near future, but in a way that supports future unknowns and evolution. "
By Fundamentals of Data Engineering
"A surprising number of projects are one small change away from succeeding, one quick modification away from unlocking a new opportunity, or one conversation away from consensus. With your organizational privilege, relationships you’ve built across the company, and ability to see around corners derived from your experience, you can often shift a project’s outcomes by investing the smallest ounce of effort, and this is some of the most valuable work you can do."
staffeng.com/guides/work-on-what-matters
"A team that doesn't continuously experiment with their process is not an agile team."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Avoid being too argumentative or letting things get too personal in a negotiation—calm leadership combined with clear and concise reasoning will always win a negotiation"
By Fundamentals of Software Architecture
"Bad software architects leverage their title to get people to do what they want them to do. Effective software architects get people to do things by not leveraging their title as architect, but rather by leading through example, not by title. "
By Fundamentals of Software Architecture
"because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don’t know we don’t know."Former United States Secretary of Defense Donald Rumsfeld
"Because the dev environment is where engineers work, improvements in the dev environment translate directly into improvements in engineering productivity"
By Designing Machine Learning Systems
"Beginning with praise is like the dentist who begins his or her work with Novocain. The patient still gets a drilling, but the Novocain is pain-killing."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"Being able to take control of a mess is a key aspect of technical leadership. If security detects a breach, a database gets dropped, or a meteor hits US-East-1, there are likely to be many responders. Unless they’re working together, the ensuing chaos can make the problem worse. Everything goes better if someone is coordinating."
—The Staff Engineer's Path
"Being able to take control of a mess is a key aspect of technical leadership. If security detects a breach, a database gets dropped, or a meteor hits US-East-1, there are likely to be many responders. Unless they’re working together, the ensuing chaos can make the problem worse. Everything goes better if someone is coordinating."
—The Staff Engineer's Path
"Be warned that, when you delegate, you’re not going to get a clone. (Sorry, we don’t have that technology yet.) Inevitably the person you’ve delegated to is going to take a different approach than you would have. Be a guardrail, coach them, and ask questions, but inhibit the urge to step in. So long as they’re going to achieve the goals, let them do it their way."
—The Staff Engineer's Path
"Build custom solutions and code only where this creates a competitive advantage"
By Fundamentals of Data Engineering
"Build small pieces of end-to-end functionality, learning about the problem as you go. Apply this learning as you continue to flesh out the code, involve the customer at each step, and have them guide the process."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Build the code, not your ego. It's not about who's brightest; we all have our moments, good and bad."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"By documenting a design, the designer exposes himself to the criticisms of everyone, and he must be able to defend everything he writes. If the organizational structure is threatening in any way, nothing is going to be documented until it is completely defensible."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Celebrate shipping things to users, rather than milestones that are only visible to internal teams. You don’t get to celebrate until users are happily using your system. If you’re doing a migration, celebrate that the old thing got turned off, not that the new thing got launched."
—The Staff Engineer's Path
"Celebrate shipping things to users, rather than milestones that are only visible to internal teams. You don’t get to celebrate until users are happily using your system. If you’re doing a migration, celebrate that the old thing got turned off, not that the new thing got launched."
—The Staff Engineer's Path
"Code versioning has more or less become a standard in the industry. However, at this point, data versioning is like flossing. Everyone agrees it’s a good thing to do, but few do it."
By Designing Machine Learning Systems
"Companies don’t hire engineers simply to hack on code in isolation. To be worthy of their title, engineers should develop a deep understanding of the problems they’re tasked with solving, the technology tools at their disposal, and the people they work with and serve."
By Fundamentals of Data Engineering
"Criticize the code, not the person. “Let's look at this block” sounds much better than “you're wrong.”"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Defining leadership and management is such heavily trodden terrain that it’s hard to add much to it, but roughly management is a specific profession, and leadership is an approach one can demonstrate within any profession."
Staff Engineer: Leadership beyond the management track
"Delight Users, Don't Just Deliver Code"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Depending on the audience of the alert, it’s often necessary to make the alert actionable by providing mitigation instructions or a runbook, a compilation of routine procedures and operations that might help with handling the alert."
By Designing Machine Learning Systems
"Developers are drawn to complexity like moths to a flame—frequently with the same result."
By Fundamentals of Software Architecture
"Don't adopt new tech, frameworks, or libraries just because “everyone is doing it,” or based on something you saw at a conference or read online. Deliberately vet candidate technologies with prototypes. Put tasks on the schedule to try the new things and analyze results."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Don't be afraid to make suggestions that change the requirement if you can demonstrate that they will move the project closer to the objective."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Don't be a slave to history. Don't let existing code dictate future code. All code can be replaced if it is no longer appropriate."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Don't rely on the properties of things you can't control."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Don't spoil a perfectly good program by overembellishment and overrefinement. Move on, and let your code stand in its own right for a while. It may not be perfect. Don't worry: it could never be perfect."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Don't Think Outside the Box—Find the Box"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Don’t worry about stating the obvious in a checklist. It’s the obvious stuff that’s usually skipped or missed."
By Fundamentals of Software Architecture
"Do What Works, Not What's Fashionable"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Effective visions ground themselves in serving your users and your business. That tight connection keeps the vision aligned with your leadership team’s core values–users and business. Bad visions treat technical sophistication as a self-justifying raison d’être–a view that is never shared by your company’s leadership."
Staff Engineer: Leadership beyond the management track
"Embrace the fact that debugging is just problem solving, and attack it as such."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Escalating doesn’t mean raising a ruckus or complaining about the other team. It means holding a polite conversation with someone who has the power to help, and trying to solve a problem together. Keep it constructive."
—The Staff Engineer's Path
"Estimates given at the coffee machine will (like the coffee) come back to haunt you."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Even after you begin implementation, listen to reality’s voice and remain open to changes."
Staff Engineer: Leadership beyond the management track
"Even for a short document, I recommend an "abstract" or an "executive summary". Nothing is more powerful than explaining the crux of your arguments in three paragraphs or less."
— Getting Started with Data Science
"Even for the most private of programs, prose documentation is necessary, for memory will fail the user-author."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Even on the most internal project, you have “customers”: someone is going to use the things you’re creating. Sometimes you’ll be your own customer. Most of the time it’s going to be other people. If you don’t understand what your customers need, you’re not going to build the right thing"
—The Staff Engineer's Path
"Every time you find yourself doing something repetitive, get into the habit of thinking “there must be a better way.” Then find it."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Expect that knowledge to decay a little every day. The system will never again be as well understood as it is on the day it’s created"
—The Staff Engineer's Path
"fail to refactor now, and there'll be a far greater time investment to fix the problem down the road—when there are more dependencies to reckon with. "
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"faster is safer. The health of your product and the speed of development are not actually in opposition to each other, and products that release more frequently and in small batches have better quality outcomes."
— Software Engineering at Google
"Faults are a natural part of any architecture. Think of your strategy to recover and manage faults."
Serverless Development on AWS
"Flaky tests will promote a culture of easily ignoring test results and quickly erode confidence in your test strategy, similar to an alert that is always ignored."
Serverless Development on AWS
"Gather perspectives widely but write alone. Just be careful not to fall in love with what you’ve written until after you’ve reviewed it with others."
Staff Engineer: Leadership beyond the management track
"Get out and talk to people, and avoid working in silos. We often see the data team working in a bubble, not communicating with people outside their departments and getting perspectives and feedback from business stakeholders. The danger is you’ll spend a lot of time working on things of little use to people"
By Fundamentals of Data Engineering
"Given the pace of change—and the decoupling/modularization of technologies across your [data] architecture—always strive to pick the best-of-breed solutions that work for today. Also, be prepared to upgrade or adopt better practices as the landscape evolves."
By Fundamentals of Data Engineering
"Good cooking takes time; some tasks cannot be hurried without spoiling the result."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Good Design Is Easier to Change Than Bad Design"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Good questions are asked with the desire to learn, and they are specific. They sharpen the conversation. They free the answerer from the obligation to defend their position."
Staff Engineer: Leadership beyond the management track
"Good strategies are opinionated. If they aren’t opinionated, then they won’t provide any clarity on decision making."
Staff Engineer: Leadership beyond the management track
"Good strategies guide tradeoffs and explain the rationale behind that guidance. Bad strategies state a policy without explanation, which decouples them from the context they were made."
Staff Engineer: Leadership beyond the management track
"great vision is usually so obvious that it bores more than it excites."
Staff Engineer: Leadership beyond the management track
"Hold yourself accountable to the same pressures your manager experiences. Work through their fear of what could go wrong, and create excitement for how much can go right."
Staff Engineer: Leadership beyond the management track
"How does one control a big project on a tight schedule? The first step is to have a schedule"
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"I do not believe you can do today’s job with yesterday’s methods and be in business tomorrow."Nelson Jackson
Serverless Development on AWS
"if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"If a bug slips through the net of existing tests, you need to add a new test to trap it next time."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"If an architect has a great idea but can’t figure out a way to present it effectively, they will never get a chance to realize that vision."
By Fundamentals of Software Architecture
"If an architect thinks they have discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet."
By Fundamentals of Software Architecture
"If a person makes a statement that you think is wrong—yes, even that you know is wrong—isn’t it better to begin by saying: “Well, now, look. I thought otherwise, but I may be wrong. I frequently am. And if I am wrong, I want to be put right. Let’s examine the facts.”"
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"if a presenter wants to make a point, insert a blank slide—everyone in the room will focus their attention back on the speaker because they are now the only interesting thing in the room to look at."
By Fundamentals of Software Architecture
"If architects never allow other roles to make decisions of consequence, the organization will struggle with empowering the next generation of architects."
By Fundamentals of Software Architecture
"If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"If someone needs to take notes, raise your hand. If someone needs to follow up on action items, be available. Prioritize being useful, especially when it isn’t the most exciting work."
Staff Engineer: Leadership beyond the management track
"If the meeting doesn’t have notes, was it really worth getting together? Meeting notes are a great example of glue work. If a junior person is taking notes, they’re unable to participate, and it’s considered low-status administrative work. If a senior person takes notes, they’re making sure the meeting is effective, and everyone’s very impressed!"
—The Staff Engineer's Path
"If the meeting doesn’t have notes, was it really worth getting together? Meeting notes are a great example of glue work. If a junior person is taking notes, they’re unable to participate, and it’s considered low-status administrative work. If a senior person takes notes, they’re making sure the meeting is effective, and everyone’s very impressed!"
—The Staff Engineer's Path
"If there is some point you haven’t thought about, be thankful if it is brought to your attention. Perhaps this disagreement is your opportunity to be corrected before you make a serious mistake."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"If you can reach your goal by empowering someone else to do better work, that’s just as much a victory as if you solve it yourself. Consider your impact to be what wouldn’t have happened without you, not just what you personally did."
—The Staff Engineer's Path
"If you can reach your goal by empowering someone else to do better work, that’s just as much a victory as if you solve it yourself. Consider your impact to be what wouldn’t have happened without you, not just what you personally did."
—The Staff Engineer's Path
"If you can’t resist the urge to include your most brilliant ideas in the process, then you can include them in your prework. Write all of your best ideas in a giant document, delete it, and never mention any of them again. Now that those ideas are out of your head, your head is cleared for the work ahead."
Staff Engineer: Leadership beyond the management track
"if you could speak only a few words per month, you would probably try to make them worth listening to"
By Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow, 3rd Edition
"If you ever find yourself in a conversation with an unclear goal, then define the purpose. Take a moment to ask if your understanding of what the group hopes to accomplish is correct."
Staff Engineer: Leadership beyond the management track
"If you have no objections, say so."
—The Staff Engineer's Path
"If you only see the gap without acting on it, you might be a visionary, but you’re inert. If you take action without a clear view of the goal, many will consider you a leader, but your impact will be random, arbitrary, and inefficient. Combining both with some luck is likely to take you a long way in your career..."
Staff Engineer: Leadership beyond the management track
"If you realize that you’ve rehashed the same discussion three or four times, it’s time to write a strategy."
Staff Engineer: Leadership beyond the management track
"If you really want to reduce complexity, use pictures. There’s no easier way to help people visualize what you’re talking about. If something’s changing, a set of “before” and “after” pictures can be clearer than an entire essay"
—The Staff Engineer's Path
"If your first reaction on witnessing a bug or seeing a bug report is “that's impossible,” you are plainly wrong. Don't waste a single neuron on the train of thought that begins “but that can't happen” because quite clearly it can, and has."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"if you tell them they are wrong, do you make them want to agree with you? Never! For you have struck a direct blow at their intelligence, judgment, pride, and self-respect. That will make them want to strike back. But it will never make them want to change their minds."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"If you want to delight your client, forge a relationship with them where you can actively help solve their problems. Even though your title might be some variation of “Software Developer” or “Software Engineer,” in truth it should be “Problem Solver.”"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"If you’re adding custom load balancing, extra caching, or automatic region failover, explain why it’s worth the extra time and effort. “We might need it later” is not a good enough justification."
—The Staff Engineer's Path
"If you’re introducing a culture change, be patient. It takes a lot of time and dedicated effort to make everyone behave in a different way, but it’s the only way you’ll ever be able to stop pushing the process along manually."
—The Staff Engineer's Path
"If you’re setting off to do something and you don’t know why, chances are you’ll do the wrong thing. You might complete the work without solving the real problem you were intended to solve"
—The Staff Engineer's Path
"If you’re stuck articulating the problem, show what you have to five people and ask them what's missing: fresh eyes always see the truth."
Staff Engineer: Leadership beyond the management track
"if you’re trying to run a project with a title like “unofficial lead,” that’s an invitation to fail—if you’re the lead and nobody else knows you are, you’re not the lead."
—The Staff Engineer's Path
"Ignore a spew of tests that “always fail” makes it easier to ignore all the tests, and the vicious spiral begins"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"I have come to the conclusion that there is only one way under high heaven to get the best of an argument—and that is to avoid it."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"I kind of think writing about engineering strategy is hard because good strategy is pretty boring, and it’s kind of boring to write about. Also I think when people hear “strategy” they think “innovation”."Camille Fournier
Staff Engineer: Leadership beyond the management track
"Imposter syndrome is a horrible, insecure feeling: it can even make you do less good work because you don’t feel safe taking calculated risks. Take comfort in the fact that it’s common, even at this level. Find opportunities to put ability points into something that makes you nervous, and show yourself that it’s just another learnable, knowable topic. But most of all: if you’re “impostoring,” try to give yourself a break. Nobody knows everything."
—The Staff Engineer's Path
"Incident response isn’t just about technology and tools, though these are beneficial; it’s also about open and blameless communication"
By Fundamentals of Data Engineering
"In earlier roles, you may have tried to influence decisions towards technology choices you were motivated by; in senior positions, you’re accountable to the business and organization first and yourself second."
Staff Engineer: Leadership beyond the management track
"In more senior roles, you’re often in the right place to provide input when it’s relatively cheap to incorporate, where otherwise your feedback might not be incorporated–despite being very valuable–because the related roll out or implementation has advanced too far."
Staff Engineer: Leadership beyond the management track
"Instead of being completely DRY, test code should often strive to be DAMP—that is, to promote “Descriptive And Meaningful Phrases.” A little bit of duplication is OK in tests so long as that duplication makes the test simpler and clearer."
Software Engineering at Google
"it can be overwhelming to track too many things, and tracking less important things can distract you from tracking what is really important."
By Designing Machine Learning Systems
"It doesn't really matter whether the bug is your fault or someone else's. It is still your problem."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"It is always easier to listen to unpleasant things after we have heard some praise of our good points."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"It is far better to be explicit and wrong than to be vague."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"It is inevitable that you’ll meet some roadblocks and have to change direction, and you’ll have a better time if you go into the project assuming something is going to go wrong—you just don’t know yet what it will be. This attitude can help you be more flexible, so you’ll find it sort of interesting when the roadblock arrives, rather than being frustrated by it."
—The Staff Engineer's Path
"It is really difficult to watch work that you care about being done badly, but try not to step in and do it for them. If it’s critical that the problem gets solved right now, see if you can work with the other person and get them to take each step, rather than just doing it yourself. Your colleague won’t learn to drive if you take the wheel."
—The Staff Engineer's Path
"It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you’ll do things differently."Warren Buffett
"it’s a better use of your time to be wrong or controversial than it is to be vague. If you’re wrong, people will tell you and you’ll learn something, and you can change direction if you need to. If you’re trying out a controversial idea, you can find out early whether your colleagues will pull against your approach. Having disagreements about your design doesn’t mean that you need to change course, but it gives you information you wouldn’t have had otherwise."
—The Staff Engineer's Path
"it’s easy for researchers to put off fairness as an afterthought: “Let’s try to get state of the art first and worry about fairness when we get to production.” When it gets to production, it’s too late. If you optimize your models for better accuracy or lower latency, you can show that your models beat state of the art. But there’s no equivalent state of the art for fairness metrics."
By Designing Machine Learning Systems
"It’s fine to use a few extra words or even repeat yourself if it means avoiding ambiguity"
—The Staff Engineer's Path
"It’s important to pick the right metrics or abstract out lower-level metrics to compute higher-level signals that make better sense for your specific tasks."
By Designing Machine Learning Systems
"It’s much harder to explain something simply! It requires more understanding of the topic and more self-awareness about your own context. But it’s a real indicator of expertise. If you can explain a topic in plain language, so that nonexperts can hook it onto something they already understand, you really understand it. "
—The Staff Engineer's Path
"It’s much harder to explain something simply! It requires more understanding of the topic and more self-awareness about your own context. But it’s a real indicator of expertise. If you can explain a topic in plain language, so that nonexperts can hook it onto something they already understand, you really understand it. "
—The Staff Engineer's Path
"Knowing how to navigate an organization, scope and gather requirements, control costs, and continuously learn will set you apart from the [data] engineers who rely solely on their technical abilities to carry their career."
By Fundamentals of Data Engineering
"Know who uses your software and know how they use it. Make sure they can use the thing you’re creating for them, and that they want to."
—The Staff Engineer's Path
"Learn the mental model. Don’t focus on the implementation details."
Serverless Development on AWS
"Listen and try to understand others' viewpoints. Different isn't wrong."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Listen to your stakeholders. If they bring up issues—and they inevitably will—try not to take offense. Instead, use this as an opportunity to improve what you’ve built."
By Fundamentals of Data Engineering
"Maintaining a good balance between being pragmatic, yet visionary, is an excellent way of gaining respect as an architect. Business stakeholders will appreciate visionary solutions that fit within a set of constraints, and developers will appreciate having a practical (rather then theoretical) solution to implement."
By Fundamentals of Software Architecture
"management should never be seen as a promotion—it’s a change of profession with a different set of skills to learn. There should be no change in status when you go from people leadership to technical leadership or vice versa: each will build a separate set of skills, and will enhance the skills on the other side"
—The Staff Engineer's Path
"Many think the more code, the better. In fact, running software in production for a long period of time has proven the opposite to be true: code is a liability."
Serverless Development on AWS
"ML production would be a much better place if ML experts were better software engineers"
By Designing Machine Learning Systems
"modules of code should be encapsulated with well-defined interfaces, and that the interior of such a module should be the private property of its programmer, not discernible from outside. Programmers are most effective if shielded from, not exposed to, the innards of modules not their own."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"More users find more bugs."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Much of the time, tomorrow looks a lot like today. But don't count on it."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Never begin by announcing, “I am going to prove so-and-so to you.” That’s bad. That’s tantamount to saying: “I am smarter than you are. I am going to tell you a thing or two and make you change your mind.”"
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"Never shoot for the best architecture, but rather the least worst architecture."
By Fundamentals of Software Architecture
"Never shoot for the best architecture, but rather the least worst architecture."
By Fundamentals of Software Architecture
"No architecture decision should be made isolated from the implementation team"
By Fundamentals of Software Architecture
"No matter how brilliant an architect’s technical ideas, if they can’t convince managers to fund them and developers to build them, their brilliance will never manifest."
By Fundamentals of Software Architecture
"Nothing is more dangerous than an idea if it's the only one you have."
Emil-Auguste Chartier
"Offload the parts that are not unique to your application to services and SaaS offerings that can implement those functionalities for you. Focus on what you want to build. It’s there where you can make a difference."
Serverless Development on AWS
"Once a human tester finds a bug, it should be the last time a human tester finds that bug. The automated tests should be modified to check for that particular bug from then on, every time, with no exceptions, no matter how trivial, and no matter how much the developer complains and says, “Oh, that will never happen again.”"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road."Stewart Brand
"One molehill of a word can make a mountain of difference. When “but” appears, the praise, however sincere, proves to be a mere lead-in to what you really want to say. When used as sugarcoating, what began as a genuine compliment has now turned as sour as forgotten milk. The word “but” means trouble and the person on the receiving end knows it. Don’t use it! Find a better and more honest way to present your case."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"One of the best measures of your long-term success as a Staff-plus engineer is that the organization around you increasingly benefits from, but doesn’t rely upon, your contributions."
Staff Engineer: Leadership beyond the management track
"One of the biggest signs of respect for your coworkers is listening to them and then changing your mind afterward."
Staff Engineer: Leadership beyond the management track
"Organizations must be designed around the people available; not people fitted into pure-theory organizations."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
Conway's Law
"Overly investing in any particular methodology can leave you blind to alternatives. You get used to it. Soon it becomes hard to see any other way. You've become calcified, and now you can't adapt quickly anymore."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Owning decisions includes accepting that you might be wrong. Make the cost of a wrong decision as low as possible, and if it turns out that you are wrong, own that, too"
—The Staff Engineer's Path
"Owning decisions includes accepting that you might be wrong. Make the cost of a wrong decision as low as possible, and if it turns out that you are wrong, own that, too"
—The Staff Engineer's Path
"Owning your career isn’t only about asking for things. It is about that, but it’s much more about facilitating those things happening."
Staff Engineer: Leadership beyond the management track
"Perfection is achieved, not when there is nothing left to add but when there is nothing left to take away..."
Antoine de St. Exupery, Wind, Sand, and Stars, 1939
"Proceed from a plan, whether that plan is in your head, on the back of a cocktail napkin, or on a whiteboard"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"programmers who are two or three levels removed from the actual users of their code are unlikely to be aware of the context in which their work is used. They will not be able to make informed decisions."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Program size is not bad; unnecessary size is."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Prototyping is a learning experience. Its value lies not in the code produced, but in the lessons learned. "
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Providing the business value when justifying decisions is vitally important for any architecture decision. It is also a good litmus test for determining whether the architecture decision should be made in the first place."
By Fundamentals of Software Architecture
"Providing the justification or reason first is always a good approach. Most of the time, once a person hears something they disagree with, they stop listening."
By Fundamentals of Software Architecture
"Rather than a process for design review, try to instill a respect for design review and trust that teams will make their own choices about what form works for them. Offer some easy defaults, but don’t get hung up on whether everyone’s following exactly the same process"
—The Staff Engineer's Path
"Regular deliverables will discourage people from leaving everything until the end. Set clear expectations about what you expect to happen when."
—The Staff Engineer's Path
"Rely only on reliable things. Don't depend on assumptions. If you can't tell if something is reliable, assume the worst."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Remember, attention is a scarce resource! If you waste folks’ time with a nudge email or ping, they won’t pay attention to the next one."
Staff Engineer: Leadership beyond the management track
"Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Schedule disaster, functional misfits, and system bugs all arise because the left hand doesn't know what the right hand is doing."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Security through obscurity just doesn't work."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Shared State Is Incorrect State"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Shipping imperfect features should never be confused with promoting unilateral, careless engineering. Software engineering should always be a social activity and the needs of your users held in the highest regard. But the best software is always software that is being used. "
Serverless Development on AWS
"Software doesn’t age like fine wine. It ages poorly."
By Designing Machine Learning Systems
"some changes in objectives are inevitable, and it is better to be prepared for them than to assume that they won't come. Not only are changes in objective inevitable, changes in development strategy and technique are also inevitable."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Someone needs to be brave enough to say, “I don’t know what to do with the information you just gave me!” Take charge and ask. Tech can be fraught with egos and insecurity, and it’s sometimes scary (or legitimately risky!) for junior people to admit that they don’t know something. It’s safer for senior people to ask."
—The Staff Engineer's Path
"Someone needs to be brave enough to say, “I don’t know what to do with the information you just gave me!” Take charge and ask. Tech can be fraught with egos and insecurity, and it’s sometimes scary (or legitimately risky!) for junior people to admit that they don’t know something. It’s safer for senior people to ask."
—The Staff Engineer's Path
"Some people really resist asking for help. It feels like failure, maybe. But if you’re stuck and need help, the biggest failure is not asking for it. Don’t struggle alone."
—The Staff Engineer's Path
"Some senior folks feel like they need to weigh in on everything to justify their seniority. Others require each decision to exactly mirror a similar decision they once made. Both of these center insecurity over impact and prevent others from growing as leaders."
Staff Engineer: Leadership beyond the management track
"Sometimes even the most trivial-seeming decision becomes important when you gather feedback."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Sometimes it’s better to let someone set a pattern that’s good enough and not overrule them, even if you would have done it better."
—The Staff Engineer's Path
"Stay abreast of the field and learn how to learn"
By Fundamentals of Data Engineering
"staying involved in the implementation ensures that you feel the cost of your own architectural decisions as much as your team does."
—The Staff Engineer's Path
"Structuring an organization for change is much harder than designing a system for change."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Successful DataOps works when all people are on board and focus on making systems holistically work."
By Fundamentals of Data Engineering
"Successful data products reduce friction with the end user."
By Fundamentals of Data Engineering
"successful tools adapt to the hands that use them. Successful requirements gathering takes this into account. And this is why early feedback, with prototypes or tracer bullets, will let your clients say “yes, it does what I want, but not how I want.”"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"success in dealing with people depends on a sympathetic grasp of the other person’s viewpoint.”
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"Surprisingly, many users would rather use software with some rough edges today than wait a year for the shiny, bells-and-whistles version (and in fact what they will need a year from now may be completely different anyway)."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Swapping out or upgrading components in a monolith is often an exercise in trading one pain for another. Because of the tightly coupled nature, reusing components across the architecture is difficult or impossible"
By Fundamentals of Data Engineering
"System debugging, like astronomy, has always been done chiefly at night."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Technical solutions exist not for their own sake but in support of business goals."
By Fundamentals of Data Engineering
"Test Early, Test Often, Test Automatically"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Test State Coverage, Not Code Coverage"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"The architect must always be prepared to show an implementation for any feature he describes, but he must not attempt to dictate the implementation."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"The attraction to the strangler pattern is its tar­ge⁠ted and surgical approach of deprecating one piece of a system at a time. This allows for flexible and reversible decisions while assessing the impact of the deprecation on dependent systems."
By Fundamentals of Data Engineering
"The closer you test your code to production, the more valuable the results of these tests will be. You need to shift right on testing and make it later in your software’s delivery lifecycle."
Serverless Development on AWS
"The data field feels like it’s changing at light speed. People who succeed in it are great at picking up new things while sharpening their fundamental knowledge"
By Fundamentals of Data Engineering
"The first and most important rule when it comes to crypto is never do it yourself."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"The first step in controlling a big project on a tight schedule is to have a schedule, made up of milestones and dates for them."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"The fundamental problem with program maintenance is that fixing a defect has a substantial (20–50 percent) chance of introducing another. So the whole process is two steps forward and one step back."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"The highest barrier to adopting a practice of continuous delivery is typically a social one, rather than technological. Most engineers on your team will have worked in environments where releasing to production is someone else’s responsibility and approached with maximum caution."
Serverless Development on AWS
"The key to making effective architectural decisions is asking whether the architecture decision is helping to guide teams in making the right technical choice or whether the architecture decision makes the technical choice for them"
By Fundamentals of Software Architecture
"the more you value future rewards, the more you are willing to put up with some pain now for the promise of future bliss."
By Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow, 3rd Edition
"The most important single ingredient in the formula of success is knowing how to get along with people."Theodore Roosevelt
"The negative trade-off of reuse is coupling. When an architect designs a system that favors reuse, they also favor coupling to achieve that reuse, either by inheritance or composition."
By Fundamentals of Software Architecture
"the only company that can tolerate being constrained by you is a company that doesn’t grow. The only way to remain a long-term leader of a genuinely successful company is to continually create space for others to take the recognition, reward, and work that got you to where you’re currently sitting."
Staff Engineer: Leadership beyond the management track
"the only viable long-term bet on your career: focus on work that matters, do projects that develop you, and steer towards companies that value genuine experience."
Staff Engineer: Leadership beyond the management track
"The people you bring onto the project will make a huge difference in whether you meet your deadlines, complete visible tasks, and achieve your goals. Their success is your success, and their failure is very much your failure"
—The Staff Engineer's Path
"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"There's one technique that you must use if you want people to listen to you: listen to them. Even if this is a situation where you have all the information, even if this is a formal meeting with you standing in front of 20 suits—if you don't listen to them, they won't listen to you."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"There are no wrong answers in architecture, only expensive ones."
By Fundamentals of Software Architecture
"there is no point in developing software unless you care about doing it well."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"There is some expectation that you will write and review design documentation. That’s because it’s very difficult to have many people achieve something together without shared understanding, and it’s hard to be sure you have that shared understanding without a written plan."
—The Staff Engineer's Path
"The risks you take to increase delivery speed by reducing test coverage must always be counteracted with useful alerts, automated recovery from failure, and effective debugging of root causes."
Serverless Development on AWS
"the royal road to a person’s heart is to talk about the things he or she treasures most."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"The secret of getting ahead is getting started."Mark Twain
"The separation of architectural effort from implementation is a very powerful way of getting conceptual integrity on very large projects."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"The weakest link in security and privacy is you. Security is often compromised at the human level, so conduct yourself as if you’re always a target."
By Fundamentals of Data Engineering
"The work that’s most important will often be the work that nobody else sees. It might be a struggle to even articulate the need for it, because your teams don’t have good mental models for it yet. It might involve gathering data that doesn’t exist, or spelunking through dusty code or documents that haven’t been touched in a decade"
—The Staff Engineer's Path
"Thinking like an architect is knowing the difference between architecture and design and seeing how the two integrate closely to form solutions to business and technical problems."
By Fundamentals of Software Architecture
"Tired, stressed people often disagree about the right way to proceed. If you can stay calm and constructive and avoid casting blame, other people will too."
—The Staff Engineer's Path
"Tired, stressed people often disagree about the right way to proceed. If you can stay calm and constructive and avoid casting blame, other people will too."
—The Staff Engineer's Path
"To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Today’s hot technology or stack is tomorrow’s afterthought. Popular opinion shifts quickly. You should aim for reversible decisions, as these tend to simplify your architecture and keep it agile."
By Fundamentals of Data Engineering
"To lead, you have to follow"
Staff Engineer: Leadership beyond the management track
"To lead a team and become an effective leader, a software architect should try to become the go-to person on the team—the person developers go to for their questions and problems."
By Fundamentals of Software Architecture
"Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"To write an engineering strategy, write five design documents, and pull the similarities out. That’s your engineering strategy. To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future. That's your engineering vision."
Staff Engineer: Leadership beyond the management track
"Treat test code with the same care as any production code. Keep it decoupled, clean, and robust. Don't rely on unreliable things "
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Trust metrics over intuition."
Staff Engineer: Leadership beyond the management track
"Visions should be ambitious, but they shouldn’t be audacious. They should be possible, but the best possible version if possible. Do write what you could accomplish if every project is finished on time and without major setbacks. Don’t write what you think would be possible with infinite resources."
Staff Engineer: Leadership beyond the management track
"We all move faster when the going is safe"
—The Staff Engineer's Path
"We can be proud of our abilities, but we must own up to our shortcomings—our ignorance and our mistakes."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"We developers are incredibly privileged. We are truly building the future. It's an extraordinary amount of power. And with that power comes an extraordinary responsibility."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"We only get value from finishing projects, and getting a project over the finish line is the magical moment it goes from risk to leverage. Time spent getting work finished is always time well spent."
Staff Engineer: Leadership beyond the management track
"whatever you do will set expectations for the team. For that reason, it’s important to produce good work. Meet or exceed your testing standards, add useful comments and documentation, and be very careful about taking shortcuts"
—The Staff Engineer's Path
"What you can accomplish alone is far from what you can accomplish by creating leaders."
Staff Engineer: Leadership beyond the management track
"When evaluating ML solutions through the business lens, it’s important to be realistic about the expected returns. Due to all the hype surrounding ML some companies might have the notion that ML can magically transform their businesses overnight. Magically: possible. Overnight: no. "
By Designing Machine Learning Systems
"whenever someone says “do this, and you'll be agile,” they are wrong. By definition. Because agility, both in the physical world and in software development, is all about responding to change, responding to the unknowns you encounter after you set out."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"When heavily invested in a technology, a developer lives in a memetic bubble, which also serves as an echo chamber. Bubbles created by vendors are particularly dangerous, because developers never hear honest appraisals from within the bubble. But the biggest danger of Bubble Living comes when it starts collapsing, which developers never notice from the inside until it’s too late."
By Fundamentals of Software Architecture
"When I shared the graph showing how many had been done and how many were left to do, people were more eager to do their part to get the numbers down. Something in our brains really likes seeing a graph finish its journey to zero"
—The Staff Engineer's Path
"When ML algorithms are deployed at scale, they can discriminate against people at scale. If a human operator might only make sweeping judgments about a few individuals at a time, an ML algorithm can make sweeping judgments about millions in split seconds"
By Designing Machine Learning Systems
"When people follow regular security processes, security becomes part of the job."
By Fundamentals of Data Engineering
"When we plan projects, we often only list the parts of the work that are about writing the code. But there’s so much more that needs to happen to allow the user to get to the code: deploying and monitoring it, getting launch approvals, updating the documentation, making it run for real. The software being ready isn’t enough"
—The Staff Engineer's Path
"When we plan projects, we often only list the parts of the work that are about writing the code. But there’s so much more that needs to happen to allow the user to get to the code: deploying and monitoring it, getting launch approvals, updating the documentation, making it run for real. The software being ready isn’t enough"
—The Staff Engineer's Path
"When you find yourself saying, “I don't know,” be sure to follow it up with “—but I'll find out.” It's a great way to admit what you don't know, but then take responsibility like a pro"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"When you have a title, you don’t have to spend so much energy putting your credentials on the table. It helps set the context for others."
Staff Engineer: Leadership beyond the management track
"When you see a name that no longer expresses the intent, or is misleading or confusing, fix it."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"While most of us are comfortable with using a microwave without understanding how it works, many don’t feel the same way about AI yet, especially if that AI makes important decisions about their lives"
By Designing Machine Learning Systems
"With any creative activity come dreary hours of tedious, painstaking labor, and programming is no exception."
By Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition
"Without business domain knowledge, it is difficult to understand the business problem, goals, and requirements, making it difficult to design an effective architecture to meet the requirements of the business. "
By Fundamentals of Software Architecture
"Work with a User to Think Like a User"
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"you're not sure why it works, you won't know why it fails."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"You can make more friends in two months by becoming interested in people than you can in two years by trying to get people interested in you."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"you couldn’t be an effective long-term leader until you learn how to follow."
Staff Engineer: Leadership beyond the management track
"You know your own brain: do whatever makes you smart."
—The Staff Engineer's Path
"your colleagues won’t learn as much if you only delegate the work after you’ve turned it into “beautifully packaged, cleanly wrapped gifts.” If you instead give them “a messy, unscoped project with a bit of a safety net,” they’ll get a chance to hone their problem-solving abilities, build their own support system, and stretch their skill set. A messy project is a learning opportunity that’s hard to get otherwise."
—The Staff Engineer's Path
"Your junior engineers are future senior engineers. Give them the space to learn, and opportunities to do hands-on work and solve increasingly difficult problems"
—The Staff Engineer's Path
"Your organization, codebase, and production environment probably existed before you joined them. They’ll probably exist after you move on. Don’t optimize for now at the cost of future velocity or engineering ability. It’s OK to plant some seeds that you won’t personally see grow."
—The Staff Engineer's Path
"Your organization, codebase, and production environment probably existed before you joined them. They’ll probably exist after you move on. Don’t optimize for now at the cost of future velocity or engineering ability. It’s OK to plant some seeds that you won’t personally see grow."
—The Staff Engineer's Path
"Your signature should come to be recognized as an indicator of quality. People should see your name on a piece of code and expect it to be solid, well written, tested, and documented. A really professional job. Written by a professional."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"Your software delivery lifecycle starts with an engineer’s keyboard and finishes in production. The stability of your software depends on the optimization of the path from keyboard to production."
Serverless Development on AWS
"You shouldn't jealously defend your code against interlopers; by the same token, you should treat other people's code with respect."
By The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
"You should write design documents for any project whose capabilities will be used by numerous future projects. You should also write design documents for projects that meaningfully impact your users. You should write a design document for any work taking more than a month of engineering time."
Staff Engineer: Leadership beyond the management track
"you tell them they are wrong, do you make them want to agree with you? Never! For you have struck a direct blow at their intelligence, judgment, pride, and self-respect. That will make them want to strike back. But it will never make them want to change their minds."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
"You’ll have a profound impact on the folks you support as a manager, and if you take it on with the wrong motivations, you’ll regret the experience, but not nearly as much as your team will. If you’re motivated to help your team grow and succeed, then go ahead and do it; if you’re only doing it for yourself, then don’t."
Staff Engineer: Leadership beyond the management track
"you’ll learn more and more quickly from failing to roll out the easy stuff than failing to roll out the hard stuff."
Staff Engineer: Leadership beyond the management track
"You’re far more likely to change your company’s long-term trajectory by growing the engineers around you than through personal heroics."
Staff Engineer: Leadership beyond the management track
"You’re working as part of a team, not a collection of competing individuals. Don’t become a single point of failure where the team can’t get anything done when you’re not available. It’s not sustainable. It hides problems."
—The Staff Engineer's Path
"You’re working as part of a team, not a collection of competing individuals. Don’t become a single point of failure where the team can’t get anything done when you’re not available. It’s not sustainable. It hides problems."
—The Staff Engineer's Path
"[about latency] Higher percentiles are important to look at because even though they account for a small percentage of your users, sometimes they can be the most important users"
By Designing Machine Learning Systems
"[about metrics] If it moves, we track it."
etsy.com/codeascraft/measure-anything-measure-everything/
"[Data] Engineering is increasingly a discipline of interoperation, and connecting various technologies like LEGO bricks, to serve ultimate business goals."
By Fundamentals of Data Engineering
"“All men have fears, but the brave put down their fears and go forward, sometimes to death, but always to victory” was the motto of the King’s Guard in ancient Greece."
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
(About design document) "The “alternatives considered” section is where you demonstrate (to yourself and others!) that you’re here to solve the problem and you aren’t just excited about the solution. If you find yourself omitting this section because you didn’t consider any alternatives, that’s a signal that you may not have thought the problem through"
—The Staff Engineer's Path
“A good Three Bullets and a Call to Action email contains (at most) three bullet points detailing the issue at hand, and one—and only one—call to action. That’s it, nothing more—you need to write an email that can be easily forwarded along. If you ramble or put four completely different things in the email, you can be certain that they’ll pick only one thing to respond to, and it will be the item that you care least about. Or worse, the mental overhead is high enough that your mail will get dropped entirely.”
— Debugging Teams
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand."Martin Fowler
“Big data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.”Dan Ariely
“Consistency does not require perfection.”James Clear
“Cooperativeness in conversation is achieved when you show that you consider the other person’s ideas and feelings as important as your own. Starting your conversation by giving the other person the purpose or direction of your conversation, governing what you say by what you would want to hear if you were the listener, and accepting his or her viewpoint will encourage the listener to have an open mind to your ideas.”
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
“Describe the reality of the situation you’re in, so you won’t spend all your time being mad at reality for not being as you wish it to be”
—The Staff Engineer's Path
“Everything breaks all the time.”CTO of Amazon Web Services Werner Vogels
“He who treads softly goes far.”
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
“If there is any one secret of success, it lies in the ability to get the other person’s point of view and see things from that person’s angle as well as from your own.”
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
“If you argue and rankle and contradict, you may achieve a victory sometimes; but it will be an empty victory because you will never get your opponent’s good will.”
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
“If you can’t fix it you shouldn’t test it.”
Serverless Development on AWS
“If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there"Martin Zinkevich
Rules of Machine Learning: Best Practices for ML Engineering
“If you’re new to an existing project, don’t just jump in. Have a lot of conversations. Find out what half-built systems you’re going to have to use, work around, or clean up before you can start creating a new solution. Understand people’s feelings and expectations, and learn from their experiences”
—The Staff Engineer's Path
“In every work of genius we recognize our own rejected thoughts; they come back to us with a certain alienated majesty.”Ralph Waldo Emerson
“I wish there was a way to know you are in the good old days before you’ve actually left them”
The Office
“Men are ruled by toys.”Napoleon
“People who can put themselves in the place of other people, who can understand the workings of their minds, need never worry about what the future has in store for them.”
How to Win Friends and Influence People: Updated For the Next Generation of Leaders
“Respect what came before”— Amazon's Principal Engineering Community
“Sometimes five years of experience is just…the same year of experience, five times over.”
—The Staff Engineer's Path
“The tremendous power of the written word makes it much harder to misunderstand one another.”
—The Staff Engineer's Path
“What one programmer can do in one month, two programmers can do in two months.”Frederick P. Brooks
”The degree to which other people want to work with you is a direct indication of how successful you’ll be in your career as an engineer. Be the engineer that everyone wants to work with."
— On Being a Senior Engineer

Discover more from The Same Tech

Subscribe to get the latest posts to your email.