Quotes - romitagl/kgraph GitHub Wiki

Developer Facts

• A clever person solves a problem. A wise person avoids it. - Albert Einstein
• Everything should be made as simple as possible, but no simpler. - Albert Einstein
• Premature optimisation is the root of all evil. - Donald Knuth
• Premature abstraction is probably worse than premature optimization.
• Measure twice, cut once. - John Florio
• We learn nothing from being right. - Elizabeth Bibesco
• There is nothing more uncommon than common sense. – Frank Lloyd Wright
• A little copying is better than a little dependency. - Go Proverbs from @rob_pike
• Done Is Better Than Perfect.
• By failing to prepare; you are preparing to fail.
• Have patience; all things are difficult before they become easy.
• Rare things become common at scale
• Bending Spoons believes, as a principle, that they should seek out the most radically simple solution and approach and. When adding complexity, the person or team approaching should bring proof why this complexity is beneficial. Those who retain the simpler status should not have to defend this, unless there is evidence and data that adding more complexity truly helps.

Keep it simple.

Steve Jobs has a good quote on this: ‘Simple can be harder than complex. You have to work hard to get your thinking clean, to make it simple. But it’s worth it in the end because once you get there, you can move mountains.’

Simplicity is hard and requires being ruthless, but it allows so much scale.”

Remember the 90-90 rule when doing SW estimates:

In computer programming and software engineering, the ninety-ninety rule is a humorous aphorism that states: The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. — Tom Cargill, Bell Labs

Pareto principle:

80% of a piece of software can be written in 20% of the total allocated time. Conversely, the hardest 20% of the code takes 80% of the time.

Life

• True happiness comes from the zest of creating new things. - Antoinde De Saint-Exupery

• People do not decide to become extraordinary. They decide to accomplish extraordinary things. - Edmund Hillary

• The only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. - Steve Jobs

• The biggest communication problem is we do not listen to understand. We listen to reply. - Stephen Covey

• The hedonic treadmill, also known as hedonic adaptation, is the observed tendency of humans to quickly return to a relatively stable level of happiness despite major positive or negative events or life changes. According to this theory, as a person makes more money, expectations and desires rise in tandem, which results in no permanent gain in happiness.

• Striving for success without hard work is like trying to harvest where you haven't planted.

• What comes easy won't last, what lasts won't come easy.

• Winners focus on winning, losers focus on winners.

• Don't get burned twice by the same flame.

• The world is full of obvious things which nobody by any chance observes. - Sherlock Holmes

• Beauty perishes in life, but is immortal in art. - Leonardo da Vinci

Work

• A bad system will beat a good person every time. - W. Edwards Deming

• https://en.wikipedia.org/wiki/W._Edwards_Deming: book The New Economics for Industry, Government, and Education

• Every job looks easy when you’re not the one doing it.

• In natural hierarchies, we look up for purpose and down for function. Charity Majors.

• In 2021, Tesla CEO Elon Musk pressured engineers to stop installing radars, which served as a backup for the vehicles’ eight visible-light cameras, to cut costs. Tesla reinstated radars in January 2023, and crashes fell in that quarter

• Musk applies a methodology for shipping everything from electric cars to Mars rockets to flamethrowers to humanoid robots:

  1. Question every requirement. Each should come with the name of the person who made it. You should never accept that a requirement came from a department, such as from "the legal department" or "the safety department." You need to know the name of the real person who made that requirement. Then you should question it, no matter how smart that person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement came from me. Then make the requirements less dumb.
  2. Delete any part or process you can. You may have to add them back later. In fact, if you do not end up adding back at least 10% of them, then you didn't delete enough.
  3. Simplify and optimize. This should come after step two. common mistake is to simplify and optimize a part or a process that should not exist.
  4. Accelerate cycle time. Every process can be speeded up. But only do this after you have followed the first three steps. In the Tesla factory, I mistakenly spent a lot of time accelerating processes that I later realized should have been deleted.
  5. Automate. That comes last. The big mistake in Nevada and at Fremont was that I began by trying to automate every step. We should have waited until all the requirements had been questioned, parts and processes deleted, and the bugs were shaken out.

• The Peter principle is a concept in management developed by Laurence J. Peter which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.

• Tech Lead

In an ideal world, the tech lead is the guru with the respect of all the devs, the experienced senior or principal engineer that has seen it all and knows it all. These gurus are a rare breed though, and there is a shortage of good seniors in the market. The lead should be experienced, yes, but also important here I think is that the tech lead is a strong communicator and culture setter. The tech lead should know the capabilities, hopes, and dreams of their team well. Together with the people working on the horizontal levels (for example, chapter leads and learning & development managers) the tech lead would be wise to create a culture of continuous learning. Dev culture can be meritocratic, and this can be fine, as long as everyone builds each other up. So "Pfft, this guy didn't even know about X in the CLI" is a red flag, and alternatively "Owww, but you could also just fix this from the CLI, let me show you if you want!" is the green flag you want. I believe this starts at the top! If your tech leads adopt this attitude, while also always being open to learning new things from others, your team will flourish. It starts at the top. Key responsibilities: solution design, quality assurance, culture setting, standard operating procedures, team learning & development, problem-solving. Ideally, the tech lead also has business acumen, but the position can be executed without it if the tech lead has strong support on the wings by the other roles.

• Advice for time management as a manager - https://www.benkuhn.net/tmgr/

Welcome to being a manager! Your time-management problem just got a lot harder. As an IC, you can often get away with a very simple time-management strategy: Decide what your one most important thing is. Work on it until it’s done. GOTO 1 As a team lead, this isn’t going to work, because much more of your work is interrupt-driven or gets blocked for long periods of time. One-on-ones! Code reviews! Design reviews! Prioritization meetings! Project check-ins! All of these are subject to an external schedule rather than being the type of thing that you can push on in a single focused block until it’s done. Being a team lead means three big changes for your time management: You no longer have a single most important thing. You’ll have to learn how to juggle competing priorities. Your most important responsibility is for your team’s output, not your personal output. That means that individual engineering work goes last in your list of potential most important things. You’ll need to start spending some of your time on a manager’s schedule: There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. > It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour. Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started. Here’s some advice on how to cope with those changes. Have accurate expectations of yourself Your responsibilities to your team will take time, and even more importantly, attention. That means you’ll be a lot less productive on IC work than you have been in the past—especially at first while you’re finding your legs. Additionally, your time will be less predictable week-to-week as you might have to spend an unknown amount of time responding to “inbound” work. For the first few months, you should treat any individual engineering work that you get done as a bonus. Even after that, you should expect to have something like 10-20% less individual output per engineer you manage, depending on how experienced you are, they are, etc., and with substantial week-to-week variance. To mitigate this, my rule for myself has been to make sure that my IC work is important but not urgent—i.e. that nobody will be sad and no plans will be derailed if I end up having to spend the next week firefighting instead of pushing it forward. For honing my intuitions about how much I can actually expect to accomplish, I’ve found time tracking very useful (see How time tracking helped me be a better manager and I apparently got 50% better at my job last month).

• Prioritize ruthlessly A corollary of the above is that it becomes very important for you to prioritize what to work on, both on an hour-to-hour cadence and on a larger timescale. It’s not possible to write down a full algorithm for prioritizing in a blog post—that’s why they pay us the big bucks—but here are some heuristics for which things are most worth prioritizing: Deadlines where something bad happens if you miss them. (e.g. performance improvements in advance of a holiday rush.) Note that the badness of missing deadlines varies wildly. Make a habit of asking “what is the reason for this deadline?” for any deadline-driven project. Work that increases your or your team’s future bandwidth. This can include hiring, addressing tech / process debt, automating toil, mentoring people, reducing pager burden, etc. A useful way of thinking about it is to rank this kind of work based on the “payback period,” or how long it takes before the time saved by the improvement exceeds the time invested in making it. One-on-ones. Try very hard not to cancel these, unless you’re on vacation—the other 39.5 hours a week they’re focused on what you need from them, so please don’t disdain the 0.5 hours you spend focused on what they need from you. If you cancel too many, expect your reports to feel less safe bringing up tricky things, and to have more issues “blow up” because they didn’t get addressed early. Unemploy your future self One of the most important types of “work that increases your or your team’s future bandwidth” is delegating things. This is something entire books have been written about, but here’s how to avoid a few common delegation pitfalls for new team leads: Negotiate how hands-on to be. Effective delegation means finding the right balance between micromanaging, and throwing your report to the wolves. The stereotype is that new managers often micromanage, but at Wave, I’ve noticed that new managers often err on the side of undermanaging, or being too hands-off, perhaps out of a desire to signal that they trust their reports. If you’re unsure, it’s good to have an explicit conversation with the person you’re delegating to about how much support they want. E.g. “do you want to do the design for this feature yourself, have me do the high-level and fill in the details, or have me write the entire design doc?” Calibrate to your team members’ task-relevant maturity, or how capable they are of independently doing a particular type of task. A senior engineer should be able to design most features independently (with review), but give the same design task to a junior engineer and they’ll probably flail around and make no progress. You should be maintaining a mental map of each of your team members’ strengths and weaknesses—and updating it over time as you help them improve. Delegate ahead of future growth. Your team’s workload is going to increase over time, so even if you don’t feel like you have too much work to do right now, you probably will in the future, unless you currently feel underutilized. You should aim for a workload where in the steady state, you feel like you have some slack capacity. Delegate “stretch projects” to help your team level up. Getting enough slack might require you to delegate work that no one else on your team can currently do. Take your mental strengths-and-weaknesses map, ask yourself what the most important growth directions for each of those team members are, and figure out how to give them work that stretches them in that direction. Note that these delegations will probably require more frequent monitoring, since your reports will have less task-relevant maturity on their stretch projects! A five-step “help, I’m overwhelmed” checklist Despite your best efforts to follow the above advice, there will probably come a time when you feel very stressed about the amount of work on your plate. When that time comes, here’s what to do: Schedule time with your manager, for the soonest slot you can, to triage your todo list. (If the primary stakeholder for your scariest todos is your PM, schedule with them instead.) Make a list of everything that’s on your plate currently. Yes, everything, even that code review that’s been sitting in your backlog for the last 3 months. At the meeting you scheduled in step 1, figure out how to delegate everything in that list you can delegate, then stack-rank the remainder. Realistically (see Have accurate expectations of yourself) decide how far down the list you’re going to get. Remember to leave yourself some slack for whatever comes up! For things below the cutoff, decide that you’re not going to do them, and notify everyone who cares that you probably won’t get to it. Carve out focused time If you’re not careful, it’s easy to fill your entire calendar with meetings, Slack, etc. and have no time for deep work. With careful planning, you can avoid this by “batching” all your distractions to particular times of day. There are lots of tactical tips for doing this; I catalogued some that work for me in Tools for keeping focused. One tech-lead-specific one that I’ll add is batching meetings: I schedule all my meetings back-to-back on Tuesdays and Thursdays to leave the rest of the week as free as possible for deep work.

Motors

• Adding power makes you faster on the straights. Subtracting weight makes you faster everywhere. - Colin Chapman
• If everything seems under control, you’re just not going fast enough. – Mario Andretti
• Straight roads are for fast cars, turns are for fast drivers. — Colin McRae

Resources

• Visualisations of quotes, ideas and wisdom https://www.golimitless.xyz, https://twitter.com/GoLimitless

Translated from Japanese, ikigai means “reason to live.”: