All the Highlights from Klaus Breyer

This page is created by an personal open source project of mine called all-the-highlights to extracts my Highlights from Readwise Reader and format them for easy copy & pastable into Obsidian . Read more in my blog post (outdated) .

The Quiet Revolution of Animal Crossing, Ian Bogost, 2020

• But according to the Tom Nook doctrine, pastoralism and capitalism coexist perfectly. You can fish for high-value red snappers and sell them to buy espadrilles for your character, or 1950s-diner furnishings for your house. Or you can fish for never-before-seen specimens, to donate them to the museum. Or you can cast a line just to enjoy watching the moon dance across the water. All of these activities are interchangeable and equally delightful. Animal Crossing sees no greater or lesser virtue in one than another.
• Every effort is valid, every accomplishment exchangeable for capital. Want to do no job whatsoever, but just sit on stumps and shake a tambourine? That’s fine too; there are no consequences for not earning “bells.” Nobody cares in Animal Crossing. You are okay.
• And yet, isn’t this exactly the trade-off that real smartphones demand, a constant lifeline to new options, all more or less the same in nature, judged valuable by how many likes or hearts they accrue?

Eine Handvoll Mutige Menschen Machen Eine Lebensdienliche Wirtschaft, neuenarrative.de, 2020

• Der Markt war im Wesentlichen eine Plattform für Tauschgeschäfte mit dem Ziel der eigenen Lebenserhaltung.

How to Write Usefully, paulgraham.com, 2020

• Ditto for correctness, importance, and strength. In effect the four components are like numbers you can multiply together to get a score for usefulness. Which I realize is almost awkwardly reductive, but nonetheless true.

Life Is Made of Unfair Coin Flips, alexdanco.com, 2020

• Or the sender could be you twenty years ago, the recipient is you today, and the message is that arrangement of neurons and synapses in your brain that have somehow retained every single word of the song No Scrubs by TLC, even though you haven’t heard that song in years.
• Individuals maximally propagate information from their past to their future. This propagation is measurable, at least in theory. Therefore, individuality ought to also be measurable.

Solving Online Events, Benedict Evans, 2020

• it gives a selection filter for people who care.

Looking Back on Four Years at the Times, Nick Rockwell, 2020

• My answer is that a tech org should be evaluated according to the business metrics by which the company itself is assessed. There are two reasons why.
• Second, alignment is gold, and non-alignment is poison. A Tech team performing masterfully against misaligned goals is, just, a terrible situation.
• Sacrificing alignment in the service of self-defined functional glory is never the answer — fighting through the often painful process of alignment almost always is.

Antifragility, alexdanco.com, 2020

• In a fragile system, that stressor creates uncertainty. You had a plan, and you were good to follow that plan so long as you stayed within a certain state. But now you’re thrown into a new state, so your plan no longer works. You’re in trouble. That’s fragility. In a robust system, that stressor is information-neutral. You had a plan, and there’s enough buffer or slack in your system to absorb the stressor. Your state is resilient to the new challenge; the plan continues. In an antifragile system, that stressor resolves uncertainty. You had no preexisting plan; the stressor tells you what to do. In an antifragile system, stressors are information. Without stressors, an antifragile system is rudderless. It doesn’t know how to grow or what to do. It actively suffers, until a challenge gives it direction.
• Antifragility is something you do, rather than something you have or something you are. Antifragility is an operating state of growing through continuous reaction. It’s like the opposite of predicting the future. You’re not making any forward-looking assumptions about anything, but you need disorder: you need a state change to have something to react to. Good antifragile systems react quickly and correctly, like the Hydra growing new heads when you cut one off. Without disorder, the Hydra doesn’t grow.
• Accordingly, antifragile systems and organisms tend towards a common theme: bottoms-up decision-making, rather than top-down decision making. Antifragility requires real options, and real options are low-cost. Antifragility is only successful if you can actually detect, react, and grow in response to deviations from your present state in real time; the only way you can feasibly do this is for disorder detection and response to take place at a small enough resolution, and tight enough turnaround time. Top-down systems have a hard time with antifragility, because for them, all options are costly.

Remote Work Is a Platform, Jason Fried, 2020

• No one knew what to make of the web at that time, so we pulled over things we were familiar with and sunk them in place. At that time, Web design wasn’t web design – it was print design, multimedia/interactive design, and graphic design. It took years for native web design to come into its own.
• They’ll have stopped trying to make remote look like local. They’ll have discovered that remote work means more autonomy, more trust, more uninterrupted stretches of time, smaller teams, more independent, concurrent work (and less dependent, sequenced work)

Derek Sivers & the Art of Enough — Brendan Cahill, brendancahill.io, 2020

• If you really want to grow, focus solely on your preexisting clients. None of your customers will ask you to turn your attention to expanding. They want you to keep your attention focused on them. The more my own businesses have grown and the more the businesses of my friends have grown the more headaches they’ve experienced. Instead of trying to grow your business in volume or quantity grow it qualitatively. Your current clients are going to be your best source of newer clients anyway.

Attention Is Your Scarcest Resource, benkuhn.net, 2020

• Monotask As a programmer, I tried to make sure that I was only ever working on one thing at a time. Even if I got stuck on that one thing—say I was blocked on waiting for a tech partner to give me API documentation—I’d let myself stay stuck instead of sliding off to work on something else. In the short term, this made me less efficient, because I’d spend less time programming and more time staring vacantly at the ceiling. But if I stared vacantly for long enough, I’d eventually get mad enough to, e.g., reverse-engineer the partner’s API in a fit of rage. This resulted in me shipping my most important projects faster, hence getting faster compounding growth.

Misunderstanding "Skin in the Game", Alex Danco, 2020

• The core, unifying theme across all of Taleb's writing - from his early work around randomness and The Black Swan through later works like Antifragility and Skin in the Game - is the logic of risk-taking. Taleb takes great offence at creating work, exercise, or any other kind of activity that’s designed to consciously offload risk from the participant; he’s particularly fond of complaining about elliptical machines at the gym, jogging, or really any kind of exercise that isn’t free weight deadlifting. But I have a distinct feeling that he would be willing to make an exception for trail running, which seems like it’d be a lot more in his ballpark.
• Upside incentive can matter a great deal, but it has almost nothing to do with skin in the game the way that Taleb uses the phrase. When Taleb talks about “Skin in the game”, he’s talking about survival. A small business owner does not have SitG because she’s incentivized to run her business well; she has SitG because if she doesn’t run her business well, then it doesn’t stick around.
• just raise less money! It’ll force you to work harder, learner, and smarter, and it’ll force you to get things right faster, or run out of cash trying. But I’ll bet you that’s not what these people have in mind.

If It's a Nice Problem to Have, Don't Solve It Now, Open Source, 2020

• An example to illustrate is signup functionality. Let's say I'm starting on a new product. Without signup, there's no possibility of getting any users, which is a problem. From my perspective right now, is this a nice problem to have? No - I have zero users right now, and can't get any until signup is done. The only way to move forwards is to build signup.

Tiffany-Matthe, tiffanymatthe.com, 2020

• But real extraordinary is nothing like this. Yes, it's exciting, but it also comes with sacrifices, limitations, and constraints. And it's not permanent. Extraordinary can disappear over time, just like you can achieve it over time.

On Being Bipolar, Andrea Bennett, 2020

• I don’t dream about not being bipolar, because I don’t know where my self ends and where the illness begins—and if there is even really a difference. And I don’t know what I would dream to render the divisions between good sick and bad sick unnecessary, to make it so that we all get to remain people, without sacrificing some of us to quarantine and cautionary tale.

Systems Thinking for Startups, best practices, 2020

• Thus, we may cut our advertising budgets, see the benefits in terms of cost savings, and in turn further trim spending in this area. In the short run there may be little impact on people’s demands for our goods and services, but longer term the decline in visibility may have severe penalties. An appreciation of systems will lead to recognition of the use of, and problems with, such reinforcing feedback, and also an understanding of the place of balancing (or stabilizing) feedback. Peter Senge
• The systems viewpoint is generally oriented toward the long-term view. That’s why delays and feedback loops are so important. In the short term, you can often ignore them; they’re inconsequential. They only come back to haunt you in the long term.

Apple University Dean Shares Deep Dive Into Apple's Organizational Structure, Juli Clover, 2020

• Apple's structure dictates that the people who have the most expertise and experience in a given domain should have the decision rights for that domain, with the company relying on technical experts rather than managers to make key decisions.
• Leaders should know the details of their organization three levels down," is one of Apple's principles.

Early Work, paulgraham.com, 2020

• Making new things is itself a new thing for us as a species. It has always happened, but till the last few centuries it happened so slowly as to be invisible to individual humans. And since we didn't need customs for dealing with new ideas, we didn't develop any. We just don't have enough experience with early versions of ambitious projects to know how to respond to them. We judge them as we would judge more finished work, or less ambitious projects. We don't realize they're a special case.
• The right way to deal with new ideas is to treat them as a challenge to your imagination not just to have lower standards, but to switch polarity entirely, from listing the reasons an idea won't work to trying to think of ways it could.

Why Life Can’t Be Simpler, fs.blog, 2020

• Complexity is like energy. It cannot be created or destroyed, only moved somewhere else. When a product or service becomes simpler for users, engineers and designers have to work harder. Norman writes, “With technology, simplifications at the level of usage invariably result in added complexity of the underlying mechanism. ” For example, the files and folders conceptual model for computer interfaces doesn’t change how files are stored, but by putting in extra work to translate the process into something recognizable, designers make navigating them easier for users.
• As long as you pay your bills, the water supply to your house is probably fully automated. When you turn on a tap, you don’t need to have requested there to be water in the pipes first. The companies that manage the water supply handle the complexity.

Container Orchestration Tools Explained, Manager node, 2020

• An important distinction between virtual machines and containers is that VM virtualizes underlying hardware whereas the container virtualizes the underlying operating system. Both have their own use cases. Interestingly, many container deployments use VM as their host operating system rather than running directly on bare metal.

How to Think for Yourself, paulgraham.com, 2020

• One of the most effective techniques is one practiced unintentionally by most nerds: simply to be less aware what conventional beliefs are. It's hard to be a conformist if you don't know what you're supposed to conform to. Though again, it may be that such people already are independent-minded. A conventional-minded person would probably feel anxious not knowing what other people thought, and make more effort to find out.
• You don't want to start a startup to do something that everyone agrees is a good idea, or there will already be other companies doing it. You have to do something that sounds to most other people like a bad idea, but that you know isn't like writing software for a tiny computer used by a few thousand hobbyists, or starting a site to let people rent airbeds on strangers' floors. Ditto for essayists. An essay that told people things they already knew would be boring. You have to tell them something new.
• The three components of independent-mindedness work in concert: fastidiousness about truth and resistance to being told what to think leave space in your brain, and curiosity finds new ideas to fill it. Interestingly, the three components can substitute for one another in much the same way muscles can. If you're sufficiently fastidious about truth, you don't need to be as resistant to being told what to think, because fastidiousness alone will create sufficient gaps in your knowledge. And either one can compensate for curiosity, because if you create enough space in your brain, your discomfort at the resulting vacuum will add force to your curiosity. Or curiosity can compensate for them: if you're sufficiently curious, you don't need to clear space in your brain, because the new ideas you discover will push out the conventional ones you acquired by default.

What Comes After Smartphones?, Benedict Evans, 2020

• There’s an old saying that the first fifty years of the car industry were about creating car companies and working out what cars should look like, and the second fifty years were about what happened once everyone had a car - they were about McDonalds and Walmart, suburbs and the remaking of the world around the car, for good and of course bad. The innovation in cars became everything around the car.

5 Predictions for 2021, . The US Dollar, 2020

• 2020 becomes the decade of data. The 2010s were the decade of software and SaaS, the era when Salesforce become the first SaaS company to sail past the $100B market cap mark. The 2020s will be the era of data companies boosting massive markets. Database startups, data movement startups, data quality startups, data lineage startups, machine learning startups will be the zeitgeist of the decade as they shape the next wave of massive innovation.

How to Be Indistractable, Nir Eyal, 2020

• . I convinced myself that, once I banished all the technology from my life, I’d become the disciplined writer and focused father I’d always strived to be. Talk about a rude awakening. Sitting at my ancient word processor, my eyes began to peer over to my now-tantalising bookshelf. ‘Hmmm,’ I said to myself, ‘I really should take a glance at this book’. I’d justify the distraction as necessary for ‘research’. And if it wasn’t reading, then I’d find something else – the laundry that needed to be folded right now, my desk that needed to be tidied-up this minute. The technology wasn’t distracting me. I was distracting me.
• Or in reality, I could get comfortable with the discomfort that I might indeed be missing out on something
• I discovered that I was just as susceptible to being distracted by a news report or a dirty closet as I was by a glowing screen. Does that mean I cut out the news, or let my closets go? No. It meant having to figure out what I was avoiding (writing) and why I was avoiding it (all the writerly anxieties) and then dealing with those. It also meant building systems to manage my time, attention and internet use.

100 Tips for a Better Life, Ideopunk, 2020

• You can improve your communication skills with practice much more effectively than you can improve your intelligence with practice. If you’re not that smart but can communicate ideas clearly, you have a great advantage over everybody who can’t communicate clearly.
• Explaining problems is good. Often in the process of laying out a problem, a solution will present itself.
• Defining yourself by your suffering is an effective way to keep suffering forever (ex. incels, trauma).

Validation Is a Mirage, Jason Fried, 2020

• Truth is, you don’t know, you won’t know, you’ll never know until you know and reflect back on something real. And the best way to find out, is to believe in it, make it, and put it out there. You do your best, you promote it the best you can, you prepare yourself the best way you know how. And then you literally cross your fingers. I’m not kidding. You can’t validate something that doesn’t exist. You can’t validate an idea. You can’t validate someone’s guess. You can’t validate an abstraction. You can’t validate a sketch, or a wireframe, or an MVP that isn’t the actual product.
• When I hear MVP, I don’t think Minimum Viable Product. I think Minimum Viable Pie. The food kind. A slice of pie is all you need to evaluate the whole pie. It’s homogenous. But that’s not how products work. Products are a collection of interwoven parts, one dependent on another, one leading to another, one integrating with another. You can’t take a slice a product, ask people how they like it, and deduce they’ll like the rest of the product once you’ve completed it. All you learn is that they like or don’t like the slice you gave them.
• If you want to see if something works, make it. The whole thing. The simplest version of the whole thing – that’s what version 1.0 is supposed to be. But make that, put it out there, and learn. If you want answers, you have to ask the question, and the question is: Market, what do you think of this completed version 1.0 of our product?

Systems Design Explains the World Volume 1, apenwarr.ca, 2020

• if you were a Novice going for Junior, you had to prove you could fix bugs without too much supervision; going for Senior, you had to prove you could implement a whole design without too much supervision; going for Staff, you had to show you could produce designs based on business problems with basically no management; going for Senior Staff, you had to solve bigger and bigger business problems; and so on.
• With systems design, the key insight might be a one-sentence explanation given at the right time to the right person, that affects the next 5 years of work, or is the difference between hypergrowth and steady growth.
• Our team felt flat and egalitarian. But you can't ever forget that it was only that way because you forced it to be that way."
• A "disruptive" innovation was meant to refer to specifically the kind you see in that plot up above: the kind where an entirely new thing sucks for a very long time, and then suddenly and instantly blows you away. This is the kind that creates the dilemma.

My Favorite Essays of Life Advice, benkuhn.net, 2020

• There is another trait that took me many years to notice, and that is the ability to tolerate ambiguity. Most people want to believe what they learn is the truth: there are a few people who doubt everything. If you believe too much then you are not likely to find the essentially new view that transforms a field, and if you doubt too much you will not be able to do much at all. It is a fine balance between believing what you learn and at the same time doubting things. Great steps forward usually involve a change of viewpoint to outside the standard ones in the field.

What Shape Are You?, madeofmetaphors.com, 2021

• But at higher levels, there's just too much to spell it all out. It's important to try, to define boundaries for that shape so you have some way to talk about them, but you can't capture all of it in full detail. It relies on a mutual understanding about implied work. Some work yields knowledge that you need to do other work, and so a viable role that does one of these things must do the other.
• If you're in charge of writing some code, you also have to comment it, because if you don't, nobody else will understand it well enough to do it for you. If you're in charge of coming up with a creative direction for a project, you also need to communicate it outwards to others, because if you don't, nobody else knows enough to do it for you.
• During conversations about performance, everything you talk about should boil down to one thing: the value they contribute to the team. What is their value, and how can they become more valuable?
• As you get more senior, maybe you're a specialist, so your shape gets bigger and the boundary remains nice and clear. Or you end up as a lead, and you're able to fill spaces in the project and pick up slack that few others can, so your boundary gets messier
• These diagrams I'm drawing fundamentally express project development as a subtractive process: you start with a mountain of stuff to get done, and by the time you're done, someone will have done all of it. These diagrams visualize the abstract notion that there's "all the work" and each person subtracts some of it from the space, and you're done when everything has been subtracted. But not all work is subtractive. Consider a factory worker assembling cars. If he assembles 2 cars in a day, he makes the company a profit; if he works harder and assembles 4 cars in a day, he makes the company twice as much. This is an additive sort of work. You can do the same work, but just more of it, and you generate more value. Creative endeavors are not additive. They are iterative, convergent processes, and so they are subtractive: you work until you have converged, and then you stop.
• And to managers, I'd say: when you talk to your reports, help them think about their work and everyone's work as subtractive, as cutting out shapes from the big space of all work. Tell them what things are clearly theirs, and talk about those with whom they share boundaries, and what those boundaries should be. Talk about imperatives: tell them what kinds of problems you foresee and what roles you see them playing in the solutions. Talk about the whole project, even the stuff they'd never otherwise hear about - especially that stuff. Give them context. Talk about convergence. Help them see their shapes.

State Machines Are Wonderful Tools, Chris Wellons, 2021

• I love when my current problem can be solved with a state machine. They’re fun to design and implement, and I have high confidence about correctness. They tend to: Present minimal, tidy interfaces Require few, fixed resources Hold no opinions about input and output Have a compact, concise implementation Be easy to reason about

Setting Up Personal OKR [JFM-2021], Pravendra Singh, 2021

• One of the common mistake during OKR planning is; ignoring the difference between the initiatives/key-results.

Difficult Conversations, madeofmetaphors.com, 2021

• If you're afraid of difficult conversations, only having difficult conversations will make you less afraid. And second, it gets better. Have those difficult conversations and the fear will recede. I promise.
• How do you know when you should have a difficult conversation? Obviously you shouldn't berate people constantly just because you believe they could be doing a tiny bit better. Let's say you have someone who's doing fine, could probably be doing more, but when you probe a bit, seems totally content. Just mention to him the options - "If you ever want to do more, we can talk about that" - and leave it at that. He doesn't have a problem. Don't project your impatience onto people. But if you have someone who's not succeeding and wants to be, or who clearly wants to do more and is being held back by limitations he doesn't understand or believe, that's a dissonance. Dissonance is a signal that you need to have a difficult conversation
• The key part of a difficult conversation is being in touch with the proper intention when you go into it. In a nutshell, that intention is this: I am telling you these observations I have made even though it is difficult for me because I care about you and believe they may help you learn and grow. Here are a few notable things that aren't part of that intention: I expect you to take this advice. My observations are absolutely correct. I am personally attached to the outcome. I know better than you do what's appropriate for you. I'm telling you this because I want you to see me as smart. I'm telling you this because I like identifying as a "mentor" or "teacher" or "wise person."

How to Stop Endless Discussions, candost.blog, 2021

• That's why we need to balance both taking action and asking people to present their opinion on a topic. This balance is achievable with an excellent process. I helped build this balanced process in an organization where we aimed to solve another problem - the lack of feedback. We introduced a process called Request For Comments (RFC). It is a common feedback mechanism in the software world presented by the Internet Society (ISOC) and used currently in the Rust language
• The RFC process uses a document written by someone about their proposal on a topic. It has a specific timeframe and everyone can give feedback on it. The RFC and feedbacks are posted publicly. Everyone can join the discussion. The goal is to include as many people as possible to access more points of view and spread the knowledge simultaneously. The good thing is that people focus on the proposed idea and give their feedback based on facts instead of only beliefs. On the other hand, it has a way bigger effect.
• We used the NABC model from Stanford. The model starts with defining the Need, followed by Approach, Benefits, and lastly, Competitors. Separating the Need from the approach is very smart. While writing the need, the authors have to understand it very well. The approach and benefits sections are pretty straightforward, where authors define their strategy and list down the advantages.
• The process seeks a consent-based environment, not a consensus-based one. If some people care about a topic a lot and come up with a written document that explains many things in detail, everyone can (and should) trust them. The authors shouldn't wait for everyone's confirmation of their proposal. When they get enough feedback, they should be able to continue further with or abandon the idea. It's their decision. Since they prepared the doc and collected many comments on it, they can have a better judgment.
• These hidden gems of writing the idea in a structured way and asking people for comments afterward prevents many endless debates

Boundaries and Infinities A Post About Responsibility, madeofmetaphors.com, 2021

• Her shape on that diagram, then, represents all those responsibilities. Emily’s shape is finite: it is bounded on all sides. It doesn't shoot off into infinity. And all the adjacent shapes are other people’s roles.
• Those boundaries are dark black lines in the diagrams, but in reality they’re much fuzzier – they have to be fluid. And when you are in a role like Emily’s, the fluidity at the boundary is the most interesting part. That example is a simple one, too. They get far more complicated:
• To succeed, the skills she’ll need include discipline and personal talent for the production work, of course, but moreover she’ll need the political savvy and social skills to navigate the boundaries between her shape and others’ with nuance
• Paul’s shape is infinite – if you keep zooming out, it keeps going. There are no boundaries at the edges. Paul’s responsibilities look like this: Decide what needs to be done. Do all of it.
• The challenges Paul faces are the challenges of a man faced with infinite potential and limited time. And to succeed, he’ll need vision, personal talent, discipline, confidence, and decisiveness.
• In terms of the visual metaphor, the difference between them is that Emily’s shape is finite and Paul’s is infinite. A finite shape has a finite list of responsibilities, and the nuance is in the fractal intricacy of its boundary with all the other shapes. An infinite shape’s responsibilities end with “et cetera”, and the nuance is in triage: The shape is infinite, but the person occupying it is finite. The interesting part is when conditions change.
• Paul has a team, now, and they look to him for management and counsel. They’re mostly finite shapes, so they need a manager who can tell them about political savvy and nuance and help them develop the skills of working within their constrained roles but still having an impact. But Paul doesn't know how to do any of that. He knows how to forge ahead and make big decisions and push on things so they get done. And none of those are appropriate behaviors for his new team members.
• Because his tenure makes him the 800lb gorilla, but people in Paul’s situation can be surprisingly oblivious to this. Often, Paul doesn't understand why other people don’t just behave like he does. After all, it works for him!
• People like Paul, when they give advice, often focus on personal effectiveness, alpha behavior, and triage, and deride or overlook the importance of management, coordination, and “overhead.” They are allergic to process and overhead because for small companies, that’s the right way to be. It takes tremendous self-awareness, humility, and flexibility for people in Paul’s situation to internalize the changes intrinsic to a growing company and develop that new skill set
• People in privileged positions who don’t understand the importance of relationship-building and nuance in larger organizations end up marauding through situations and leaving them even worse off, all the while thinking they’re being highly effective.
• The way you avoid waste in small organizations is by staying lean and not wasting time with politics. In larger organizations, it’s almost the opposite: you avoid waste by respecting the boundary lines between shapes and navigating them with nuanced coordination, communication, and management, none of which are usually strengths for people like Paul, who got to where he did precisely because he thrives when there aren't boundary lines.

Billionaires Build, paulgraham.com, 2021

• What YC looks for, above all, is founders who understand some group of users and can make what they want. This is so important that it's YC's motto: "Make something people want."
• The ideal combination is the group of founders who are "living in the future" in the sense of being at the leading edge of some kind of change, and who are building something they themselves want.
• If I had to decide whether to fund startups based on a single question, it would be "How do you know people want this?"
• The crucial feature of the initial market is that it exist. That may seem like an obvious point, but the lack of it is the biggest flaw in most startup ideas.
• Competitors are rarely what kills startups. Poor execution does.
• They're usually doing it from some combination of the desire to make money, the desire to seem cool, genuine interest in the problem, and unwillingness to work for someone else.

No Meetings, No Deadlines, No Full-Time Employees, sahillavingia.com, 2021

• Because I was burned out and didn’t want to think about working any more than I needed to, I instituted a no-meeting, no-deadline culture. For me, it was no longer about growth at all costs, but “freedom at all costs.”
• We also have an “anti-overtime” rate: past twenty hours a week, people can continue to work at an hourly rate of 50 percent. This allows us to have a high hourly rate for the highest leverage work and also allows people to work more per week if they wish.

My Goals for 2021, Interesting Lives, and Other Considerations, thesephist.com, 2021

• In every complex system, there are two sets of rules: the rules that everyone thinks describe the system, and the actual rules by which the system really works. In software, we call these two rules the “specification” and the “implementation”.

How to Remember What You Learn, Vasili Shynkarenka, 2021

• Make it time-based, take regular breaks, and learn what you’re curious about.
• A file with a timestamp where my random thoughts go. A file with a timestamp where I think about the subject. A file with questions.
• file with questions
• The second file is where I write about what I’m learning. Folks in the kitchen call it metacognition, which means thinking about thinking. Metacognition is the single best trick I’ve found to improve understanding, and I will write more about it in the future. Whenever I don’t understand something or see that my understanding is shallow, I begin writing in the first person. It looks like this: “So Peter explains that there are four characteristics of a monopoly, but I don’t really understand why branding is one of them; why so?”
• Having a file with my thinking about the subject keeps my working memory clean. I don’t feel overloaded as I usually feel after reading many articles at one go. You’ve probably experienced this yourself; your brain is almost melting after an hour of scrolling through the web. That’s because you present yourself with too much information without really making sense of it. After a few months of applying metacognitive practices, I realized that I can’t go back. It just feels so strange to experience that cognitive load again.
• After I’m done with the summary, I write down the answers to three questions: What are the key ideas? How can I apply this knowledge that I learned? How do these ideas relate to what I already know?
• So much of what we call creativity and intelligence is just memory. If you think you can look it up on Google, you’re wrong. The thought process is way faster than looking stuff up, and when you’re thinking about something or solving an important problem, you have to have your toolkit ready. Also, the most interesting ideas come when you’re not at your desk but showering, glazing over stars or wandering around in the city center. When you can’t Google. And this tiny 10-minute habit of recalling ideas is totally worth it if you think of the implications on a fifty-year timeframe.
• By taking just 10 minutes a day to quickly scroll through the book instead of my Twitter feed, I end up having 365 books scrolled in a year. From these 365, about two end up being life-changing, ten – deeply interesting, and ten – sort of interesting. Everything else is noise. 94%. Now, do the math. If I didn’t have this discovery routine and aimed to read books from cover to cover, I’d randomly sample about twenty books from 365 with meager chances of all of them being good. And I was doing that for years. So don’t repeat my mistake and invest 5-10 minutes a day to discover what you learn from, because learning is like eating. You become what you consume.
• . I usually start from the book description to understand what it’s about, and write down a couple sentences, trying to guess what’s coming up. Then I go straight to the table of contents and see if anything catches my attention there
• But the purpose of this “picture walk” reading is different; it’s to catch my curiosity. And curiosity is different from understanding because it’s either happens or not. It’s like you’re seeing a pretty girl; you don’t really sit and reason, “well, do I really like her?”

Context Switching Costs More Than We Give It Credit For., Mayank Verma, 2021

• But when it comes to work, especially engineering work, the cost of multitasking skyrockets. Because (for software engineers) all tasks fall under cognitive function. And as a result, it requires a lot of context switches.
• Writing code and reviewing code are now two separate functions within the same cognitive function. Even writing/reviewing code for two separate code bases are two separate sub-functions.
• Grouping/responding to all emails is an email function. Even that is further broken down into triaging email function and responding function.

Maximizing Developer Effectiveness, martinfowler.com, 2021

• Being productive motivates developers. Without the friction, they have time to think creatively and apply themselves.
• They know what type of organization they are striving to build. The four key metrics (lead time, deployment frequency, MTTR and change fail percentage) are great measures of DevOps performance.
• Those two minutes can add up quickly, and could top 100 minutes a day. These small pauses are opportunities to lose context and focus. They are long enough for a developer to get distracted, decide to open an email or go and get a coffee, so that now they are distracted and out of their state of flow, there is research that indicates it can take up to 23 minutes to get back into the state of flow and return to high productivity. I am not suggesting that engineers should not take breaks and clear their head occasionally! But they should do that intentionally, not enforced by the environment.
• Distributed systems are a particular challenge. There are many valid reasons for splitting systems into different deployable units (usually microservices). However, distributed systems also make many things difficult (see Microservice Prerequisites), including developer effectiveness. Sometimes teams might optimize for team autonomy or for runtime performance, but they sacrifice developer effectiveness because they do not invest in maintaining fast feedback loops. This is a very common situation my company runs into.

How I Build JavaScript Apps in 2021, Tim Daubenschütz, 2021

• Extracting a library from a codebase allows me to think about it from a user's perspective. It means I'm able to think about a piece of code's interfaces emphatically.

My Role Models, Or, a Few Stories of Others to Live By, thesephist.com, 2021

• Software engineering is an almost paradoxical juxtaposition of collaboration and isolation: successful software engineers are able to work well with (and understand the needs of!) others, but are also able to focus intensely on their own… They must be able to build castles of imagination, and yet still understand the constraints of a grimy reality: they must be arrogant enough to see the world as it isn’t, but humble enough to accept the world as it is.

ARCHITECTURE.md, matklad.github.io, 2021

• Start with a bird’s eye overview of the problem being solved. Then, specify a more-or-less detailed codemap. Describe coarse-grained modules and how they relate to each other. Codemap should answer “where’s the thing that does X?”. It should also answer “what does the thing that I am looking at do?”. Avoid going into details of how each module works, pull this into separate documents or (better) inline documentation. Codemap is a map of a country, and not an atlas of maps of its states. Use this as a chance to reflect on the project structure.

How to Kill a Unicorn, chrisfrantz.com, 2021

• Creating content in the app means content can be shared outside the app. That’s a simple growth mechanism that can be leveraged mightily once a certain user volume has been hit.

“Third Places” as Community Builders, Carmen Diaz, Stuart M. Butler, 2021

• Depending on their location, social classes and backgrounds can be “leveled-out” in ways that are unfortunately rare these days, with people feeling they are treated as social equals.

The Almanack of Naval Ravikant by Eric Jorgenson, Facebook, 2021

• Don’t take yourself too seriously, you’re just a monkey with a plan.
• Most of the time, the person you have to become to make money is a high-anxiety, high-stress, hard-working, competitive person. When you have done that for twenty, thirty, forty, fifty years, and you suddenly make money, you can’t turn it off. You’ve trained yourself to be a high-anxiety person. Then, you have to learn how to be happy.
• Naval also encourages taking at least one day a week (preferably two, because if you budget two you’ll end up with one) where you just have time to think.
• Happiness is not about positive thoughts. It’s not about negative thoughts. It’s about absence of desire, especially the absence of desire for external things. The fewer desires he can have, the more he can accept the current state of things, the less his mind is moving, because the mind really exists in motion toward the future or the past. The
• Happiness to Naval is mainly not suffering, not desiring, not thinking too much about the future or the past, really embracing the present moment and the reality of what is, and the way it is.
• Decrease the importance of yourself. The world does not conform to your desires, and this causes you problems.
• Our lives are a blink of a firefly in the night. You’re just barely here. You have to make the most of every minute, which doesn’t mean you chase some stupid desire for your entire life. What it means is every second you have on this planet is very precious and it’s your responsibility to make sure you’re happy and interpret everything the best possible way.
• Happiness is a choice you make and a skill you develop. Happiness is being satisfied with what you have. Success comes from dissatisfaction. Choose.
• The fundamental delusion: There is something out there that will make me happy and fulfilled forever.
• You will get rich by giving society what it wants but does not yet know how to get. At scale.
• People who live far below their means enjoy a freedom that people busy upgrading their lifestyles can’t fathom.
• Any end goal will just lead to another goal, leading to another goal. We just play games in life.
• Then you just get tired of games. Naval says he is at the stage where he’s just tired of games. He doesn’t think there is any end goal or purpose. He just lives his life as he wants to, from one moment to another.
• Become the best at what you do. Opportunity will seek you out. Luck becomes your destiny.
• Be a maker who makes something interesting people want. Show your craft, practice your craft, and the right people will eventually find you”.
• great people have great outcomes. You just have to be patient. Every person he met at the beginning of his career twenty years ago, where he looked at them and said, “Wow that guy or gal is super capable - so smart and dedicated” …all of them, almost without exception, became extremely successful. You just had to give them a long enough timescale. It never happens in the timescale you want, or they want, but it does happen.

The Future of Software Will Be Hyperplexed, Vikas Taneja, Pranay Ahlawat, Bernd Schlotter, 2021

• To build and scale such applications quickly, companies have to ensure their enterprise software architectures support new kinds of programming, deployment, and operational paradigms. That’s why we believe that the future of software architectures will be hyperplexed, by which we mean that they will have to support many widely-distributed software applications, several different types of devices, and new user experiences and interfaces. (See “Defining Hyperplexed Architectures.”)

What I've Learned From 10+ Years of Personal Projects, Benoit Bernard's Picture, 2021

• My best project ideas came organically - I didn't actively try to come up with those ideas, but instead I just followed my interests and tried to solve my own problems.

What I Worked On, paulgraham.com, 2021

• Computer Science is an uneasy alliance between two halves, theory and systems. The theory people prove things, and the systems people build things
• But the most important thing I learned, and which I used in both Viaweb and Y Combinator, is that the low end eats the high end: that it's good to be the "entry level" option, even though that will be less prestigious, because if you're not, someone else will be, and will squash you against the ceiling. Which in turn means that prestige is a danger sign.
• One of the most conspicuous patterns I've noticed in my life is how well it's worked, for me at least, to work on things that weren't prestigious. Still life has always been the least prestigious form of painting. Viaweb and Y Combinator both seemed lame when we started them. I still get the glassy eye from strangers when they ask what I'm writing, and I explain that it's an essay I'm going to publish on my web site. Even Lisp, though prestigious intellectually in something like the way Latin is, also seems about as hip.

The Healing Power of JavaScript, Craig Mod, 2021

• The real joy of this project wasn’t just in getting the search working but the refinement, the polish, the edge bits. Getting lost for hours in a world of my own construction. Even though I couldn’t control the looming pandemic, I could control this tiny cluster of bits.

99 Additional Bits of Unsolicited Advice, Recomendo, 2021

• What you get by achieving your goals is not as important as what you become by achieving your goals. At your funeral people will not recall what you did; they will only remember how you made them feel.
• The greatest rewards come from working on something that nobody has a name for. If you possibly can, work where there are no words for what you do.
• Always say less than necessary. • You are given the gift of life in order to discover what your gift *in* life is. You will complete your mission when you figure out what your mission is. This is not a paradox. This is the way.
• It is much easier to change how you think by changing your behavior, than it is to change your behavior by changing how you think. Act out the change you seek.

An Interview From Alternative Universe, Tomas Petricek, 2021

• Knowledge about design is hard to externalize. It is embedded in people and in the products they build, but it is not clear how you could turn such knowledge into a textbook.
• So, you cannot learn software design from a textbook then? That's right. Knowledge about design is hard to externalize. It is embedded in people and in the products they build, but it is not clear how you could turn such knowledge into a textbook. You acquire it by working with experienced software designers and by studying existing artifacts.
• Even though the digital medium makes it easy to directly copy things, this is actually mostly done by recreating system from scratch. So you would typically start from an empty program and construct it step by step, often by importing existing well-tested parts that you see elsewhere.
• the creation of software as a design activity, putting it as a third item on the same level as science and art.
• A typical form of what you call specification in our world is a bit more like a design brief. A much more space is dedicated to the context in which the work is happening, the problem that you are trying to solve and constraints that you are facing, but design briefs say very little about any specific potential software solution to the problem.
• When you're solving a problem, even as you get to a more technical level, you always keep in mind why you are solving it. I noticed that software engineers in your universe often ignore this. You fixate on some technical solution and then completely forget what is the context in which you're building it.
• that a large part of problem solving is actually precisely understanding the problem. Most problems that you face are ill-defined and open to interpretation. And when solving problems that are not inherently ill-defined, you often find better solutions by treating them as such!
• The problem really only becomes apparent as you try to solve it. So, the key thing is to quickly iterate.
• The most important thing in software design is problem framing and you need a lot of expertise for that.

Everyone Is Still Terrible at Creating Software at Scale, mikiobraun, 2021

• There is something peculiar about software that makes it different from other crafts. A long while ago, I read “The Mythical Man-Month” by Frederick Brooks and I think he called it accidental complexity.
• Somehow it seems to be an activity that benefits a lot from being done in one mind (as exemplified by this comic). Somehow, the code in front of you is just the tip of the iceberg of a lot of mental representation of what is happening
• As soon as you start to involve more than one person, you can either try to have them all work on the same mental representation (like in pair programming), or you need to introduce some restrictions on the area of responsibility, so that everyone can mind their own business, or at least work more independently.
• This separation of work happens every time you decide who works on what within a team, but also once you define teams in a company.
• Cities can be thought as platforms for human activities. They provide basic infrastructure like roads, electricity, buildings, shop space you can rent, and now Internet. Some of these pieces of infrastructure change very slowly (like roads), while others are much more flexible, like the way apartments or shops are used. What if software were built in the same way? What if the core parts of our business would be like streets, and all that newfangled stuff is something we could build on top, experiment, tear it down if it does not work? I’ve seen a few e-commerce companies from the inside, and while their systems are marvel of technologies able to handle thousands of transactions per second, it does not feel like this, but things like the app and the website are very deeply entangled with the rest. Even if you wanted, you couldn’t create a completely new app or website.
• The Team Topologies book suggests to favor teams that are end-to-end, that fully own a problem to be solved, supported by platform teams and teams that manage a very complex piece of technology.

How People Get Rich Now, paulgraham.com, 2021

• People who don't look any deeper than the Gini coefficient
• Fast growth has a double effect on the value of founders' stock. The value of a company is a function of its revenue and its growth rate. So if a company grows faster, you not only get to a billion dollars in revenue sooner, but the company is more valuable when it reaches that point than it would be if it were growing slower. That's why founders sometimes get so rich so young now. The low initial cost of starting a startup means founders can start young, and the fast growth of companies today means that if they succeed they could be surprisingly rich just a few years later.

Stop Spending So Much Time in Your Head, Darius Foroux, 2021

• “A great many people think they are thinking when they are merely rearranging their prejudices.”
• Pragmatism believes that a mind is a tool. Your mind should work for you, not against you. People who don’t master their mind, don’t believe it’s possible.
• If you’re constantly thinking, it’s because you haven’t’ trained your mind yet. You HAVE to get out of your head.

The 3 Stages of Failure in Life and Work, James Clear, 2021

• Fixing a Failure of Tactics is not a one time job, it is a lifestyle.
• You haven’t really started working on [your idea] till you’ve launched.”
• Launch it quickly. Do it cheaply. Revise it rapidly.

Want a Killer Product? Become More Opinionated, Adil Aijaz, 2021

• There is a place for flexibility, but it is not the hammer for every product problem.

How to Think Clearly, Tom Chatfield, 2021

• Inviting people to pause is among the easiest advice in the world to give, and the hardest to take. Yet it’s foundational to clarifying your thinking, because this is where it all begins: with a moment of self-reflection. Without pauses, there can be no second thoughts and no self-interrogations. There is no process until you take the time to embark upon it. You might think that this point is too obvious to be worth making. Yet, in my experience, it’s where most of us fall down. We all carry around countless unclear, confused, contradictory thoughts and feelings. And precisely because we have neither the time nor the tools to sort them out, they mostly stay this way. Once you’ve paused, a common psychotherapeutic exercise can help you take a first step towards clearer thinking. It’s about observing yourself as neutrally as possible. You make yourself comfortable, relax, then try to notice the flow of your thoughts and feelings in a nonjudgmental way: the flickers of anxiety, anticipation, regret; the memories and ideas bubbling into consciousness.
• This suggests that either: I don’t believe the above reasons to be true, or to be the whole story; or that I do, yet somehow still don’t find them compelling.

A Project of One's Own, paulgraham.com, 2021

• Many kids experience the excitement of working on projects of their own. The hard part is making this converge with the work you do as an adult. And our customs make it harder. We treat "playing" and "hobbies" as qualitatively different from "work". 1] Instead of telling kids that their treehouses could be on the path to the work they do as adults, we tell them the path goes through school. And unfortunately schoolwork tends be very different from working on projects of one's own. It's usually neither a project, nor one's own. So as school gets more serious, working on projects of one's own is something that survives, if at all, as a thin thread off to the side.
• If you can find the right people, you only have to tell them what to do at the highest level. They'll handle the details. Indeed, they insist on it.
• The

Joining Hypergrowth Startups 😬, klinger.io, 2021

• Example: Processes are not chains of bureaucracy. They are expectations made explicit. Can be 1-step actions. Processes allow you to scale as you don’t need to discuss continously one-offs.
• Stuff is stressy but remember stress is you losing control; not you working too much you can burn out barely working at all being overwhelmed is ok; temporary; if you can stay in control Example: managers frequently burn out people by letting them face the consequence of rapid changes without shared control over reasoning nor impact of them
• Never wait; never get stuck switch quickly between issues if stuff is stuck make sure balls dont get dropped never “wait” consider if you can do a good-enough solution by yourself consider what alternative thing is most impactful instead

#162 Minimum Viable Self, Drew Austin, 2021

• Illusion or not, we tend to see other people’s lives as works of art. And having seen them this way, we struggle to (make our lives) the same.”
• Offline we exist by default; online we have to post our way into selfhood. Reality, as Philip K. Dick said, is that which doesn’t go away when you stop believing in it,

Being a Tech Lead in an Empowered Product Team, domk.website, 2021

• If everyone “does their bit” in isolation in order to combine them at the end, it isn’t true collaboration. True collaboration requires a high bandwidth conversation where you can bounce ideas off of each other and work in small increments
• Assessing feasibility is the main expertise you bring to the product team leadership trifecta. You are in a unique position to know what is and isn’t possible with the technology you have or can have.
• that the role is different both from purely technical senior IC roles and from engineering management roles. While all of the above traits can be learned, not every senior IC or manager is a good fit for a tech lead.

Don’t Feed the Thought Leaders, Adam Gordon Bell, 2021

• Thankfully, not all the advice I received was bad. One person, in particular, asked very pointed questions about the problems be solved and identified some potential blind spots in our plan. They also offered a great tip for dealing with advice that didn’t seem relevant to the project’s success: Create an extended product roadmap and put those items at least a year off into the future “and as long as they don’t seem relevant, you can just keep pushing them into the future.” Perversely this plan made everyone happy – everyone’s feedback is on the roadmap, and now it’s all just a question of priorities.
• Still, there is some evidence that noncontingent, one-big-idea advice is less valuable than more nuanced, complicated advice.
• Tetlock’s talk on this is subtitled “Ignore Confident Forecasters,” which I think is an excellent summary of his findings.

Drunk Post Things I've Learned as a Sr Engineer, flipstables, 2021

• Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.
• Tests are important but TDD is a damn cult.
• The best demonstration of great leadership is when my leader took the fall for a mistake that was 100% my fault. You better believe I would've walked over fire for her.On the same token, the best leaders I've been privileged to work under did their best to both advocate for my opinions and also explain to me other opinions 'that conflict with mine. I'm working hard to be like them.

Friday Facts #366 - The Only Way to Go Fast, Is to Go Well!, kovarex, 2021

• Its primary function is that the bees build their tiles evenly and quite fast, as it is just natural to follow the optimised structure that is already there. And this is exactly what happens with code that has a good and expandable design from the start.
• one of his main roles was making sure that any discovered bug is first covered by a test before it gets actually fixed, and generally improving our code test coverage. This made the releases much more confident, and we had less regression bugs, which directly transitions into long-term efficiency. I strongly believe that this clearly indicates and supports what Uncle bob is saying. Working with tests feels slower but it is actually faster.
• The only way to go fast is to go well!

How to Work Hard, paulgraham.com, 2021

• Working hard is not just a dial you turn up to 11. It's a complicated, dynamic system that has to be tuned just right at each point. You have to understand the shape of real work, see clearly what kind you're best suited for, aim as close to the true core of it as you can, accurately judge at each moment both what you're capable of and how you're doing, and put in as many hours each day as you can without harming the quality of the result. This network is too complicated to trick. But if you're consistently honest and clear-sighted, it will automatically assume an optimal shape, and you'll be productive in a way few people are.
• The difficulty of figuring out what to work on varies enormously from one person to another. That's one of the most important things I've learned about work since I was a kid. As a kid, you get the impression that everyone has a calling, and all they have to do is figure out what it is. That's how it works in movies, and in the streamlined biographies fed to kids. Sometimes it works that way in real life. Some people figure out what to do as children and just do it, like Mozart. But others, like Newton, turn restlessly from one kind of work to another.
• The only way to find the limit is by crossing it. Cultivate a sensitivity to the quality of the work you're doing, and then you'll notice if it decreases because you're working too hard. Honesty is critical here, in both directions: you have to notice when you're being lazy, but also when you're working too hard. And if you think there's something admirable about working too hard, get that idea out of your head.

On Working Too Hard Finding Balance, and Lessons Learned From Others, blog.lawrencejones.dev, 2021

• Doing this might help you work more, but it may permanently impact your ability to enjoy yourself outside of work. This type of mental trick is addictive, and it alters your perception of normal, developing a need to work that is disconnected from your personal goals. It’s more than developing a habit, it’s building an addiction. There is a risk of losing your ability to be present and enjoy your life when you’re not at a desk making ‘progress’.
• Ensuring you could be fully present in whatever you were doing was clearly important to him, and I’ve found this a healthy goal to balance against getting too into work.

Building a Vision of Life Without Work, livafi, 2021

• Some losses are net gains.
• Activities lead to interests.  Interests lead to passions.  And passions lead to the dark side.  (Sorry, couldn’t resist.)

Technical Debt Is Not Debt; It’s Not Even Technical, grevillemark, 2021

• A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable
• I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial.
• Technical debt affects: Competitiveness by slowing/speeding up new product development Costs (short-term decrease/long-term increases in development cycles) Customer satisfaction Whether a company can survive Once we realize that technical debt is a company-wide concern, we can no longer consider it technical, this label is too narrow and doesn’t communicate its significance.

Henry Rollins on Defining Success, thecreativeindependent.com, 2021

• But, I do try to write 1,000 words a day. It’s just like going to the gym.
• I think it’s important if you’re a creative person, or aspire to be, that you don’t spend too much time aspiring or asking advice. Just get going and address what’s roaring inside you.

Farnam Street, fs.blog, 2021

• The answer— and, in a sense, the tragedy of life— is that we seek to understand the goal and not the man. We set up a goal which demands of us certain things: and we do these things. We adjust to the demands of a concept which CANNOT be valid. When you were young, let us say that you wanted to be a fireman. I feel reasonably safe in saying that you no longer want to be a fireman. Why? Because your perspective has changed. It’s not the fireman who has changed, but you. Every man is the sum total of his reactions to experience. As your experiences differ and multiply, you become a different man, and hence your perspective changes. This goes on and on. Every reaction is a learning process; every significant experience alters your perspective.
• As I see it then, the formula runs something like this: a man must choose a path which will let his ABILITIES function at maximum efficiency toward the gratification of his DESIRES.
• beware of looking for goals: look for a way of life. Decide how you want to live and then see what you can do to make a living WITHIN that way of life. But you say, “I don’t know where to look; I don’t know what to look for.”

It’s Not What You Think, The Next Ten, 2021

• It’s possible that, along with grunge, Generation X’s other great gift to society is depression. I mean, of course it was here long before the Baby Boomers started re-producing, but we talk about it more than those who came before us. We talk about it as a demon or a monster. It’s a dark shadow that shows itself at any point in time without warning. It surrounds us, isolates us, and quiets us. Depression likes to blame things. We feel like shit because of mistakes we have made in life or because of the state of the world or because we aren’t perfect. Without a lot of help and a lot of work, it’s impossible to know that it really is a chemical imbalance in our brains. After twenty-plus years of trying to de-stigmatize depression, some of us still have a hard time recognizing it for what it is. And even then, it doesn’t always matter.
• You might think grunge is about anger, but that’s not completely true. Yes, it can sound that way, but it’s really about depression and cynicism. Those two go hand-in-hand, along with their nasty little sister, anxiety. When the three of them get going, they just eat hope as quickly as it can be summoned. That leaves despair and despair is exhausting, not just for those who experience it, but for the people around it as well. So we keep it to ourselves because we don’t want to be a burden. And then it gets to be too much.

Agile at 20 The Failed Rebellion, Al Tenhundfeld, 2021

• They weren’t project managers or CTOs or VP Engs. They were developers, programmers, scientists, and engineers. They were still slingin’ code* and working with their stakeholders to solve problems. This is important.
• Scrum was invented to function in hostile environments. It’s a contract between hard-pushing managers and developers needing time to think and explore.
• It turns out that prioritizing individuals and interactions is a hard concept to sell. It’s much easier to sell processes and tools. It turns out that working software is harder to produce than unrealistic plans and reams of documentation. It turns out that collaborating with customers requires trust and vulnerability, not always present in a business setting. It turns out that responding to change often gets outweighed by executives wanting to feel in control and still legitimately needing to make long-term plans for their businesses.

Henry Rollins’ Iron and the Soul, Brett, 2021

• I have never met a truly strong person who didn’t have self-respect. I think a lot of inwardly and outwardly directed contempt passes itself off as self-respect:
• pain is not my enemy; it is my call to greatness.

We Need to Talk About Testing, dannorth.net, 2021

• Shifting left on testing means thinking about architecture and design differently, considering different stakeholders early and continually. Which in turn means shifting left on security, accessibility, and all the other dimensions of quality that we should care about. So shifting left on testing motivates all kinds of assurance activities, which can stop us over-investing in a solution that was never going to work. It is like TDD on steroids.
• The purpose of testing is to increase confidence for stakeholders through evidence.
• To summarise: TDD, BDD, ATDD, and related methods categorically do not replace testing, whatever their names may suggest. They are primarily design and development techniques.

Almost-Billionaires, mikeBOS, 2021

• My own approach is to just keep the door open. I don’t have any big projects planned. Though I can see how building a business could be fun. Especially if you can do it without the stress of facing potential starvation and financial ruin if you don’t succeed.
• It seems there is something demotivating about financial independence. When you actually have the time, the money, the skills to do that great project you would have loved to had the resources to do when you were in college, suddenly it just doesn’t seem like such a great idea anymore

The Mindset That Kills Product Thinking, jpattonassociates.com, 2021

• I start lots of classes and talks by asking “what makes a product great?” Try this yourself right now. Think of a product you use routinely. Ask yourself why it’s great. Really. Pause and do that. I’ve done this long enough to know that a few things always come up. Things like: Easy to use Solves a problem Fun Delightful Saves me time
• Service providers make money selling time and materials. The service they provide is the product. Interestingly if your stakeholders love your work it likely doesn’t impact your business one way or another. And, I bet your company doesn’t make money selling your time and materials. And happy stakeholders giving you even more work isn’t helpful. It just buries you in more work.
• Too much work, or extra unplanned work is a good thing for him. It’s called “demand” in product speak. If he has more demand than he can satisfy he can: Hire more people Raise prices to reduce demand Turn down work – which often makes him more desirable enhancing his brand
• Reread the agile manifesto and all those values and principles. Notice how they’re written from the service provider’s perspective. Notice how customer, user, and the business are used almost interchangeably. Look at values like: Customer collaboration over contract negotiation That’s exactly what I want when I hire a kitchen remodeler. But collaboration doesn’t make much sense when I choose a product to use. Look at principles like: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software This makes perfect sense if you’re building software for money
• There’s one simple thing you and your team can do right now to start breaking the habit: Reflect on the outcome of everything you release.
• After releasing a feature, use part of your team’s routine reflection or retrospective to discuss how long the whole feature actually took relative to what you’d planned. Discuss its quality. Those are the service provider outcomes and they do matter. But, remember, they’re table stakes. What matters more is the outcome.

The Importance of Written Communication for Engineering Teams, Stephanie Emma Pfeffer, 2021

• To arrive at this solution, says Buritica, the first step is to survey the team about the issue: “How should we talk to each other? How should we communicate our availability? What isn’t working? What can work better? How should we deal with emergencies?” “Everyone is given the ability to provide suggestions, and I will come back with a draft of consolidated proposals,” he says. “Then as a team we discuss it, roll it out, and pilot it.” After he publishes the first draft, the team operates within the suggested framework for a few weeks to evaluate how the new process is working. Over time they integrate other necessary changes into the document until it defines standard operation.
• While good engineering managers can code, great ones can also communicate.

Effective Technical Leadership, David Byttow, 2021

• A tech lead is often a “human 302" (or a human redirect) and connects individuals together.
• Be a decider Part of your duty is to make decisions, and your team will rely on you. The faster you can reach a decision, the quicker others can act on it. Often, there is no clear path forward and simply going with your gut is the right thing to do.
• By design, a tech lead is often not a manager because they focus their energy on code, not people. So, it’s important to have the respect and trust of your team, which is best accomplished by demonstrating that you know your stuff.

Learning to Be a Mouse-Less Web Developer in VS Code, The drawback, 2021

• Backward and Forward" (
• Move a line up or down"

I Ruin Developers’ Lives With My Code Reviews and I'm Sorry, habr.com, 2021

• No big deal if the code’s not good, I can fix it myself it I need to. But I can’t fix the psyche of a guy broken by dozens of harsh reviews.

How Many Pets Do You Have?, sive.rs, 2021

• My house was overflowing. But it didn’t feel that way at the time. In each moment, I was giving just one pet my full attention. My life was full of so many loves. Ah, but that’s seeing it from my point of view. What about from theirs? Each pet only got a little of my time each week. The rest of the time they were neglected, waiting for my attention.
• So, I started releasing them back into the wild. One at a time, reluctantly, I’d set one free, or find it a new home with someone who was really going to give this pet 100% of their love. I mourned the loss of possibility with each one as I said goodbye.
• I let my last pet go, came home, and cleaned the house. There’s so much room for focus now.

What I Learnt Becoming a Tech Lead, tomgamon.com, 2021

• You don’t have to be the most experienced engineer in the team
• When giving updates to stakeholders such as product managers, project managers or engineering directors, tell them the impact of that decision upfront. We have decided to spend some extra time refactoring the Goose Protocol. The impact of this is that we will have to push the release out a week, but it will save us time when we implement the Duck and Chicken protocols next quarter.
• Don’t write code on the critical path

The Deep Life Some Notes, calnewport.com, 2021

• The tricky part in cultivating a deep life, of course, is figuring out what things matter. This will differ between different people. I strive to divide my focused attention among four categories: community (family, friends, etc.), craft (work and quality leisure), constitution (health), and contemplation (matters of the soul).
• In each of these areas I keep striving to identify the big swings — the actions or commitments that will make the most difference

On the Source of Our Drive to Get Things Done, calnewport.com, 2021

• titled: “Having Too Little or Too Much Time is Linked to Lower Subjective Well-Being.” This paper reports on the analysis of two large-scale time use data sets spanning over 35,000 Americans, and find that while it’s true, as expected, that having too little discretionary time lowers subjective well-being, the same unhappiness is also shown for having too much.
• The allure of productivity is therefore a complex one. We cannot dismiss it as the result of the evil master plan of mustache twirling capitalists. We also cannot embrace it as an unalloyed good. It’s a human drive tangled with the contradictory imperatives of culture.

Why You Should Repeat Yourself, a Lot, tomtunguz.com, 2021

• The typical audience increases its unaided recall to a brand after roughly 7 impressions [1].

How to Be a Nice Programmer, kennydodrill.net, 2021

• Learn to be nicer. Read articles aimed at the kinds of issues I've brought up. Books like How to Win Friends and Influence People by Dale Carnegie and The Mythical Man-Month by Frederick P. Brooks Jr are a great starting point.
• Stop being exact, and ask meaningful questions
• Step 1: Be nice

A Pastor Embraces Slowness, calnewport.com, 2021

• she scheduled only two-thirds of her available work hours, leaving time free to handle pastoral emergencies, and enabling, more generally, margin surrounding her daily activities.
• She forwarded all work calls to voicemail and put in place a rule saying she must wait 24 hours before replying to any message that either made her upset or elated.

Always Do Extra, Ben Northrop, 2021

• Doing More would be completing those two screens and then taking on a third screen that's just like it. Yes, this would help move the project along faster and make your manager happy, and that's great, but in the long-run, More doesn't give you much. Extra is different than More. Extra is finishing those two screens, but then researching a new library for form validation that might reduce the boilerplate code. Or it's learning ways to protect against common security vulnerabilities from data entry
• The first rule is this: Extra must be balanced against Normal Work. Real stuff still needs to get done.
• The second rule of Extra is that it must be aligned with your Normal Work.

Code Runs on People, rachelbythebay.com, 2021

• We get it, you're clever. But the business doesn't need clever. It needs code that is only as complicated as absolutely necessary to get the job done. Anything else is just wasted effort.

Best Practices, fev.al, 2021

• I found that most of the time, the expression could be replaced by “tradition”, “pattern”, or “the way I’ve seen others do”. If it’s a tradition, standard, or convention, and most people agree to it, fine. Might help with readability and familiarity ; and help people navigate through a code base (or whatever the best practice is about - boat knots, how you grease your mountain bike front fork, etc.). Call it a convention, stop pretending it’s the best, it’s just how we (or you) decided to do things. If it’s pattern, fine, but be ready to tell me why it’s applicable and helpful in our context. And stop calling it best, call it by its name. If you can’t explain why you’re doing something, and you’re just doing what you’ve been seeing others do, maybe rethink it and educate yourself on the topic. And do NOT call it a best practice because, obviously, you don’t know if it really is the best. Call it cargo cult.
• You don’t need to re-explain everything everytime, but at least don’t be lazy, and refer to the standard or the pattern that you’re referring to

They Don't Even Know the Fundamentals, blog.royalsloth.eu, 2021

• As a consequence of that, figuring out “what” we have to build is usually harder than figuring out “how” we are going to build it. A lot of the programming jobs out there are not really about coming up with groundbreaking solutions and once you understand the “what”, “how” will often be quite obvious and you can always fill the missing gaps of knowledge as you go along. After all, we are supposed to be engineers and not a walking encyclopedias.
• Ah yes, the fundamentals or endless list of things that everybody working in the field ought to know. Atomicity, something, something, Durability? To avoid any future embarrassments I made sure to dust off my Wild Hog book 1 and re-read the section on ACID. Here’s an excerpt directly from the book:
• After that passage the book goes on explaining all the potential situations and problems that you may fall into when dealing with databases. It’s an interesting read for sure (and necessary for anyone that is designing distributed systems), but even if I knew the exact definition I would be none the wiser.

Software Architecture Patterns 5 Minute Read, Orkhan Huseynli, 2021

• There are 5 patterns described in the book by Mark Richards:Layered architectureEvent-driven architectureMicrokernel architecture (or Plugin architecture)Microservices architectureSpace-based architecture (or Cloud architecture pattern)

Beyond Smart, paulgraham.com, 2021

• Imagine you had a choice between being really smart but discovering nothing new, and being less smart but discovering lots of new ideas. Surely you'd take the latter.

Don’t Be Spooky, therealadam.com, 2021

• Even more important, it prevents people from pre-gaming the conversation. That way, they don’t prepare for a conversation that happened in their heads, instead of one that’s about to happen. (Avoiding pre-gaming is important on both sides of the conversation, as it turns out.)
• It’s possibly the best advice for managers I’ve given so far. When you’re communicating with your team, lead with context and reassurance. Never message someone on your team, “let’s talk when you get a minute”. That’s void of information and scary as heck!

How Big Tech Runs Tech Projects and the Curious Absence of Scrum, Gergely Orosz, 2021

• Teams with dedicated project managers typically recorded lower satisfaction ratings at public or venture-funded tech companies. However, at non-venture funded companies and consultancies, several respondents were very happy with project management, and called out these people as a reason for their satisfaction. Teams being allowed to choose their own way of working was more common at public tech companies and venture-funded scaleups. Large, non-tech companies and smaller, non-venture-funded companies were more likely to mandate the same approach for all teams within the company. Team autonomy and high satisfaction seemed to be correlated. Many people rating their satisfaction as 4 or 5 mentioned autonomy, freedom and flexibility, and the putting of quality first at the team level, as a positive. Teams struggling often had little to do with the methodologies. People mentioned lack of vision, good engineers leaving, lack of transparency or poor tooling as reasons why things went badly. For these teams, no change of methodology would help because the issues ran deeper. JIRA has been mentioned mostly with negative associations: all 13 mentions of JIRA were in this setting. Being able to get things done without working much with JIRA was mentioned as a positive. Additionally, a recently IPOed, high-growth tech company moved over to JIRA and ran a survey among engineers. It measured a Net Promoter Score (NPS) of -83. This is staggeringly low, and means that 83% of engineers would advise against JIRA. As a counterpoint, an engineering leader at a public tech company with stable growth shared that their organization heavily relies on JIRA, using it as a knowledge engine. In their case, JIRA works well for large-scale coordination, after the organization fully adopted it.
• Engineers not involved in estimations that the team then committed to, is a frequent pain point. In my view, it’s one of the easiest ways to demotivate engineers – to the point of some leaving – and also to get a false sense of what a team can achieve. Requirements changing, even with dedicated project managers, sits poorly with engineers. While there are teams where requirements change a lot, on these teams it’s typically the engineers who run the projects, and can deal with them. However, when a dedicated project manager is unable to shield the team from requirements changing, respondents rated this approach as poor. Teams with no autonomy to change a failing project management approach also recorded low satisfaction. These kinds of responses were pronounced at companies where all teams were expected to follow the same methodology. It’s an example of directive leadership and while this approach can work well for roles where there is little creativity needed, it is usually a poor way to build high-performing software engineering teams. When teams can iterate together and change their processes on their own terms, satisfaction and productivity go up.
• Teams are free to choose the project management methodology they use. Many teams go with an RFC-like planning process, iterate on building, and ship all within a few weeks. Other teams use more Kanban-like processes, where they work on the highest priority items
• In order to understand how Big Tech manages projects, let’s take a step back and look at the environment most of these companies operate in, which I dive deeper into, in the article What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not. Autonomy for software engineers and teams. The expectation of developers at traditional companies is to complete assigned work. At SV-like companies, it's to solve problems that the business has. This is a huge difference. It impacts the day-to-day life of any engineer. Curious problem solvers, not mindless resources. A motivated engineer easily makes multiple times the impact of a "factory worker" who only does what they’re told.  For organizations with a factory worker attitude, this approach will bias towards more heavyweight project management approaches that leave little room for interpretation, on purpose. Internal data, code, and documentation transparency. Employees – and not just engineers – often have access to real time business metrics and data sources, to write their own queries and create custom reports. Exposure to the business and to business metrics. Engineers are encouraged to interact with the rest of the business and build relationships with non-engineers. In contrast, traditional companies often make it impossible for developers to interact with the rest of the business. Engineer-to-engineer comms over triangular-communication. Traditional companies will encourage hierarchical communication that slows down information flow, and results in slower decisions. Investing in a less frustrating developer experience. Companies that care about engineers solving problems quickly set up various platform teams, which reduce the developer experience churn. Higher pay, justified by higher leverage. Companies that leverage engineers well, have no trouble paying close to the top of the market, or above it. Caliber of the talent hired. These companies hire highly competent and highly motivated people, thanks to the combination of all the above. They have a large pool to choose from, as they are known for generous compensation packages, and strong career growth opportunities.
• In many cases, Product Managers do not own project management at Big Tech. The team is responsible for the execution, and the team lead – usually the Engineering Manager – is responsible for making this happen.
• With empowered and autonomous teams, managing a project is rarely a top down exercise. Each team will vary, but I’ve found great success in rotating the project lead role among engineers, helping everyone on the team grow their leadership muscle
• The lack of dedicated project managers raises several questions. Are engineers overloaded with project management? Is managing projects a good use of engineering time? All of these are possible, and here is my take. For team-level projects, not having a dedicated project manager ends up simplifying processes, and strengthening personal relationships. Engineering project leads will add as little process as they can, as this is in their interest. When collaborating with other teams – also without project managers – they will also build relationships for other engineers leading projects, or owning products. This kind of engineer-to-engineer communication is more efficient than if it went through multiple project managers as well. For complex projects that span several teams across different offices and time zones, leading such a project is a full-time job for an engineer. Big Tech pulls in Technical Project Managers (TPMs) to manage these complex, and often strategic projects, taking the load off engineers. Dedicated Program Managers or Project Managers still exist within Big Tech. They are typically tied to external-facing commitments and customers – such as a Program Manager for the Apple partnership – or to long-running initiatives, like a compliance program. Similar to how TPMs are not allocated to a single engineering team, these Program Managers or Product Managers also don’t tend to have an engineering team, but they work across many teams instead.
• Infrastructure and developer tooling removed the need for many Scrum rituals. Scrum rituals like demoing to the Product Owner, signing off the work and then shipping it, assumes a few things: That the Product Owner is the one who can with certainty validate the work as done to spec. That the Product Owner wrote the spec- because they are validating it. That the work is not being shipped to production before the signoff is done. However, in our environment, these assumptions were often flawed. All code we wrote was tested with unit tests and, where needed, with integration and end-to-end tests. We shipped our code behind feature flags, and validated them with staged rollouts, starting with a rollout to the team. A lot of the “specs” – or tickets – were also written by engineers, who could then validate if they worked as expected. CI/CD, feature flags and experimentation tooling allowed us to have faster feedback cycles than relying on a Product Owner.
• The first thing we did was make QA part of engineering. In the “old world”, an engineer would finish their work, check into their branch, update a ticket, and let the QA know it’s ready for review. The QA would take this ticket a day or two later, review it, and reopen the ticket if they found issues. This was a long delay.
• When talking to engineers at Facebook, Whatsapp, Google, Netflix and similar organizations, most of them have never used Scrum. Why? It’s because of a few things: Competent, autonomous people need less structure to produce reliable, high-quality output. Big Tech is able to attract, afford and hire these people. Leveraging competent teams comes through giving them freedom to choose how to operate. This is true for most types of engineering, and there’s good reason why the Skunk Works model of autonomy with reduced bureaucracy, is what many high-performing teams with high-caliber people end up following.
• Scaling an engineering organization goes well beyond team-level processes, which is another reason most of Big Tech does not push heavyweight team processes. This is not to say these organizations don’t have challenges with productivity, but most of these challenges are not ones that a heavyweight process would solve.
• A few situations where Scrum can be a good alternative: 1. “Kitchen sink teams” which have everything thrown at them, typically find that managing stakeholders with a heavyweight process like Scrum is a win. Stakeholders are educated to understand that an ongoing sprint cannot be interrupted and that new feature requests need to be groomed. Teams with conflicting priorities get to execute with fewer interruptions, thanks to the sprint structure giving space for the team to ignore these interruptions. “Kitchen sink teams” are typical within non-tech companies, where the business has no understanding of how engineering works. Scrum helps rein in the stakeholders and educates them on software development processes, while giving the engineering team breathing room to execute. They are also common in early-stage startups, where there is one engineering team to build everything.
• Forming” and “storming” stages of new teams. Psychologist Bruce Tuckman came up with the phrase "forming, storming, norming, and performing” as phases on how groups work. This model very much fits how most engineering teams evolve as well. When a new team is assembled, that team needs to decide how it will work. Reaching for an off-the-shelf approach like Scrum is almost always a better choice to start with, than group members who are unfamiliar with each other coming up with custom processes – or none at all
• Iterative changes always work better than ‘big bang’ ones. A European tech company struggling with shipping very slowly hired a new VP of Engineering. This person decided to move the whole organization to a NoEstimates method in the first few months of their tenure. They organized a major event, hired a rock band, and unveiled the new way of working. The following weeks and months were chaos, and the organization reverted to doing what it did beforehand.
• The fewer people you need to make decisions, the faster you can make them. If an engineer only needs to talk to an engineer to decide, that decision will be faster than if the engineer needs to talk to their project manager, who talks to another project manager, who talks to an engineer, who talks to… you get it.
• Optimizing for reporting is optimizing for a low-trust environment.

The NoEstimates Movement, ronjeffries.com, 2021

• The basic idea, as I understand it, is that it is possible to do small chunks of work incrementally, leading as rapidly as possible to a desired shippable product, and that when you do that there is no need to do much of anything in the way of estimating stories or the project.

How WhatsApp Scaled to 1 Billion Users With Only 50 Engineers, Quastor Tech, 2021

• WhatsApp’s Engineering culture consists of 3 main principles Keep Things Small Keep Things Simple Have a Single Minded Focus on the Mission
• Keep Things Simple WhatsApp uses the mantra Just Enough Engineering. They avoid over-investing in systems and components. Instead, they focus on building just enough for scalability, security and reliability. One of the key factors when they make technical choices is “what is the simplest approach?” Also, they avoid investing in automation unless it’s completely necessary

Don’t Let Architecture Astronauts Scare You, Joel Spolsky, 2021

• It’s nice that we can use XML now for the format on the wire. Whoopee. But that’s about as interesting to me as learning that my supermarket uses trucks to get things from the warehouse. Yawn. Mangos, that’s interesting. Tell me something new that I can do that I couldn’t do before, O Astronauts, or stay up there in space and don’t waste any more of my time.

Goodbye, Clean Code, overreacted.io, 2021

• It’s a Phase Obsessing with “clean code” and removing duplication is a phase many of us go through. When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. A set of strict lint rules, a naming schema, a file structure, a lack of duplication
• Let clean code guide you. Then let it go.

WTF Is Strategy?, hackernoon.com, 2021

• Strategy is a set of principles and decisions — informed by reality (eg. market forces, data) and caveated with assumptions — that you commit to ahead of development to ensure the greatest likelihood of achieving your vision. Vision: This is the idealized solution that addresses the problem you’ve articulated in your mission. Vision is the goal post and rallying point for your product — it paints the picture of how your product will make an impact. Strategy may evolve with the introduction of new data, while the mission and strategy remain a pivot.
• The Framework Before we talk about strategy, it needs to be contextualized within a few other concepts primarily because strategy never exists (or shouldn’t exist) in isolation. Here are the high-level definitions of the different components from a product-centric view: Mission: This is a statement that describes the problem you are setting out to solve, typically including who you are solving it for. This is often set at the company level, but can also be defined for a product or product line. Vision: This is the idealized solution that addresses the problem you’ve articulated in your mission. A product vision typically has just enough viability to be relatable, but is still devoid of the details that may hamper your imagination. Product vision is also the goal post and rallying point for your product — it paints the picture of how your product will make an impact. Strategy: This is a set of principles and decisions — informed by reality (e.g. market forces, laws of physics, data) and caveated with assumptions — that you commit to ahead of development to ensure the greatest likelihood of success in achieving your vision. Your strategy may evolve with the introduction of new data. If there’s a big shift in strategy while the mission and vision remain constant, it’s called a pivot. Roadmap: This is the manifestation of your strategy in concrete steps towards your product vision, inclusive of rough milestones and timelines. This, too, often changes given new data. (As I like to say, a roadmap is defunct as soon as it’s published.) Execution: This is the day-to-day activities along the path of the roadmap. This is where you do the hard work to build, launch, and iterate, all the while collecting the necessary data to inform any changes in your roadmap and strategy.

What if Performance Advertising Is Just an Analytics Scam?, Rand Fishkin, 2021

• If Williams Sonoma turns off branded search ads and Exasol shuts off display ads, who wins? Sure, their bottom lines do. But, which member(s) of their organizations gets credit? Maybe, if we lived in a very different macroeconomic environment, a hard-nosed CFO could get a pat on the shoulder. But in a world with interest rates at 0% and investors clamoring for growth > profits, fuggedaboutit.
• When no one’s incentivized to make the right move, the right move may as well not exist.

Feedback Loops Are Bullshit, danielbmarkham.com, 2021

• This leaves us stuck using flowcharts, class diagrams, feedback loops and the rest. But the real action is with Feedback Webs. Like our database diagrams, the situation, the things we have to work with, are both solid and amorphous at the same time, depending on the level of detail you're using.

136 Facts Every Web Dev Should Know Before They Burn Out and Turn to Landscape Painting or Nude Modelling, Baldur Bjarnason, 2021

• Sturgeon’s law applies to your work as well. Don’t linger on one project forever. Make new things. That’s the only way to learn.
• Most products don’t need the features that SPAs provide. Teams need SPAs but not for the product itself. SPAs make for great demos and lovely presentations, which leads to more support for the team, more funding, and that way, SPAs improve the odds of success.
• The first rule of SPAs: we always underestimate the complexity of handling state. Often by a large margin. The second rule of SPAs: we always underestimate the complexity of reimplementing history and link navigation. Often by a large margin. But we get away with not caring because nobody tests history management properly.
• Every SPA I’ve ever used has at some point let me down when it comes to navigation or history management: Resetting a view when you click the back button (browsers have an excellent back-forward cache! Use it!). Not loading the correct view. Failing to load a part of the screen. Losing data/context when opening a link in a new tab. Or just giving up altogether. They all fuck up at some point. Server-routed sites aren’t perfect, but there’s a lot less that can go wrong.
• Minimalism is garbage. Simplicity is great, but minimalism sucks. Everything you see on the screen should have a reason to be there (be an embodiment of ‘doing’), but if the reasons are complicated, then the design should represent that complexity. Hiding complications makes everything harder, and excessive minimalism is just as harmful as excessive decoration.
• Svelte and Typescript are very useful, but the cost of building is always more than you think, especially once the codebase grows.
• The job of development is to build a theory in your mind about the codebase.
• Avoid using web workers (the web stack’s equivalent for a process) or threads if you can. They make theory-building harder.
• Working on a functioning app’s codebase does more to increase its quality than adding features.
• Working on an iffy codebase (and they all start iffy) to make it cleaner, more sensible, and more robust without adding features or functionality can save you weeks if not months of future work.
• Once you have a working app, working on code quality is just as likely to provide as much business value as a new feature.
• Fuck ups happen. Nobody is to blame even when somebody is responsible. Use it as an opportunity to see where the process didn’t work. And if you don’t have a process—well, that’s what’s wrong. Right?
• Most project management software is garbage because organisations generally don’t lack the tools to manage work. You could replace most project management software with a spreadsheet with no issue. The problem all organisations have, which most think is a project management problem, is team and organisation communications.
• The only exception to this is when a brand new technical innovation opens up a new field. Which is rarer than you think as a better design doesn’t qualify as sufficient innovation. Unless you are the one who spent years developing that innovation from scratch, you are only performing arbitrage. That’s a recipe for squashed margins and brutal competition.
• Any field with multiple successful competitors is good news. It means that there is demand, which you can tap in by addressing the problem in your way
• Never go up against a free service from a multinational. At least, never directly. Try to position yourself so that the free services from other companies complement your paid service.
• Any field where all of the other competitors have five (or more) salespeople for every developer isn’t going to be pleasant for the developer, no matter if they’re an employee or a founder. Probably great if you’re a salesperson, though.
• Web dev is pop culture. Don’t get too stuck on trend-du-jour. Give it enough time and what was old is new again.
• Web dev is pop culture. You have two choices: keep up with the trends or have enough individuality to be timeless. (Which is easier said than done, though.)
• Web dev frameworks are for organisations, not small software teams or individual developers. The value frameworks provide lies in bridging team boundaries: they create a shared understanding that aids in collaboration across groups, simplify messaging, and establish clear conventions. Frameworks turn teams in large organisations into service interfaces.
• Individual teams or individual developers don’t have that problem, so they get less value from a web dev framework. The more opinionated the framework is and the more of the web platform it abstracts away, the more its value proposition skews towards solving organisational problems and the less value it provides to individual teams.

Join the AMAZING CTO Newsletter Like Many Others!, Stephan Schmidt, 2021

• Why work on things together as a team? Why work together on designing the feature? We write the code while you draw the UI. Product is two sprints ahead, design is one sprint ahead, developers write the code and QA – if there is QA – is one sprint behind. Waterfall kills agile because you can’t change course with a queue and roadmaps.
• Sadly, I haven’t seen many product owners, most are product managers that manage external stakeholders.
• Those stakeholders drive the product, madly pulling the steering wheel to the right and left. These external stake holders want predictability, because they don’t care about the product but see the product as a tool for their goals. When will it be ready? The stake holders queue up in a long line. And just like in Disneyland where it says “60 min from here” they want to know when “their” feature is developed. This drives waterfall. To coordinate and communicate about the queue product management draws up roadmaps. With a roadmap the product team will sprint ahead and work on future things – for the sake of efficiency. “I can already work on the UI of the next feature”. Efficiency is the key driver for waterfall. In a culture of permanent business pressure with a long queue of stakeholders everything gets sacrificed on the altar of efficiency. Efficiency drives waterfall into everything.

Product Roadmaps for CTOs, Stephan Schmidt, 2021

• Roadmaps only work with deadlines which make developers feel miserable without need and leads to unsuccessful products. Therefore, you have to say: No, no, no!
• Roadmaps are also driven by the desire for control. If you do not have a roadmap, what will developers build? Managers do not trust their departments; CEOs do not trust their companies to build the right things. With a roadmap, managers can feel in control.
• Roadmaps are pacifiers, they keep people calm and shut up, “my feature is on the roadmap”. They are there so someone didn’t have to say no. They pawn the future to happiness in the present. Instead of all of this, say No! Steve Jobs told employees in 1997 when he killed a feature Apples developer loved:
• Start each quarter with an empty table - tabula rasa - and not with a backlog or a roadmap filled with features and products. Build what needs to be built in that moment. Do what need to be done for the success of your company in the marketplace. For developing features and products push down responsibility as far as possible. Self-organized product teams decide what to build. Self-organized product teams decide what not to build. Self-organized, cross functional teams are responsible for the success of their work. They are guided by objectives which help them to make decisions.
• Have a dedicated team for marketing and other departments, which only builds marketing integrations and landing pages. Your product teams focus on building the product. This will remove the pressure to put things on a roadmap, as often marketing wants a roadmap and their features on the roadmap so they are – rightfully - not forgotten and can plan their campaigns. Decouple marketing campaign planning from building successful products.

The Skill of Org Design, Cedric Chin, 2021

• How did you do it? Or more importantly, how do you get good at org design?” And I said: “I don’t know. I just did what felt right.”
• Organisational design is a design problem. Like all design problems, the nature of the problem is a search for form-context fit. In other words, you are attempting to find some ‘form’ (an org ‘shape’, or a combination of systems, processes, and culture) that allows you to achieve some set of goals, given the specific constraints in which the org operates (the ‘context’). The key difficulty with this task is that organisations are complex adaptive systems
• economic incentives, b) ‘contractual’ obligations, and c) culture. These three tools make up your org design toolbox.
• Systems thinking means a particular thing here: you are able to predict how people are going to respond to incentives. I mean incentives broadly: there are psychological and status incentives, created by the structure of your org and the people in it, and there are also economic incentives, that fall out of your promotion and compensation policies.
• The Three Modes of Organisational Control In High Output Management, Andy Grove argues that there are really only three forms of organisational control: Economic incentives (what Grove calls ‘free-market forces’) — for instance when you purchase something for a price, or take economically motivated action with your self-interests in mind. Contractual obligations — when you stop for a traffic light, or work within prescribed roles in a company — say, if you are in marketing, and you have to work with sales (Hubspot sales leader Mark Roberge calls this ‘the sales-marketing service level agreement’, which is usually implicit in most companies). Culture — when you are influenced by ‘this is the way we do things here.’
• So the way I ran certain org changes was to: Get a sense for team receptivity for that org change, balanced against the necessity of the org change. If I sensed that the team would be resistant to the change, I would: Figure out how much I had left in the ‘credibility/trust’ bank, and if I wanted to burn that capital. If possible, find a smaller, more reversible version of the org change to introduce first. Use disasters to my full advantage (people are usually more receptive to trying new ways of doing things in the wake of something painful). Strategically allow certain things to blow up so that I could exploit the pain to introduce org change, as per 4) above. Or build consensus; consensus was always the best, if most time consuming, option.

3 Lines of Code Shouldn't Take All Day, Adam Berg, 2021

• When I finally left the company I felt better knowing that I left a system that had it’s own checks in place. The hours of me figuring out how something is supposed to work is codified in a test spec.
• it takes too darn long to test these changes, is there a better way?”

Why Tacit Knowledge Is More Important Than Deliberate Practice, Cedric Chin, 2021

• If you are a knowledge worker, tacit knowledge is a lot more important to the development of your field of expertise than you might think.

You Don't Need That CORS Request, > nick, 2022

• This conversation between the browser and the API is only necessary because our API at api.foobarbaz.app is not of the same origin as foobarbaz.app, specifically our hostname is now different. Port (:443, :80, etc) and protocol (HTTP, HTTPS) also follow the same logic as hostname, so any differences in the page's hostname, port, and protocol and a request executed on the page will require a CORS request. web.dev's Understanding "same-site" and "same-origin" does a great job of breaking down the parts of a URL.

Why I’m Using HTTP Basic Auth in 2022, Joel Dare, 2022

• Some online resources mention that HTTP Basic Authentication is deprecated, but that’s a misunderstanding. Only passing username and password as part of the URL is deprecated. It’s still perfectly valid to pass the credentials in the HTTP header and that’s what I’ll be doing. This method works in every modern browser.

Don’t Waste the Good Days, seths.blog, 2022

• If you’re feeling creative, do the errands tomorrow. If you’re fit and healthy, take a day to go surfing. When inspiration strikes, write it down. The calendar belongs to everyone else. Their schedule isn’t your schedule unless it helps you get where you’re going.

Most Advice Is Pretty Bad, Sam, 2022

• I think good advice has three main components: It is not obvious It is actionable It is based on some true insight

How I Learned to Stop Worrying and Push to Master, Thenable, 2022

• We do have a manual QA step in staging, but since we are continuously integrating our code, every issue that is found is considered a new bug in our system. We do have more bug tickets than we did before changing our process, but it also allows us to complete features more quickly and iterate on them.
• Trunk-Based Development,

I Think I Know Why You Can't Hire Engineers Right Now, cushychicken.github.io, 2022

• Cool stuff to work on. Smart people to work with. Some degree of repeatability in work environment.

It’s Time to Embrace Slow Productivity, Cal Newport, 2022

• A natural fear is that by reducing the amount of work each employee tackles at any given time, it might reduce the total amount of work an organization is able to complete, making it less competitive. This fear is unfounded. As argued, when an individual’s work volume increases, so does the accompanying overhead and stress, reducing both the time remaining to actually execute the tasks and the quality of the results.
• The bigger challenge of Slow Productivity is that it requires systems to manage work that’s not yet assigned. If you’re a boss, and an important task pops to mind—“We need to update our Web site with new client testimonials!”—you can no longer simply e-mail the request to one of your underlings and move on with your day. Slow Productivity would require you to log this item into a system where it can be properly prioritized and ultimately assigned when the right person has the needed time available.
• If you instead enable the individual to work more sequentially, focussing on a small number of things at a time, waiting until she is done before bringing on new obligations, the rate at which she completes tasks might actually increase.

⭐️ Effortless Personal Productivity, Jakob Greenfeld, 2022

• Step 1: develop meta-awareness of your state of mind. Step 2: pattern-match to identify your mind’s most common modes. Step 3: learn to pick activities that match each mode.

Why It’s Great to Be a Consultant, zwischenzugs, 2022

• You are outside the company hierarchy
• You have to keep learning
• You get more exposure

Stop Brainstorming, matthewstrom.com, 2022

• Here’s how one leader interpreted the first rule to one of his [brainstorming] groups: “If you try to get hot and cold water out of the same faucet at the same time, you will get only tepid water. And if you try to criticize and create at the same time, you can’t turn on either cold enough criticism or hot enough ideas. So let’s stick solely to ideas—let’s cut out all criticism during this session.”
• Because blocking slows down the generation of ideas in groups, it might be more effective to ask subjects first to develop their ideas in individual sessions and next have these ideas discussed and evaluated in a group session.

The Boring Technology Checklist, blog.staging.begin.com, 2022

• A Boring Technology Checklist
• In a companion talk/website Dan proposes a system for selecting new technology called ‘Innovation Tokens’. You get three. One per technology. “These represent our limited capacity to do something creative, or weird, or hard. We really don’t have that many of these to allocate. Early on in a company’s life, we get like maybe three. Not too many more than that.”
• Familiarity, stability, reliability, well-understood limits, and expected trade-offs

Tips on Prioritizing Tech Debt in a Healthy Way, Csaba Okrona, 2022

• Some examples of phrasing technical debt around risk: We might fix a bug in 2 places but miss the 3rd due to code duplication. The design of the current system could lead to a slow user experience at higher usage scenarios. Lacking security practices could result in breaches and legal liabilities. Accidental introduction of new bugs into the feature is probable due to our lack of unit tests. The complexity and inflexibility of the codebase result in us saying no to new features due to long development times
• ICE and RICE scoring You end up with many items of different sizes and impacts – then it becomes very chaotic. ICE can help bring order to this chaos by a methodical approach to assessing these items and creating a single numerical representation of their priority based on which you can simply sort them. ICE stands for Impact, Confidence, and Ease/Effort. The R in RICE stands for Reach. For each of these factors, the team agrees on a set of numerical points, e.g. Massive = 3 High = 2, Medium = 1, Low = 0.5, Minimal = 0.25 Impact - What impact would solving this issue have on the customers (remember, customers can be internal too!) - or, when thinking about risk, what impact would not solving the issue have? Confidence - How confident are you in your estimation of the impact (and optionally the ease/effort)? Ease/Effort - Effort is usually easier to talk about - how much effort would it take to solve the issue? Remember that it's a relative metric, comparable only across the other issues in the current batch. Reach - How many people will this impact? 100% of your customer base? Only a specific persona? It's important to understand that these scores are only meaningful in the local, relative context and should not be compared across domains. Once you have the numbers, the calculation is easy: RICE score = (Impact x Confidence) / Effort or Impact x Confidence x Ease
• The myth of the two backlogs Let's start with what not to do. Many teams end up with two kinds of backlogs – one product-focused and one tech-focused. It won't work for multiple reasons: It'll be nearly impossible to cross-prioritize items in separate backlogs against each other. It fuels the "us vs. them" mindset, which kills team cohesion and common goals. Prioritization is the job of the whole team; leaving out Product representatives won't work. It makes sprint planning harder unless you have strict rules on how to allocate capacity (e.g., 20% goes to tech debt consistently)

Unlearning Perfectionism, arunkprasad.com, 2022

• More prosaically, the tendency correlates with a stunning number of maladaptive patterns, often as a cause. Here are four: Procrastination through fear of failure and delaying complex uncertain tasks. The perfectionist procrastinates to avoid confronting her imperfection. She is also slow to ask for help because doing so would mean admitting that she's struggling. Impostor syndrome as the fear of being found out and judged unworthy: not smart, not capable, not good enough to meet an ideal standard. The perfectionist blends in and acts the part for fear of being found out and rejected. Obsessive compulsion, both as full OCD and in its milder forms. For example, the recurring anxious fear of inadequacy leads to the self-soothing response of scrolling Twitter for an hour. Burnout, which some see as a kind of PTSD. A defenseless perfectionist that chronically fails to live up to her ideal endures deep emotional trauma. In the worst case, she loses all sense of self-worth.
• The perfectionist fears setbacks, uncertainty, true knowledge of her strengths and weaknesses, failure that can't be blamed on others, and anything else that threatens her outcomes or her fixed sense of self. She deprives herself of the explosive growth that comes from uncertainty, struggle, and open exploration. Like a tree that grows only as large as its pot, she hews to the familiar and stunts her potential. She is theory over practice; dreaming over acting; resentment over curiosity; fantasy over reality. She dwells in puddles for fear of the ocean.
• None of these outcomes are problems. But they become so when they intertwine with our identity and self-worth. If a perfectionist of fame ever feels unknown, then he feels worthless and ashamed. Hence the perfectionist stakes his identity on achieving his outcomes, meaning his self-worth depends on realizing them. This is a pitiful wager and a poor strategy. Above all, perfectionism is a tendency, not a law. With practice, we can unlearn it and replace it with far better approaches. If you clearly see this tendency in yourself, you then have a choice: to reinforce it through your actions, or to unlearn it and practice something better. Either way, it's your decision.
• One alternative with a similar flavor is excellence, which differs in two respects: Where perfectionism focuses on achieving, excellence focuses on pursuing. Success and failure aren't ever in our full control. All we can control is what we choose to do right now, in this moment. Our attention shifts from outcomes to process. Where perfectionism focuses on fixed outcomes, excellence focuses on better outcomes. Any real situation can always be improved. Since there is no perfect outcome, perfection is impossible.

Managing People 🤯, klinger.io, 2022

• your job is not to manage people but to manage processes and lead people You manage processes on how you expect work to be done, where each person's authority starts and ends, how their careers are made, and how all this can be discussed, and/or changed Additionally, you are leading people by example and through empathy. They have goals, fears and motivations. Frequently also problems outside of work. Act how you would want them to act if the role would be reversed.
• Processes are not complex chains of people doing things that are burdened by horrible overheads Processes are expectations made explicit They can be as simple as "every morning we all do X to ensure everyone else is unblocked." Have few but very explicit processes and expect them to be followed
• In every discussion/project/problem/situation, it needs to be clear who makes decisions …everyone else only adds opinions. Ideally, the person who will afterward do (or lead) the follow-up work makes the decisions. Everyone else just adds opinions. This includes people of higher "rank" or pay.
• The worst thing that can happen is that you frequently step in, and people disassociate from their work
• Don't confuse autonomy and abandonment I frequently meet founders who hire people "and get out of their way" While this is principle correct it doesn't absolve you from enabling them to succeed
• Always reflect if your nervousness is due to other people's work or your insecurity Should other people have to handle your emotions for you? Also, it's easy to trust when things go well The real challenge is when things go wrong Always differ between your frustration about a situation and your frustration about a person
• Avoid drive-by management Don't start throwing your opinion or ideas around in meetings You most likely lack context, and most likely, you won't be the person needing to follow through. Make it clear that it's just opinions and not decisions.
• Feedbacking people people x context = output I had great people in bad setups that had lousy output I had very ordinary people in great setups that churned out more work than a whole team
• A huge production incident happened? How was this possible in the first place? Where was the focus of the engineering team? Was there a process in place to avoid it? Should there be one? The person breaking production isn't at fault here. A whole team focused on other priorities Was this for the right reasons? (eg release pressure?) Or the wrong ones? (lacking sophistication?)
• Firing should never be a surprise People should never be surprised that they are fired Context changed, new requirements should have been communicated
• Explicit > Implicit Clear decisions after meetings No clear decision? Make that explicit too.
• Best practices: Start by making true what's real When looking for best practices or changes in the team/processes, always look at first what already naturally emerged
• It's a common misconception that burnouts come from hard work.  Burnout comes from a felt loss of control and/or impact.

I Relearned Typing to Save My Wrists, zsa, 2022

• in the beginning I accepted I'd be significantly slower, and I forced myself to keep typing properly – working from home definitely helped since nobody could see me struggle I moved all the keycaps so that they now reflect the Colemak layout – it's possible because Ergodox uses flat keycaps (I believe they're called DSA) instead of sculpted ones like a lot of other keyboards
• I only switched to QWERTY when I had to write something long quite quickly and I got too frustrated with Colemak; in the first couple of weeks it was maybe once a day, later I stopped switching entirely
• The best example from my setup are tap vs hold. The home row keys on my keyboard as act letters when I tap them, but when I press and hold them they act as modifier keys (Cmd, Opt, Ctrl). This allows me to use common shortcuts like Cmd+C (copy) or Cmd+S (save) without having to reach keys in the most bottom row of the keyboard. Instead my shortcuts are N+C (copy) or N+S (save). It required some trial and error, but it's been a real game changer for me. Here's my current setup if you're curious.

The Baseline for Web Development in 2022, Alan Dávalos, 2022

• TL;DR:The baseline for web development in 2022 is: low-spec Android devices in terms of performance, Safari from two years before in terms of Web Standards, and 4G in terms of networks. The web in general is not answering those needs properly, especially in terms of performance where factors such as an over-dependence on JavaScript are hindering our sites’ performance.

A Career Ending Mistake — Bitfield Consulting, John Arundel, 2022

• Managing people is hard; much harder than programming. Computers just do what you tell them, whether that's right or wrong (usually wrong). Anyone can get good at programming. I'm not sure anyone can get good at managing, and most don't. Most managers are terrible.
• Once you do have a sense of where you want to go, it can help guide your choices. Even if you don't know exactly what your perfect job looks like, you may start to feel that you won't be truly happy until you're independent, or a senior IC, or a manager. You can steer away from things which would limit your options in those areas, and instead seek out companies, fields, or sectors where you'll have the best chance of achieving the career you want. That's not to say you should have a detailed
• It's not the plan that's important: it's the planning, and the time to start planning is now. It's never too early, and it's also never too late, provided, of course, that you don't have your own little incident. Let's be careful out there.

Practical Guide to Solving Hard Problems, praeclarum.org, 2022

• No huge revelations here, just hard-earned advice. Think hard about the problem for a few weeks before typing any code. Type in a function or write a class that has the inputs and outputs you need. Break the function down into multiple steps with clear objectives. You may not know how to achieve those objectives, but that’s a problem for your future self. Right now, you’re just trying to write out the high-level algorithm. Create a function for each of those steps and throw new NotImplementedException() in each of them. Their names should be long and explanatory and there should be no question about what’s expected of them. It’s really OK if you don’t actually know how to write ‘em. Now, go implement a few of those functions. You know they’re not all hard. Some may even be fun! Build up your confidence and implement the easy ones. It feels good to make progress and it lets the analytical part of your brain run in the background for a bit while you focus on nitty grid number types and file IO. Time to tackle some of those harder functions. Go into each of those and break the problem down into steps just like you did before. You’re right, I’m gonna say it: Rinse and repeat. Keep breaking those hard problems down into steps. Turn each of those steps into a function with a clear name. Implement the easy ones. Then break the hard ones down into steps again. Do this over and over again. You’ll be surprised how much you can actually get done. Pretty soon (haha) you will have an 80% complete solution with just a few pesky functions left that throw NotImplemented. Now go scour your favorite package repository, or code repository, or question and answer site, or artificial intelligence programming assistant for implementations. Chances are you’re not the first person to need this particular function or widget. Find some giants, climb on top of them, and scream “Holy shit, there are a lot of smart programmers in the world!” OK, you’ve scoured the inter webs and yet you still have a few pesky NotImplemented exceptions. It’s time to check on those scientists. Enter every SEO permutation of your problem statement into arXiv. Surely others have worked on problems related to one you are trying to solve. They will most likely offer insights or perspective shifts that can help you reframe your problem into something solvable. Do that. Reframe your problem and knock out those NotImplementeds. Now you’re in trouble. If you still have a few NotImplemented exceptions, and there are no giants upon which to stand nor academics obsessing over this particular field, then it’s all up to you. Think big. Think outside the box. Your career depends on it. (Just kidding, I hope.) Perhaps a bath will help you think? I think these are steps all programmers take, but sometimes it’s good to spell it out.

How to Do Less, Alex Turek, 2022

• Copy/paste: How to Say No Here are some concrete ways to tell management or stakeholders no. This isn’t MAIN_PRIORITY, so we aren’t going to do it until at least ESTIMATED_DONE_DATE. Right now our priority is MAIN_PRIORITY because of ONE_SENTENCE_JUSTIFICATION, and this is 100% our shipping focus. I agree this sounds like a really useful feature - once we finish MAIN_PRIORITY, should we consider dropping SECOND_PRIORITY and do it?
• Get out of the trap First, you need to lower everybody’s expectations, ASAP. Make and broadcast cuts
• Cut the entire roadmap of new features down to one thing at a time.
• Here’s the thing: an early stage startup is just a future company that might get customer traction and take off. A tiny incubation team in some big tech company might become a 100-person org building features to try to match execs’ ambitions. Both of these have these things in tension: Iterate: You need to try some stuff with the product, to see if customers care about it. Invest: There’s a reasonable chance that this hack you’re about to ship causes an entire team to be mad at you in 6 months. The only way I’ve found to handle that tension is in a small org is to be all in on one mode or the other. Default to Iterate, but be willing to Invest, maximizing how many people can work on the investments until they’re done.

No Is a Complete Sentence, networkingnerd, 2022

• Let me tell you clearly. “No” is a complete sentence. It requires no explanation or defense.
• Everything Sucking Equally If you know anything about QoS, you know that once a given circuit reaches the limitation for bandwidth you can no longer send additional information. What’s counterintuitive about this is most people would assume that if you try to squeeze one more stream or packet into the mix that only that last packet would be affected and everything else would work perfectly fine, right? Only one of the many would suck. Sadly, all of the packets or flows on the circuit are affected in this situation. Adding just one more thing to the mix means all things are affected because the system has to process the problems all at once. You suffer everywhere because the interface couldn’t say “no” to that last packet
• The calling card of bad management types is to show up, assign a bunch of tasks that only other people should do, and then fly away to measure their productivity and comment on how nothing seems to be getting done. Instead, management should be asking how they can help. Is this something that someone else could do? Do you have the bandwidth to do the task? Is there another task on your plate that I can do for you that would help you to take care of this?
• I will admit this post is as much for me as it is for others. I am the world’s worst for taking on additional things when I know I don’t have the bandwidth to do it all. I don’t like to disappoint. I really want to keep people happy. And instead I end up failing because I overestimate my ability to get work done and underestimate how much others could do if they knew I needed help. Next time you need to tell someone you can’t do something, don’t spend a ton of effort figuring out how to counter their eventual arguments. Just say “no” and move on. If it’s important or something that only you can do they will find a way to make it work. Otherwise, you will have saved so much more effort because you used a complete sentence instead of a needless paragraph.

How to Design Better APIs, r.bluethl.net, 2022

• Prefer PATCH over PUT As mentioned earlier, PATCH requests should apply partial updates to a resource, whereas PUT replaces an existing resource entirely. It's usually a good idea to design updates around PATCH requests, because:

Titles, Gokul Rajaram, 2022

• A better label for people managers: Use the term “Lead” (or a similarly generic term) for all people managers. This word replaces “Manager”, “Director”, “VP” or any other titles. Also make people manager titles as descriptive as possible. For example, Product Management Lead, Firmware Engineering Lead, <ProductName> Engineering Lead, <ProductName> Product Lead, <Geography> Sales Lead.
• Descriptive titles for individual contributors: Create job titles that precisely articulate what the person actually does. For example, Software Engineer, Firmware Engineer, Business Development Representative, Product Manager, Product Marketing Manager. This forces you to clearly spell out each person’s high level job description concisely as part of the job title, which is an excellent organizational design goal in and of itself.

Putting Ideas Into Words, paulgraham.com, 2022

• There may exist people whose thoughts are so perfectly formed that they just flow straight into words. But I've never known anyone who could do this, and if I met someone who said they could, it would seem evidence of their limitations rather than their ability.
• Putting ideas into words doesn't have to mean writing, of course. You can also do it the old way, by talking. But in my experience, writing is the stricter test. You have to commit to a single, optimal sequence of words. Less can go unsaid when you don't have tone of voice to carry meaning. And you can focus in a way that would seeem excessive in conversation.
• If writing down your ideas always makes them more precise and more complete, then no one who hasn't written about a topic has fully formed ideas about it. And someone who never writes has no fully formed ideas about anything nontrivial.
• It feels to them as if they do, especially if they're not in the habit of critically examining their own thinking. Ideas can feel complete. It's only when you try to put them into words that you discover they're not.

The Consulting Business Model, Cedric Chin, 2022

• The top performers must have special client-facing skills, which in turn places a heavy burden on the firm to recruit and train the best people in your field with such client-management skills (if you’re familiar with Joe Average Programmer, you should know that this is a lot harder than it sounds). In turn, this forces the professional firm to actively compete in two markets: the ‘input’ market for talent, and the ‘output’ market for its services.
• This implies that the firm’s people strategy must stem from its project mix.
• For any given rate of growth, a highly leveraged firm (one with a high ratio of juniors to seniors) will offer a lower probability of “making it” to the top, since there are many juniors seeking to rise and relatively few senior slots opening up. A less leveraged firm, at the same rate of growth, will need to “bring along” a higher percentage of its juniors, thus providing a greater promotion incentive. (emphasis added)
• In other words: if a firm doesn’t change its project mix, then to remain successful it must get rid of staff over time.
• Must the firm grow? Yes, it must. Recall that people join professional service firms for a career, not for a job. There is a built-in expectation that juniors should become mid-level staff members, and mid-level staff members should eventually become senior partners.
• Brain’-type projects eventually turn into ‘Grey Hair’ projects. What is once cutting-edge becomes cookie-cutter — Maister calls this the ‘life-cycle’ of the client market. Therefore, ‘Brain’-oriented firms must either evolve their firm structure to attack ‘Grey Hair’ projects, or they must continually seek new frontiers to apply their expertise in order to maintain their current firm shape.

The Terrible Things I'd Do With Your Money, Tim Daubenschütz, 2022

• VCs are sheep. They don't take risks."
• As an engineer that has been kept in check by founders and managers for years - since they always want you to factor in the business side while developing tech, I admire the boldness of true risk-takers — the insanity of wanting to settle on Mars or to blood-test everyone with a tiny pinch.
• The Utopia of Creative Freedom I dream of the freedom to work on what I think is right - for how long I think is good. I dream of not owing responsibility to my employers or financiers. The utopia of creative freedom, where no budget limitations, no sense of scarcity, or fear of failure exists. I dream of a place where financiers understand my desire to take risks, a place where not only engineers have empathy towards the business but vice versa. It's there where I'd waste your hard-earned dollars on days of "unnecessary" and tangential work. It's where I'd rent servers to compute seemingly useless shit - where I'd blow tons of carbon dioxide into the atmosphere just to gather more, to you, irrelevant information. If I had all the creative freedom in the world, I'd do "terrible" things with the money you invested.

Why Is Selling Software So Weird?, zeptonaut.com, 2022

• Contrast this with software, which lives in the realm of often-near-zero marginal costs. I can’t make a living building Zoom for someone because Zoom already did that. The marginal cost to Zoom of onboarding a new customer is almost zero, whereas the fixed cost to me of recreating Zoom is astronomical.
• First is that software takes a lot of time to write up-front. By the time you’ve signed up your first customer at $10/month, there’s a good chance you’ve spent 100s or 1000s of hours writing that software. Low volume software is not a good business to be in.
• The second downside of the “high-leverage” software model is that unless you aggressively seek out feedback, you’ll probably realize that your software sucks only after you’ve built it and can’t find a customer. The digital nature of software makes it extremely easy to ignore pesky distractions like customers right up until the moment you need their money to buy that expensive Icelandic yogurt you love.
• If you’re building software - particularly new software that hasn’t already found a market -this underscores the importance of being good at what you do: if you’re just average (or more precisely, just median), you’re creating zero value.
• for each few percentile you move to the right on that curve of outcomes, the value you’re creating increases exponentially. To achieve this, you need to not only build high quality software but also understand adjacent ideas like identifying promising distribution channels, soliciting and incorporating customer feedback, and building defensible moats around your business.

The Things We Did Not Do While Reaching $2M ARR, missiveapp.com, 2022

• A list of things tech startups usually go through that we did not. Warning: This is not a list of things you should not do; it's simply a collection of things we did not. We did not do a business plan. We did not create a pitch deck. We did not spend money on Google Adwords. We did not move out of Heroku. We did not create a US bank account to save on Stripe fees. We did not grow our headcount past four. We did not raise venture capital. We did not go through an incubator. We did not code a native iOS app. We did not code a native Android app. We did not code a native Windows app. We did not code a native Mac app. We did not spend money on ads. We did not type-check our codebase. We did not switch to a new programming language after launch. We did not hire a PR firm. We were not featured in any noteworthy tech publications. We did not win any prize nor apply to win one. We did not attend networking events. We did not join the local chamber of commerce. We did not devote a % of our days to marketing. We did not pay for a competitor product to try features. We did not focus 100% of our work hours on only one business. We did not buy or use an email list to reach potential leads. We did not use a CRM. We did not track/monitor user behavior in the apps. We did not A/B test anything. We did not sell the company to a competitor. We did not split our codebase into microservices. We did not use AWS Lambda. We did not apply for the government salary subsidies. We did not translate our app or website. We did not have coaches. We did not ask questions at user signup (What is the size of your company?) We did not give discounts. We did not offer yearly plans. We did not order mugs/socks/T-shirts/hoodies with our logo. We did not pay for a LinkedIn premium plan. We did not host a page that asks for email addresses to download a PDF. We did not have mentors. We did not do an MBA. We did not present talks at our alma maters. We did not pivot. We did not setup automated email follow-ups. We did not waste money. Were we successful because or despite of all of these did-nots?

Working Backwards, Cedric Chin, 2022

• In my tenure at Amazon I heard him (Bezos) say many times that if we wanted Amazon to be a place where builders can build, we needed to eliminate communication, not encourage it. When you view effective communication across groups as a “defect,” the solutions to your problems start to look quite different from traditional ones
• , Jeff’s vision was that we needed to focus on loosely coupled interaction via machines through well-defined APIs rather than via humans through emails and meetings. This would free each team to act autonomously and move faster
• The reason writing a good 4 page memo is harder than “writing” a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what’s more important than what, and how things are related.
• Amazon innovation called “single-threaded leadership,” in which a single person, unencumbered by competing responsibilities, owns a single major initiative and heads up a separable, largely autonomous team to deliver its goals. In this chapter we’ll explain what these terms mean, how they came to be, and why they lie at the heart of the Amazon approach to innovation and high-velocity decision-making.

How to Freaking Find Great Developers by Having Them Read Code, freakingrectangle, 2022

• So instead of writing code, consider instead having the candidate read existing code and talk about what it does and how it works. This offers some powerful advantages:
• For each fresh interview cycle, I create a set of predict-the-output exercises that start really easy, then get harder. My current set starts off with a basic function call, then multi-level function calls, then recursion, then side-effects. These are generally “pretend” functions that are meant to give the candidate some quick success and give me some clues on how the rest of the interview will go. For more advanced questions, I pull code from stuff I’ve written. My current “hard” questions explore ability to make abstractions while reading and also following asynchronous operations
• At the start of the interview, I explain: I’m NOT testing knowledge of syntax. Treat me like an AI-enabled google and I will just tell you what some function or operator does. I don’t expect you to finish because nobody does. We will stop after 20 minutes. I don’t expect you to get answers correct. If the answer is wrong, I would love to see you go back and debug your thinking. This is just as valuable to me as anything else.

Be Less Technical, sequential.dev, 2022

• thoughts about situations under which thinking in terms of implementation can remove more value than it adds. I am also not an expert in product or engineering - just someone who is trying to write down my thoughts :)

Where Are Good Startup Ideas Born?, zeptonaut.com, 2022

• Coming up with a good startup idea is a three step process. You need to find a problem, find a way in which technology can help solve that problem, and then analyze your solution to see if you can build a good business around it. When it invariably turns out that your idea sucks, there’s a fourth step where you soak that idea with gasoline and light it on fire.
• Here’s my short, short version of what makes a good software business: Is there a real, pressing problem? Does your business solve the problem in a significantly better way than the alternatives? Do you have a realistic plan to grow your business? Is the total addressable market large enough? Once your business starts to succeed, is there something that will prevent competitors from just copying you?

11 Principles of Engineering Management, Alan Johnson, 2022

• Managing comes first Most managers are strong executors. They may inherit executional responsibilities, have the tendency to fall back on executing to solve problems, or want to let execution take priority. Managing comes first. Management can require large blocks of time, sometimes without warning, which means it’s crucial to stay out of the critical path of execution, wherever possible.
• Distribute problems, not solutions Managers with excellent execution skills and deep domain knowledge must resist the urge to present solutions to their reports. Reports learn by discovering solutions. Create safe learning opportunities. Create time for learning to occur. Give constraints, and justifications for the constraints.
• Work on yourself Investments in yourself are magnified in how effectively you can help your reports. Self-awareness is critical; your blind spots and rough corners can hurt other people. Always be reflecting. Always be learning.

The Niche Programmer, ano.ee, 2022

• Anyway, this is all to say that being a niche programmer is not bad at all. Pay is great, competition is low and the interview processes for the most part very humane.

The Hardest Thing About Making Decisions Is Saying No, fev.al, 2022

• The hardest thing about making a decision is that you have to say no to something, and often it is stuff you’d love to say yes to.

A Principled Way to Solve Problems, Elías Masquil, 2022

• The principled way to solve problems is the following: Ask yourself what’s the problem you’re trying to solve Be sure that you understand it deeply, and that you at least have an idea of how would you know that the problem is solved. Propose a course of action Remind yourself: what I was trying to do? Ask the question: does doing this solve my problem? Doing this should transform your problem into your imaginary solved problem (that’s why it’s important to have an idea of how does the solved problem looks like) Do I need to do this? All actions should be needed for solving the problem. Any action that is not obviously needed, should be discarded

Thoughts on OKRs, joeblu.com, 2022

• I’ve worked at four companies that used some variation of OKRs (including Google!). All of them set a hierarchical pyramid of OKRs that cascaded down, rather than a set of OKRs that worked bottom-up, even if the company wasn’t in a crisis and would have benefited from promoting innovation.

The Other Kind of Staff Software Engineer, Adam Gordon Bell, 2022

• Market pressures don’t apply to internal teams, which can be both good and bad.
• It’s going to be hard to climb the ranks of an organization where most of the teams are made up of people who do the same job as you. For example, I once managed twelve people as an engineering manager and my boss, a director, managed around that many managers himself, the pattern continuing up to the CTO. So if you envision being part of the C-suite yourself someday, then out-competing the 12^N people below the CTO or CPO is a brutal way to do it.
• At a tech company, especially a large one, you will specialize. You may become an expert in a particular subsystem or a particular layer of the stack and then good luck telling your mom what you do. In a staff role at a non-tech company, you will likely have a much larger but shallower scope. You may talk to the stakeholders, make changes to the frontend, build that backend, and keep the database up. Depending on the size of the place, you may do all of that in a single day, and spend time getting familiar with the intricacies of the business your company operates in.

How to Be Successful, blog.samaltman.com, 2022

• I believe that it’s easier to do a hard startup than an easy startup. People want to be part of something exciting and feel that their work matters. If you are making progress on an important problem, you will have a constant tailwind of people wanting to help you. Let yourself grow more ambitious, and don’t be afraid to work on what you really want to work on. If everyone else is starting meme companies, and you want to start a gene-editing company, then do that and don’t second guess it.
• The most successful people I know are primarily internally driven; they do what they do to impress themselves and because they feel compelled to make something happen in the world. After you’ve made enough money to buy whatever you want and gotten enough social status that it stops being fun to get more, this is the only force I know of that will continue to drive you to higher levels of performance.
• I will fail many times, and I will be really right once” is the entrepreneurs’ way. You have to give yourself a lot of chances to get lucky.

Thinking in Bets How to Make Decisions Like a Poker Player, Frontera, 2022

• Life is a decision-making game. Investments, what projects to work on, career changes… The better decisions you make over the long term, the more successful you get. But people make one common mistake while assessing their decisions. They judge the quality of the decisions based on the outcomes. And this is a flaw that creates a dangerous illusion for future decisions. Because life is not chess. It’s poker. Luck plays a bigger role than you think.
• Professional poker players decide to bet (or not) on a hand by calculating the expected value of the bet. Let’s say there is $300 in the pot — that’s the total money you can earn. You need $50 to call your opponent’s bet and you estimate a 25% chance of having the winning hand. So the expected value of that bet would be 25% of the $300, which is $75. Since the expected value ($75) is higher than the bet ($50), it makes sense to bet 50 bucks for that hand. Do the same for your life decisions.
• Another way to make better decisions is to examine your past choices. But remember, regardless of the outcome. What made you win big in that investment? Your good decision or luck? Was starting that business a good decision despite the failure? If you don’t find your mistakes, you run the risk of repeating them.

Donald Knuth on Work Habits, Problem Solving, and Happiness, shuvomoy.github.io, 2022

• I used to have three or four papers always in sort of a pipeline, waiting for their ideas to mature before I would finally prepare them for publication.
• bet this unhappiness is really something chemical, not actually caused by circumstances.*" I began to speculate that my body was programmed to be unhappy a certain percentage of the time, and that hormones or something were the real reason behind moments of mild depression

When Everything Is Important but Nothing Is Getting Done, sharedphysics.com, 2022

• Step 4: Getting Work Started, or “Start With Project Number 1, Work on One Thing At a Time, In Order, Until It’s Done”

Why I Turned Down $500K, Pissed Off My Investors, and Shut Down My Startup, Startup Type, 2022

• Unfortunately, top-down sales is much more expensive than content marketing and SEO. Running the numbers convinced me that we would have to raise prices to a point that would push us out of the mid-market and into competition with more established, better-funded firms. Since we lacked an overwhelming advantage in this market segment, this was a non-starter.

Write Documentation First. Then Build., Matthew Guay, 2022

• Writing is a way of finding out,” wrote Swift decades ago, but he didn’t stop there. “Rewriting,” Swift continued, “is the key to improved thinking.”
• It all starts as an idea, a tiny speck of something that could be. You can picture it; it almost feels real. Now you just have to translate your vision into reality. So pull out a pen. Start writing.

The Definition of a Tech Lead, Pat Kua, 2022

• Where the Team Lead focused on team issues, the Tech Lead focused on technical topics affecting more than one developer. The Tech Lead mediated technical debates.
• The Team Lead had 1-to-1s with people focused on feedback and career development. They actively organised activities to build psychological safety and foster trust.
• Where a Product Manager focuses on the “What“, the Tech Lead focuses on the “How.” Where the Engineering Manager/Team Lead focuses on “People and Team Growth“, the Tech Lead focuses on “Technical Growth

Overthinking, Sylvain Kerkour, 2022

• My take on the matter is that the architect of any project needs to be one of the developers, one of the doers.
• Stop trying to connect all the dots ahead of time. Embrace uncertainty and start doing. "You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life." - Steve Jobs
• I've also noticed that, up to a certain point, the smarter a person is, the more it has to be apparent in their work. Every algorithm needs to be perfect, every function needs to be side-effects free, every data structure needs to be the fastest, and every best practice needs to be followed. It's not bad per se, but when it prevents doing the real stuff, this busy work should be avoided.

No-One Knows What They Are Doing, Andy Brice, 2022

• It is easy to read 20/20 hindsight accounts of successful businesses and assume they they knew exactly what they needed to do at each stage. They didn’t. Running a business involves making a lot of decisions under great uncertainty in a constantly changing environment. So if you want to start a business, don’t be put off by not knowing what you are doing. No-one does.

TBM 27b/52 Why Most Strategies Lack Clarity, John Cutler, 2022

• The unlock, I think, is realizing that you can confidently communicate a coherent strategy that also acknowledges uncertainty. You know what you know. You assume what you assume. You believe what you believe.
• Yes, there will always be some people internally who will only accept certainty. But you can’t change those people, and catering to them is a losing game.

Life Is Not Short, dkb.show, 2022

• he most surprising thing is that you wouldn’t let anyone steal your property, but you consistently let people steal your time, which is infinitely more valuable.2 No one is willing to hand out their money randomly, but that’s exactly what you do with your time. You’re very frugal with your physical possessions, but when it comes to your time, you’re wasteful of the only thing in the world that you should actually be frugal with.3
• Let’s take the great emperor Augustus as an example. He was the most powerful man in the world. He had all the social status, all the money, and he could do anything he wanted. Even with all that, he was looking forward to the day that he could step down and retire from it all. The man with all the power in the world was happiest when he thought about the day he could let go of all the power.8 How foolish is it to spend your life chasing fame, riches, and power, while being unhappy the entire time, even after you achieve it? What is the point of it all? To impress other people? Is that really worth it in the end?
• You should organize each day as if it were your last, so that you neither need to long for nor fear the next day. You should avoid spending time on people and things that don’t really matter to you. You should be very thrifty with your time, because you know there’s nothing for which it is worth exchanging.11 What I was trying to say before was just because someone’s always busy, and lives to an old age, doesn’t mean they’ve lived long. They’ve just existed long.

The New American Micro-SaaS Dream, About me, 2022

• "I work slowly. I don’t subscribe to the ideas of “rapid iteration” and I don’t think you should “fail fast”. Instead, I try to work at a slow but steady pace. I try to make sure I get closer to my goals every day, without burning out on the way to get there."

I Hate MVPs. So Do Your Customers. Make It SLC Instead., blog.asmartbear.com, 2022

• The motivation behind the MVP is still valid: Build something small, because small things are predictable and inexpensive to test. Get it into the market quickly, because real learning occurs only when real customers are using a real product. Trash it if it’s a flop, or invest if it’s a seedling with potential.
• For example, it was okay that early versions Google Docs had only 3% of the features of Microsoft Word, because Docs did a great job at what it was primarily designed for, which is simplicity and real-time collaboration. Docs was simple, but also complete.
• A SLC product does not require ongoing development in order to add value. It’s possible that v1 should evolve for years into a v4, but you also have the option of not investing further in the product, yet it still adds value

The Mind of a Benevolent Dictator, dkb.show, 2022

• You need to make a choice about who you want to be, and the kind of life you want to live, and stick to it.
• Pain is either endurable or it isn’t. If it’s not endurable then you’ll die, and the pain will end. If it's endurable, then you should just endure it and stop complaining about it.7
• DKB: Do you have any last words of wisdom for people who are trying to live better lives? Marcus Aurelius: You just died. You’ve lived your life. Now you have a second life. Live this one properly.28

TBM 30/52 Why Don’t We Have a Strategy?, John Cutler, 2022

• Strategy requires discourse, collaboration, contemplation, and critical thinking. It takes time and space. Sadly, time to think—alone and together—is in short supply in most organizations.
• A lot of what people think of as strategic malpractice is more about lack of time, fatigue, fear of conflict, and a healthy level of skepticism and pragmatism. Strategy nerds ignore this, and immediately assume people are incompetent.
• By being thoughtful and public about communicating strategy, you help build everyone's critical strategic abilities. You'd be amazed by how quickly people can learn with a role model. Strategy can be applied at many different horizons, so it is vital that everyone builds their skills.

#Blog *From Idea to Paying Customer*, linen.dev, 2022

• Finally if they were ready to pay I would send them a Stripe checkout page for payment and I would then update a field in the database manually of whether the user was a paid user.
• took note to anything that has been recurring and have experienced in a professional capacity. I then took note of anything that I had a competitive advantage in. Something that I am a domain expert in or something where I know who the first 10 customers are.
• You’ll need a landing page if you don’t know how to reach your first few customers (but you probably shouldn’t build a product unless you know how to reach your first few customers…)

How to Transition From Engineering to a Product Manager Role, Ajit Kulkarni, 2022

• If you continue on as an engineer, you may become a director of engineering in 10–15 years. Now ask yourself, “Would I be happy with that?”

Steve Blank Finding and Growing the Islands of Innovation Inside a Large Company – Action Plan for a New CTO, steveblank.com, 2022

• find these islands of innovation and who was running them and understand if/how they Leveraged existing company competencies and assets Understand if/how they co-opted/bypassed existing processes and procedures Had a continuous customer discovery to create products that customers need and want Figured out how to deliver with speed and urgency And if they somehow had made this a repeatable process
• Anthony believed one of his roles as CTO was to: Map and evaluate all the innovation, incubation and technology scouting activities Help the company understand they need innovation and execution to occur simultaneously. (This is the concept of an ambidextrous organization (seethis HBR article).) Educate the company that innovation and execution have different processes, people, and culture. They need each other – and need to respect and depend on each other Create an innovation pipeline – from problem to deployment – and get it adopted at scale
• If these groups existed, his job as CTO was to take their learning and: Figure out what barriers the innovation groups were running into and help build innovation processes in parallel to those for execution Use their work to create a common language and tools for innovation around rapid acceleration of existing mission and delivery Make permanent delivering products and services at speed with a written innovation doctrine and policy Instrument the process with metrics and diagnostics

I Regret My $46k Website Redesign, Michael Lynch, 2022

• Hire an individual freelancer instead of an agency
• I would have preferred to have the logo first, then a new navbar design, then the landing page design, etc.

The Disproportionate Influence of Early Tech Decisions, brandur.org, 2022

• Velocity and maintainability: A balancing act So what’s my point? Simply this: software has inertia. Most of it will eventually die by virtue of rewrites, or the products, companies. or organizations using it dying themselves, but what makes it passed that initial push for survival will likely last longer than expected. The Lindy effect states:
• It’s not a bad instinct, but quality is more of a sliding scale than it is a good or bad dichotomy, and I’d argue that many small companies optimize too much in favor of speed by trading away too much in terms of maintainability by shipping the first thing that was thrown at the wall.
• And this fails the other way too, where major believers in academic-level correctness agonize over details to such a degree that projects never ship, and sometimes never even start.

The Demo → Demo Loop, daverupert.com, 2022

• A prototype is worth a thousand meetings — IDEO
• Demos improve workflows. Breaking up large tasks into “what can I demo next” is an exciting way to work. There’s always an immediate goal for me to find a demo-able checkpoint where I can get tactical feedback frequently. It can save a lot of rework and we can catch ourselves going down a bad path early.
• The point is, do whatever is a right fit for your organization but never wait too long to demo. Allow room for ad hoc “hallway” demos to happen. And move the needle closer to daily.

The Energy to Suggest Change, Home, 2022

• Voice too many concerns, or a concern too big, and you’ll grind the project to a halt. The gaze of the entire organization, the ire of management, all falls on you. A spotlight of insecurity begins to shine. Does your bank account have the social capital to cover this debit? Is this political suicide? Have you sufficiently divorced your concerns about the project from the personalities working on the project?
• After passing all internal checks and you still feel compelled to say something, you attempt to pump the brakes of an already moving machine. Ideally it’s like the sport of curling, a few gentle sweeps to correct the course of the already in-motion object. But if your blaster is not set to stun, you end up scorching every participant in the project. It has to be perfect, no margin for error. Overly couch your language, you subvert your own message. Overly assertive (or even just competent at your job), you’re seen as an asshole.

Tiny Abstractions With Functions in Go., Mat Ryer, 2022

• Abstractions are one of the most useful tools in a programmers belt, but early abstraction (carving them out before you should, when you dont have enough information) remains one of our biggest sins.

Interview With Leonardo Da Vinci, dkb.show, 2022

• Some days I would go early in the morning, climb the scaffolding, and paint all day without moving to eat or drink. Other days I would go there and stare at the painting for hours, looking for flaws and opportunities for improvements. Then I would leave without painting anything. Sometimes I would suddenly have a new insight, go to the painting, climb the scaffolding, apply a single brush stroke, then leave.
• The Duke of Milan heard about this stuff and was worried I wouldn’t finish the painting on time. I had a discussion with him about how creativity worked. I told him that creative people sometimes accomplish the most when they work the least. Our minds are filled with ideas, and we need time for those ideas to marinate, until we eventually get an insight
• Leonardo: Just like a day well spent brings happy sleep, a life well used brings happy death.16 Use your life well. Follow your curiosities, dive down rabbit holes, and make something you’re proud of.

Why Long-Term Plans Don't Work and How to Fix Them, lucasfcosta.com, 2022

• the long-term plan approach is comparable to placing a bet on a horse race. When you go to the hippodrome, you must choose a horse before the race even starts, and you must stick to it all the way until the end. Besides cheering and praying, you can do nothing to help the chosen horse win the race. Just like winning the pot in a horse race, when the long-term plan succeeds, it’s not because of its competent executors; it’s because of a sheer stroke of luck.
• Furthermore, in the world of car manufacturing, value is created by producing more cars in less time for lower prices. In that world, car companies estimate and optimise manufacturing, not design. In the world of software development, manufacturing is not a challenge. In fact, replicating and distributing software is virtually free. The problem with software development is that we try to forecast how long it will take for us to design features, not to replicate them. Because every new feature is — obviously — new, there’s just no way of knowing how long feature development will take unless we actually do it. Moreover, while manufacturing poses operational risks, design poses product risks. When manufacturing is poorly managed, you have fewer products to sell or narrower profit margins, but you still have a product people are willing to buy because you’re past the design stage. On the other hand, when a product is poorly designed, it doesn’t matter how efficient its manufacturing and distribution are because no one is willing to buy it.
• Before I enumerate alternatives to a long-term plan, first, let me tell you shouldn’t do: Plan more carefully Add a larger margin of error The problem with planning more carefully is that no matter how carefully you plan, you will still get estimates wrong because of the reasons listed above. If anything, planning more carefully will yield greater cost and frustration. Greater cost because you’ll spend time planning and preparing for a wide variety of events, and greater frustration because you’ll get those events wrong anyway
• Instead of making your plan better, make it shorter. Making plans shorter was the part of the Agile manifest everyone missed. Remember “responding to change over following a plan”? The whole point of Agile was to run into walls as quickly as you could, just so that you could map out where the walls were and stop hitting your head against them.
• Notice I’m not telling you to break your long-term plan into smaller increments. A long-term plan broken down into sprints is still a long-term plan! Instead, I’m telling you to either scrape your long-term plan altogether or avoid adding detail to longer-term goals. Moreover, I’m telling you to be open to changing those long-term goals as new pieces of information arise, either good or bad. As your planning horizons diminish, your risks do too.

The Einstein Principle Accomplish More by Doing Less, calnewport.com, 2022

• We are most productive when we focus on a very small number of projects on which we can devote a large amount of attention.
• Achievements worth achieving require hard work. There is no shortcut here. Be it starting up a new college club or starting a new business, eventually, effort, sustained over a long amount of time, is required.
• a perfect world, we would all be Einsteins. We would each have only one, or at most two, projects in the three major spheres of our lives: professional, extracurricular, and personal. And we would be allowed to focus on this specialized set, in exclusion, as we push the projects to impressive conclusions.
• In Search of Your Own Theory of Relativity
• Our problem is that we don’t know in advance which project might turn out to be our theory of relativity and which are duds. Because of this, most ambitious people I know, myself included, follow a different strategy. We sow lots of project seeds. We e-mail a lot of people, join a lot of clubs, commit to a lot of minor projects, set up lots of meetings, constantly send out feelers to friends and connections regarding our latest brainstorm. We don’t know which seed will ultimately take root and grow, so, by planting many, we expose ourselves to enough randomness, over time, to maximize our chance of a big deal, interesting, life-changing success eventually happening. These numerous seeds, however, have a tendency to transform into weeds. While some of them clearly grow into pursuits worth continuing, and others die off quickly, many, instead, exist in a shadowy in-between state where they demand our time but offer little promise of reward in the end.
• Imagine if Einstein maintained a blog, wrote a book, joined a bunch of clubs at ETH, and tried to master rowing at the same time he was working on General Relativity? We’d still be living in the age of Newton.
• When it feels like your schedule is becoming too overwhelmed, take out a sheet of paper and label it with three columns: professional, extracurricular, and personal. Under “professional” list all the major projects you are currently working on in your professional life (if you’re a student, then this means classes and research, if you have a job, then this means your job, etc). Under “extracurricular” do the same for your side projects (your band, your blog, your plan to write a book). And under “personal” do the same for personal self-improvement projects (from fitness to reading more books). Under each list try to select one or two projects which, at this point in your life, are the most important and seem like they would yield the greatest returns. Put a star by these projects. Next, identify the projects that you could stop working on right away with no serious consequences. Cross these out. Finally, for the projects that are left unmarked, come up with a 1-3 week plan for finalizing and dispatching them. Many of these will be projects for which you owe someone something before you can stop working on them. Come up with a crunch plan for the near future for shutting these down as quickly as possible. Once you completed your crunch plan you’ll be left with only a small number of important projects. In essence, you have purged your schedule of all but a few contenders to be your next Theory of Relativity. Here’s the important part: Try to go at least one month without starting any new projects. Resist, at all costs, committing to anything during this month. Instead, just focus, with an Einsteinian intensity, on your select list.

Software Visualization — Challenge, Accepted, Renato Kalman, 2022

• Our software is modeled using three core entities: APIs: The boundaries between different components, defining the interface between those components Components: Individual pieces of software (e.g., a backend service, website, data pipeline, library) Resources: Infrastructure needed to operate a component at runtime (e.g., databases, virtual machines, storage buckets)
• The C4 model is a lightweight and straightforward approach to visualizing software architecture.

How We Built a $1M ARR Open Source SaaS, Marko Saric, 2022

• April: Picking a fight and going viral ($607 MRR) On April 8th, I published my first Plausible blog post. Our new positioning was based on how different we are compared to Google Analytics, so we decided to pick a fight. The post went to the top of Hacker News, and it helped us spread the word about Plausible to more people than ever before. I submitted the post myself, didn’t try any tricks to game the system, and we got lucky that so many people found it interesting. More than 25,000 people visited our site on the day we published the post. We broke all our records in April: most traffic, trials and the biggest MRR increase. The post that changed our traction was: Why you should stop using Google Analytics on your website.
• May: First mention on a prominent site ($1,055 MRR) May started great as we were featured on OpenSource.com
• We launched on Product Hunt. This is typically a big event for startups. Product Hunt was worthwhile, but it’s not our core growth strategy, so it was just another day for us, albeit a bit busier. We didn’t put all of our eggs in this one basket
• April: Put your personal spin on the news ($22,290 MRR) Google announced their FLoC initiative which is a topic we have a lot of thoughts about. So we published a blog post on “how to fight back against Google FLoC” to increase awareness. More than 16,000 people read the post during the month, and we got a lot of attention. This is an example of a different way to approach content marketing. It doesn’t always have to be based on keyword research and what people search for. If there are some news and happenings that you and your potential audience care about, create a post about it. Don’t just repeat the information everyone else is reporting but put your personal spin and point of view into it. Add something unique, informative and/or entertaining. There’s a lot of interest in this type of content.
• We focus on a small number of things, but we try to do them as best as we can: Build a great product that people enjoy using and want to recommend. This is the key, as nothing else would work without a great product. We publish content on our blog and social media, communicating what we believe in and stand for. We take a stand and hope it resonates with as many people as possible
• We don’t use paid advertising We don’t use spy pixels and retargeting We don’t use session recordings We don’t do popups and other intrusive calls to action We don’t pay anyone to promote or recommend us We don’t use a chat bot to engage you or convert you We don’t participate in any link buying for SEO purposes

15 Best Startup Marketing Practices We Say "No" to, Marko Saric, 2022

• Don’t confuse marketing with advertising, spamming and shouting Marketing is not the same as advertising. Many startups confuse marketing with spending money on advertising, spamming, interrupting, shouting, being annoying, trying to steal people’s attention, taking shortcuts and other hacks and tricks. Marketing is communication. You get to know people, look at the world from their point of view, listen to what they need, focus on them, create something that solves their issues, be valuable to them, help them notice you, remember you and keep in touch
• Demographic and geographic data are a big part of marketing. For us, we don’t need to know anything about you so we don’t try to collect anything about you either. We don’t know what you look like, where you’re from or what else you like

How to Advertise to Developers Deep Dive Into Paid Developer Marketing, developermarkepear.com, 2022

• Once people click on your ad they go somewhere, right? Many marketers choose this somewhere to be the homepage. I think this is almost always not the best place to direct people.   Actually, I think many campaigns show no return on investment because of this.
• Ethical ads It is an ad network, similar to Google Ads, that does display ads on developer-focused pages. They call it a "Transparent Advertising For Developers That Works”
• Components of paid developer marketing There are four parts of every paid ad campaign: Goal: what do you want those people to do Targeting: where and who you want to show your ads to Creative: what you want to show them Landing page: where they go after clicking your ad

Why Success Stories Are Just Propaganda, martin weigel, 2022

• Whatever the reason, for the most part these stories (Steve Jobs’ included) have nothing to teach us. Painting false realities, creating the illusion that success is far easier than it actually is, and laying claim to universal wisdom, they enslave us in the fictions, fantasies and ideologies of others. Comforting though it might be, they stop us thinking for ourselves.
• So if you’re on the receiving end of a Self Made success story exercise extreme caution.
• But above all accept the truth that you are alone. There are no heroes or gods who can tell us what to do. There is nobody who’s figured it all, who can save us the hard work and the risk. Nobody has the keys to wisdom and certainty.
• Only by recognising that we are alone can we liberate ourselves from being enslaved by the subjective experiences, fictions, fantasies, dogmas, pseudo-science, false reporting and ideologies of others. All success stories are propaganda. We can and must make our own way.

How I Write React After 8 Years, Nessim Btesh, 2022

• Decoupling logic from componentsI try to decouple the logic from the component as much as possible, it makes components more reusable. Where do the API calls and states go? Usually into a hook that is also reusable in different components throughout the app.
• Any function that is passed down uses React.useCallbackThe title explains it if you don’t do this then React.memo won’t work and the experience won’t be as great.
• Security — Authorization into routesSecurity should be managed at the route component, not the children.
• Redux is scrap: We don’t use redux (even do we have twice). I’ve developed two massive applications with millions in transactions and both of the times redux becomes a nightmare. The only reason people use redux is that they want a sharable state across the app. I can think of 10 ways to do that very easily without all of Redux boilerplate.
• Web Vitals (Largest contentful paint, first input delay, etc…) is a way for Google to sell more products: Think about this, if you are google and your primary product is a search engine you want to make that search engine as amazing as possible. That’s why they created web vitals, it is a w
• Centralizing API calls in one place
• Forms don’t have to suckUse a library here or create a hook, I usually create a hook that wraps an Input and adds the rules (see the ModalContent above).
• Don’t use (almost) any libraries:
• CSS: Use styled components
• ComponentsA typical component is compromised of a folder followed by an index file and a style.js file.

Becoming a Full-Time Creator as a Software Engineer Controversial Advice, Gergely Orosz, 2022

• Most creators are B2C (business to consumer), bootstrapped businesses. They typically make their revenue through selling: Own digital products and subscriptions. For example, this is how former Stripe engineer Julia Evans makes a living creating Wizard Zines which are visual programming explainers. In 2019 she already made more than $30,000 in a month. Small software products that can be built by one person. These include apps, games, SaaS software and many others. For example, software engineer Riley Tomasek started to build Standard Resume as a resume generator when he applied for tech companies. This was the tool that got him his job at Dropbox. A few years later, this side project grew to $5,000/month in revenue and Riley later quit his fulltime job, and is currently working on this product. Sponsorships and advertising. This is a typical model of how many creators with a large audience monetize the fact that many people pay attention to them. Affiliates - where they get a cut of all sales.
• Understand the models of making money
• Social media not used as a channel to make a living off
• A much better model for the "sustainable creator" is creating on the side of the one-person business.
• Books are an interesting area, as they don’t sound terribly profitable, and they are the most work to produce. However, because they take so much work to do, there’s less competition among excellent tech books for a given topic, than there is for videos, articles, or even courses
• People who create content that has a wide reach often start with ads, sponsorships, and affiliates as their income streams. Those starting off with a more specific niche tend to start off with subscriptions, sponsorships, courses, or books as streams
• Highly profitable one-person businesses work with several people so the person in the middle - you! - can leverage their time the best possible way. This means investing in people and tools to spend your time more efficient.
• Build up unfair advantages. As a one-person business, you'll have to somehow stand out among the crowd of businesses offering similar things - advice, education, entertainment and so on. While you are working full-time, can you start to build out things that will become your unfair advantage?
• Buy tools that make you more productive. In my case this means paying for Grammarly, Canva, my note-taking tool (Craft) or Centered app
• Consider small bets on the side. Former Amazon engineer Daniel Vasallo is the pioneer of the small bets strategy for which he offers a course. Several engineers I know took this course and started to do their own small bets approach.
• Build side projects to learn more about yourself. I have always done this, building dozens of side projects over the years.

Publishing Your Work Increases Your Luck, github.com, 2022

• Luck = [Doing Things] * [Telling People]

6 Ways to Stay Focused While Working on Your Startup and Having a 9 to 5, Fernando Pessagno, 2022

• However, if you take the time to plan ahead on Sundays, you can set yourself up for a more productive week. Sit down and think about what you want to accomplish during the week.
• When you have a plan, you can execute without getting stuck trying to decide what to do next, which can be taxing on your brain.

Thinking With Pen and Paper, Lj Miranda, 2022

• I like to think of thoughts as streaming information, so I don’t need to tag and categorize them as we do with batched data. Instead, using time as an index and sticky notes to mark slices of info solves most of my use cases.
• Writing with ink captures more than words. It captures my mood and my mistakes. I remember in my college chemistry classes, we were instructed never to tear off or hide any error we made in our lab notebooks. Instead, we should mark it with a strikethrough. I brought this practice up to this day, and it’s nice to see the small corrections, marginalia, and scribbles representing the unrefined parts of my thought process.

⭐️ Why the Indie Maker Playbook Is Dead, Jakob Greenfeld, 2022

• Why spend months building an audience in a specific niche, when I can also pay some money to get a shoutout from someone who managed to do just that?
• I’m quite frugal in my personal life. So being frugal when it comes to my business ventures came naturally to me. But I’ve started to seriously question if this is really that smart of an approach.
• Why spend days crafting Reddit posts hoping that one of them will go viral if I can also pay a few cents per targeted click using Reddit ads?
• Yes, there are of course people who don’t have enough money to pay for traffic. But many indie makers have well-paying jobs or savings and could easily afford to spend a little bit of money to validate and grow ideas faster. The only reason why they’re not doing it is the general negative sentiment towards ads in the indie maker community. That was 100% what was holding me back.
• When you’re testing ideas in private and running multiple experiments in parallel it’s so much easier to kill projects that are just not working the way they should.

⭐️ Build a Business, Not an Audience, Jakob Greenfeld, 2022

• While charging money for something you created is scary, there is almost zero risk in putting out free content. And if you’re just remixing other people’s content, the intellectual risk is effectively zero. After all, you can always reply “hey, don’t shoot the messenger”.

A Process for Finding Your Niche, Rob Hardy, 2022

• In my course, I have students go through several different layers of self-audit. But here are some of my favorite prompts to get you started: The labels that most define me are… I feel like I belong when I’m with… It breaks my heart when I see… I’m endlessly curious about… The problems I’m most proud of overcoming are…
• Every time you stumble across a related website, community, social profile, podcast, YouTube channel, or anyone/anything influential, add it to your Market Map. More specifically, you’ll want to… Add URLs to their main site and social channels. Categorize them. What type of media do they create (videos, books, podcasts, emails, etc), and optionally, what topics do they cover? Estimate their size/reach by looking at their subscriber/follower counts, and estimating their website traffic using a tool like SimilarWeb or Vstat. When you add enough of these sources into your database, you should be able to make a rough estimate of how big the niche is. Add any additional notes you think might be useful to you in the future. I like to keep track of whether I can post directly (for content sharing) and whether I’m able to be a guest (usually podcasts and YouTube interview shows). Also, if you can find contact info for the person/source, it’s a good idea to add it.
• And for the next 2-3 weeks, I want you to live in this niche. I want you to eat, sleep, and breath it. The content, community, and commerce. Be obsessed.
• No niche is going to be 100% delightful, 100% of the time. In fact, you should expect to stumble across ideas and people who rub you the wrong way. That’s just the nature of the internet, and you should not take it as a sign to abandon the niche.
• But here’s the thing. Nearly every creator I’ve worked with has felt trepidation before committing to a niche. There’s always—and I mean always—a nagging voice in the back of your head saying, “what if this isn’t the niche for me?” “What if I get bored?” “What if I want to create things that don’t fit in this place?” It’s entirely possible to get this far into the process, then paralyze yourself. That voice in your head might convince you of the need for more research, or to jump ship and find another niche idea. Here’s a little secret. If you’ve done the work above, the niche you’ve landed on is as good as it gets. If you feel at least 80% certain, there’s not a whole lot you can do to fill in that other 20%, other than committing and diving in.
• Here’s a quick roadmap of the process we’ll be working through together. Brainstorm niche ideas that are tied to your identity and passions. Validate those ideas to see if they align with pre-existing markets. Build out a database (Market Map) of the major players in the niche. Immerse yourself in the space to ensure creative and personal fit. Make the commitment to show up and serve your people generously.
• There are three questions you need to answer in this stage. Does this niche actually exist? (Is there already a market around this idea?) If so, is that market big enough to support my business/financial goals? Is it active and engaged? (ie. are people already consuming and conversing?)

No Distribution, No Dice, Charlie Andrews, 2022

• One of the biggest changes in how I evaluate startup ideas in the last ten years is that I now place at least as much emphasis on a good distribution strategy as I do a good product.
• An interesting and frustrating trait shared by good distribution strategies is that they’re highly tailored to the products themselves. For example, let’s look at distribution strategies for three very viral consumer companies:
• Similarly, I think that your distribution strategy should be developed and tested alongside your product, not after it
• How are you going to get your first 5-10 customers? How are you going to grow from 5-10 customers to 50-60 customers? Are there any other successful companies that share your target customer? How did they grow? How are new customers finding out about your product? Once you’ve saturated a single market (geography, vertical, etc.), how do you gain a foothold in a new market? How can you gather more information about your distribution strategy before you need to use it?

8 Ways to Crank Up Speed in Software Development, Focused Work, 2022

• There are two very different types of speed: Short-term speed (Sprint) and Long-term speed (Marathon). Sprint vs. Marathon is a perfect analogy here. In software development (and in running as well) you can’t have both
• Let me explain what I mean about Fast Pace Mode. In this mode, the team (or a whole company) drops all secondary activities: all meetings about future, learning events, HR activities, etc. The team focuses on delivering value: writing code, testing, creating documentation and shipping. Fast Pace Mode ends with relaxation week. This week dedicated to refactoring, discussions and thoughts about the future.
• Domain knowledge is crucial for any software developer. It helps to understand problems deeper, create better solutions faster and reduce re-work.
• Technical Debt is a deliberate decision to implement not-the-best solution or write not-the-best code in order to release software faster.
• But Scrum, for example, demands commitment, thus applying psychological pressure. People start to cut corners. On a small scale for sure, but still. It is not always bad, as we already know, but it is good to be aware of this counterproductive side effect.
• How do you know what feature to work on next? Product Owner’s intuition likely is not the best way to choose that. Simple linear models outperform experts, so use them. Create a simple model, rank features with the model, verify it on several features, correct it and then trust it. We spent several months on Feature Ranking model in Targetprocess. We reviewed various sources, discussed priorities, accumulated feedback from customers and finally created a good model everybody believes in.
• The problem is that a product itself should be modular enough to support independent teams. There should be minimum relations between modules, otherwise integration will be an issue. Targetprocess is not there yet.

Vertical SaaS The Future of SaaS Is in Niche Industries, singlegrain.com, 2022

• Before you start building your SaaS product, it is essential to understand the differences between horizontal and vertical SaaS in order to determine what is right for your business so you can create your product accordingly.

The Minimum Viable Audience, seths.blog, 2022

• Two things happen when you delight your minimum viable audience: you discover it’s a lot larger group than you expected they tell the others

What Should You Work On?, perell.com, 2022

• Broadly, there are five buckets that talented people should start companies around: energy, education, housing, healthcare, and transportation.

The Stair Step Approach to Bootstrapping, robwalling.com, 2022

• The strategy that seems to give people the best chance of success is creating a simple product, with a simple marketing plan – one that only requires a single traffic channel.
• Specifically, I’m suggesting that you don’t get started by building a stand-alone subscription software (SaaS) product. Recurring revenue is the holy grail for bootstrappers, as we’ll discuss later in this essay, but it also makes your business more complex if you try to launch a stand-alone product that you have to not only build, but market on your own.
• In my case, that meant getting good at SEO with my first project, instead of trying to learn SEO, Adwords, Facebook ads, etc. all at once.
• One of the biggest mistakes I see founders make is abandoning what already works and trying to take on a bigger challenge before they’re making enough money to own all of their time in a given week.
• That kind of growth is the promise that drives a lot of new founders to dive headfirst into SaaS projects. But frankly, I hope this post has made your reconsider that it’s probably the wrong place to start due to the technical and marketing complexities (not to mention the competition) that go along with SaaS.

Less Is More Agile, beny23.github.io, 2022

• Estimating is very hard. I’ve been in many Sprint Planning meetings, played planning poker, and had hours worth of discussion whether a story has a Large or actually Small. And at the end of it, the estimate has to be thrown out anyway because the devs who picked up the story didn’t have the same experience as the devs estimating. The solution is simple: don’t estimate! Don’t spend the time trying to work out how long something will take! If you really have to, I quite like no bullshit estimation - basically there’s only three types of story: 1 TFB (Too Fucking Big) NFC (No Fucking Clue)
• Worrying about deadlines is dysfunctional. Allen made this point about agile: If you’re not happy, you’re not doing it right
• Agile has come to mean doing half of scrum poorly and using Jira

1001 SaaS Product Ideas, bannerbear.com, 2022

• How might we make this "zero config"? How might we make this more no-code friendly? How might we make this more relevant to the ecommerce industry?
• How might we make this privacy-friendly? How might we make this into a premium product vs. an infrastructure product? How might we make the pricing easier to understand?
• How might we make this better for Japanese users? (insert your language here) How might we make this specfically tailored for special diets / religions?
• API products involve interesting technical challenges - as a technical founder you probably suffer from Shiny Object Syndrome where you keep getting bored of a product you've built and want to build a new one.
• API Service: Online file storage (aka Amazon S3) Example challenge questions: How might we make this more privacy-friendly? How might we make this more no-code friendly? How might we make this better for Japanese users? (insert your language here) How might we make this faster? How might we make this better specifically for video creators? How might we make the pricing easier to understand? How might we make this into a premium product vs. an infrastructure product? Once you have about 5-10 of these you are ready to move on to the next step.
• As I mentioned, the point here is not to clone one of these products, but to look at the problem being solved and then think creatively how it could be adapted to different use-cases, audience segments or price points - using your challenge questions.
• You can also google for lists of "popular APIs" or "best APIs for…" to find lists like this: 50 Awesome APIs list of 2019 A Curated Collection of Over 150 API’s to Build Great Products Top 50 Most Popular APIs on RapidAPI
• How might we make this faster? How might we make this more relevant to remote work? How might we 10x improve the developer experience?

3 Levels of “Finding Your Niche”, Rob Hardy, 2022

• More specifically, “find your niche” can refer to… Identifying a concrete market that can support your creative/media business. Making sure that market is a great fit for you creatively and personally. Doing research to understand the depth and breadth of that market.
• Building a profitable business isn’t the top priority for most of us. Creating unique, worthwhile stuff is. In the hierarchy of creator needs, following our curiosity and making cool shit lives higher than being an entrepreneur. When our creative work isn’t fun or fulfilling, the rest of the equation falls apart.
• Building a profitable business isn’t the top priority for most of us. Creating unique, worthwhile stuff is. In the hierarchy of creator needs, following our curiosity and making cool shit lives higher than being an entrepreneur. When our creative work isn’t fun or fulfilling, the rest of the equation falls apart.
• The trick is to find a niche in where you feel a sense of Creator-Market Fit. This delightful state is defined by three characteristics… You’re a member of (and active contributor to) a subculture you love. The interpersonal relationships you form enrich your life. When you create for that subculture, it’s intrinsically rewarding. The ideas and topics at the center of your work are an endless source of curiosity and exploration. As a result of 1 & 2 working in tandem, you satisfy a segment of the market in a way that only you can. You’re doing work you love for people who care.

Be Good-Argument-Driven, Not Data-Driven, Richard Marmorstein, 2022

• There’s nothing wrong with a fondness for data. The trouble begins when you begin to favor bad arguments that involve data over good arguments that don’t, or insist that metrics be introduced in realms where data can’t realistically be the foundation of a good argument.
• When are data-based arguments appropriate? Sometimes data-based arguments are perfectly acceptable. Let’s have a diagram! Let’s have some prose, too: Are all factors that drive your metric well-understood?
• Can you run an experiment?
• Are you prepared to do some very very fancy statistics?
• Metrics are important, says the organization, so you encourage your engineers to focus disproportionately on improvements that are easy to measure through metrics - i.e. you focus too much on engagement, growth hacks, small, superficial changes that can be A/B tested, vs. sophisticated, more nuanced improvements whose impact is more meaningful but harder or impossible to measure.
• Data has its place. Metrics are a useful tool for making a certain class of persuasive arguments in certain domains. But they are only a tool for making good arguments. Data is not an end in itself.
• Be skeptical! Have no tolerance for poor arguments made with data. Keep intrinsic motivation alive.

Becoming a Systems Architect, wojtekmandrysz.com, 2022

• no matter how many smart people you hire, and how many nice frameworks are used - if the organization and processes are not in order, you will keep losing time and money.
• We make software to solve a problem, we make it for the users. This is how I see it - and if there’s a dirty hack or unformatted code, or paradigm break - it doesn’t matter. What matters to me is solving that problem in a timely manner, in a friendly atmosphere, and reiterating on it.
• I’ve listened to a lecture from a Systems Engineer from NASA - I got that I would work between the teams and make sure everything integrates nicely - OK, I like that.
• actively participated in scoping the MVP, and how to onboard early adopters

🧠 Don't Offer Free Stuff if You Have Nothing to Sell, Jakob Greenfeld, 2022

• The loss-leader pricing strategy is certainly no secret. But it only works if you’ve actually something to sell.

Walters' Lever of Improvement, Daniel Walters, 2022

• Items higher up the lever have more leverage. I say this with the caveat that it’s assuming “on average” - of course, every organisation’s context is different. But for it not to be true at a given organisation, leaders would need to be doing these higher leverage items well already. And lets be honest, that’s a very short list of organisations.

Put It on the Crazy Pile Ideas and Creativity, bastian.rieck.me, 2022

• I instead set aside a 15 minutes every month or so to go through the file, with the intent of deleting ideas that appear to ludicrous.
• there. In case you are wondering: those crazy ideas come mostly in the form of associations between seemingly-unrelated concepts.

Twipped/InterviewThis, Twipped, 2022

• This is not a checklist, this is not a shopping list. If you send this entire list to an employer, they probably won't be calling you back

New Study Confirms the Value of Solitude, calnewport.com, 2022

• We fear solitude, but it’s exactly this time alone with our own thoughts that we need to make sense of our experiences and grow as humans. TikTok is fun, but grappling with the core questions of our existence is fundamental.

Thoughts on Copilot, daverupert.com, 2022

• My biggest adjustment with using Copilot was that instead of writing code, my posture shifted to reviewing code. Rather than a free form solo-coding session I was now in a pair-programming session with myself (ironically) in the copilot seat reviewing. I kept having a verbal conversation with myself… “Okay…” “Do I like that?” “Is that right?” ”It’s probably good enough.” ”That will have to be fixed.”
• The robot’s suggestion reinforces my intuition and makes me feel that I’m on a right path because this robot (who was trained on billions of lines of code from hundreds of thousands of developers) arrived at near the same answer as me. That is a reassuring feeling.

⭐️ the Epsilon Method, Jakob Greenfeld, 2022

• Compare this to the situation if we focus on “one plus epsilon ideas”. Here, we simply copy an existing and functioning machine and then focus on modifying one or maybe two of the moving parts. Use a well-proven offer and explore a new customer acquisition channel, or use a well-proven channel and put your creativity into your offer.
• Running experiments on multiple fronts is a recipe for a failure.

Second-Order Thinking What Smart People Use to Outperform, Tweet, 2022

• Second order thinkers ask themselves the question “And then what?” This means thinking about the consequences of repeatedly eating a chocolate bar when you are hungry and using that to inform your decision. If you do this you’re more likely to eat something healthy.
• First-level thinking looks similar. Everyone reaches the same conclusions. This is where things get interesting. The road to out-thinking people can’t come from first-order thinking. It must come from second-order thinking. Extraordinary performance comes from seeing things that other people can’t see.

⭐️ No More Insight Porn, Jakob Greenfeld, 2022

• When I’m consuming non-fiction content, I try to write down specific experiments I can try that put the things I “learned” into practice.
• But the pattern is always the same. It’s advice that sounds plausible and breaks down a goal many people dream about into actionable steps. This is extremely inspiring content. It’s insight porn par excellence.

Resources & Tools for Managers, Katie Womersley, 2022

• 20 Great Open Questions

20. Framing, world.hey.com, 2022

• The principle of treating projects as bets and capping our downside is sound.
• To spend time on shaping, there has to be impetus from the business up front that says "this problem matters." Especially in growth-stage companies, carving out time on the calendar isn't easy.
• There has to be justification and support for the shaper and a lead dev to say 'no' to other things and spend a few hours this week in shaping sessions. To solve this, I've coached teams to introduce a new step before Shaping that we call Framing. Framing is all about the problem and the business value.
• It's the work we do to challenge a problem, to narrow it down, and to find out if the business has interest and urgency to solve it. The framing session is where a feature request or complaint gets evaluated to judge what it really means, who's really affected, and whether now is the time to try and shape a solution.
• framed problem: something where the business says "if we can shape this into something doable and execute within X weeks, that will be meaningful to us."
• There's a commitment to spend time shaping, but not yet a commitment to go into a build cycle.

22. Design Systems, Modularity and Interdependence, world.hey.com, 2022

• This raises really fun and juicy questions from the strategy perspective, because we've reframed the debate from "design system good or bad" to *where* and *when* in our system does the design system give good-enough performance, and where do we have special needs that call for reinvention.

Software Component Names Should Be Whimsical and Cryptic, Aaron Zinger, 2022

• I’m probably being overdramatic there, but I hope my point is clear. “Descriptive” names don’t create transparency, they create the illusion of transparency. If you see that something has the name OrderStatusService, you will instinctively assume you know what it is and does, and you will probably be wrong.
• Names should be easy to remember and easy to spell.Names should not relate too much to the domain you’re working with. It might feel cute to name part of your zoo administration software “Tiger”, but eventually somebody’s going to be searching for “tiger” in your log files and seeing lots of irrelevant stuff about actual tigers.Names should usually not incorporate your company’s name. If everything at BongCo starts with Bong, it just makes the names longer without adding information.Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is.Names should not describe what you currently think the thing you’re naming is for. Imagine naming your newborn child Doctor, or SupportsMeInMyOldAge. Poor kid.

Don't Compare Yourself to Other Entrepreneurs, kg-card-begin html, 2022

• In fact, a great post on the IndieHackers forum titled "Holy heck this hard" points out at the time that only 193 businesses listing their revenue on the website were making more than $2,000 per month. At the time Indie Hackers had about 17,000 users, so 193 means less than 2% of users were making more than $2k a month:
• It's a lot more gratifying to compare your present self to your past self if you are going to compare anything.

How to Disagree With Someone More Powerful Than You, Amy Gallo, 2022

• Identify a shared goal Before you share your thoughts, think about what the powerful person cares about — it may be “the credibility of their team or getting a project done on time,” says Grenny. You’re more likely to be heard if you can connect your disagreement to a “higher purpose.”
• When you do speak up, don’t assume the link will be clear. You’ll want to state it overtly, contextualizing your statements so that you’re seen not as a disagreeable underling but as a colleague who’s trying to advance a shared goal.
• Stay humble Emphasize that you’re offering your opinion, not “gospel truth,” says Grenny. “It may be a well-informed, well-researched opinion, but it’s still an opinion, [so] talk tentatively and slightly understate your confidence.”

Engineering Org Structures, Joseph Gefroh, 2022

• The first and foremost benefit is that interruptive tasks can be handled by a single, dedicated execution stream. While that team may context switch frequently, the organization as a whole ends up switching away from important things less
• This helps prevent context shifts away from the primary focus of the organization, which should be on non-urgent, important work. It’s ultimately a system-level optimization at a local-level cost.
• Maintenance is the most costly aspect of a system’s lifecycle. It gets costly because it often gets delayed, which increases the risk and work required to maintain the system. The QRF helps ensure that important maintenance doesn’t go undone — eg. things like bugs, operational tooling, and other items.
• The biggest part of QRF’s mission is to “shift left” on interruptions. They should strive not just to react to solve the instance of a problem but to avoid the entire class of problems from ever reaching engineering in the first place.
• No — Scrum’s prioritization tempo can be too long. The QRF may reprioritize daily, even in some cases several times a day, depending on the fires. That’s what makes it powerful — it’s a commitment to allow for that. Scrum does the opposite — it creates a near-immutable contract that specifies that reprioritization should (ideally) only occur at the end of a sprint.

How to Read a Book, dkb.io, 2022

• To gain true knowledge and understanding from the book, you have to go to work on it. You and the author need to have a conversation, and it’s up to you to figure out what’s true in the end.

What Is Tech Debt and How Can You Explain It to Non-Technical Peers?, Leslie Chapman, 2022

• all comes down to communication and compromise. If the roofer simply said, ‘That’ll be $10,000, instead of $2000’, we’d never just hand over the money with no questions asked. Equally, as software engineers, we need to be prepared to explain, in terms that our colleagues can understand, why our original estimate needs to be increased, and what the drawbacks and costs are of postponing the extra work. We also need to stop defining core deliverables
• We also need to stop defining core deliverables as optional add-ons, for example delaying a needed refactor, or omitting documentation, unit tests, metrics, and feature flagging. Too often, when I define these core deliverables as part of what I need to build into a feature, I’m asked if we can add them later.

Work Is Work, codahale.com, 2022

• Keep the work parallel, the groups small, and the resources local When presented with a set of problems which grow superlinearly intractable as \(N\) increases, our best bet is to keep \(N\) small. If the organization’s intent is to increase value delivery by hiring more people, work efforts must be as independent as possible.
• If your work product–e.g. codebase, documents, etc.–can be factored into independent modules, do so. The key word there is independent. Slicing your shit up into a hundred microservices will not help you if everyone needs to change ten of them to get anything done
• To avoid that, organization leaders should keep the development of a product portfolio as an explicit goal. Feature or product ideas which are complimentary to the organization’s overall business strategy but don’t naturally coexist with the main product can be developed as separate products by independent teams. We have evidence that software development schedules can be shorted by, at most, 25%;

Life Is Worth Living, dkb.show, 2022

• The human heart has a natural desire for meaning and purpose. But the universe is devoid of meaning. It doesn’t have anything to offer us.

Customers Extrapolate From Quality, zeptonaut.com, 2022

• During later conversations with those prospective customers, we’d discover that they were making the entire purchase decision based on the sliver of the product they saw. They just assumed that the rest existed and was built to the same quality bar.
• Early customers are surprisingly accepting of the limitations of an early product that’s great at one particular thing. See: “Instagram only lets you post square pictures.”
• We use a tool called FullStory that allows us to see how users interact with our site. Every time we sent the demo to a customer, they looked at the “main page” for about 20 seconds. Then they closed the demo. They’d shoot back an email along the lines of, “This looks great! Let’s meet next Tuesday to talk more.”

Get in Zoomer, We're Saving React, Steven Wittens, 2022

• What does any of this have to do with React? Well it's very simple. Mac OS X was the first OS that could actually seriously claim to be reactive. The standard which virtually everyone emulated back then was Windows. And in Windows, the norm—which mostly remains to this day—is that when you query information, that information is fetched once, and never updated. The user was just supposed to know that in order to see it update, they had to manually refresh it, either by bumping a selection back and forth, or by closing and reopening a dialog.
• Just know: nobody else is going to do it for you. So what are you waiting for?
• every templating language inevitably turns into a very poor programming language over time
• Along the way, third party React libraries have followed a similar path. Solutions like Redux appeared, got popular, and then were ditched as people realized the boilerplate just wasn't worth it. It was a necessary lesson to learn.

Prototyping to Learn, daverupert.com, 2022

• Did you know your prototypes can serve different purposes? Bob and Greg have big buckets for them. Learning prototype Communication prototype Milestone prototype These are wonderful categorizations of the roles prototypes can play.
• Prototypes aren’t uniform in scope and sometimes look at problems from different scopes or dimensions: Comprehensive prototype - Explore how many aspects fit together Focused prototype - Focus and optimize a single aspect
• A good prototype helps answer a question. The questions Bob and Greg came up with were: “What question are you trying to answer?” “Why are you doing it?” “Who is it for?” “What do you hope to learn from it?”

Want Cleaner Code? Use the Rule of Six, David Amos, 2022

• Every line does only one thing One line, one task. But don't go crazy with it.

How I Think About Product Management, Matt Lane, 2022

• I see PM as innovation risk management. Why? In general, 50% percent of the solutions we ship won’t have an impact on customers and 50% will need lots of iterations to deliver customer value. This is not an issue, but a reality. The reality is that there are no requirements. Users/customers do not know what they want.
• I am skeptical of simulations and believe in decision processes designed to support building systems that quickly and cheaply roll out real things into the real world.
• I favor options over plans (be present, and act on your inspiration. It won't last forever), bets over backlogs (learn from the past, and avoid being pulled back into it), half-products over half-ass products (trade scope for quality), impact over velocity (fewer things matter more than more things), and customers over investors (the source of value is when people send you money for what you built not when you send requests for money for things you want to build. Plus, it is the CEO’s job to manage boards, not the other way around).

The Prioritization Manifesto, Matt Lane, 2022

• Prioritization is not focus. In product development, focus is achieved by having a clear understanding of what makes your product different, i.e., the trade-offs you make at the highest level of your feature strategy by stating what your product is more about and what it is less about and the positioning rationale for each statement. These become your product’s principles and the focus filter that makes downstream prioritization less convoluted. Before you prioritize anything, create your focus filter
• Every project pitch should always have a hypothesis statement;
• No” is no to one thing. “Yes” is no to a lot of things. “No” creates optionality.

YAGNI Exceptions, Luke Plant, 2022

• We can afford to do YAGNI only when the systems we are working with are malleable and featureful. Relational databases are extremely flexible systems that provide insurance against future requirements changes. For example, my advice in the previous section implicitly depends on the fact that removing data you don’t need can be as simple as “DROP COLUMN”, which is almost free (well, sometimes…).
• Applications of Zero One Many.
• Versioning. This can apply to protocols, APIs, file formats etc. It is good to think about how, for example, a client/server system will detect and respond to different versions ahead of time

How Boring Should Your Team's Codebases Be, Steve Brazier, 2022

• When to discuss the novelty? Most teams I’ve worked on have some process to make larger architectural decisions. This could be a larger discussion on a PR for a proof of concept. Or maybe a more formal process for making “Architectural Decisions” that leads to the creation of an ADR.
• Too little novelty None of the things listed above are bad in isolation. They may bring a number of benefits: The new thing may be a better tool for solving your problem. It may help express your domain logic more cleanly. It may result in less bugs and improved development time. It may offer better performance. The codebase might become smaller and easier to maintain. It can be exciting and motivating as part of your team member’s personal development to learn new skills & technology. To me the important thing is to be conscious of the total novelty your team owns. If your team has very little novelty perhaps you could consider writing the next proof of concept using a new technology. If you find have a lot of novelty maybe it’s time to rewrite that old proof of concept that got pushed into production.

How to Plan?, kellanem.com, 2022

• This interview was for one of those jobs leading product and engineering which are coming back into vogue, sometimes called a GM, or CPTO, or just a VP of something or other. As an industry we’ve gotten pretty clear on the downsides of matrix management and the pendulum has started to swing the other way.
• So here are a few rules of thumb for making planning suck less.  Do fewer things. Bottom up processes don’t work.  Planning is the wrong time to introduce anything new. You must provide frameworks and constraints. Project planning has an inflection point. Don’t wait to kill bad ideas. Minimize dependencies. Headcount planning won’t map to your plans. What if money is no object?
• As a leader top down planning comes with not only real cost, but real risk. There’s a good chance that you’re wrong about at least a few things. You need to be comfortable finding that out, and you need people who are willing to tell you that.
• Many organizations miss this critical inflection point and go sailing off into Strategic Planning with the expectations of Project Planning still firmly in place. Companies operating in this mode are the ones whose frustration with not getting the strategic results they were hoping for leads them to push for more and more fine grained planning as the antidote: an attempt to achieve greatness by optimizing for predictability.
• My experience being at hypergrowth companies, and also being at companies that were trying to be successful post hypergrowth is that it is important to remember that  that all code, all products, all marketing material, every piece of work product comes with long term costs, even if it’s just the cost of deleting it (something most people find surprisingly difficult). Especially in a hypergrowth environment or when money and headcount are no object, you need to be better at planning, because the only constraints are the quality of your thinking.
• The first is it acts as a point in time to synchronize our multi-threaded company.  All year we operate with different teams and functions loosely coupled. Having a moment in time when we all agree we want to collate as comprehensive a view of what we’re doing as possible is an important investment to keep us from drifting too far apart.  That’s what Planning is, a time to all get on the same page before we all start running fast again.

Seven Shipping Principles, 37signals.com, 2022

• Feature creep and blown estimates are the industry standard. Our standard is that we ship the best work within the time we’ve given it, and we hold our heads proud to the compromises that entail.

You Don't Need Scrum. You Just Need to Do Kanban Right., lucasfcosta.com, 2022

• Why did you choose Scrum instead of Kanban? If you can’t answer that question, you didn’t choose Scrum. Someone else chose it for you.
• Scrum is a manager’s training wheels: it prevents them from bruising their knees, but also prevents their teams from being as fast and dynamic as they could be
• Kanban, on the other hand, establishes principles. Once you understand these principles, you can tailor them to your particular situation and obtain much better results.
• Kanban boards were made for practicing Kanban should be a strong enough argument. Still, it’s worth highlighting that making work visible by itself doesn’t make any difference if you don’t actually use that visualisation to take action.
• Furthermore, because Kanban focuses on tasks rather than sprint-sized batches, it pushes responsibility to the edges of the team, meaning engineers are responsible for going after the pieces of information they need to move forward. When that happens, instead of designing features by committee, which demands a significant amount of back-and-forth discussions, decisions happen locally, and thus are easier to make. Additionally, fewer people making decisions lead to fewer assumptions. Fewer assumptions, in turn, lead to shipping smaller pieces of software more quickly, allowing teams to truncate bad paths earlier.
• Furthermore, it enables teams to size work effectively because it relies on rate matching instead of accurate accurate estimations, which are almost impossible to do given the stochastic nature of the software development process. Such focus on rate-matching, when combined when principles such as limiting work in progress, reduces waste because it incentivises just-in-time scoping, allowing teams to create stories closer to the time at which they’ll be implemented and shipped.
• As I mentioned before, sprint planning meetings are unproductive because they lead to “designing by committee” and focus on getting estimations right, which is not only a waste of time, but also impossible to do in a stochastic process such as software development.
• In Kanban, instead of carefully measuring each part of the process and ensuring it works uniformly, you simply focus on rate matching processes from right to left, meaning you will only start working on the next set of tires once the chassis-mounting stage has signaled its ready for more work. That way, you can dynamically adapt to problems that may happen temporarily at any part of the process. If your deployment process breaks, for example, you’ll be able to focus on fixing it instead of starting new tasks and causing everything to take longer on average, both because of the sheer amount of pending tasks and because of the cost of context switching.

Ditching Scrum for Kanban, Grant Ammons, 2022

• Scrum forced us to get more disciplined about upcoming features. The engineers needed wireframes, workflows, and light specs in order to properly estimate the work.
• Peter told me that indeed, many companies follow the same path that we did. They go from no system to Scrum, which teaches them the disciplines they need to properly develop software. Then, as teams fully understand Scrum, its disciplines and rituals, teams have the option to move to Kanban.
• It turns out that cramming to make sprint deadlines was not the major motivating factor to get work done. We still have deadlines, and we still have a strong, motivated set of engineers and team leads.

Developing SaaS? Forget Scrum, Check Out Kanban and Similar Approaches, sprint backlog, 2022

• Personally, I don’t feel that the metaphor is critical to success. In the end of the day, one needs to define how Issues flow through the system. Whether a tester “pulls” an Issue or whether the Issue is “pushed” by a developer downstream to a tester seems to be a matter of definition, with little practical difference. The important part is to ensure that the issues actually flow through the system and not pile up in one phase (a concept called Limit the WIP in the Kanban jargon).
• It is Sunday, a working day in our R&D facilities in Israel. A new iteration, towards release 2012.05, has just started. The Issue is moved from Backlog to In Play, and named IP-412. It is assigned to a specific developer. Its ranking is increased. This is a small visual enhancement, so the issue is marked as requiring visual design guidance (this is not a phase in the process but an indicator set up for the Issue). 2012-02-14 10:34am Two days pass. It is Tuesday, three days into the iteration. The designer uploads the revised graphics. 2012-02-15 9:07pm Another day passes. It is Wednesday night. The developer moves the Issue to In Development.
• We were easily able to address non-breakable tasks. We did not have to come up with an alternate methodology for an Issue that spanned 3 iterations.
• We were not forced to assemble a team of generalists. Our system is composed from some 20 unique sub-systems, dealing with Content Editing, Content Serving, Content Processing, Content Feeds, internal SDKs, Analytics, MPN/GTIN Matching, SEO, and more. Our expertise areas range from back-end systems (SQL, NoSQL) to business rule programming and front-end development (JSP, HTML, CSS, JavaScript). Attempting to get everyone to master all systems would be a futile effort. Trying to normalize all Issues into a universal scale (like Story Points) and distribute equally among team members would be a folly.
• First, there is the well-known Backlog. We manage two levels of backlog Issues. The first is a Wish List, which includes any idea or request that is a candidate for inclusion in the software. In many cases, this includes a request in its raw form (I need a button that does this and that), which may transform into a different approach during product design. The second is a true Backlog, which includes items that are candidate for implementation in the near future. Issues are moved from the Wish List to the Backlog, and then, when their time has come, to the In Play collection. The second source of Issues is a Ticket system. At WebCollage, the development organization receives approximately 2 tickets a day. The Kanban approach lets us handle important tickets as they come even if they arrive during a development iteration. When an Issue is determined to be of a high priority or requires very little effort, we put it in a Fast Track, and usually address it either during the current iteration or the next one. Consequently, we can resolve an issue in an average of less than two weeks. With such a turnaround, the need for hot fixes and other exceptional handling is greatly reduced. The ticket workflow we use is the following:

This Simple Team Activity Builds Psychological Safety., Duncan Skelton, 2022

• Most people think psychological safety is about creating happy teams.Nope. Wrong.Psychological safety is about high performance.
• Each idea, each sticky note should be an example of a behaviour.Behaviour is key — it is observable. It generates an experience within those who observe it or on the the receiving end of it.

Startup Engineering Hiring Anti-Patterns, South Park Commons, 2022

• Great engineers all have the capability to learn new languages and frameworks easily.
• for the most part startups don’t need deep specialists. They need people who are quick learners and can rapidly find 80–20 solutions
• The easiest thing in an interview is to find a reason to say no. I see this happen all the time. Someone will find a minor issue, blow it up and suddenly convince the entire interview panel that the candidate isn’t a good fit.
• As a startup, you need to be comfortable taking risks on hires but also parting ways if it isn’t working out after 2–3 months.

Your CTO Should Actually Be Technical, South Park Commons, 2022

• It allows them to make highly educated tradeoffs—between quality, speed, launch dates, feature inclusion etc. Making the right tradeoffs is one of the cornerstones of great leadership.
• You can't improve something unless you start measuring it. So step 1 in the sustainable battle plan against bugs is to start measuring how good quality is right now. But step 0 is actually to define what good looks like. This requires answering a product question: “What are the top 2-3 things that users really care about from our app?” That’s the stuff that must always be working correctly and be high quality
• CTOs have to be very clear with everyone that if quality falls below a certain point then everything will be paused to focus on improving quality.
• But one of the CTO/VPE’s most critical roles is knowing when it’s necessary to first go slow to go fast.
• Step 3 in the War on Bugs: continually raising the bar for quality in every roadmap/OKR planning process. We moved the Red Line further away and made it possible to keep pushing it back over time.

Learning by Working on Problems Just Outside of Your Reach, Alex Ellis, 2022

• Working on problems just outside of reach One of the most helpful things about this is that it gives more immediate and appropriately scoped goals;

Co-Founding Considered Harmful, florentcrivello.com, 2022

• But the grass is always greener. Solo founders often fantasize about having “another them,” a sort of soulmate in the trenches with them. Reality often falls short. Instead of a soulmate, you might find yourself trapped with someone who greatly adds to your stress instead of subtracting from it.
• Being solo makes finding PMF harder in two ways: you lack a thought partner, and, most importantly, you run a bigger risk of being in denial.
• But there are ways to mitigate this too. I’ve found it critical to set aside at least three hours every Friday to think about my startup, with no interruptions (credit to Mathilde Collin for the idea). It is indispensable to do this thinking on paper — I completely agree with Einstein that “you can’t do much carpentry with your bare hands, and you can’t do much thinking with your bare brains.” Or as Leslie Lamport said, "If you’re thinking without writing, you only think you’re thinking."
• Whatever you do, do not go “co-founder dating.” This is the single most important decision you will make in the lifetime of your company. No amount of dating or interviewing will suffice — if you don’t already know someone you’d feel not just okay, but elated going in business with, then you’re going solo.
• Do define ahead of time which decisions will require unanimous consent, and which can be made unilaterally, and by whom. Put it in writing. Especially consider situations like wanting to sell the company, or having to pivot.

AI Will Replace Middle Management Before Robots Replace Hourly Workers, chatterhead.bearblog.dev, 2022

• AI managers are the missing link between the when and how of implementing retail level automation. Reducing middle management, freeing up cash flow, incentivizing hourly workers and implementing automations will all depend on the fecundity and vision of senior leadership. Or maybe just which blogs they decide to read.

Against Maximization, world.hey.com, 2022

• I can’t imagine anything less interesting in business than maximizing shareholder value. Yet this is what public companies are pressured — if not legally required — to do.
• Am I interested in increasing profits? Yes. Revenues? Yes? Being more productive? Yes. Making our products easier, faster, and more useful? Yes. Making our customers and employees happier? Yes, absolutely. Do I love iterating and improving? Yes sir. Do I want to make things better? All the time. But do I want to maximize “betterness”? No thanks.
• I like knowing there’s headroom. And once in a while it’s a fun challenge to chip away at that headroom. But that’s not for maximization’s sake — it’s for curiosity’s sake. “Can we do it?” is a lot more interesting to me than “we must do it because that’s what you’re supposed to do.”

My Take on Why Goal Cascades Are Harmful and What to Do Instead, Jason Yip, 2022

• There is no reason to assume that the primary driver for a goal should always come from the top of an organisation. The senior-most leaders of an organisation do not have perfect knowledge, nor perfect reasoning and depending on the specific context, they don’t even have the best knowledge or reasoning.
• Goal cascades are inherently delayed.
• Optimal action never comes from simply aligning to top-down goals as they cascade through the organisation.
• Things that don’t change that often, what John Cutler refers to as the “persistent model”:The overall shared mission;The shared model of reality, that is, the coherent overall strategic narrative based on data and insights;The shared beliefs on how to succeed (aka doctrine)Things that change more frequently, what John Cutler refers to as “point-in-time goals”:Specific bets / projects;OKRs (annual, quarterly);Delivery plans
• Persistent models enable parallel planning
• Instead of a top-down tree where teams are waiting for visions and strategies to come down from on-high, think of every node in a network developing an opinion about vision and strategy in parallel based on past communication and current information they’re seeing in their local context and ongoing synchronisation with other teams.Develop models as a network, not just top-down

Strategy Deployment From Cascade to Translation to Synchronization., Jason Yip, 2022

• Strategy deployment as simultaneous evolution with synchronization. People’s evolving understanding of context and meaning don’t actually stop while waiting for the next communication from “management”. Instead of a cascade or even a translation, it’s better to think of strategy deployment as regularly synchronizing a constantly evolving context and meaning simultaneously occurring at all levels of the organization.

Formalizing Our Engineering Principles, Nif Ward, 2022

• In contrast to organizational values, principles tell how we work, rather than what we value. Many companies don’t make a clear distinction between principles and values – plenty of companies’ “values” look like other companies’ “principles”. We found this distinction helpful when describing what we hoped to accomplish by formalizing Cash’s Engineering Principles.
• We also researched other tech companies’ engineering principles and values and found things worth emulating or eliminating from our own
• ther than publishing principles that reflected an ideal or aspirational state of Cash Engineering, we focused on establishing a cultural baseline – principles that reflect how Cash Engineering teams actually work, right now
• We tried to keep each principle focused on positive action – what a Cash Engineer at their best should do. If a principle took more than a couple of sentences to explain, that probably meant it was too complex

Connecting Dots 41 ◎⁃◎ Leaderless Teams — Brett Macfarlane, Brett Macfarlane, 2022

• In the research, groups of soldiers without an appointed leader were given a “set” problem. However, the “real” problem unbeknownst to participants was their ability to balance their desire to do well with the need to work with and support other members of the group. Observers assessed, documented and ultimately coached this capacity. What emerged from this exercise is that social class, education, gender and athletic ability were less important for leadership than the capacity for an individual to attend to others in the group.

Only Solve One New Problem at a Time, Ben Nadel, 2022

• The example he gives in the episode is "learning Golang". Understanding how to use Golang was a new problem for the company. As such, in order to start integrating Golang into their work, they applied it in the context of an already-solved problem: sending emails. This way, Golang was the "one thing" they were solving—the email-sending logic already existed in Ruby; and, they just had to port it over to a new application server.
• f I could be so bold as to add a corollary to the rule of "one new problem at a time", I'd suggest that if it can't be done incrementally, don't do it. Over the last 6-years, feature flags have revolutionized the way that I work. And, a majority-stake in that change is the fact that everything I do is now built and integrated incrementally. Until you've worked this way, it's hard to even articulate why this is so powerful. But, I literally can't imagine building anything of any significance without an incremental path forward.
• When you build and integrate code incrementally as a rule, you are forced to think about the work differently. You have to break it up into smaller problems. And, the order in which those problems are solved (and integrated) starts to matters. This, in turn, allows you - and your external stakeholders - to create a better sense of how long things will take, how often value will be added, how far the project is progressing, and how the path forward (and expectations regarding delivery) might need to be adjusted.

All Companies Are Fucked Up, jonpauluritis.com, 2022

• If you're trying to figure out "how do I find the company that's fucked up in the way that works for me?" here's my advice: Do whatever you are into as fast and with as much focus as you can. Learn as much as you can about the stuff that you care about, and put yourself around people that are doing the same thing... or put another way: "Turn your belt black." Eventually, you'll end up with people who are fucked up in the same ways that you are fucked up... and by the transitive property, you'll find yourself at a company that's fucked up in its own special way just the way that you like.

What to Blog About, simonwillison.net, 2022

• Today I Learned A TIL—Today I Learned—is the most liberating form of content I know of. Did you just learn how to do something? Write about that.
• Write about your projects If you do a project, you should write about it.

Appropriate Context for XP, Scrum and MVP, Richard W Bown, 2022

• Use the most agile techniques when you’re trying new things out. Agile meaning – eXtreme Programming featuring pairing or mob programming. Use the Lean approach with lighter weight but slightly more formal processes (Scrum and Kanban) while you’re learning about the product and need to provide consistency and want to optimise it somewhat. Once it’s delivered (commodity) your product can be ascribed strong quality controls

What Happened When Zapier Cancelled Meetings for a Week?, calnewport.com, 2022

• Instead of my weekly 1:1, I consolidated questions for my manager and sent them to her in a direct message on Slack. Instead of a project check-in, all team members shared their updates in the relevant Asana tasks. Instead of a one-off strategy call, stakeholders shared their thoughts (and comments) in a Coda doc. Instead of a project kickoff call, our project manager sent a Slack message that shared the project charter, timeline, and next steps.”

How I Wrote Shape Up, Ryan Singer, 2022

• The application asked them to tell stories about problems they experienced with product development. Using their answers, I could screen out anyone who was merely curious or a fan but wasn’t really struggling. This created the best possible audience for getting feedback: hungry and motivated with skin in the game.

Introducing a Product Delivery Culture at Etsy, Tim Cochran, 2022

• Cross-functional teams: They structured their teams around “4 table legs”: Product, Design, Engineering, and Analytics. All planning and delivery practices happen with collaboration among the groups.
• I promise you that at least half the ideas on your roadmap are not going to deliver what you hope. (By the way, the really good teams assume that at least three quarters of the ideas won’t perform like they hope.)
• After some initial research the team came up with a metric they called Time to Learning – the time it took for a product team to validate an idea with a customer and gain a better understanding of its value. They had a baseline of 50 days that they wanted to reduce.

How Writing Helps Doist's Asynchronous Setup Soar, Write Louder, 2022

• When we say that we’re async first, what we mean is that we’re writing first.”

The Perks of a High-Documentation, Low-Meeting Work Culture, Kate Monica, 2022

• We do have meetings to discuss particularly heated topics and succinctly communicate ideas on projects that require high-bandwidth collaboration.
• We spend a lot of time writing. A lot more time than most other companies probably spend.  While this is quite a commitment, the resulting searchable, traceable, public record of all significant decisions, projects, and initiatives across the organization makes it way easier to onboard and scale.

GitHub’s CTO on Architecting Engineering Teams That Scale, FirstMark, 2022

• “If I say, ‘We’re going to deliver x on y, but we’re going to burn people out to get there,’ that matters to my employees,” explains Warner. “But if we’re never going to deliver something because we don’t want to burn people out, that also matters to my team. You need to find the right balance between what you do and how you do it in order to keep your employees around long-term.”
• Be authenticOne of the most effective ways to build trust as a leader is to be authentic and vulnerable. By admitting that you have struggles, worries, and fears, you’ll get a lot more leeway and credit from your team and colleagues. But if a person tries to be perfect or unbreakable, a single misstep or crack in the armor will bring everything crashing down.
• The sociologist mode: When it’s time to make the best decision for the company, leaders should be in sociologist mode.The psychologist mode: When working through problems one-on-one with an employee, leaders should be in psychologist mode.
• 11. Find the right org structure for you *right now*No organization structure is ever going to work 100% of the time. When coming up with an org structure, you need to think about what you’re optimizing for at this moment in time and for the next set of deliverables. Then organize around that. You’re never going to have the perfect structure — something is going to feel wonky and you’re going to have to be okay with that.
• Worry about too many programming languages and frameworks. Multiple build systems are okay, but you don’t want 14 different programming languages. Pick one compiled language and one dynamic language and stick to them.
• One of the first things leadership should do is establish a mission and a vision for the company, which should then be broadcast to employees. Everyone at the organization should know why they’re at the company, what they’re building and for whom; and they should be able to understand and tell that story in a consistent way.
• When it comes to setting up principles and practices, Warner suggests creating just enough processes to have a structured organization without creating too many limitations. But he adds in the caveat of context. As you’re reading about best practices and ways in which other organizations have been successful, note the size of the organization, how new it is and how they operate. What works for one company might not work for you in the same way.

The Coach and the Fixer, randsinrepose.com, 2022

• Leader, the Fixer, and the Coach. I will briefly each role and then explain how I’ve screwed up each. I’m going in reverse order because I’m building tension.
• They liked me? Perhaps too much? What I heard between the words was the team appreciated me as a Coach and as a helper, but they did not trust me to make the hard calls because I was afraid of hurting my relationship with the team. And they were right.

The 10x Development Environment, Alberto Fernández-Capel, 2022

• For example, some of the older parts in Basecamp are still implemented in jQuery. They works fine and there’s little practical reason to rewrite these areas (that’s another thing about productivity at 37signals: we only focus on things that matter). The old JS code is not bad code, but it’s not the kind of code you’d write in 2022, and because of that we didn’t reuse much of it for the Card Table.

Sep 11 the Power of “Yes, If” Iterating on Our RFC Process, Tanya Reilly, 2022

• Approvers say “yes” or “not yet.” We want to encourage constructive comments, so the template doesn’t suggest “no.” Instead of just vetoing an idea, it’s better to be clear on what it would take to approve it. A “yes” might come with caveats. For example, in reviewing the first draft of this post, Eva might write, “Yes, if you can show that each iteration was a useable milestone.” This sort of “yes, if”
• Note the status field here: it’s free text, and I’m using it to be clear about the kind of review I want. For a first draft, I might want reviewers to tell me whether this is even a good idea.
• To make reviewers’ lives easier, we added a few sections to help discover potential sources of conflict or wrong assumptions: Alternatives Considered/Prior Art: List the other approaches you considered and why they didn’t work. Are there existing systems that almost worked? Dependencies: What other systems do you depend on? Do they know you’re about to depend on them? Operational work: What manual tasks are you adding and who do you expect to do that work? Will other engineering teams or our excellent Customer Operations folks need to do anything to make this design successful? Spell out what you expect.

Work 10x Smarter With One Magic Word Asynchronicity, Pim, 2022

• Control your urge(s) This one is probably the hardest of all. Try to control your urge to work synchronously. Don't interrupt others. Stop bringing people together in meetings. Avoid constantly checking your email. Prioritize messaging over calls. Steer clear of real-time chat. Respect interruption-free work slots. No, it's not easy, but it's certainly worth your while. And everyone else's.
• What most companies call “remote work” is actually just a new name for all the bad stuff that used to happen in offices. Back-to-back meetings, constant availability, and endless interruptions.
• Focus on results
• Focus on writing
• Focus on documentation
• Focus on transparency

Staring Into the Abyss as a Core Life Skill, benkuhn.net, 2022

• However, in most cases you have to either admit this eventually or, if you never admit it, lock yourself into a sub-optimal future life trajectory, so it’s best to be impatient and stare directly into the uncomfortable topic until you’ve figured out what to do.
• Eventually, whatever part of me originally flinched away from these uncomfortable questions switched to being drawn towards them, at least for many classes of question.
• Recently I’ve been thinking about how all my favorite people are great at a skill I’ve labeled in my head as “staring into the abyss.”1 Staring into the abyss means thinking reasonably about things that are uncomfortable to contemplate, like arguments against your religious beliefs, or in favor of breaking up with your partner. It’s common to procrastinate on thinking hard about these things because it might require you to acknowledge that you were very wrong about something in the past, and perhaps wasted a bunch of time based on that
• Another abyss-staring strategy I’ve found useful is to talk to someone else. One reason that I sometimes procrastinate on staring into the abyss is that, when I try to think about the uncomfortable topic, I don’t do it in a productive way: instead, I’ll ruminate or think myself in circles. If I’m talking to someone else, they can help me break out of those patterns and make progress. They can also be an accountability buddy for actually spending time thinking about the thing.
• This suggests that a critical part of being effective at staring into the abyss is timing. If you do it too little, you’ll end up taking too long to make important life improvements; but if you do it too often, you might end up not investing enough in being great at your current job or relationship because you’re too focused on the prospect of next one.

Zero to CTO – Jody Bailey Is in the Spotlight, Andy Skipper, 2022

• The best way to acquire talent is to create a place where technical talent wants to work. You need to foster a great engineering culture, have interesting problems to solve and develop the careers of your engineers. Top talent attracts more top talent.
• Beyond that, in my experience, people want clarity around the goals we’re trying to achieve, clear boundaries, and the ability to operate autonomously within those guard rails.
• I believe the primary factor in motivating teams is creating clear, meaningful goals that align with the individual’s goals and values. Then, it’s about supporting them in pursuit of those goals.
• I aim to build teams with people whose skills are different from and complementary to mine so we’re able to push each other and succeed as a team.

Scrum Has Failed the Developers, Willem-Jan Ageling, 2022

• Scrum Teams became cogs in the machine of the delivery of goods, the software, to the clients.
• For most teams, the goal of sustainable pace is an illusion. But the other principles of the Agile Manifesto that I just discussed are under pressure too. How to keep motivation high when you are under constant pressure? How to uphold technical excellence when you need to deliver “NOW”? How to be a self-organizing team when all you need to focus on is faster and faster delivery?
• As long as the working environment of developers doesn’t change, every approach will fail to bring them relief.

Unpacking Boris, vaughntan.org, 2022

• Boris works because it forces decisionmaking stakeholders to talk about what they are willing to give up to get what they really want. Being aware of tradeoffs and agreeing on which ones are acceptable is essential to both good strategy and good execution.
• It focuses on identifying goals (or targets or objectives or whatever) and ensuring that the organization converges on a set of agreed shared goals, but Does not focus at all on making explicit and clarifying the acceptable and unacceptable tradeoffs in achieving those shared goals.

What You (Want To)* Want, paulgraham.com, 2022

• You can do what you want, but you can't want what you want. Yes, you can control what you do, but you'll do what you want, and you can't control that.

Five Reasons You Shouldn’t Rewrite That Code, Camille Fournier, 2022

• I’m not saying you should never rewrite anything. I have led successful rewrites, so I know that they are possible. But before you agree to the commitment of rewriting, allow me to share five reasons it might be a bad idea.
• Unless your system is very small, or new and barely used (in which case, why are you rewriting it?), there is no way that you have thought through all of the pieces of code you will actually need to replicate.
• This is one of the easiest pitfalls to avoid, and yet people still walk into rewrites without doing this work. Can the team articulate the underlying reasons that the old system is failing? Sometimes there are clear causes, but often it is more nebulous (“The users are complaining about the old system, so we need to rewrite it,” or, “Java sucks and Rust is cool”). If you can’t even articulate why the old system is bad, how do you know that the new system is going to fix it?

First Time With Basecamp’s ShapeUp, Kuba Płoskonka, 2022

• Start with appetiteThis was the first shift in thinking that changed a lot. With clear time and budget boundaries, we could reason about a solution that fits within these

The Unicorn Project The Feeling of Complexity Debt, Richard W Bown, 2022

• I’m reading The Unicorn Project by Gene Kim. He calls this ‘Complexity Debt’ because these are not just technical issues – they are business issues
• As Kim quotes, in 2003 Ward Cunningham said “technical debt is what you feel the next time you want to make a change”
• The power of complexity debt is that it acknowledges that production code doesn’t live in a vacuum.

What Is “Engineering for Software?”, github.com, 2022

• My definition of engineering is "the application of an empirical, scientific approach to finding efficient solutions to practical problems." The science part is important. We need to iterate so that we can have more opportunities to learn. We need to gather feedback so that we can reflect on the results. We need to work incrementally so that we can compartmentalize the problems in front of us and explore them efficiently. We need to organize our work into a series of small, safe experiments so that we can build our knowledge up in a more productive way. We need to capture data from real world systems so that we can learn empirically what really works and what doesn't. These are the tools of scientific reasoning. These are the tools of real "engineering.”
• Most engineers don't ever expect to get things right the first time. If you get it right the first time, you aren't learning, you are just fulfilling your expectations.
• My take on continuous delivery is consciously centered on applying scientific reasoning to solving problems in software. We create deployment pipelines that allow us to iterate fast, aiming to create a production-releasable outcome multiple times per day

How to Distort Scrum Until It No Longer Works, lucasfcosta.com, 2022

• Just like creating your own front-end framework is a rite of passage for web developers, creating your own version of Scrum is a rite of passage for engineering managers. Both cases usually result in catastrophic failure, followed by tears and despair.
• Backlogs are the best way to avoid difficult conversations. Whenever someone wants developers to implement a new feature, you can tell them you’re going to “add it to the backlog” and forget about it. Then, when they ask you about that feature again, you can tell them it’s still in the backlog and that you just haven’t had the time to get to it.
• the best way to ensure nothing gets done is to design by committee
• Doing a lot of refinement is a great way to waste time because it will cause people to think about how to handle every single edge case that comes to mind, including the ones that will probably never happen and don’t impact the overall goal. If that sounds too productive, don’t worry. Even then, people will not think about the edge cases that truly matter: the ones that will come up as developers write code. That way, you can maximize the time developers waste, thus increasing costs.

Two Development Team Configurations I Lobby Against, Richard Mironov, 2022

• lobby my engineering counterparts away from: Dedicated bug-fixing teams (usually proposed by Engineering) Special Projects or 'Overflow' Teams (usually proposed by Sales/Go-To-Market) Ultimately not my call, but worth spending some social capital on.  Here’s my thinking
• at finding and fixing their own issues because they know what was written, where it lives, and why they thought it might be correct.   A bug team that works across a product’s whole surface area won’t build the deep knowledge about any one part – or be included in design/architecture discussions and decisions.
• If we’re just noticing a lack of automated tests, let’s allocate 10%-20% of each sprint to test creation until we catch up
• Hiring an outside team for a little while to build out test coverage might be smart.  But fixing what’s broken still belongs to whoever broke it.
• every one of our customers and execs will always have another dozen unmet needs, amplified by our enterprise sales teams.  It’s turtles all the way down.  So our first Overflow Team is immediately booked through 2024 and there’s demand for a second (third, fourth, fifth) team.  We can accidentally (but rapidly!) become a professional services/custom consulting company.
• , mironov.com

Tech Leadership Mistakes That Ruin Productivity, Jason Lengstorf, 2022

• 3. Leaders stay too involved in tactics for autonomy to exist Imagine yourself as a member of the team. Leadership gives you a project and tells you to own it. You sit down to start doing the work, and you feel eyes burning into the side of your head – the person who just assigned you the project is staring at you intently. ‘Go ahead,’ they say, gesturing toward your computer. ‘Be productive.’
• Commit to trusting the team and only weighing in at milestone check-ins As a leader, you may have been nodding along to the last three solutions, thinking, ‘Yes, this is exactly what my team needs to do better.’ Get ready. This is the part where you have to do something hard. You have to approve the plan, step back, and let the team work.

No-Code Isn’t Scalable. Our Learnings at FINN Going From 1000 Toward 100,000 Car Subscriptions, Ishtiaque Zafar, 2022

• We came up with a strategy “Think 10x”. The idea was to start small, with just 10 cars targeted to be sold, and then scale 10 times in each phase. 10 cars → 100 cars → 1,000 … 100,000 cars. This ambitious project was called the “Green Dragon”.
• Here the engineering principles we laid down at FINN:Keep it simple: we want to solve today’s problem in a simple way with an eye looking at tomorrow, rather than solving tomorrow’s problem todayEmbrace errors: We operate in a legacy environment where failures are common. We don’t want to fight errors, we want to embrace them and design with failure in mindMake it visible: Our services must talk to us, tell us what is happening and show us how well they are doing. We don’t want to find things out, we want to be toldInternalise complexity: We cannot change how our partners work, but we can change how easy we make it for them to work with usCustomer first: Our customers rely on us to give them the best possible experience, but they also trust us to manage their data and informationData is always accessible: we never want to block people from reading our data and we should always provide a way for them to do it without any workClear is better than clever: We strive for readable code that is easy to understand and change. Our goal is not to write the least amount of code, but the clearest. Magic is not our friend here

The 37signals Guide to Internal Communication, 37signals.com, 2022

• If something’s going to be difficult to hear or share, invite questions at the end. Ending without the invitation will lead to public silence but private conjecture. This is where rumors breed.
• Reflect every 6 weeks: Heartbeats Heartbeats summarize the last ~6-weeks of work for a given team, department, or individual (if that person is a department of one). They’re written by the lead of the group, and they’re meant for everyone in the company to read.
• Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it’s important, critical, or fundamental, write it up, don’t chat it down.

Stand-Up Meetings Are Dead, Ben Darfler, 2022

• What does this “meandering team sync” look like? For my team at Honeycomb, our meetings are an hour a day, five days a week. I can already hear the productivity crowd moaning in the back—but I’m genuinely not sure we could devise a better use of our time.
• Ease in with some structure. Come prepared with some conversation starters. For instance, on a previous team, we had a practice of going around the room on Mondays and talking about our weekends. This is a great opportunity to both be goofy and learn more about each other as human beings.
• Bring the fun. Bring in an online social game sometimes. My team has picked up playing Skribbl on Fridays, and I’m still laughing to myself about the round we played a few hours ago. Don’t let the “mandatory fun time” vibe get to you. I promise no one will remember when you are all cry-laughing at each other's terrible pictionary skills.
• As the world abruptly cut over to remote work in early 2020, we all scrambled to replicate our existing team practices in this new distributed world. Of course, we all know that distributed work is best done asynchronously, and thus the asynchronous (async) stand-up was born.

U.S. Stock Market Returns – A History From the 1870s to 2022, themeasureofaplan.com, 2023

• the stock market is a device for transferring money from the impatient to the patient

Why Domain Driven Design?, John Pradeep Vincent, 2023

• “What’s the difference between Principles and patterns?” The answer is that patterns emerge from principles.Principles are the basic building blocks of software models, while patterns are a layer above principles that help capture, document, and share solutions to common problems.
• The formal definition of an Entity is: “An object fundamentally defined not by its attributes, but by a thread of continuity and identity.”
• As you can already see in the example, the Order entity (has a global unique identifier), LineItem entity (has a local unique identifier) and the Money value object together form a cluster of objects called the Aggregate
• I have seen cases where people use a repository almost like a data access layer, but it’s much more than that, repositories should be always looked at as “Repository of Aggregate roots”Example: “Repository of Orders”, “Repository of Customers” etc.
• That’s the same question as “how perfect a circle should be?”, the answer to both questions are simply “to a degree that is useful to solve a specific problem”.
• In essence, Accuracy is not very important, but usefulness is!
• Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.
• Money is a value object. The form definition of a value object in the DDD community is: “An object that describes some characteristic or attribute but carries no concept of identity.”It is very straightforward that Mone
• GRASP principles for instance make you think and consider how you go about assigning responsibilities to various classes so that you achieve high cohesion on low coupling.

Bottleneck #03 Product v Engineering, Tim Cochran, 2023

• Assets that describe your economic model These should describe the value your company receives from customers, the cost of creating that value, and the ways in which you measure that value. Examples include: Business flywheels Value stream maps Wardley maps Retention/churn models Customer acquisition models Customer lifetime value models Projected balance sheets and income statements
• Identify and reinforce your “First Team”
• The key to any successful startup is close collaboration between product and engineering. This sounds easy, but can be incredibly difficult. Both groups may have conflicting goals and different definitions of success that have to be reconciled.
• As leaders, it’s important to identify and reinforce a team dynamic around the creation of value rather than an organizational reporting structure
• Engineering might want to build a product that is perfectly scalable for the future with the best developer experience. Product might want to quickly validate their ideas, and put features out that will entice customers to pay for the product. Another example that’s common to see is an engineering-led "engineering roadmap" and a product-led "product roadmap" and for the two to be completely independent of each other, leading to confusion for product engineering.
• Assets that describe customer and user value These should describe the value your product and services create, who they create it for, and the ways you measure that value. Examples include: Business Model Canvas/Lean Canvas User Journeys Service blueprints Personas Empathy maps Storyboards Job forces diagrams Product overviews (one-pagers, etc)
• Assets that describe your strategy These should describe why you’ve chosen to serve these customers in this way, the evidence you used to make that decision, and the highest leverage ways you can increase the value you create and the value you receive in return. Target customer profiles Issue trees Impact maps Opportunity/solution trees Hierarchy diagrams Causal loop diagrams Other bespoke frameworks and models
• Team working agreements frequently contain: Team Name: What is the unique identifier for the team? Team Mission: Why does this specific team exist? What value is it expected to deliver? Team Metrics: How will the team measure success? Include value creation metrics, not just activity metrics. Team Responsibilities: What work needs to be done to ensure success and which team members are agreeing to own those work items? Organizations can seed this work with typical activities and recommendations for team responsibility allocations, but team members are free to renegotiate amongst themselves. Team Skills: What skills are needed on this particular team to ensure success? Team Norms: Guidelines, principles, ceremonies, and/or sensible defaults for team members to align on how team members are expected to behave, interact, and make decisions.
• Functional managers are responsible for ensuring that they are providing a healthy bench of skilled players to staff those teams. It’s critical that these direct managers are aligned on the roles and responsibilities of product team members to avoid conflict within the product teams.
• Account for cross-functional requirements A good product isn't just a product with the latest features. It must be built to be performant, reliable and stable. It should be cost efficient – the cost of operating the product shouldn’t exceed the revenue that the product generates. The underlying architecture of the product should enable future feature development to occur quickly and efficiently. It should have in mind client expansion and be able to scale, without too much rework. It shouldn’t put private customer or business data at risk.
• When negotiating a backlog, startups often find it challenging to understand the relative impact between potential investments — and because usage and revenue metrics are easy to obtain and well understood, work that will impact those is often prioritized, which pulls the investment mix out of balance. To counteract this, we recommend finding metrics that allow you to measure the impact of technical investment as well. Each situation is different, but there are a number of research-supported, de facto standards shown to improve long-term productivity that you can use as a starting point. Focus on DevOps and DX outcome-driven metrics. Reading maximizing developer effectiveness is a good starting point. In the Thoughtworks Scaleup Studio, we have a number of sensible defaults, that come from a study of what practices and technologies that successful scaleups are using. This includes continuous delivery, domain-oriented microservices, prudent use of technical debt, building experimentation processes and infrastructure. Set a non-negotiable quality bar and keeping to it. For example, each language has a set of good practices that we can easily check our work against, automatically

Write Admin Tools From Day One, milwaukeemaven.blogspot.com, 2023

• What Tools To Provide
• System Visibility
• Data Modification
• Support Actions
• Audit Trail
• Leverage a 3rd party admin framework from day one.

What Is a CTO? Your Organization’s Tech Visionary, Josh Fruhlinger, 2023

• The CTO is typically one of the most senior technology leaders within an organization. They develop the policies, procedures, and vision for how the company will use technology to improve the products and services it offers. A CTO needs to understand technology from a business perspective, and will make important decisions about major technological projects within the company.
• They think about technology in terms of how it can benefit the company’s customers, and how it can boost revenue and increase sales. A CIO, by contrast, is more focused on the technology which a company runs on, including core email, file storage, process automation, and data processing and analysis systems
• Thought leadership – A true thought leader takes the previous two roles to the next level, analyzing target markets and developing business models in order to understand what role tech can play in a company’s future, and staying ahead of the competition

Manage Like an Engineer, Ben Balter, 2023

• TL;DR: If issues, pull requests, and project boards are the best way to develop software, should they not also be the best way to manage software development?
• Here are a few of the engineer-inspired “how we work” principles which I strive to embody through my own management: Make work visible - Proactively share to the widest extent practical given the subject.4 Write things down - Especially the why and how. Ensure that everything has a URL. Be generous with links. Over communicate - Use a durable, searchable, and discoverable medium. Let others opt-in to context and subscribe to updates. Bias for shipping - Ship early, ship often. Whether decisions, process, or “manager code”, ship an MVP and iterate. Minimize batch size. Streamline and automate - Never force a human to do what a robot can. Prefer non-blocking over blocking operations. Codify policy as code. Embrace collaboration - How we work is as important as what we work on. Software development is a team sport.5 Asynchronous first - Reserve higher-fidelity mediums for conversations that require them. Practicality beats purity - These are guidelines, not rules. Process should drive outcomes
• Managing like an engineer means a manager’s go to tool for planning, tracking, and communicating managerial work is issues, project boards, markdown files, and pull requests:6 Issues - Issues are the atomic unit of work across teams and is the primary means by which work is planned, tracked, coordinated, and communicated, and where updates are shared.7 Project boards - Project boards are the primary means by which work (in the form of issues) is organized, managed, prioritized, and made visible. Markdown files - Markdown files are the primary means by which long-lived information is memorialized. Markdown files are created and modified via Pull Requests. Pull requests - Pull requests are the primary means by which proposals are reviewed and decisions are made.
• If issues and project boards track and organize work, “management decision records”,8 socialized and discussed via pull requests are how decisions are made and communicated.

Leaders Show Their Work, Ben Balter, 2023

• Start by stating the problem you’re trying to solve and why Enumerate what your goals were and what principles you followed Communicate not just what, but how, and why the decision came to be Link to any source materials or prior art that you used to make the decision Include what alternatives you evaluated and why they were ultimately dismissed If it’s not apparent, explain who was involved with the decision along with their roles Set expectations around opportunities for feedback, improvement, or participation, if any Explain the state of the decision (for example, final, proposed), and when it will be revisited, if ever Distill meeting recordings and chat transcripts to create a concise and easily consumed historic record Avoid using “best practice”, “industry standard”, or “parent company/former employer does X” as a justification Establish clear timelines and provide regular updates to avoid the perception that lack of visibility is lack of movement
• Empowers others to learn through observation
• Captures institutional knowledge -
• The easiest way to ensure everyone can understand the how and why of a decision is to adopt systems that, through their daily operation, ensure such context is automatically and readily available to those who might want it (and explicitly not only those who presently need it).
• Socializes organizational culture and values
• At a high level, “showing your work” means capturing who made what decision and when, along with a detailed, but concise description of why and how that decision was made. Showing your work offers organizations and teams a number of advantages:
• Fuels engagement
• Keeps the bar high
• Near-term convenience creates long-term communications debt I admit, as GitHub has grown, I’ve fallen astray and am guilty of starting a Slack DM, Google Doc, or Zoom meeting, tempted by the siren song of near-term efficiency that quickly hashing out a problem in private offers. Similar to how quick technical fixes often saddle an organization with ongoing technical debt, so too can communication shortcuts be an avoidable source of ongoing communications debt.

How to Write a Great Extended Leave Document, Ben Balter, 2023

• Points of contact
• Dates
• Contact preferences
• Regular meetings
• Sections to include ⏳ TL;DR:
• Important links
• Rolodex For everything you touch regularly, list your primary point of contact. This will allow others to unblock themselves if they have a question or request of another department or team. Example:
• Share early and often
• Stuff you touched recently or hope can be picked up while your out

„Arbeiten, Wie Ich Wirklich, Wirklich Will.“, Ausgabe kaufen, 2023

• Das ganze Homeoffice-Thema wird falsch, weil binär diskutiert. Wenn ich gegen Home-office bin, bin ich das Unternehmer-Schwein. Bin ich fürs Homeoffice, bin ich super New Work. Keiner guckt zum Beispiel aus der psychologischen Perspektive: Was brauchen Menschen für Bindungen? Was braucht es, um miteinander kreativ zu sein? Das sollten die Fragestellungen sein.
• Wir empfehlen, dass Dringliches über einen Kanal geht, beispielsweise den Firmenchat. Und Wichtigkeit geht über einen anderen Kanal, meist per E-Mail oder über das Projektmanagement-Programm. Denn wichtiger Inhalt geht oft mit Dateianhängen einher.
• Es gibt da zwei weitere interessante Studien. Die eine belegt eine Korrelation zwischen Meeting-Effizienz und Unternehmenserfolg. Das heißt: Produktive Meetings zahlen sich aus. Und die andere besagt: Je früher am Tag Meetings liegen, desto eher machen die Leute Multitasking – einfach weil noch viel vor ihnen liegt. Genau deswegen plädieren wir für eine Fokuszeit am Vormittag.
• Eigentlich mache ich, was ich tue, total gern, nur nicht in der Art und Weise, wie ich es tun muss. Deswegen sollte es heißen: Arbeiten, wie ich wirklich, wirklich will.
• Wenn ich Führungskräfte frage, wo die Schrauben sind, an denen wir drehen müssen, sagen sie alle, wirklich alle: Ich möchte in Ruhe arbeiten können. Ich möchte nicht von Meeting zu Meeting hetzen und immer zu spät kommen, weil ich zwischendurch mal zur Toilette war. So gestresst erleben Sie die Kunden? Ja, total. Allerdings stecken sie oft auch in einer, wie wir es nennen, Erwartungserwartung: Sie denken nur, dass sie dauernd erreichbar sein müssen. Wenn man dann mit den Unternehmerinnen oder dem Vorstand spricht, sagen die: Moment mal, das haben wir doch nie gefordert!
• Ja. Stattdessen sollte es völlig in Ordnung sein, wenn jemand sagt: Ich habe in vier Stunden einen top Job gemacht, ich bin fertig. Da sollten auch nicht vier Stunden abgezogen werden. Die Person hat das Ergebnis gebracht, das sie bringen musste, sodass alle anderen weiterarbeiten können und das Gesamtergebnis steht. Doch stattdessen messen wir lächerlicherweise die Produktivität von Denkarbeit am Achtstundentag und sponsern den Yoga-Kurs, damit der Rücken nicht durchbricht. Das sind Symptompflaster.
• Das durch die Pandemie erzwungene millionenfache Arbeiten im Homeoffice hat beileibe nicht jeden beglückt, manchen hat es sogar krankhaft erschöpft. Viele mussten erkennen, dass ihnen Struktur und Strategie fehlen, um die neu gewonnenen tatsächlichen oder vermeintlichen Errungenschaften der Telearbeit zu genießen.
• Genau das aber ist die Herausforderung von New Work: Es verlangt, Verantwortung für sich selbst zu übernehmen und den eigenen Tag so zu organisieren, dass ich selbstwirksam sein kann.
• Wenn das Smartphone dauernd entsperrt werden muss, weil es Arbeitsnachrichten empfängt, werden naturgemäß auch private Nachrichten angezeigt. Es kostet Überwindung, die zu ignorieren. Das verbraucht Energie, die fehlt, um sich zu konzentrieren.
• Wir lassen die Kunden sich selbst 25 Fragen stellen und diskutieren, wie sie Lösungen finden, um fokussierter arbeiten zu können. Das tun sie auf den fünf Feldern Arbeitsorganisation, Meetings, Führung, eigenes Verhalten und Kultur. Das Modell ist für Unternehmen gedacht und als Open Knowledge frei zugänglich
• Wer bewusst so zwei Stunden am Vormittag in Ruhe arbeiten kann, geht ganz anders durch den Tag. Der Spiegel des Stresshormons Cortisol im Blut sinkt messbar. Voraussetzung ist aber, dass das Management diese Fokuszeit nicht nur will, sondern auch selbst nutzt und durchsetzt.

Demystifying Managing Managers, Anita Singh, 2023

• One of the biggest changes when you step into this role is that you are no longer just responsible for one team, but multiple teams and their leads. You not only have to gain the trust of your direct reports, but the direct reports of your direct reports. You also want to get their honest feedback about how your organization is performing to help you best support your leads. How do you go about this?
• I find demos, knowledge sharing spaces, skip-levels and all-hands meetings great spaces to build trust and also to receive feedback. I go through RFCs (Request for Comments) and post-mortems as it gives me insight into technical decisions and how engineers collaborate with each other
• You have to give your leads your trust and autonomy, otherwise you will hurt the very people you are trying to help succeed.
• You have to actively give up control to be successful as a leader of leaders. You are now a multiplier through complete indirection, and this means you will not be as involved in technical decisions and the day-to-day work, while having many new stakeholders.

Software Engineering Practices, simonwillison.net, 2023

• Documentation in the same repo as the code
• Automated code formatting
• Tested, automated process for new development environments The most painful part of any software project is inevitably setting up the initial development environment. The moment your team grows beyond a couple of people, you should invest in making this work better.
• Automated preview environments Reviewing a pull request is a lot easier if you can actually try out the changes.

We Invested 10% to Pay Back Tech Debt; Here's What Happened, Alex Ewerlöf, 2023

• TPD trio (tech, people, domain), I was familiar with the tech and people but relatively new to the domain.
• Every other week, we had the "Tech Debt Friday". These days were not planned for a specific issue or story. We had a one pager policy that I forgot to copy, but it went something like this: We spend 10% of our time to deal with tech debt. The first rule is not to create tech debt in the first place. The PR (pull request) that creates tech debt should come paired with the issue to deal with it. All Tech Debt work is recorded as issues and labeled “tech-debt.” We deal with tech debt at the same time. Keep that day light on meetings. It is recommended (but optional) to demo the results in the next team demo. When changing code to fix tech debt, add/update the tests and documentations.
• Due to lack of formal structure of assigning issues and stories, these days were one of my favorite mob programming sessions. We investigated the code base together and learned about the history of it.
• but the lack of a concrete agenda also helped the autonomy that unlocked creativity.

Deep Work. Essentialism in Asynchronous Culture, jorzel, 2023

• We cannot do everything, so the only way to be successful and do not feel overworked is to assess and choose only essential options. It is the ability to say ‘no’ when we know that something is not worth our time, or we simply do not have enough time to do it in the right way, even if it is a tempting opportunity. “If something is not definitely ‘yes’, it is definitely ‘no’”. This is the leading idea of Greg McKeown’s great book Essentialism: The Disciplined Pursuit of Less that I strongly recommend reading. The author tries to convince us that a trade-off is an intrinsic part of our life and we should take the approach of determining where is our highest contribution point

How to Get New Ideas, paulgraham.com, 2023

• The way to get new ideas is to notice anomalies: what seems strange, or missing, or broken? You can see anomalies in everyday life
• the best place to look for them is at the frontiers of knowledge. Knowledge grows fractally. From a distance its edges look smooth, but when you learn enough to get close to one, you'll notice it's full of gaps. These gaps will seem obvious; it will seem inexplicable that no one has tried x or wondered about y. In the best case, exploring such gaps yields whole new fractal buds.

Software Has Bugs. This Is Normal., world.hey.com, 2023

• The only reliable, widely used way to ensure impeccable software quality is to write less software that does less stuff, and then spend eons honing that tiny lot. Such an approach, however, is very rarely compatible with commercial success or even programmer motivations (despite what many may claim).
• Useless software can be entirely bug free, yet remain entirely useless. Useful software can be ridden with bugs, yet remain highly valuable. Or, the value of software depends far more upon the problem it solves than the quality by which it does so.
• The value of a any given bug can be rated by the number of users affected times the criticality of the issue. Lots of users are losing all their data due to this bug? Okay, then, Very Damn Important! Fix it NOW! Lots of users are a little annoyed or confused by this? Probably should fix it some time soon. A few users have to spend another 30 seconds on a work around? Unlikely to get fixed any time soon!
• Software organizations that stay in business triage their backlog of bugs like that. They do not drop everything to deal with any damn bug. As the economies of scale kick in, so does the magnitude of consequences from such triaging. Large software packages and organizations will have hundreds if not thousands if not TENS OF THOUSANDS of open bugs of various criticality. THIS IS NORMAL. THIS IS EXPECTED.

20 Things I’ve Learned in My 20 Years as a Software Engineer, Justin Etheredge, 2021

• 7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system This is something I struggle with a lot as my responsibilities take me further and further from the day to day of software engineering. Keeping up with the developer ecosystem is a huge amount of work, but it is critical to understand what is possible. If you don’t understand what is possible and what is available in a given ecosystem then you’ll find it impossible to design a reasonable solution to all but the most simple of problems. To summarize, be wary of people designing systems who haven’t written any code in a long time.
• Every system eventually sucks, get over it Bjarne Stroustrup has a quote that goes “There are only two kinds of languages: the ones people complain about and the ones nobody uses”. This can be extended to large systems as well. There is no “right” architecture, you’ll never pay down all of your technical debt, you’ll never design the perfect interface, your tests will always be too slow. This isn’t an excuse to never make things better, but instead a way to give you perspective. Worry less about elegance and perfection; instead strive for continuous improvement and creating a livable system that your team enjoys working in and sustainably delivers value.
• One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more
• Interviews are almost worthless for telling how good of a team member someone will be Interviews are far better spent trying to understand who someone is, and how interested they are in a given field of expertise. Trying to suss out how good of a team member they will be is a fruitless endeavor
• There are a lot of forces that will push you to build the bigger system up-front. Budget allocation, the inability to decide which features should be cut, the desire to deliver the “best version” of a system. All of these things push us very forcefully towards building too much. You should fight this. You learn so much as you’re building a system that you will end up iterating into a much better system than you ever could have designed in the first place. This is surprisingly a hard sell to most people

The Generative AI Revolution Has Begun—how Did We Get Here?, Haomiao Huang, 2023

• There’s a holy trinity in machine learning: models, data, and compute.

Culture by Poster, Simon Cross, 2023

• 4: “It isn’t prioritisation until it hurts”
• We thought we were measuring progress: # of events run, # of attendees — but we were actually just measuring motion - things we thought were important, but didn’t have any clear connection to business outcomes.
• B/ “Break Things” Some people have read this as “cause disruption without thought for the consequences” - but to me this means something more subtle: have a healthy disrespect for the status quo, and a willingness to question why things are they way they are.
• 1: “Done is better than perfect” This is about two things: A) improvement through iteration and B) opportunity cost.
• 2: “Don’t mistake motion for progress”
• Now, this increase in speed wasn’t accidental - it was intentful, It took WORK. A lot of work. And created risk — potentially making it more likely for a bug to takedown one of the worlds largest communication platforms on whom billions of people relied.
• Things to think about: Stack rank: As a team, ask yourself the question: if we could only do ONE of these two things, which would we do? Sequencing: If you have two things that are clearly important — ask yourself, is one more urgent than the other? If feature A is as valuable if built next half as it is this half, but feature B is more valuable if built now, then build B before A. Remember (and say to yourself and your team!) that just because we’re down-pri’ing thing X, doesn’t mean it’s not important and we’ll never do it — it’s just less important RIGHT NOW — it may well be the most important thing next planning cycle. One in, one out: When someone asks for “just one more thing” in the roadmap: ask them: which of these other features would they’d like you to drop? If they can’t identify one, you’ve already done your job well.
• But this isn’t where you should be spending your time — you need to be up the other end of the roadmap looking at your P1’s. If you only de-pri the easy stuff, you’ll end up with many high-pri things to do — each of which looks important and urgent — because because you’ve not had the hard, frank conversations required to really really tease out what matters most.
• This tradition started, the story goes, when the company approached 150 employees (Dunbar’s number). A designer, Ben Barry, realised that as the company grew, it would be harder to infect new joiners with the principles and tenets that the first employees organically shared. A screen-printing enthusiast, he made up some posters and stuck them around the office
• Sean Byrnes has written about this eloquently and persuasively. He offers a simple framework: Activities that are internal to the business are motion. These include: Implementing new tools; Implementing new processes; Building a new report; Attending regular meetings. Activities that affect your position in the market are progress. These include: Adding new customers; Improving customer satisfaction; Making money; Hiring new people; Layoffs. “What was the impact?” is the single most powerful question in management. If you (or the person your questioning) can’t immediately explain the business impact — or how this thing clearly moves us toward creating business impact (progress): you have a problem

How to Pay Down Your Monitoring Debt, Paige Cruz, 2023

• There are one or two people on your team that refine alerts, or it’s exclusively the job of site reliability engineers (SREs).
• Updating or checking monitor accuracy is not a part of your deployment process.
• Alert configuration is not cleanly ordered or hierarchically namespaced.

Taking the Initial Phone Screen With Candidates, davidgomes.com, 2023

• In fact, the goal with the first call is that they’ll ask the majority of the questions (and I let them know about this so that they’re not as shy about it).
• That’s really it. And of course, we’ll always end up talking about what they’re looking for and their motivations. Candidates will typically ask about team processes, the company’s outlook, salary ranges, and whatever else.
• The main goal is setting the stage for candidates: What do we do here? How do we work? What will the rest of the interview process look like? What questions do you have for me

Technical Debt Can Investing in It Unlock 2x Team Impact?, Fergus Doyle, 2023

• If we’re going to affect meaningful change, we’re going to need more visibility on the problem than just an umbrella term. Be specific on the problems you’re trying to solve and shape the solutions in the same way you would a product opportunity
• Many teams have a dedicated swimlane for technical projects with an agreed percentage of overall team capacity. This can be a great way to maintain a healthy codebase however limits the team’s ability to deliver larger technology initiatives as they end up being squeezed into this secondary swimlane.
• Step 3: Return on Investment
• Step 1: Stop calling it technical debt
• Example 2: Developer Experience Implementing styleguides / code formatting takes 30 hours from across an 8 person team and will save 15 mins/engineer/day: Investment: 30 hours Outcome: 4% more team bandwidth - 80 hours time saved per month (15 mins * 8 people * 20 days) ROI: 7.5 days Low hanging fruit and probably worth doing! However, it’s probably unlikely that there are 12 more initiatives that deliver the same return
• Step 2: Focus on the outcomes What are you trying to achieve and how will you know when you’ve got there? For example, you might be looking at outcomes like the following: “Enable the team to release software 5x faster through investments in our CI/CD pipelines”

The Real Value of Middle Managers, Zahira Jaser, 2023

• In my 20 years of being one and then researching them, however, I have developed great respect for middle managers. They are the engine of the business, the cogs that make things work, the glue that keeps companies together. Especially as remote and hybrid work takes over — and the distance between employees increases — middle managers are more important than ever.

The Feature Work → Maintenance Work Loop, daverupert.com, 2023

• Apple used this loop a bit with OS X releases where Leopard was the feature release and Snow Leopard was the maintenance release. It had an interesting user effect where I was happy one year with new shiny toys and I was happy the next year when all the apps on my computer got better

Focus, boz.com, 2023

• The best time to stop a distraction is before it starts. The second best time is now.

Tech Lead Management Roles Are a Trap., lethain.com, 2023

• The reality is that when you’re trying to learn something brand new, like team management in this case, you’re almost always going to be better off getting to focus on that area.
• In a team management role, you’ll be encouraged to lean on your team for technical leadership rather than fulfilling both roles.
• Folks attempting to fulfill both often retreat towards work they find familiar, which typically results in tech lead managers who forget to perform the management part.
• Another problem with the split focus is that the tech lead manager role is a bit of a dead end. Down the managerial path, the evolutionary step is towards group management. Down the technical path, the evolutionary step is towards staff engineer. Splitting your time across both functions isn’t ideal for pursuing either path, and unfortunately it’s the rare role and organization that supports ongoing growth for folks in tech lead manager roles. They do exist, but they tend to be a bit specialized, for example working on infrastructure efficiency, performance engineering, or applied machine learning

My Fifth Year as a Bootstrapped Founder, Michael Lynch, 2023

• I aim for everyone at TinyPilot to run at around 50% capacity. That is, a balance of 50% reactive work and 50% proactive work. For some roles, the balance isn’t quite 50/50, but it’s a good rule of thumb.
• The technical support team is the clearest example of a 50/50 split: they spend half of their time responding to support requests and the other half finding ways to save users from needing support. The proactive tasks include fixing bugs in the product, writing documentation, and improving our diagnostic tools.

Inspiration Is Perishable, world.hey.com, 2023

• We all have ideas. Ideas are immortal. They last forever.  What doesn’t last forever is inspiration. Inspiration is like fresh fruit or milk: It has an expiration date.

AI‘s Instagram Problem Someone Else’s Cool AI Project Doesn't Make Your Project Less Valuable., deeplearning.ai, 2023

• Judge your projects according to your own standard, and don’t let the shiny objects make you doubt the worth of your work!
• After all, think about how all the LLM researchers must have felt a few years ago, when everyone was buzzing about RL.

How I Give Formal Written Feedback, quad, 2023

• Of the intended recipient, I ask what they want “Is there anything in particular you'd like feedback on?”
• From that, I write my feedback, kindly and directly addressing their prompt with concrete examples
• I show what I’ve written “Here's what I got! [link to a doc]”
• I ask them to review it, looking for context and corrections “Am I missing or should I add something? Am I off-base? Anything I should remove? Anywhere I can be more clear?”
• I only share what we agree upon
• for their feedback on drafts of this!)

People Can Read Their Manager's Mind, yosefk.com, 2023

• People generally don't do what they're told, but what they expect to be rewarded for. Managers often say they'll reward something – perhaps they even believe it. But then they proceed to reward different things.
• think people are fairly good at predicting this discrepancy. The more productive they are, the better they tend to be at predicting it. Consequently, management's stated goals will tend to go unfulfilled whenever deep down, management doesn't value the sort of work that goes into achieving these goals.
• A manager enjoys "software architecture", design patterns, and language lawyer type of knowledge. The manager requests to cooperate better with neighboring teams who are upset by missing functionality in the beautifully architected software. People will tend to keep designing more patterns into the program.
• A manager truly appreciates original mathematical ideas. The manager requests to rid the code of crash-causing bugs, because customers resent crashes. The most confident people ignore him and spend time coming up with original math. The less confident people spend time chasing bugs, are upset by the lack of recognition, and eventually leave for greener pastures. At any given moment, the code base is ridden by crash-causing bugs.

Why Backlogs Are Harmful, Why They Never Shrink, and What to Do Instead, lucasfcosta.com, 2023

• Backlogs never shrink because the list of things we’d eventually like to do never shrinks, and that’s what a backlog is: a bunch of unimportant tasks that we’ll eventually get to, but not today
• Important tasks never go into the backlog. We create them, we work on them, and we ship them. Don’t believe me? Ask your product manager when was the last time they had to take something out of the backlog because they ran out of things to do. I’m sure the answer will be a resounding “never”.
• Backlogs exist because they’re a great way to avoid difficult conversations and shift blame away from product to engineering.
• In reality, a product manager’s job is not to create as many tickets as possible but to delete as many as they can and avoid unnecessary work at all costs.
• In other words, a product manager’s job is to prioritize ruthlessly, and maintaining a long backlog is anything but good prioritization.
• Additionally, a backlog is a great way for all blame to fall upon engineering. As long as there is enough work, it’s engineering’s fault for not getting it done sooner.
• If backlogs are bad, what should I do instead? Do not maintain a backlog unless it’s the backlog for your next few weeks of work.

Supercharge Your Engineering Work Through Marketing, zeptonaut.com, 2023

• Boom! That’s marketing. (Specifically, this “provide-utility-without-clicking-link” technique is often called “zero click marketing”.) You identified your target audience, what they’re trying to achieve, what value you can offer, and how you can show that value immediately. That’s extremely targeted and I would frankly be shocked if you didn’t get a subscriber out of that – your marketing efforts made it through the Death Star exhaust port.
• Who are you trying to make aware of your work? Where do those people gather? What are the norms about acceptable ways to communicate in that gathering place? What do you want them to know about your work? What is your target audience trying to achieve? Why should they care? How can you demonstrate value immediately? Where’s the overlap
• Unfortunately, while your newsletter may rock, your marketing skills still need improving: people want to open threads that bring them value, not threads that bring you subscribers
• ush hard in the opposite direction: I’ve set up Zapier to send me a text message every time my blog gets a new subscriber and it genuinely thrills me. Whatever a “sale” means for your thing - a new subscriber, a new demo request, a view of your presentation - I’d encourage you to find creative ways to amplify the feeling of that win

Simple, Modern JavaScript, vue-mjs.web-templates.io, 2023

• This template focuses on simplicity and eschews many aspects that has complicated modern JavaScript development, specifically: No npm node_modules or build tools No client side routing No heavy client state

How to Succeed as a CTO, Part 1, South Park Commons, 2023

• Focus On Builders, Not Managers If you are managing your hiring funnel and selecting for strong cultural fit, you will quickly find yourself facing a new question: how far can you go without a formal engineering management layer? The surprising answer is pretty damn far, which means your hiring should for a while focus overwhelmingly on the people shipping product.
• In my experience, you can have roughly 30-35 engineers without formal management. You will likely want some Tech Leads before then but that is way simpler than a management layer.
• Too many culture/fit interviews boil down to: Do I want to hang out with this person? A more thoughtful (yet simple) methodology: In every interview, ask yourself whether you got positive/negative/non signal about a company value. How does that work in practice?

The Case for Frameworks, seldo.com, 2023

• Alex makes the astonishing assertion that "vanishingly few scaled sites feature long sessions and login-gated content".

How to Create More Collisions in Remote Working Environments, Wissam Abirached, 2023

• A habit that I’ve recently adopted is writing weekly team snippets every Friday. These snippets tend to be highly informal and don’t take longer than 20 minutes to write, but I have received great feedback from the team on the value they add. Typically, these snippets will include:
• The easiest and lowest friction way of doing so is to allocate the first five to 10 minutes of a team meeting for non-work conversations and keeping it open-ended. Let folks chat through whatever is on their mind, whether it’s their weekend plans, their kid’s hockey game, or the new video game that they’re excited about. This is the real-life equivalent of folks getting to a conference room a little earlier and chit-chatting until the meeting begins. Remember that leaders have to be intentional about creating these moments in a remote environment.

23. Noise Factors vs. Control Factors, world.hey.com, 2023

• If we treat everything across this interdependence as a control factor — meaning all of it is in scope — that leads down the path of growing the scope to include fixing or replacing the PDF tooling
• The alternative is straight from Bob’s quote: to treat the interdependence as a noise factor. That means breaking the chain by deciding that the PDF generation isn’t going to change as part of this project.
• But remember that wasn’t the end of the quote. The next part is “…and designing around it.” If changing the PDF tooling is off limits — for this project, in this time window — what are our options? The first option is to just leave out the notice on the PDF, which leads to an inconsistency between the PDF and other views of the invoice. Someone may catch that in the future, file it as a bug, and now we’ve created future work we don’t want. Another option is to drop the notice entirely from all displays of the invoice, so the PDF remains consistent. This might be fine, but perhaps the designer had a good reason for wanting the notice
• If we treat everything across this interdependence as a control factor — meaning all of it is in scope — that leads down the path of growing the scope to include fixing or replacing the PDF tooling. That means delaying the project, piling up unfinished work, and so on. (This kind of power-through-it response is more common than you might expect!) The alternative is straight from Bob’s quote: to treat the interdependence as a noise factor. That means breaking the chain by deciding that the PDF generation isn’t going to change as part of this project. But remember that wasn’t the end of the quote. The next part is “…and designing around it.” If changing the PDF tooling is off limits — for this project, in this time window — what are our options? The first option is to just leave out the notice on the PDF, which leads to an inconsistency between the PDF and other views of the invoice. Someone may catch that in the future, file it as a bug, and now we’ve created future work we don’t want. Another option is to drop the notice entirely from all displays of the invoice, so the PDF remains consistent. This might be fine, but perhaps the designer had a good reason for wanting the notice? Simply dropping a requirement because it’s hard can accumulate as low UX quality over time.
• If we treat everything across this interdependence as a control factor — meaning all of it is in scope — that leads down the path of growing the scope to include fixing or replacing the PDF tooling Very often, there’s a third way. In this case, the team can declare the invoice template in all its forms to be a noise factor. At the same time, they could decide that the email where the invoice is delivered is now a control factor. They could redesign the solution slightly by mentioning in the text of the email that this is a recurring invoice, above where the existing invoice template is rendered. This is what designing around the noise factor means — taking the noise factor as a constraint, stepping back, questioning assumptions, and finding a new design that still meets the overall goals with the control factors.
• In this example, deciding the PDF tooling is a noise factor actually opens up that work for parallelization. The PDF tooling and the recurring invoices become independent efforts, that can be worked on by different people at different times. The invoice team doesn’t have to wait to deploy their new functionality, and meanwhile — or in the future — another team can replace what happens behind the PDF generation API to use better tooling

The Age of AI Has Begun, Bill Gates, 2023

• Company-wide agents will empower employees in new ways. An agent that understands a particular company will be available for its employees to consult directly and should be part of every meeting so it can answer questions. It can be told to be passive or encouraged to speak up if it has some insight. It will need access to the sales, support, finance, product schedules, and text related to the company. It should read news related to the industry the company is in. I believe that the result will be that employees will become more productive.

The 10 Principles of Product Discovery, Martin Spinnangr, 2023

• For a product to be successful, it needs a well-driven business around it. So start thinking about the business model and validate the assumptions concerning its nine building blocks:
• Prioritize your assumptionsThe goal is not to run tests, but to make progress by answering key questions and reducing risk. In other words, the purpose is to de-risk the new product initiative to a level where one can comfortably decide whether to keep investing in it.
• Gradually increase the toughness of the testsThe evidence’s quality depends on the test type and the number of data points. More robust tests typically yield higher-quality evidence. Therefore, you may want to jump straight into a large-scale test. But, robust tests usually require more time and investments to carry out. Instead, you want to start small to get early signals of being on the right track or do rapid course corrections if learning otherwise. So, start small and iterate towards “(…) bigger, more reliable, more sound tests, only after each previous round provides an indicator that continuing to invest is worth the effort.” Teresa Torres.
• Reduce the risk as much as possible before building anything
• Making both top-down and bottom-up estimations of TAM (total available market), SAM (serviceable available market), and TM (target market) is a good start. 100% accuracy is not the point, instead, use these estimations as a quick sanity check and decide whether to move forward.

Policy on Util Packages, brandur.org, 2023

• We’ve come to a compromise of sorts, with two simple rules: A general util package is not allowed. Individual util packages targeted around specific, well-defined concepts are allowed. They’re suffixed with *util like emailutil or randutil.

How Processes Are Born, Why They Can Be Damaging, and How to Fix Them, lucasfcosta.com, 2023

• Every process you see in a company is a little reminder of someone’s mistake. Somebody messed up, and their boss was like, “hey, we gotta make sure this doesn’t happen again!”. And that’s how the process was born.
• In cultures that are afraid of failure, heavy-weight processes are inevitable. It’s a never-ending cycle. As soon as one failure gets addressed, another one is bound to happen sooner or later, and a new process will have to be put in place.
• Also, it’s not just the processes themselves that are problematic; it’s the culture they create. Suddenly, everyone’s afraid to take risks or try new things because they’re scared of breaking some arbitrary rule or getting in trouble for not following the “correct” process.
• There are only two ways to deal with failure, none of which involves creating a new process. You either make systems that can handle failure, or you ensure that the chances of failure are zero.
• Think about a team that’s slow and unpredictable, for example. In that case, try limiting the team’s “WIP” instead of opening up whatever flowchart software you have and trying to design a brand-new complex process
• That approach, creating small constraints, is easier for humans to follow and doesn’t instill a bureaucratic culture into the team.
• Finally, if you already have too many processes, revise them all. Tell people to be candid and ask them which processes they think you should discontinue. Use your good judgement to pick which ones to throw in the bin.
• Finally, if you already have too many processes, revise them all. Tell people to be candid and ask them which processes they think you should discontinue. Use your good judgement to pick which ones to throw in the bin.

Just the Two of Us, world.hey.com, 2023

• At 37signals, both Basecamp and HEY are built by multiple teams of two using our Shape Up process. No feature takes more than 6 weeks to build, and each feature is assigned a maximum of two people: one designer and one programmer. And in more than a few cases, it may just be one person
• How can we build so much software in such a short amount of time with tiny teams of two? That's how. If it takes more than two people, it can't. We won't let it. We'll clear it up, simplify it down, make more tradeoffs, find more elegance.
• Want to do more than two people can do? Add another two person team to to the mix on something else. That's what you do. Don't add them to what you're doing, add them to something you aren't.
• Direct communication, no meetings, no catching any one up about the stuff they missed, nothing to filter down or sift through — it's all right there when it's just two. Get two it.

Throwing an Exception 3 Types of Decision and What to Do in Each Case., Simon Cross, 2023

• Great organisations are really, really good at quickly making good decisions that stick, unblocking progress and enabling teams to move fast. The benefits are non-linear, they compound.
• TL;DR: Decisions you know you can make → communicate. Decisions you know you can’t make → escalate. Decisions you’re not sure you can take → give leaders an opportunity to “throw an exception”.
• In this case, I advise my teams to make the decision, but give leadership the opportunity to “throw an exception”. “Throw an exception” is a term from software engineering. You run some code, but if there’s a problem, the code “throws an exception”; it stops running and triggers something else to happen instead. Here’s what you do: Document the decision as you would in #1 or #2 (what’s the problem, what are the options, what are the tradeoffs). State your “recommendation” — the option you want to go with. Email this to your leadership team (include a traffic light!) Tell them you’ll move forward with this decision unless you hear otherwise in some time period (typically 48 hours). If you don’t hear back, the decision is made. If you do hear back, you can go into “escalate” mode.

What I Learned at Stripe | steinkamp.us, steinkamp.us, 2023

• It’s not uncommon for a project to begin with writing (but not sending!) the Shipped email, serving as a north star for understanding the scope and goals of a project.
• The Atlas team does track date estimations, but those dates are always accompanied with a confidence level in that date.
• Friction logs When I started in the team, my first task was to “friction log” Stripe Atlas. This means I was to select an end-user persona (bonus points from the team for something cute or funny), and go through the Atlas product flow as that user, taking very detailed notes along the way of anything that was not perfect
• One big CICD risk-mitigating tool in Stripe’s toolkit is a very well engineered feature flag system. This allows the team to deploy entirely new features or product flows, but to only expose that new code to specific test accounts. The downside is that there is more complexity in running old and new code paths, but it is offset by a clear confidence in the operation of the new code in the production environment.

Actions Beat Arguments, world.hey.com, 2023

• if you wish to be persuasive, you ought to spend less time arguing and more time doing. This is as it should be
• This is why we listen more to those who do than those who merely opine.

The Simplest Thing That Could Possibly Work, world.hey.com, 2023

• I'm seeing that in action now as we're working on a new product, and marveling at how quickly we've gone from concept to code. Yet it always seems to be a struggle to stick with this intent. Like human nature is primed to dwell on all potentialities vs the activating the instinct for action. So the mottos help
• your eyes will be trained to look for the simplest thing that could possibly work.

The Effective Decision, Peter F. Drucker, 2023

• ffective executives know when a decision has to be based on principle and when it should be made pragmatically, on the merits of the case. They know the trickiest decision is that between the right and the wrong compromise, and they have learned to tell one from the other. They know that the most time-consuming step in the process is not making the decision but putting it into effect. Unless a decision has degenerated into work, it is not a decision; it is at best a good intention. This means that, while the effective decision itself is based on the highest level of conceptual understanding, the action commitment should be as close as possible to the capacities of the people who have to carry it out. Above all, effective executives know that decision making has its own systematic process and its own clearly defined elements.

Understanding People Matters More Than Understanding Tech, mooreds, 2023

• Because software requires personal knowledge and creativity to both find the right problem and to solve it, people are foundational to project success.
• If there was only one piece of advice that I wish I had known early in my career as a software dev is that understanding people is more important than understanding tech, by a long shot.

Designing the Ideal Bootstrapped Business, Michael Lynch, 2023

• Better target: 150 customers You should have 20-30 customers waiting to pay you monthly before you even start building. If you can’t find 20-30 in the first few months, it’s going to be hard to reach a sustainable customer base ever. First 50: Scratching and clawing your first customers Next 25: Guest postings, social media Next 75: Basic marketing
• Present yourself to customers as “boutique.” Customers will tolerate higher prices if they think of it as supporting an independent boutique vendor.
• Only build B2B companies
• One-off sales never get easier.
• High prices, but lots of coupon opportunities Example: Standard rate is $99/mo, but give bloggers a 30% off coupon for their readers.
• Good Market: Aftermarkets 🔗︎ Find an established product with a significant following, and build add-ons or integrations. Examples Smart Bear: Added code review to Perforce and Subversion Balsamiq: Started as add-ons to Basecamp WooThemes: Themes for WooCommerce AlienSkin: Paid plugins for Photoshop QODBC: Makes ODBC interface for QuickBooks, allows customers to make database queries against it

Running Your Engineering Onboarding Program., lethain.com, 2023

• Curriculum Once you’ve identified the orchestrator for your onboarding program, there’s still the matter of deciding on your curriculum–what should you actually focus on teaching? As an initial point to experiment from, I’d recommend three segments: Engineering values and strategy Technical architecture Spinning up the development environment
• Once you have those three overview courses, work the problem from two angles: Survey new hires a month after onboarding to ask what they wish had been covered Survey manager and tech leads about areas where new hires are struggling. These might be technical, but is even more likely to be cultural

How to Have Buckets of Time, world.hey.com, 2023

• One of the most important techniques I've embraced for managing my time is to direct related tasks to a bucket, let that bucket accumulate until full, then empty it all in one go.
• This is an intentional and sequential way to live and work. Too many people delude themselves into thinking they can parallelize a million things at once, but they can't. Multitasking is a mirage. Humans run single-core CPUs. All they can do is swap context in and out, losing ever more to switching costs as they do.
• There's enough time. Time isn't the scarce resource, attention is. Find your buckets, develop the patience to let them fill, then empty them one at the time. There's your 10x productivity hack.

Slack, Martin Fowler, 2023

• a range: say from 15 to 22. In this situation the team can plan at their lowest consistent number (15) and treat the additional time as slack.
• One benefit of this approach is that it reduces the variability of story completion. Rather than wondering if this iteration will complete those last five of a 20 story allocation, we can expect 15 with high confidence. For planning and coordination, higher confidence is often worth more than trying to maximize throughput
• But doing more stories is often not the most productive thing to do. Most teams are slowed by factors in their working environment. There may be inefficiencies in the build process, cruft in the code base, or unfamiliarity with productivity tools (most people have all sorts of undiscovered gems in their IDEs). Spending the slack time on these can make a big difference by increasing productivity in future interactions. Indeed the most common productivity problem teams face is due to a congested schedule that allows these impediments to fester.
• While I've described slack here in terms of Timeboxed Iterations it is also important to Continuous Flow. The smell here is if a continuous flow team is always busy - that indicates not enough slack, which will make them slower to respond to requests and unable to look after their working environment.
• While slack is both important and often undervalued, it's a seasoning not the main dish. A schedule that's all slack gives up visibility and longer-term planning. But to run without it is like skimping on your oil changes

ContinuousFlow, Martin Fowler, 2023

• Continuous flow is an alternative to Timeboxed Iterations, with the advantage that the team doesn't need to go through an exercise of allocating stories to iterations, estimating stories, or figuring out the iteration capacity
• However such teams often run into difficulties because the regular cadence of iterations provide a feedback loop that helps a team spot problems such as cruft building up in the code base. Consequently less experienced teams are better off with iterations.

The Future of Applications, mikecann.co.uk, 2023

• I think about the future of programming more as sculpting. You start off with a blank slate then using your own words you command by command iterate towards your end goal.

How to Do Hard Things, Casey Rosengren, 2023

• Here is a list of the 6 core processes that we'll explore in-depth below: Experiential Avoidance → Willingness Fusion → Defusion Past/Future → Present-Moment Awareness Rigid Stories → Flexible Perspective-Taking Lack of Direction → Clear Values Inaction → Committed Action

Rescuing a Project in Progress, world.hey.com, 2023

• Stop everything. Take status of everything. Where does each project stand in terms of size, scope, completion, and unknowns. Pick a smaller project that's almost done, andredirect all resources to finishing that one up before working on anything else. Get something finished. Establish "completion discipline". Only move on to the next project once the current project is 100% done. Do not add to the pile. No more new projects

Why Are Developers Expected to Estimate Tasks at All?, Reset to, 2023

• That's what agile frameworks address: the inaccuracy of estimates that aren't based on small, estimable, and sustainable batches that can be successfully delivered at a predictable cadence. There are even people who advocate for flow and cadence as the estimation tool (using the poorly-named #noestimates hashtag on Twitter), but there must still be bounding boxes around any project that has constraints.

Delegating Projects, Not Tasks, world.hey.com, 2023

• Projects start with a name, the people involved, and, typically, a kickoff message describing the project in a few hundred words.
• project may start with a small handful of tasks on day one, two, or three. Work is added as the project progresses, as more discoveries about the work are made. Things make the list as they need to, not in anticipation of being needed. No one defines all the work up front. That's a fools errand
• They're on the ground, they know best. But there's no one outside the project making to-dos for them, assigning them work, or otherwise telling them what to d

The Lone Developer Problem, Evan Hahn, 2023

• When this happens, I’ve observed that code written by a single developer is usually hard for others to work with. This code must’ve made sense to the author, who I think is very smart, but it doesn’t make any sense to me!

Fast-Forwarding Decision Making, James Stanier, 2023

• All organisations waste a huge amount of time believing that they are making progress on decisions, when in fact they’re just involved in the theatre of decision making.
• You enumerate the approaches in the message and highlight that you think that the second option is the most reasonable. You also say that you’ve reserved a meeting slot in the future if it needs some further debate. However, within 24 hours, all of the people in the group have replied asynchronously to say that they agree that the second option is the most viable, and they’re supportive of your team putting a prototype together. The meeting isn’t needed, and it gets cancelled. You then start building the prototype.
• I’ll pitch the takeaway up front, and it’s this: hold yourself accountable for making decisions and progressing discussions as quickly as possible, by whatever means necessary. Be restless while a decision hasn’t been made. Dead time is your enemy. Be creative about ways of shaving minutes, hours and days from a decision point.
• Letting free calendar slots decide your timeline

90% of My Skills Are Now Worth $0, Kent Beck, 2023

• First, I do not have the answer for which skills are in the 90% & which are in the 10%. (I’ll tell you why I concluded that split in a second.) We are back in Explore territory in 3X: Explore/Expand/Extract terms. The only way to find out is to try a little bit of a lot of ideas
• Anyone who knows to ask (and there is a hint about the remaining 10%) could get the same results.

I Left My Previous Job to Work on Nzyme Full Time, Lennart Koopmann, 2023

• An expectation of growing revenue by 100% or 200% yearly will make you chase one unfinished feature after another. There is never time to finish anything, and the last mile, the essential details, are left out in the never-ending pursuit of new functionality. This pressure leads to shortcuts, a bad user experience, and a bad time for everyone involved, including the user.
• If everyone involved is on board with slower but sustainable growth, you can build software that people will love and continue to use. Additionally, you, as the author, will probably enjoy your work more again.
• Deciding to delay without fear or pressure is possible in a sustainable growth environment.
• We don’t have this yet, but it’s on the roadmap and will be released in July!”. This is another form of debt. This often happens under the veil of product planning. Development teams, however, rarely need to work with exact plans for so many months ahead.
• For that reason, nzyme is publishing priorities instead of a roadmap. Users should base their decision to use nzyme on the current state of it instead of future changes.

The Age of Cargo Cult Agile Must End., Ron Jeffries, 2023

• 4 variables: Cost, Time, Quality, Scope BUT we recommend you flex Scope and fix the restAnother way of saying this from Basecamp’s Getting Real is “Build half a product, not a half-ass product”.
• Iterations were originally 3 weeks, then more often 2 weeks, than 1 week, but now Extreme Programming teams are more likely to be doing Continuous Delivery. Iterations are a delivery construct.

Efficiency Trades Off Against Resiliency, Nelson Elhage, 2023

• Small teams – including “teams” of one person – can be incredibly productive and efficient. The smaller the team, the less communication overhead, and the easier it is to keep rich shared context inside every engineer’s head.
• Small teams can get much further using strategies like “think carefully and try hard” than large teams, and often need to rely less on tooling like linters and careful defensive abstraction design.
• Systems with healthy amounts of slack will – at least in the short term, on a simplistic analysis – by definition be inefficient: That slack is time or resources which are going “idle” and which could instead be producing output. Taking a broader view, though, that slack is key to resiliency: having “give” in the system lets the system cope with small disruptions or mishaps; developers or operators can use that slack to step in and handle unexpected load or resolve underlying issues before they become catastrophic or externally visible.

Give It the Craigslist Test, ericaheinz.com, 2023

• Low-fidelity (shown in my UX sketching kit image above) means: NO: styling, photographs, illustrations, colors, or fonts (besides a default one) YES: real text (not lorem ipsum), symbolic images, and symbolic UI
• Focus on content and functionality when you’re designing new products; that’s the validation that will build a business.

Keep the Monolith, but Split the Workloads, Learn, 2023

• Rule 1: Never mix workloads First, we should apply the cardinal rule of running monoliths, which is: never mix your workloads. For our incident.io app, we have three key workloads: Web servers that handle incoming requests. Pub/Sub subscribers that process async work. Cron jobs that fire on a schedule.

Some Mistakes I Made as a New Manager, benkuhn.net, 2023

• The first thing I noticed about being a manager was that I wasn’t sure whether anything I was doing was useful. As an engineer, I had a fast feedback loop—I could design something, code it, test it, show it to coworkers, ship it and see users happily using it all within a day or two. Managing doesn’t have that kind of feedback.
• Gradually, over my first year, I built up better self-evaluation instincts. Today, if I give someone advice, I can usually guess right away whether it’s useful—not perfectly, of course, but well enough that I can feel good about my day-to-day output.

New to Public Speaking? Two Bits of Advice That'll Help You Succeed., Simon Cross, 2023

• Everyone in the room wants you to succeed.
• You know more about your subject than anyone else in the room.

How to Design Software Architecture for Startups, appventuretime.blog, 2023

• Systems that talk a lot to each other - and only synchronously - should not be separated at first, even if their domains suggest it
• The most valuable lesson that we learned over the years is that you have to move fast. This applies especially to the early stages of product development. You will almost certainly be wrong about how exactly your product and its features will be received by users. Few ideas will actually end up being successful, at least at first.
• Microservices usually don't work well for startups
• Move fast and outsource things
• Consider building reusable things
• Boundaries along sync/async communication patterns

The Leverage of LLMs for Individuals, mazzzystar.github.io, 2023

• Whenever I have a new idea, I ask GPT-4 to write the most basic version, I provide feedback, it apologizes, and we iterate until we reach the 1.0 version I have in mind. I use up my GPT-4 quota (25 entries/3 hours) multiple times a day.
• Copying and pasting documentation and APIs to GPT-4, asking it to write interfaces based on them. Current documentation is written for human reading, with a mix of text and code blocks that makes copying a poor experience. Perhaps soon, documentation and APIs will become GPT-friendly first.
• Translation and product localization. Even in the age of DeepL, longer sentences can still reveal machine translation traces. However, based on my experience, the translation capability of GPT(whether 3.5 or 4) is far surpasses DeepL. I can localize my products into dozens of other languages at once.
• If you are an individual developer, the leverage it provides might be 10 times greater, but when you work for a company, that number might be only 2. So, even knowing the current economic downturn and wave of layoffs, for those who want to achieve ideas and create, I still want to express this bold opinion: Staying in any company right now is a negative return; you are wasting personal leverage.

Context Switching Is the Enemy of Productivity, Here's How to Avoid It., Mono tab, 2023

• Mono tab
• Single monitor

Deadlines as Technology, Jim Nielsen, 2023

• The only technology that you need is deadlines.
• Deadlines are huge, but really what are deadlines? They’re opportunities to fail. That’s all they are. They’re actually opportunities to learn, to fail. Hopefully not fail catastrophically, but it’s an incredible data gathering moment.

Notes Apps Are Where Ideas Go to Die. And That’s Good., Matthew Guay, 2023

• We don’t write things down to remember them. We write them down to forget.
• By letting go, you’ve cleared up space for new quests. No more dozens of tabs open forever; you saved them, then let them go back into the ether. No perpetual thinking on an idea; you wrote it down, let your second brain remember for you. Then we’re free.
• We need to forget, but we first must feel safe forgetting.

unixtime.app Goes Open Source Now Available for Free!, Blog on Klaus Breyer > CTO writing about Code, Business, Product & Engineering Orgs., 2023

• d to make the best of the si
• hout any cost.
• stores, it did not generate enough revenue to cover the cost of the Apple D

Time to Upgrade Your Monitor, tonsky.me, 2023

• Now, it might be tempting to use, for example, 1.5× scaling. That would give you an equivalent of 2560×1440 logical pixels, which, you might think, is much better. This is not how you should use it! The idea of a 4k monitor is NOT to get more pixels but to get the pixel-perfect, high-density UI rendering. Otherwise, a normal 1440p display would work better. A simple rule to remember: *pixel alignment outweighs everything else*. 1440p display is better at displaying 1440p content than 2160p display is at it

Maybe Just Use Rails, zeptonaut, 2023

• • How are you planning to store files locally during development? • How are you planning to send emails in production? • How are you planning to test email sends locally during development? • How are you planning to run jobs that need to happen at a specific time (e.g. a monthly billing job)? • How are you planning to run background jobs that need to happen off of the main web server thread? • What payment processor are you planning to use? • Do you need a library to integrate with that payment processor? • How do you plan to mock that payment processor for local testing and continuous integration?
• • How are you planning to handle authentication in production? • If you plan to use a third-party authentication provider in production (e.g. Auth0), are you planning to use that same authentication provider locally and in CI? • What are you planning to handle authorization (i.e. determining who can do what within your app and enforcing that)? • How will database schema migrations happen when schema changes occur? • How will data migrations happen when schema changes occur? • When your new code is
• The questions 1. What ORM are you planning to use to interact with your database? 2. What method of data exchange (e.g. REST, GraphQL) are you using to communicate between your frontend and backend? 3. If you’re planning to use GraphQL, how do you plan to address the N+1 query problem? 4. What library are you planning to use to translate your ORM records into your data exchange layer? How well maintained is that library? 5. How are you planning to store files in production?
• • deployed to a new environment (staging, production), how will you run those migrations automatically? • How do you check whether records in the database conform to business-logic constraints that can’t be modeled as database constraints? • How do you insert seed data for testing changes locally? • How do you write code for one-off tasks that need to be manually executed? • How do you validate new records being saved to your database? • How the heck are you planning to test all of this? • What hosting providers are you planning on using?

Scripting With Go A 400-Line Git Client That Can Create a Repo and Push Itself to GitHub, Ben Hoyt's technical writing, 2023

• Now that Go has generics you can easily define a `check` function which returns a result.
• However, for anything more than a throwaway script, I’d quickly move to Go. Its standard library is better-designed, its `io.Reader` and `io.Writer` interfaces are excellent, and its lightweight static typing helps catch bugs without getting in the way.
• However, for anything more than a throwaway script, I’d quickly move to Go. Its standard library is better-designed, its `io.Reader` and `io.Writer` interfaces are excellent, and its lightweight static typing helps catch bugs without getting in the way.
• When used with `panic`-based error handling, Go is good for writing quick ’n’ dirty command line scripts.

My Journey Away From the JAMstack, Jared White, 2023

• JAMstack. I had intuitively understood that the exciting promise of JAM was in a sense the reverse acronym of MAJ: Markup, *then* APIs, *then* JavaScript.
• In other words, build as much as you can with static HTML (via templates, Markdown, etc.), *then* identify what you might need for some dynamic server interactions—which maybe you’d just write yourself as a Rails app or whatever—*then* write only the JavaScript you absolutely need to access those APIs (understanding that maybe certain dynamic pages would just get fetched directly from the server if need be).
• In other words, **progressive enhancement**.

11 Ways to Shave a Yak, Taylor Troesh, 2023

• Simple, central queues explode in obvious ways; yaks have few places to hide in transparent processes
• Clever systems produce clever problems.

The Code Review Pyramid, morling.dev, 2023

• Code Review Pyramid

Using Metrics to Measure Individual Developer Performance, Laura Tacho, 2023

• You’ll help your team in designing the system architecture for large scale applications.
• You’ll help with the running and maintenance of your team's applications in production.
• • *Communication and collaboration*, measured by feedback from the engineering team as well as cross-functional partners.
• *Quality of junior team members’ outcomes*, measured by quality of software as outlined above, but filtering by projects where this person played a large role in mentoring and guiding junior team members
• You’ll support and mentor junior team members, helping them create well thought out and robust solutions.
• *Leadership and participation in retros, post-mortems, and other continuous improvement processes*, measured by instances of participation.
• *Participation in architecture decisions*, with consideration for the number of decisions with direct responsibility. This would be a sum measurement, where I just count the number of times it happened.
• *Quality and reliability*, measured by incident, bugs, or even customer support ticket volume.
• Project on-time delivery
• • *Operational stability*, measured by the quality metrics mentioned above, and also other appropriate team-defined metrics.
• You’ll help your team identify opportunities to improve their ability to deliver all kinds of changes to their users.
• *Business performance of features*, measured by user adoption and other team-defined usage metrics.
• *Satisfaction with engineering partnership,* measured by feedback from cross-functional partners.
• *Satisfaction with learning opportunities*, measured by gathering feedback from junior team members
• • *Outcomes of these decisions*, measured by quality of software and ability to deliver on-time (at this point, we start seeing the interconnectedness of some of these performance criteria)

Evergreen notes turn ideas into objects that you can manipulate, Stephan Ango, 2023

• Evergreen notes allow you to think about complex ideas by building them up from smaller composable ideas.

How to Build a Website Without Frameworks and Tons of Libraries, Koding Kitty, 2023

• We set the following set of requirements: • Fast website • Fast to develop • Inexpensive hosting • Minimal complexity
• e write our content in HTML! Take a look at our website. For the kind of posts we publish there, HTML is ideal. We mix the text with HTML/CSS/JS widgets, so it makes sense to have a post written directly in HTML
• In summary, this is the simple toolchain for building our web: • Developer updates index.src.html • Watchdog.py detects the file change and ... • ... renders Jinja template into index.html and ... • ... calls [Tailwind CSS CLI](https://tailwindcss.com/blog/standalone-cli) to generate styles.min.css. index.src.htmlwatchdog.pyrenders Jinja templatecalls Tailwind CLIindex.htmlstyles.min.css It's also important to mention following: • During development, [Live Server](https://www.npmjs.com/package/live-server) serves files and reloads them as they change. • When it's time to publish, the files are uploaded manually via [FTP](https://en.wikipedia.org/wiki/File_Transfer_Protocol).

Modern Software Development Summarized, Benji Smith, 2023

• And this is the way everyone is doing it now? Everyone is using a general-purpose tool-building factory factory factory now, whenever they need a hammer?" "Yes." "Well all right. I guess that's what I'll have to do. If this is the way things are done now, I guess I'd better learn how to do it." "Good for you!!" "This thing comes with documentation, right?"

Wisdom Is Not What You Know, hey.com, 2023

• All the most valuable lessons in life require repetition. You don't get in shape by knowing how to do a push-up but by doing a hundred a week. Accept that wisdom is a form of mental exercise.
• Chief amongst the insights are the ideas that we suffer more in our imagination than in reality, and that it is folly to focus on what you can't control. Or, put a different way: This too shall pass.

Mastering Database Transactions in Go Strategies and Best Practices, Stephen's Tech Blog, 2023

• basics of managing database transactions in Go. In Go, transactions are typically managed using the `BeginTx` function from the database/sql package. The basic flow for a transaction involves acquiring a transaction, performing operations, and then either committing or rolling back the transaction. tx, err := db.BeginTx(...) // Perform database operations _, err := tx.ExecContext(...) if err != nil { return tx.Rollback() } tx.Commit()

Manage Your Priorities and Energy., Irrational Exuberance, 2023

• The core framework is: 1. Generally, prioritize company and team priorities over my own 2. If I’m getting deenergized, artificially prioritize some energizing work. Increase the quantity until equilibrium is restored 3. If the long-term balance between energy and proper priorities can’t be balanced for more than a year, stop everything else and work on solving this (e.g. change your role or [quit](https://lethain.com/leaving-the-executive-job/))

I’m Betting on HTML, catskull, 2023

• Moreover, proper tagging is extremely descriptive in a machine-readable format. This is likely a more compelling reason for adopting modern HTML than saving design time. The shift from primary data interfaces to secondary interfaces is already underway. RSS refuses to die. ChatGPT-like interfaces are likely the future of human data access. We’re going back to the beginning. Advertisers may be scared, but I’m not! Let’s start the revolution and set the world on fire with modern HTML.
• ChatGPT-like interfaces are likely the future of human data access

The ACE Technique for Starting New Things, zeptonaut, 2023

• One useful mental trick I’ve found in this situation is something I call the **ACE technique**. There are three simple steps: • **Advice**: imagine you’re giving advice to someone else in your position. What are the concrete next steps you’d recommend they take? • **Commit**: identify how long each day you feel comfortable taking your own advice. I usually find 30 minutes or an hour is good. Some activities also have a natural “increment” that you can use as your commitment, like “I will send one cold email to a potential customer every day.” • **Exit ramp**: give yourself an exit ramp by identifying a date when you’ll reevaluate your commitment. This date needs to be soon enough where the commitment feels like a sacrifice but doable. “I’ll get up early to exercise for two weeks: if I want to stop after that, it’s okay.” Put this date on your calendar so you don’t miss

Share Demos Every Friday, Taylor Troesh ([email protected]), 2023

• **tl;dr:** Add demos to a `#demo-friday` channel in Slack or Teams

Calmness Is a Superpower, Stephan Ango, 2023

• Calmness is a superpower that is useful in many situations. When you feel anxious, or stressed, or angry, you can choose to be calm

engineering-management-tricks.md, Gist, 2023

• **Can we merge this into master?**: This helps you understand where an implementation is in the proof <-> production-ready spectrum. It also emphasizes that we should be separating shipping code from delivering it to users by using feature-flagging.
• **What are you most exited about?**: Always interesting to see where this one leads. It's a red flag if they can't come up with anything they're particularly excited about.
• • **When will I be able to try something out? / How can I try this out?**: Ask how you can try out a new feature locally, in a dev cloud, or in production. This emphasizes getting a working vertical slice together as quickly as possible and entering into a feedback loop.
• • **What is the rollout plan for this? / How is the rollout going?**: Once a feature is implemented and throughout its rollout via feature flags, check in on the rollout plan to ensure we have one and are continually leaning on it.
• **How can we test this hypothesis?** We often suspect something is wrong with our systems, then craft a multi-week plan to address it. We can de-risk situations like these by quickly testing the underlying hypothesis with a simple change.
• • **What's the most important thing you're working on?**: It's easy to get lost in the weeds - this question focuses effort in the right direction and connects it to the end goal.
• • **What are you most concerned about?**: This can provide an engineer the room they need to bring up an issue that's been bothering them. You may need to ask several questions of the form "tell me more about that" to get to the root of the issue.
• **What are you blocked on?**: Sometimes people get blocked on external dependencies without even realizing it, or don't have a good venue to resolve them. Asking this can help them get unblocked.
• **How can I help you with that / can we look at that together?**: If someone is spinning their wheels, you might jump in to provide a second pair of eyes. Sometimes just being a good rubber duck is sufficient.

The Story of Fractional CTO How to Become One, Who Should Hire Them and Why, Marko Crnjanski, 2023

• Fractional CTO **also brings a wealth of knowledge and experience that is not necessarily attached to the current tech stack or the industry of the company**; they can look outside the box, play the devil’s advocate of sorts, and really see things for what they are, without being too much distracted by the details (forest to the trees).
• Compared to the general CTO position, a fractional CTO is a “part-time CTO” who usually manages only a specific part of the tech scope, or provides an on-demand service(s) to the organization.

Turns Out Nobody Cared About Panel Gaps, David Heinemeier Hansson ([email protected]), 2023

• Figuring out what consumers truly care about is hard. Deciphering what they *don't* actually care about is harder still
• If I was starting a new business tomorrow, that's where I'd focus first. Build a thesis around which aspects of the competing products – even if they aren't directly in the same category – you could probably do without, and you'll be carving out opportunity to do something else with that liberated energy. Then plow this energy into excelling on the underrepresented axis left unattended.

Leverage Points Places to Intervene in a System, The Academy for Systems Change, 2023

• Counterintuitive. That’s Forrester’s word to describe complex systems. Leverage points are not intuitive. Or if they are, we intuitively use them backward, systematically worsening whatever problems we are trying to solve.
• 12. Constants, parameters, numbers (such as subsidies, taxes, standards). 11. The sizes of buffers and other stabilizing stocks, relative to their flows. 10. The structure of material stocks and flows (such as transport networks, population age structures). 9. The lengths of delays, relative to the rate of system change. 8. The strength of negative feedback loops, relative to the impacts they are trying to correct against. 7. The gain around driving positive feedback loops. 6. The structure of information flows (who does and does not have access to information). 5. The rules of the system (such as incentives, punishments, constraints). 4. The power to add, change, evolve, or self-organize system structure. 3. The goals of the system. 2. The mindset or paradigm out of which the system — its goals, structure, rules, delays, parameters — arises. 1. The power to transcend paradigms.
• Power over the rules is real power
• The most stunning thing living systems and some social systems can do is to change themselves utterly by creating whole new structures and behaviors. In biological systems that power is called evolution. In human economies it’s called technical advance or social revolution. In systems lingo it’s called self-organization.
• RULES FOR SELF-ORGANIZATION. These rules basically govern how, where, and what the system can add onto or subtract from itself under what conditions.
• So how do you change paradigms? Thomas Kuhn, who wrote the seminal book about the great paradigm shifts of science,[7](https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/#seven) has a lot to say about that. In a nutshell, you keep pointing at the anomalies and failures in the old paradigm, you keep coming yourself, and loudly and with assurance from the new one, you insert people with the new paradigm in places of public visibility and power. You don’t waste time with reactionaries; rather you work with active change agents and with the vast middle ground of people who are open-minded

An Inside Look at How Figma Ships Product, Yuhki Yamashita, 2023

• Side note: silent reads at the beginning can be so productive. Many of our design crits actually . Also, since we're doing the silent read remotely now, we've started playing some music to avoid the eerie video conference silence!
• In we also have the ❤️ button to indicate love for a particular update.
• Each project and update had their own 🤚button that allowed readers to indicate if they wanted the group to discuss (e.g., to ask for clarification, or to debate the approach).

Remote Work Requires Communicating More, Less Frequently, Ben Balter, 2023

• Record videos with empathy, enthusiasm, and engagement
• Choose the right medium for the message
• Communicate proactively, regularly, and asynchronously
• Think of it like gzip compression, but for human-to-human communication. Yes, there’s slightly more processing overhead at the start, but it allows us to communicate more using less.[1](https://ben.balter.com/2023/08/04/remote-work-communicate-more-with-less/#fn:1) How can you communicate more, less frequently
• Async work allows for more reflection, research, and synthesis.
• Write clearly, concisely, and comprehensively

Which AI Model Should You Pick for Your Startup?, tomtunguz.com, 2023

• When to choose a large model : • time to ship is critical
• When to choose a small model? • the team has or would like to develop intellectual property around machine learning as a competitive advantage or mechanism to increase the value of the business.

Get It Done, boz.com, 2023

• In an ideal world everyone would be operating under conditions that allowed them to succeed on their own, but until we manage to create such a world loop you should do whatever you must to get it done, even if that means asking for help.
• . It may sound counterintuitive, but the mandate of such a job is not to “do the best you can.” It is to **get it done**.

Writing Summaries Is More Important Than Reading More Books, Andreas Fragner, 2023

• • In 1-2 sentences, what is the book about as a whole? • What are the 3-4 central questions it tries to answer? • Summarize the answers in one paragraph each. • What are the most important things you have learned personally?
• template I use: 1. In 1-2 sentences, what is the book about as a whole? 2. What are the 3-4 central questions it tries to answer? 3. Summarize the answers in one paragraph each. 4. What are the most important things you have learned personally?

Beyond to-Dos, Ryan Singer, 2023

• When work is turned into tickets, our brains shut off. In ticket-land, the work is a given, and it's just a matter of "doing it." This is true for any traditional to-do software.
• another tool: unpacking. This is the opposite of aggregating. It's digging inside of one thing to get more things out of it.
• That's because traditional to-do tools are made to *account* for work, not *figure out* what the work is
• The thing is, when smart people tackle work, they actually do work on the work to figure out what the work is.
• The first is affinitizing — which is like categorizing except you don't have any of the categories in advance. It's a way to chunk things up by likeness and let the categories emerge.
• But I knew I wouldn't get everything done. Today was the last day I had budgeted time to finish the feature. So instead of "doing" everything, I added another alternative: "cutting." Some stuff just wasn't going to make it into release.
• Another tool I often reach for is the [interrelationship diagram](https://world.hey.com/rjs/1-unfolding-the-interrelationship-diagram-5a79e3fc). This is for sequencing: figuring out what to work on first, second, etc. I had a couple hours set aside to kick off a research project. There were a bunch of tasks swimming in my head. To settle on what to do, in what order, I first dumped everything, and then drew an interrelationship diagram.

Marc Van Neerven’s Post, linkedin.com, 2023

• Because as a CTO, you're 𝗿𝗲𝗺𝗼𝘃𝗲𝗱 𝗳𝗿𝗼𝗺 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻. As a CTO, you are in a strategic position, close to the business, and bridging the gap with tech.

How Shopify Builds Product, Lenny Rachitsky, 2023

• So that’s kind of the lay of the land in terms of planning. Themes once a year, which gets translated into a six-month plan, and then there are four six-week cycles inside each half.
• there’s a bit of an affinity for chaos and change that doesn’t embrace structured system
• We’re structured essentially around jobs to be done. Within Core, we have 11 teams, and they are oriented around the main merchant jobs to be done
• Shopify has an internal system called GSD, which is a bit like Jira or a task management app, except it’s not really a task management app. It’s a project stakeholder reviewing tool. It stands for “Get Shit Done.” Every project that any team does goes in GSD, which has five phases of review: 1. Proposal 2. Prototype 3. Build 4. Release 5. Results
• This org structure that we’re in right now, it has downsides to it (e.g. very large teams that require a lot of centralized coordination), but the big upside is that the org chart and the actual product are very close to the same thing (e.g. we are respecting [Conway’s law](https://en.wikipedia.org/wiki/Conway%27s_law))
• In terms of jobs to be done, we don’t use the hardcore, capital JTBD framework or anything like that. There are gray areas around the edges of some of these things

Eight Ways to Say No With Grace and Style, Farnam Street, 2023

• 2. The soft “no” (or the “no but”) > I recently received an e-mail inviting me to coffee. I replied: “I am consumed with writing my book right now :) But I would love to get together once the book is finished. Let me know if we can get together towards the end of the summer.”
• Say, “Yes. What should I deprioritize?”
• When a request comes to you (obviously this works only in person), just pause for a moment. Count to three before delivering your verdict.
• Use the words “You are welcome to X. I am willing to Y.” > For example, “You are welcome to borrow my car. I am willing to make sure the keys are here for you.” By this you are also saying, “I won’t be able to drive you.” You are saying what you will not do, but you are couching it in terms of what you are willing to
• Let me check my calendar and get back to you.”
• Use e-mail bouncebacks
• 8. “I can’t do it, but X might be interested.”

5 Key Product Learnings A Chat With Ryan Singer, getlago.com, 2023

• Good money" are revenue streams that lets you build your product while staying free and flexible in your choices to best meet the common need of your customers. "Bad money" are revenue streams that lock you up in specific choices for specific customers, forces you to develop custom features out of your product vision and brings noise in your growth.
• To prioritize features, Ryan recommends starting with “framing sessions”. The framing phase is the exploratory research phase that allows teams to understand the high-level user problems that will be candidates for the roadmap (which will be further developed during the scoping phase, where we delve into the details).
• Additionally, when iterating on the customer journey, it's valuable to work on both "Big Hire" (the decision to hire a product, e.g., buy a new coffee machine) and the "Little Hire" (the decision to use the product daily, e.g., use the coffee machine). Understanding these decisions will provide insights into identifying “jobs customers want to be done.” at each step of the process.
• Learning 5: To shape the product, you need an architect Product designers generally fall into two categories: the artist or the architect. The “artist profile” is like an interior designer. The “architect profile” will build the foundations of your product, and work with the interactions and the user flows.

How we ship fast our framework, getlago.com, 2023

• . **This tech dive-in needs to be reviewed by at least one other engineer**
• Important points to have in mind • All daily syncs are around that kanban to unveil the blockers and clearly see where to put power (the card closest to the done vs. the one on next to scope). • When someone reviews a scoping, a spec or a dive-in, we make sure that the reviewer reads and validates it. If we don’t have a proper “go”, we don’t go on. It prevents assumptions or misalignments. • Never go back. We don’t challenge a scoping while a feature is under production. • Own it. It’s your spec, your scoping or your dive-in. Autonomy is key. • Trust does not prevent reviews. These are two different concepts. • Preparation is key. It’s better to prepare a feature during 2 weeks and ship it within a week, than preparing it for a day and have 4 weeks of rework. We ship feature within 3 weeks with this workflow. • Your engineers will love the flow. After living this, it’s hard to go back to a company that is not doing it. • Repeat

Squeeze the hell out of the system you have, Dan Slimmon, 2023

• But don’t just consider the implementation cost. The real cost of increased complexity – often the much larger cost – is attention.
• Complexity costs attention.

Alex in Berlin, Sopfi ([email protected]), 2023

• 

Speed matters Why working quickly is more important than it seems, James Somers, 2023

• If you work quickly, the cost of doing something new will seem lower in your mind. So you’ll be inclined to do more
• The general rule seems to be: systems which eat items quickly are fed more items. Slow systems starve.

Copilot for Cooperations, Futility of SOPs, $0->$100m->$0 in 5 Years, and Adjusting to Market Sophistication Throu…, Jakob Greenfeld, 2023

• **[GummySearch](https://link.sbstck.com/redirect/bf8244d7-3c64-4d03-bc60-cc5988679ac6?j=eyJ1IjoiMm0yYjA1In0.X7-WJtkNIjNywcSsPphOOjEID7Pj-DG1SdOGoZC1UoE)** makes customer research via Reddit easy. Discover problems to solve, sentiment on current solutions, and people who want to buy your product

How to Do Great Work, Paul Graham, 2023

• One way to discover broken models is to be stricter than other people. Broken models of the world leave a trail of clues where they bash against reality.
• it took the greater part of a century for the heliocentric model to be generally accepted, even among astronomers, because it felt so wrong.
• Originality in choosing problems seems to matter even more than originality in solving them. That's what distinguishes the people who discover whole new fields. So what might seem to be merely the initial step — deciding what to work on — is in a sense the key to the whole game.
• This is one of the places where actual expertise differs most from the popular picture of it. In the popular picture, experts are certain. But actually the more puzzled you are, the better, so long as (a) the things you're puzzled about matter, and (b) no one else understands them either.
• It's better to be promiscuously curious — to pull a little bit on a lot of threads, and see what happens. Big things start small. The initial versions of big things were often just experiments, or side projects, or talks, which then grew into something bigger. So start lots of small things.
• Being prolific is underrated. The more different things you try, the greater the chance of discovering something new. Understand, though, that trying lots of things will mean trying lots of things that don't work. You can't have a lot of good ideas without also having a lot of bad ones. [[21](http://paulgraham.com/greatwork.html?s=09#f21n)
• If you keep projects small and use flexible media, you don't have to plan as much, and your designs can evolve instead.
• You can't trick God. So stop looking for that kind of shortcut. The way to beat the system is to focus on problems and solutions that others have overlooked, not to skimp on the work itself.
• If a lot of the best people in your field are collected in one place, it's usually a good idea to visit for a while. It will increase your ambition, and also, by showing you that these people are human, increase your self-confidence.
• Colleagues don't just affect your work, though; they also affect you. So work with people you want to become like, because you will.
• sufficiently good colleagues offer *surprising* insights. They can see and do things that you can't
• Since it matters so much for this cycle to be running in the right direction, it can be a good idea to switch to easier work when you're stuck, just so you start to get something done.
• One of the biggest mistakes ambitious people make is to allow setbacks to destroy their morale all at once, like a ballon bursting. You can inoculate yourself against this by explicitly considering setbacks a part of your process. Solving hard problems always involves some backtracking.
• If at first you don't succeed, either try again, or backtrack and then try again.
• Don't let "work" mean something other people tell you to do. If you do manage to do great work one day, it will probably be on a project of your own.
• he first step is to decide what to work on. The work you choose needs to have three qualities: it has to be something you have a natural aptitude for, that you have a deep interest in, and that offers scope to do great work
• Knowledge expands fractally, and from a distance its edges look smooth, but once you learn enough to get close to one, they turn out to be full of gaps.
• Four steps: choose a field, learn enough to get to the frontier, notice gaps, explore promising ones. This is how practically everyone who's done great work has done it, from painters to physicists.
• The reason I mention this case explicitly is that so many people get it wrong. Instead of making what they want, they try to make what some imaginary, more sophisticated audience wants. And once you go down that route, you're lost.
• when it comes to figuring out what to work on, you're on your own. Some people get lucky and do guess correctly, but the rest will find themselves scrambling diagonally across tracks laid down on the assumption that everyone does
• But fields aren't people; you don't owe them any loyalty. If in the course of working on one thing you discover another that's more exciting, don't be afraid to switch.
• If you're making something for people, make sure it's something they actually want. The best way to do this is to make something you yourself want. Write the story you want to read; build the tool you want to use. Since your friends probably have similar interests, this will also get you your initial audience.
• The trouble with planning is that it only works for achievements you can describe in advance.
• Ideally those hours will be contiguous. To the extent you can, try to arrange your life so you have big blocks of time to work in. You'll shy away from hard tasks if you know you might be interrupted
• Try to finish what you start, though, even if it turns out to be more work than you expected. Finishing things is not just an exercise in tidiness or self-discipline. In many projects a lot of the best work happens in what was meant to be the final stage
• One reason per-project procrastination is so dangerous is that it usually camouflages itself as work. You're not just sitting around doing nothing; you're working industriously on something else. So per-project procrastination doesn't set off the alarms that per-day procrastination does. You're too busy to notice it.
• The way to beat it is to stop occasionally and ask yourself: Am I working on what I most want to work on?" When you're young it's ok if the answer is sometimes no, but this gets increasingly dangerous as you get older
• The trouble with exponential growth is that the curve feels flat in the beginning. It isn't; it's still a wonderful exponential curve. But we can't grasp that intuitively, so we underrate exponential growth in its early stages.
• Work doesn't just happen when you're trying to. There's a kind of undirected thinking you do when walking or taking a shower or lying in bed that can be very powerful. By letting your mind wander a little, you'll often solve problems you were unable to solve by frontal attack. You have to be working hard in the normal way to benefit from this phenomenon, though. You can't just walk around daydreaming. The daydreaming has to be interleaved with deliberate work that feeds it questions.
• Be aggressively willing to admit that you're mistaken. Once you've admitted you were mistaken about something, you're free.
• Another more subtle component of earnestness is informality. Informality is much more important than its grammatically negative name implies. It's not merely the absence of something. It means focusing on what matters instead of what doesn't
• It's easy to criticize" is true in the most literal sense, and the route to great work is never easy.
• If I'd already made the change, would I want to revert to what I have now?
• Don't divide your attention *evenly* between many topics though, or you'll spread yourself too thin. You want to distribute it according to something more like a power law. [[17](http://paulgraham.com/greatwork.html?s=09#f17n)] Be professionally curious about a few topics and idly curious about many more.
• Have the confidence to cut. Don't keep something that doesn't fit just because you're proud of it, or because it cost you a lot of effort.
• When you're doing work that could be seen as either creation or discovery, err on the side of discovery. Try thinking of yourself as a mere conduit through which the ideas take their natural shape.
• Similarly, if you're trying to build a powerful tool, make it gratuitously unrestrictive. A powerful tool almost by definition will be used in ways you didn't expect, so err on the side of eliminating restrictions, even if you don't know what the benefit will be.
• If you express your ideas in the most general form, they'll be truer than you intended.
• The factors in doing great work are factors in the literal, mathematical sense, and they are: ability, interest, effort, and luck. Luck by definition you can't do anything about, so we can ignore that. And we can assume effort, if you do in fact want to do great work. So the problem boils down to ability and interest. Can you find a kind of work where your ability and interest will combine to yield an explosion of new ideas

Why Tailwind CSS Won, Matt Rickard, 2023

• **Fewer dependencies, smaller surface.** Tailwind is tree-shaken by default and doesn’t have its own ideas of grids or flexboxes (it just defaults to the underlying CSS concepts). Compare this to the last-generation kits like Bootstrap, which had a surface that forced users to adopt JS, HTML, CSS, and CSS build systems like Saas. Tailwind is easy to coexist with other frameworks.

My Everyday LLM Uses, Matt Rickard, 2023

• **Writing Editor.** When writing longer documents, I use it as a critical editor. The suggestions aren’t always great, but I’ve found that a critique is often more helpful than raw text generation.
• **Summarizing book notes.** I create many highlights when reading books (all digital, via Apple Books). I then have a script to export all the notes (Apple removed this feature from the UI, but you can access the SQLite database where the data is held). I run this through an LLM to compress the notes further.

Notes Apps Are Where Ideas Go to Die. And That’s Good., Matthew Guay, 2023

• We did the most important work when we wrote the ideas down. “I’m not writing it down to remember it later,” declares every [Fields Notes](https://fieldnotesbrand.com) notebook, “I’m writing it down to remember it now.” The action of writing is what counts, what imprints important ideas in our brain. The note itself is a permission slip to let things go.
• We don’t write things down to remember them. We write them down to forget.
• We need to forget, but we first must feel *safe* forgetting.
• You’ll come across those best ideas again and again; your notes end up merely being a record of when you first encountered the idea.
• > You could *almost* delete your notes every so often, trusting instead in the process.

The Law of Leaky Abstractions, Joel Spolsky, 2023

• All non-trivial abstractions, to some degree, are leaky.

Imaginary Problems Are the Root of Bad Software, George Hosu, 2023

• Imaginary problems are often more fun to solve than real ones. Extremely intelligent people play competitive games, construct and solve math problems, and write books that aim to answer abstract questions about the human condition, all of them for free.
• But imaginary problems aren’t just the result of bored developers. They’re also the result of long chains of communication.
• > *“People who are bred, selected, and compensated to find complicated solutions do not have an incentive to implement simplified ones.”* > *— Nassim Nicholas Taleb*

Position, Position, Position!, Ryan Singer, 2024

• Position, Position, Position!
• The “less about / more about” format is a quick way to stake out a position. No math class required.

Software Engineers Hate Code., Dan Cowell Jul 8, 2023

• This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches!
• Rarely, you will encounter engineers who have learned to temper their baser instincts and instead find a sick kind of joy in reading, understanding, modifying and even *deleting* other peoples' code. We call these odd folks "Senior Engineers."
• The only logical course of action is to minimize the amount of code in production at any given time. Senior engineers' passion for writing code has been augmented with an even stronger desire to delete it. Code that doesn't exist can't hurt us, or the people we love.
• Don't write new code when you can use, improve or fix what already exists. If you must write new code, write only what you need to get the job done. Understand your tools, and the systems your code runs on. Leverage the features of those systems to minimize the code you need to write, and by extension, the cost that it imposes on you and your team.

Kernighan and Pike were right Do one thing, and do it well, Keaton Brandt, 2023

• At its core, Obsidian is a [markdown](https://en.wikipedia.org/wiki/Markdown) editor. It does that well. But its real magic is its plugin ecosystem. Obsidian plugins aren’t confined to sidebars or menu items, they can add new functionality to the ‘canvas’ where content is edited and consumed.
• A good extensible desktop app should embrace being an “operating system” of sorts, but one built around a specific kind of canvas. VS Code is a canvas for programming projects, Blender is a canvas for 3D environments, Figma is a canvas for UI design. Each app has solid editing features built-in, but each are elevated by rich plugin ecosystems that bring new functionality directly into the canvas.
• The hub-and-spoke model used for plugins works because it’s “Just Right” — flexible enough to create complex behaviors, but not so flexible that apps become impossible to debug or maintain. The model allows plugins to share a single canvas, and even indirectly communicate with each-other, while still forcing them to follow a consistent set of rules.
• To determine the ideal structure for complex software, consider the structures that have survived a billion of years of cutthroat evolution: atoms and molecules, solar systems and galaxies, our own internal organs. Tractors and cameras. Obsidian and VS Code. Each are built of small single-purpose units. Just like Kernighan and Pike intended.
• > Old programs have become encrusted with dubious features.
• Some of this is a UX problem, but most of it is actually a symptom of the *developer* experience.
• Second, Pᵇᵘᵍ increases as the codebase grows larger. I’ve written before about how [the most pernicious bugs are structural, not algorithmic](https://link.medium.com/d2blcKfW8Ab), ie. caused by two sub-systems interacting in unexpected ways, not by off-by-one errors or math mistakes. Therefore, as the number of sub-systems and modules increases, Pᵇᵘᵍ increases with it.
• Large codebases will eventually reach an “[enshittification](https://en.wiktionary.org/wiki/enshittification) point” — the point at which bugs are introduced faster than they can reasonably be fixed

‘The Creative Process Is Fabulously Unpredictable. A Great Idea Cannot Be Predicted’, Tracy Francis, 2023

• My experience has been that an idea starts life as a tentative thought that tends to grow from something that you’re thinking into a conversation. It turns into a conversation, and then there’s the writing. The idea is so fragile
• The difference between an idea and a product is that you’ve solved the problems. When someone says to me, “Well, you can’t do this for these reasons,” all it means is that there are problems to be solved. If they can be solved, the idea transitions into becoming a thing. If they can’t, it remains an idea
• Of the latent potential of the idea, there’s nothing of any certainty. But where there is lots of certainty is, “Well, you can’t do that because of this. I will show you proof that you can’t do that.”
• Rather than trying to just disappear into a design studio and sort of disconnect, I really try to understand what the challenges are in terms of a creative practice in the context of a large, extended group of people
• It’s a real privilege if you get to design or address a problem as a group and then go back and do it again with the benefit of what you learned the first time. I always felt very fortunate at Apple when we got to design the third or fourth version. Because if you’re paying attention, the third or fourth one is the beneficiary of an awful lot of learning

Ten Years of “Go The Good, the Bad, and the Meh”, carlmjohnson.net, 2023

• but I do worry a bit about “useless uses of generics” where people try to shoehorn in generics where regular interfaces would work just fine. We’ll see how it goes

Concise Explanations Accelerate Progress, Stephan Ango, 2023

• Concise explanations spread faster because they are easier to read and understand. The sooner your idea is understood, the sooner others can build on it.

IndigoStack, Chris Coyier, 2023

• 

How Engineering Teams Handle Unplanned Work, Anna Debenham, 2023

• The interruption role The approach that seems to work the best once a team reaches a certain scale is to dedicate an individual to handling the interruptions that come in during a sprint
• The interruption sandwich The decision to dedicate entire sprints to handling interruption work often happens when a team that’s been working ad-hoc reaches a crisis point — maybe their bug or support backlog has gotten so large it would take too long to try and stream alongside a sprint. Doing this is sometimes necessary, but the team shouldn’t be allowed to get into this position too many times. That’s indicative of poor planning or lack of resources.
• I’m not a fan of this approach because bugs can get stale, doing lots of fixes at once can introduce new issues, and it’s also not a great experience as a user to have to wait for bugs to get fixed, even if they’re not critical. It’s like a crash-diet, and makes the quality of the product feel low. There are also some interrupts that simply can’t wait, so sprints rarely looks as neat and tidy as hoped.

Link Rachel by the Bay · Tripping over the potholes in too many libraries, carlmjohnson.net, 2023

• I have a simple rule: **never use a dependency that you could replace with an afternoon of programming**
• No dependency is so self-explanatory that you will be able to get it working with less than a few hours of: • Searching online to see what solutions to the problem exist. • Reading the docs to make sure it actually works for your problem.

Shaping Isn't Writing, Ryan Singer •, 2023

• The shaped work itself looks like a mess. But the people who were there know exactly what it means

Embrace Your Imperfect Note-Taking System., Joonhyeok Ahn, 2023

• Wabi-sabi is a Japanese philosophy that celebrates the beauty of imperfection, impermanence, and the natural cycle of growth and decay.
• It also recognizes the inherent beauty in simplicity, asymmetry, and the unique characteristics that develop over time. It encourages an appreciation for the imperfect, the transient, and the incomplete, highlighting the beauty that can be found in the flaws and imperfections.

You Can't Fix Core Competency With a Stern Conversation, David Heinemeier Hansson ([email protected]), 2023

• When things aren't going well with a new hire, the problem usually falls into one of two categories: competency or engagement. If it's a problem with engagement – their style of collaboration, their communication, their approach – there's a good chance you can fix it with some clear feedback. But if the problem is with core competency – their technical skills – you can't expect to solve that with a stern conversation
• Problems with engagement are often simply due to unstated assumptions. You expect someone to act a certain way, but they don't realize that, so they don't, and you're disappointed. If they knew what was the bother, they'd be able to correct. And you do neither you nor them any favors by sugarcoating or delaying the feedback.

14 Tools for Inner Work From ‘Stutz’, Melissa Meiller, 2023

• to work on your life force means to work on the relationship with the physical body, with other people, and with self. Any time I’ve been unsure about the larger picture of my life, I turn more attention towards these three areas by exercising or considering my diet choices, reconnecting with old or new friends, and considering the way I’m relating to the world more than the big decisions.
• Stutz identifies *pain, uncertainty, and constant work* as the three aspects of reality. No matter how much mental gymnastics you try to construct, there is no escaping these facts.
• highest form of expression is to create something new in the face of adversity
• Getting lost is an inevitable part of self-work. That self-work, as Stutz described, is like a string of pearls, one in front of the other, continuously moving. But in Stutz’ illustration, each pearl also contains a turd. *“True confidence is living with uncertainty and moving forward,”* he says. For every effort you put into something, there will be that possibility of a turd. Every step, every decision, can contain the good pearl or the bad turd.
• We often spend a great deal of energy throwing shade at these pieces of ourselves that feel less than ideal.
• In the film, Stutz asks Jonah to inquire to think about how his shadow might feel to hear all of these negative opinions Jonah has of it. By personifying the shadow as a sort of friend or acquaintance, it’s no wonder that our shadows create so much friction in our lives. If a friend were constantly calling me annoying or resenting me, I’d act out also.

The 5 Reasons Not to Use Scrum, Amazing CTO, 2023

• Focus on GitOps, continuous deployments, trunk-based development, and DORA metrics as engineering practices. Instead of a process, have a strong engineering culture. Have a golden engineering vision and an engineering strategy that makes sense. If you insist on a process, try [Shape Up](https://basecamp.com/shapeup) from 37Signals.

Disagreeing With "Best Practices", Separate Concerns, 2023

• When I interview software developers, I usually ask some variation of the following questions: > What Software Engineering practices do you consider critical to achieve your objectives? Are there “best practices” that do not matter, or which can be actively harmful? My goal in asking this is mainly to understand if the candidate is opinionated, and if so where those opinions come from. For the most part there is no right or wrong answer, but there are good and bad **ways** to answer

SPACE Framework 5 Dimensions to Measure Developer Productivity, Catarina Gralha, 2023

• Satisfaction and well-being
• Efficiency and flow
• Communication and collaboration
• Performance
• Activity

Why startups do need strategy — despite what you've heard, Rob Moffat, 2023

• Set your initial strategy Force yourself to **write down a single clear goal which is stretching but achievable in five years.**
• **Then focus on the next 12 months** Identify your ICP (ideal customer profile). Which is the segment of the market that is most frustrated today and willing to move to an alternative? Why will your product be better for them? What is your advantage in developing this? Use as narrow a definition of the market as possible.

The Algorithm, Rebuilding GA3, a New Drink for the Productivity-Chasing Professional Managerial Class, R.I.P. Indi…, Jakob Greenfeld, 2023

• 

The Musk Algorithm, David Heinemeier Hansson ([email protected]), 2023

• **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.
• Question every requirement
• **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.
• Delete any part or process you can
• **Accelerate cycle time**. Every process can be speeded up. But only do this after you have followed the first three steps.

Lessons From Bootstrapped Companies Founded by Software Engineers, The Pragmatic Engineer, 2023

• Five things that worked, consistently, for five bootstrapped companies.

Manage Your Capacity, Not Your Time, James Stanier from The Engineering Manager, 2023

• Instead, you should aim for allocating a default workload that is not your full capacity, purposefully leaving some portion of your time unallocated. This is because you need to leave space for the unexpected, such as escalations, meetings, and other interruptions that will inevitably arise.

"Waterfall" Doesn't Mean What You Think It Means, Changelog, 2023

• a prototype with the main purpose of understanding as much of the problem space as they could before they built the system
• The second reason is the most notable. In Benington’s assessment, the problem with software development was not that it was top down, but that it lacked prototyping. The issues with the specifications were that you needed to write all of them before you wrote any code. He thought this method was “terribly misleading and dangerous”.
• Do a design first (“Program Design Comes First”) Royce suggests adding a stage between the *Software Requirements* and *Analysis* stages. He calls this the *Preliminary Design* and its purpose is to gather information, not to be a correct nor final design. This design guides analysis and prevents analysis from continuing when there are issues with requirements.

You Don't Need UUID, henvic.dev, 2023

• // NewID generates a random base-58 ID. func NewID() string { const ( alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz" // base58 size = 11 ) var id = make([]byte, size) if _, err := rand.Read(id); err != nil { panic(err) } for i, p := range id { id[i] = alphabet[int(p)%len(alphabet)] // discard everything but the least significant bits } return string(id) }

Why You Should Add Friction to Your Onboarding, Ben McRedmond |, 2023

• And the allure of seeing a new product is the strongest motivator a new user has to complete complex set up tasks. The second that new user can see and use your product, their motivation for set up goes out the window
• The thing people misunderstand about onboarding is the goal is not for people to complete onboarding. Your goal is for people to get their first moments of value from your product, commonly known as “activation”. All the talk about eliminating friction and removing steps is totally detached from this goal.

Stacked Diffs, The Pragmatic Engineer, 2023

• **With stacked diffs, every commit (diff) becomes a code review.** And this is the main idea behind stacked diffs. Everything else is a tooling matter.

Your Project Management Software Can't Save You, Matt Alston, 2023

• Did you know that the Manhattan Project is also part of the glorious history of project management? Increasingly complex problems need increasingly elegant solutions, and you can’t go from an idea to an atomic bomb in a few years without efficiently organized parallel paths of work
• PM software represents itself like Frederic Taylor in the late 1800s, traveling from place to place and assuring factory owners that his system can be applied equally to joinery and industrial laundry. The difference is that Taylor had a one-system-fits-all solution; PM software sells itself a jack of all systems and master of all too.
• If you put something on a digital kanban board without enough information, it is no more useful than it was before you created the task

11 Years of SaaS Product Strategy, Alex Ghiculescu, 2023

• If you don’t already know about something that people want that you can explain in 2 sentences, then you shouldn’t be starting a business.
• The customer assumed the functionality is there, so it’s an obvious requirement to them. 2) You don’t have a justification for it not being there [[3]](https://ghiculescu.substack.com/p/11-years-of-saas-product-strategy?utm_campaign=post&utm_medium=web#footnote-3-136210108) , so implicitly it’s obvious to you.
• All these tools are a bad proxy for talking to customer

The Quiet Workflow Revolution, Study Hacks, 2023

• This sudden shift in the business productivity market away from tools that help you better *execute* your work (like word processors and email clients), and toward tools that help you better *organize* your work, is important. As I’ve [long argued](https://www.amazon.com/World-Without-Email-Reimagining-Communication/dp/0525536558), one of the major problems in knowledge work is the haphazard way in which we organize our efforts, allowing the chaotic decisions of individuals to somehow aggregate into an ad hoc equilibrium.

Positioning Yourself Near the Opportunity, Matt Rickard, 2023

• You want to position yourself near opportunities. You don’t have to be that perfect. You want to position yourself near the tree. Even if you don’t catch the apple before it hits the ground, so long as you’re the first one to pick it up. You want to position yourself close to the opportunities.

Questions for Conversation, Chris Coyier, 2023

• A friend has a go-to question for a conversation starter, particularly among business colleagues:
• What’s a business you admire?

Answers to Common (Web) Design Questions, Chris Coyier, 2023

• How can I tell if my startup/product idea is any good? It isn’t. You just have to love it and work on it for the rest of your life and it will *become* good
• What `font-family` should I use? font-family: system-ui, sans-serif;

systemfontstack, systemfontstack.com, 2023

• font-family: -apple-system, BlinkMacSystemFont, avenir next, avenir, segoe ui, helvetica neue, helvetica, Cantarell, Ubuntu, roboto, noto, arial, sans-serif;

Everything About SEO Is Obnoxious, Chris Coyier, 2023

• This is what SEO should be: 1. Write content on the internet. 2. Make sure it is output in semantic, accessible HTML. 3. Make sure the performance on the site isn’t a disaster. 4. Play no games. Do no tricks. 5. Do that over a long period of time on the same domain to build trust.

People Skills for Developers, John Arundel, 2023

• *A team is not a group of people that work together. A team is a group of people that trust each other.* —[Simon Sinek](https://twitter.com/simonsinek/status/534495244847689728)

Answers to Common Design Questions, danmall.com, 2023

• **What’s wrong with my portfolio?** [​It doesn’t say what you want from the viewer](https://danmall.com/posts/portfolios/). Ditch the meaningless “I create bold experiences for a new world” copy at the top and replace it with something more direct like “I’m looking for a senior designer job at a publishing company” or “I’m looking for new clients who make sustainable vehicles” or something equally specific. [If you want something, you gotta ask for it](https://danmall.com/posts/ask/).
• Answers to Common Design Questions

Should This Meeting Have Been an Email?, Study Hacks, 2023

• The downside of asynchronous communication, paradoxically, is that it can become *too* *easy* to use in the moment. As I documented in my most recent book, *[A World Without Email](https://www.amazon.com/World-Without-Email-Reimagining-Communication/dp/0525536558),* the introduction of low-friction digital messaging led workers to move many of their interactions into haphazard threads consisting of unscheduled messages bouncing endlessly back and forth between email inboxes.

HTML First, html-first.com, 2023

• Use "vanilla" approaches to achieve desired functionality over external frameworks
• Steer Clear of Build Steps
• Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax
• Where possible, default to defining style and behaviour with inline HTML attributes
• Prefer "naked" HTML to obfuscation layers that compile down to HTML

Copilot Is an Incumbent Business Model, Matt Rickard, 2023

• Copilots don’t create new markets. It’s about making the existing workflows more efficient. Companies will make a lot of money extracting efficiency gains from customers who are willing to pay more to do the same work faster (which is just about everyo

A Coder Considers the Waning Days of the Craft, James Somers, 2023

• As he later put it, his own neural network had begun to align with GPT-4’s. I would have said that he had achieved mechanical sympathy.
• In chess, which for decades now has been dominated by A.I., a player’s only hope is pairing up with a bot. Such half-human, half-A.I. teams, known as centaurs, might still be able to beat the best humans and the best A.I. engines working alone. Programming has not yet gone the way of chess. But the centaurs have arrived. GPT-4 on its own is, for the moment, a worse programmer than I am. Ben is much worse. But Ben plus GPT-4 is a dangerous thing.
• level, I felt almost instantly that my working life had been transformed. Everywhere I looked I could see GPT-4-size holes
• “I never engaged my detailed programmer brain.” So what did I do?
• shouldn’t worry that the era of coding is winding down. Hacking is forever. ♦
• The thing I’m relatively good at is knowing what’s worth building, what users like, how to communicate both technically and humanely. A friend of mine has called this A.I. moment “the revenge of the so-so programmer.” As coding per se begins to matter less, maybe softer skills will shine.

Too Many Developers Get Refactoring Wrong, Stephan Schmidt, 2023

• Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing.”
• We have to refactor?” Most often, it’s not Refactoring at all, it’s re-architecting or re-writing.
• How did developers arrive at a state where they feel that they need a “major refactoring” to change the architecture? They arrive at that state by creating the wrong abstractions, because they anticipated a future that never arrived. They want to remedy the situation by different abstractions again for a future they don’t know.
• What to do instead: Keep abstractions in check.
• Writing side effect free methods as much as possible is as fast as writing bad code. Not hard-coding values are as fast as hard-coding them. Having the right size of methods isn’t slower. Thinking before you write code is faster than writing bad code and then debugging it.

Development Speed From Idea to Release in One Day, Stephan Schmidt, 2023

• bet your teams are too large and endlessly need to discuss and coordinate things. Smaller teams of two devs and one pm/designer are more agile and can take more responsibility.

It’s OK if Your Code Is Just Good Enough, Vedran Grgo Vatavuk, 2023

• If you want to tackle with grade 4 you need to **build infrastructure for it** and have everyone onboard with it. Aiming for **this grade will slow you down** so it should be taken into consideration when doing estimations with PD. Clear benefits will be seen in the long run.
• To me, the code that has a clear architecture, understandable names of services, and good tests ticks all the boxes. And I like it! It doesn’t have to be a clean-code candy. If you prefer candies, then you have to convince PD and your team that this extra sugar will benefit the project.
• I’ve worked with a freelancing company whose code was on this level. In order to achieve it, they enforced **highly strict static code analysis** and **really challenging code reviews**. Static code analysis was the cornerstone to stop most of the common problems from *good enough* entering the codebase. You can view them [here](https://www.elegantobjects.org/) – under principles. Code review consisted of **two reviewers**, **one developer and an architect, plus a QA** person who would check the quality of the review.

Why Life Can’t Be Simpler, Farnam Street, 2023

• To do difficult things in the simplest way, we need a lot of options. Complexity is necessary because it gives us the functionality we need. A useful framework for understanding this is Tesler’s law of the conservation of complexity, which states: > ***The total complexity of a system is a constant. If you make a user’s interaction with a system simpler, the complexity behind the scenes increases.***
• One way to conceptualize the movement of complexity is through the notion of trade-offs
• fourth lesson is the importance of thinking about how the level of control you give your customers or users influences your workload
• Perceived simplicity is not at all the same as simplicity of usage: operational simplicity. Perceived simplicity decreases with the number of visible controls and displays. Increase the number of visible alternatives and the perceived simplicity drops. The problem is that operational simplicity can be drastically improved by adding more controls and displays. The very things that make something easier to learn and to use can also make it be perceived as more difficult.
• Simplicity is not an end in itself—other things like speed, usability, and time-saving are
• A third lesson is that products and services are only as good as what happens when they break
• Removing functionality doesn’t make something simpler, because it removes options
• Trying to do something complex with a simple tool is more complex than doing the same thing with a more complex tool.

Learn to Ask, “If This Is the Only Thing I..., Tim Ferriss, 2023

• If this is the only thing I accomplish today, will I be satisfied with my day?”
• There should never be more than two mission-critical items to complete each day. Never. It just isn’t necessary if they’re actually high-impact.

Working With Problems, Seth's Blog, 2023

• is it a problem or a situation? Problems, by definition, have solutions
• some problems get better if we’re willing to talk about them. Some situations, on the other hand, simply get worse when we focus our energy and community on them.

Create Technical Leverage Workflow Improvements & Product Capabilities, Irrational Exuberance, 2023

• • There are two major categories of technical leverage that I see in industry: **workflow improvements** and **product capabilities** • **Workflow improvements** are generally about improving efficiency (e.g. new code is deployed more quickly, database migrations are less likely to break production) • **Product capabilities** make something possible that was previously impossible, or at least an order of magnitude faster (an example of the former is a machine-learning optimized landing page that optimizes content for a given user rather than globally, an example of the later is replacing a time-intensive manual process to upload content with a wholly automated tool)

Navigators, Irrational Exuberance, 2023

• • Each major area of the business has one Navigator (we started with about ten). That Navigator is an active contributor to the software written and operated within that area • There is exactly one Navigator for a given area; Navigators do not overlap

Take Your Time Making Decisions, Matt Rickard, 2023

• You can always move slower. The world will basically wait for you if you’re deciding something consequential

Notes on Tidy First?, Irrational Exuberance, 2023

• • There isn’t a single way to do things, there are things that make sense in context, and you know your context • There are many distinct ways to tidy code, which make code easier to work with: guard clauses, removing dead code, normalizing symmetries, and so on • Tidying and logic changes are different types of work, and should be done in distinct pull requests • This speeds up pull request review,and on high-cohesion teams tidying commits shouldn’t require code review at all • Tidying should be done in small amounts, not large amounts • Tidying is usually best to do before changing application logic, to the extent that it reduces the cost of making the logical change • It’s also OK to tidy after your change, later when you have time, or even never (for code that doesn’t change much) • Coupling is really bad for maintainable code

HTML Web Components, Jim Nielsen’s Blog, 2023

• But the unique power of web components (in the browser) is that they can render *before* JavaScript. React components cannot do this — full stop.

The Chimeralogists, Robin Berjon, 2023

• A technologist will be able to take your problems or your goals and to formulate a plan to effect change that is: 1. realistic across the board, 2. aware of how both technology and policy can be shaped, 3. aligned with positive societal outcomes in a credible, non-cartoonish way, and 4. centred on changes that matter to real people.

Review Notes Shape Up, John Cutler, 2023

• variable scope project with a heavy emphasis on working iteratively throughout

Commit to Competence in This Coming Year, David Heinemeier Hansson ([email protected]), 2023

• So with programming, I try to make it a point of frequently taking the longer route. First, I don’t just want the thing I’m working on to merely work. I mean, that’s step one, but we can’t stop there. As the saying goes: make it work, make it right, make it fast. And then, let me add one more: Make it beautiful.
• imagined. It’s all possible. Work offers endless opportunities and plenty of time. The main blocker is your will to see it so
• That’s why I’m a [big fan of large, long-running pull requests](https://world.hey.com/dhh/the-advantages-of-large-long-running-pull-requests-c33d913c). The size isn’t nearly as important as the cohesion of the scope. You have to be able to see the total sum of changes to evaluate the design.

ONCE #1 Is Entirely #Nobuild for the Front-End, David Heinemeier Hansson ([email protected]), 2023

• The final destination, for me, has always been simplicity. And nothing is simpler than sending a plain-text JavaScript or CSS file straight to a browser and watch the magic play
• But I’m a firm believer that complexity ought to be a temporary price we pay for progress

TBM 260 The Thoughtful HIPPO, John Cutler, 2023

• Teams often desperately want leaders to make decisions and establish meaningful constraints. They may not want a leader to dictate the *how*, but they DO want someone with formal influence and authority to take a stand, take options off the table, and take responsibility. But the big challenge is that when this is needed the most is when it is hardest. Here's why
• One of the big challenges is that we're taught to weigh all the options and consider all the trade-offs. We believe that finding the perfect solution is possible if we think hard enough and ask enough incisive questions. We want to navigate our way to that win-win solution. The antidote to this is realizing that the slide is happening, realizing that there are vastly diminishing returns with the trade-off Tetris, realizing that the analysis isn't necessarily helping, and deciding to some all-encompassing enabling constraints. The very nature of these constraints means that you typically need someone with formal authority to draw the line.

Picking a Purpose, David Heinemeier Hansson ([email protected]), 2023

• the same time, humans are, or ought to be, more than just their work. If you don’t [diversify your life](https://world.hey.com/dhh/diversify-your-life-d7fd8020), if you put it all on work, you have just one fragile pillar to carry that heavy load of a universal purpose. Develop a few more, and a rainy day in one area of your life won’t spoil the whole parade.
• This level of purpose picking is available to everyone. Anyone can choose to be needed, and thus choose to be happy. That’s the counterintuitive point from Alfred Adler’s philosophy that authors Ichiro Kishimi and Fumitake Koga present in [The Courage to Be Disliked](https://www.amazon.com/Courage-Be-Disliked-Phenomenon-Happiness/dp/1501197274). Which, as an aside, I don’t think is was written by two Japanese authors by coincidence, who then ended up popularizing this provocative point made by an Austrian psychotherapist in the early 20th century to modern audience. It never ceases to impress me how seemingly everyone in Japan takes a tremendous pride in their work, no matter how lowly or common it might seem to a Westerner.

The Munger Operating System How to Live a Life That Really Works, Farnam Street, 2023

• To get what you want, deserve what you want. Trust, success, and admiration are earned.
• If you want to persuade, appeal to interest not to reason.”
• Learn the all-important concept of assiduity: Sit down and do it until it’s done.
• attitude of Epictetus is the best. He thought that every mischance in life was an opportunity to behave well, every mischance in life was an opportunity to learn something, and your duty was not to be submerged in self-pity but to utilize the terrible blow in a constructive fashion. That is a very good idea.

John Cutler’s Post, John Cutler, 2023

• The path to the date-less roadmap is running an open book process. Visualize your work. Visualize the flow of work. Visualize the impact of too much WIP, too much reactive work, and the quality that slips in your quest to “hit dates”. Measure outcomes—even if people say that it is a waste of time.
• So how do you rid yourself of dates-on-roadmaps? Here’s one thing that doesn’t work: a missionary stance that cites “best practices” or “what X does”. No. Here’s the tough reality: When teams are delivering regularly and generating outcomes, people stop worrying about dates. “This will be done in Q4/Q1, sounds good?” “Sure!”
• Educate, to the best of your ability. Say “It sounds like you want us to run a fixed-date, variable-scope effort, am I right?”

Stop building databases, sqlsync.dev, 2023

• in any frontend application of sufficient complexity, engineers will necessarily end up building so many data management features that they are essentially creating a domain specific database
• In any frontend application of sufficient complexity, engineers will necessarily end up building so many data management features that they are essentially creating a domain specific database. This added complexity is duplicated in each project we work on and takes away from spending time on delighting users and solving business problems. My goal here was to shine a light on these patterns we have grown accustomed to and ask: **where is the frontend optimized database stack we deserve**

Long Term Refactors, Max Chernyak, 2023

• Identify code that should be refactored.
• Identify the refactoring pattern
• Name your refactor.
• Complete the refactor.
• Prepare the codebase for the refactor
• Implement an example of the refactor.
• Write up refactoring instructions.
• Prerequisites To start, you should have the following: 1. An experienced software engineer with a vision for the refactor. 2. A team of software engineers at various levels of expertise. 3. An internal knowledge base. (Any of Github Wiki, Notion, Confluence, Markdown files, etc) 4. Less than ~5-10 long term refactors already in progress, depending on their scope
• Long-term refactors involve the whole team from the beginning, which is one of their most powerful aspects. So far, I’ve participated in ~10 big refactors using this method across 2 companies with at least 3 different teams,
• Add this refactor to the list of long term refactors.
• Assign refactoring tasks.
• Introduce this refactor to your team
• Stay aware of long term refactors.

A New Mental Model Megathread Has Arrived!, Gurwinder, 2023

• 4. The Reading Recession: There is more text than ever, yet people are reading ever less and outsourcing writing to chatbots. This is dangerous because language is the basis of thought, and if you can’t read or write well, you won’t think well.
• When a measure becomes a goal, it ceases to be a good measure. Since schools started to use test-scores as targets, they’ve gradually stopped teaching kids how to live fulfilling lives, and now mainly teach them how to pass school tests (See: Campbell’s Law)
• Serial-Position Effect: We tend to recall the beginnings (Primacy Effect) and endings (Recency Effect) of things better than the middles. So if you create anything with a beginning & ending, focus more effort there.

A Few Words About Blameless Culture, mike, 2023

• My summary of blameless culture is: when there is an outage, incident, or escaped bug in your service, assume the individuals involved had the best of intentions, and either they did not have the correct information to make a better decision, or the tools allowed them to make a mistake

"MVP" Is Dead! Long Live "FPC"., Taylor Troesh ([email protected]), 2023

• To earn your **First Paying Customer**, go help somebody.
• Sit down with a literal physical person and [convince them to give you money for something](https://taylor.town/make-money). Usually this means either (1) solving problems or (2) building things that solve problems.
• Learn to listen to people and systems. Be slow to prescribe antidotes. Hone your curiosity.
• Problems are easy to find, but difficult to understand. Assumptions and biases occlude systems' true dynamics. Designers frequently miss the true sources of friction. Engineers often misunderstand friction and relocate it elsewhere.

Getting Things Done, About, 2024

• **Always know what the next thing to do is.** For
• Pay attention to feedback loops.
• or using [watchexec](https://github.com/watchexec/watchexec) to automatically re-run a script
• Make progress every day
• For bigger things, make a plan and keep a log
• **Block distractions.** If

What I Wish Someone Had Told Me, Sam Altman, 2024

• Concentrate your resources on a small number of high-conviction bets; this is easy to say but evidently hard to do. You can delete more stuff than you think.
• It is easier for a team to do a hard thing that really matters than to do an easy thing that doesn’t really matter; audacious ideas motivate people.
• Cohesive teams, the right combination of calmness and urgency, and unreasonable commitment are how things get finished. Long-term orientation is in short supply; try not to worry about what people think in the short term, which will get easier over time
• Optimism, obsession, self-belief, raw horsepower and personal connections are how things get started.
• Spend more time recruiting. Take risks on high-potential people with a fast rate of improvement. Look for evidence of getting stuff done in addition to intelligence.
• Fight bullshit and bureaucracy every time you see it and get other people to fight it too. Do not let the org chart get in the way of people working productively together.

Hacker Stations Taylor Troesh, Taylor Troesh ([email protected]), 2024

• 

I’ve Never Had a Goal, Jason Fried, 2024

• I do things, I try things, I build things, I want to make progress, I want to make things better for me, my company, my family, my neighborhood, etc. But I’ve never set a goal. It’s just not how I approach things
• A goal is something that goes away when you hit it. Once you’ve reached it, it’s gone. You could always set another one, but I just don’t function in steps like that.

Squad Health Check model – visualizing what to improve, Henrik Kniberg, 2024

• For each question, the squad is asked to discuss if they are closer to “awesome” or closer to “crappy”, and we use basic workshop techniques (dot voting, etc) to help them reach consensus about which color to choose for that indicator, and what the trend is (stable, improving, or getting worse).
• • **Green** doesn’t necessarily mean things are perfect. It just means the squad is happy with this, and see no major need for improvement right now. • **Yellow** means there are some important problems that need addressing, but it’s not a disaster. • **Red** means this really sucks and needs to be improved.
• primary audience is the team itself rather than management.
• all models are wrong, but some are useful
• Squad Health Check model – visualizing what to improve  September 16, 2014 Published by Henrik Kniberg [](https://engineering.atspotify.com/2014/09/squad-health-check-model/) > ***For more recent information on Spotify’s Health Check model, [check out this blog post](https://engineering.atspotify.com/2023/03/getting-more-from-your-team-health-checks/?utm_medium=redirect&utm_source=blog&utm_campaign=new%20health%20check%20&utm_content=updated%20content).*** What is a squad health check model? A lot of companies experiment with ways of measuring and visualizing how their teams are doing. They’re usually called “maturity models”, and involve some sort of progression through different levels. The intent of these types of models is usually benign – for example managers or coaches in larger organizations who want to get a sense of where they should focus their improvement efforts, spot systemic problems, and help teams become more self-aware so they can focus their improvement efforts too. We prefer to use other terms like “health check model”, because “maturity” sounds a bit… well…. patronizing. Plus, most of our models don’t involve progressing through different levels, and the primary audience is the team itself rather than management. Organizational improvement work is very much a guessing game (how do you know what needs to be improved, and how will you know if it’s improving?). A systemic approach with clear visualization can reduce some of the guessiness. OK, but do models like this really work? It varies. Sometimes a model like this can be really helpful. Sometimes it’s more like “meh” – people dutifully do the workshops or surveys or whatever, and the data is then ignored. Beware though. At some companies we’ve seen models like this become a monster, a systemic tool of oppression causing suboptimization and fear as managers use the “maturity model” to judge the teams and pit them against each other, and teams hide their problems to look good. Not a pretty picture! Here’s a radically generalized “chance of success” pie-chart based on what we’ve seen so far at various companies:  However, although the potential damage is worse than the potential gain, there IS a potential gain, and there are ways to avoid the disaster scenario. At Spotify we’ve done careful experimentation with this for several years, and found some ways that work fairly OK (as in more gain than pain). At best Helpful, at worst Meh, and so far never a Disaster. We’ve introduced this health check model to several other companies as well and heard similar results, so we figured it’s time to write an article :o) Who the health check model is for When checking the health of a [squad](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) (our term for a small, cross-functional, self-organizing development team) there’s really two stakeholders: 1. **The squad itself.** While discussing the different health indicators, the squad builds up self-awareness about what’s working and what’s not. The broad selection of questions helps expand their perspective. Perhaps they were well aware of the code quality issues, but hadn’t really thought about the customer value perspective, or how fast they learn. It also provides a balanced perspective, showing the good stuff as well as the pain points. 2. **People supporting the squad.** Managers and coaches that work outside (or partly outside) the squad get a high level summary of what’s working and what’s not. They can also see patterns across multiple squads.  If you have dozens of teams and can’t talk to everyone about everything, a visual summary like this helps you figure out how to spend your time, and who to talk to about what. The first step in solving a problem is to be aware of it. And this type of visualization makes it harder for everyone to ignore the problem. How we do this at Spotify We do basically three things: 1. Run **workshops** where members of a squad discuss and assess their current situation based on a number of different perspectives (quality, fun, value, etc). 2. Create a **graphical summary** of the result 3. Use the data to **help the squads** improve We have several variants, one is simply called the “squad health check model”, others are called things like “fluent@agile game” and “quarterly reflection” (maybe later articles on that). The health check model is an improved version of the old “autonomous squads” quarterly survey mentioned in the 2012 article [Scaling Agile @ Spotify](http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify). Here’s a real-life example of health check output for one tribe:  It shows how 7 different squads in a tribe see their own situation. Color is current state (green = good, yellow = some problems, red = really bad). Arrow is the trend (is this generally improving or getting worse?). Stare at it for a minute, and you start seeing some interesting things: • **Scan each column**, and you see some major differences between squads. Squad 4 is happy with just about everything. Squad 2 is having lots of trouble, but most things are improving. • **Scan each row**, and you see systemic patterns. Every squad is having fun (and it’s even improving)! Motivation is apparently not a problem at all. But the release process is problematic, and the codebase is overall in bad shape. Over time, that will probably reduce the Fun as well. • **Scan the overall picture,** and you see that just about every arrow is up, only two down arrow in the whole picture. That means the improvement process (the most important process of all) seems to be working. This is, of course, just an approximation of reality (“all models are wrong, but some are useful” – George Box). So it’s worth double checking things before taking action. Is Squad 4 really in such great shape, or are they just optimistic and not seeing their own problems? Most squads think they are delivering good value to their customers – but how do they know? Is that based on wishful thinking or real customer feedback? In this particular case, squad 4 was actually formed just a week before the health check and they were definitely in the forming phase, or “on honeymoon”. So both squad 2 and squad 4 needed a lot of support. “Easy to release” was clearly a major issue, so this led to a bigger focus on things like  continuous delivery, and we’ve seen some good progress there. Note that this is a *self-assessment model*, all based on the honesty and subjective opinions of the people in the squads. So it only works in a high-trust environment, where people trust their managers and colleagues to act in their best interest. The data is easy to game, so the key is to make sure there is no incentive to do so. Fortunately Spotify is a pretty high-trust environment and the managers and coaches are very careful to show that this is a support tool, not a judgement tool. How we gather the data We’ve found that online surveys suck for this type of thing. Mainly because it cuts out the conversation, and that’s the biggest part of the value. The squad members gain insights while having the discussion, and the coach gains insights on how to effectively help the squads. The data alone gives you only a small part of the story, which could be misleading. So we (usually agile coaches) organize workshops with the squads, facilitating a face-2-face conversation around the different health indicators. One or two hours is usually enough. To facilitate this we have a physical deck of “Awesome Cards”, each card is one health indicator with an “Example of Awesome” and “Example of Crappy”. [![Squad Health Check - Awesome Cards](https://storage.googleapis.com/production-
• **Area****Example of Awesome****Example of Crappy****Easy to release**Releasing is simple, safe, painless & mostly automated.Releasing is risky, painful, lots of manual work, and takes forever.**Suitable process**Our way of working fits us perfectlyOur way of working sucks**Tech quality (code base health)**We’re proud of the quality of our code! It is clean, easy to read, and has great test coverage.Our code is a pile of dung, and technical debt is raging out of control**Value**We deliver great stuff! We’re proud of it and our stakeholders are really happy.We deliver crap. We feel ashamed to deliver it. Our stakeholders hate us.**Speed**We get stuff done really quickly.No waiting, no delays.We never seem to get done with anything.We keep getting stuck or interrupted. Stories keep getting stuck on dependencies**Mission**We know exactly why we are here, and we are really excited about itWe have no idea why we are here, there is no high level picture or focus. Our so-called mission is completely unclear and uninspiring.**Fun**We love going to work, and have great fun working togetherBoooooooring.**Learning**We’re learning lots of interesting stuff all the time!We never have time to learn anything**Support**We always get great support & help when we ask for it!We keep getting stuck because we can’t get the support & help that we ask for.**Pawns or players**We are in control of our destiny! We decide what to build and how to build it.We are just pawns in a game of chess, with no influence over what we build or how we build it
• Squad Health Check model – visualizing what to improve  September 16, 2014 Published by Henrik Kniberg [](https://engineering.atspotify.com/2014/09/squad-health-check-model/) > ***For more recent information on Spotify’s Health Check model, [check out this blog post](https://engineering.atspotify.com/2023/03/getting-more-from-your-team-health-checks/?utm_medium=redirect&utm_source=blog&utm_campaign=new%20health%20check%20&utm_content=updated%20content).*** What is a squad health check model? A lot of companies experiment with ways of measuring and visualizing how their teams are doing. They’re usually called “maturity models”, and involve some sort of progression through different levels. The intent of these types of models is usually benign – for example managers or coaches in larger organizations who want to get a sense of where they should focus their improvement efforts, spot systemic problems, and help teams become more self-aware so they can focus their improvement efforts too. We prefer to use other terms like “health check model”, because “maturity” sounds a bit… well…. patronizing. Plus, most of our models don’t involve progressing through different levels, and the primary audience is the team itself rather than management. Organizational improvement work is very much a guessing game (how do you know what needs to be improved, and how will you know if it’s improving?). A systemic approach with clear visualization can reduce some of the guessiness. OK, but do models like this really work? It varies. Sometimes a model like this can be really helpful. Sometimes it’s more like “meh” – people dutifully do the workshops or surveys or whatever, and the data is then ignored. Beware though. At some companies we’ve seen models like this become a monster, a systemic tool of oppression causing suboptimization and fear as managers use the “maturity model” to judge the teams and pit them against each other, and teams hide their problems to look good. Not a pretty picture! Here’s a radically generalized “chance of success” pie-chart based on what we’ve seen so far at various companies:  However, although the potential damage is worse than the potential gain, there IS a potential gain, and there are ways to avoid the disaster scenario. At Spotify we’ve done careful experimentation with this for several years, and found some ways that work fairly OK (as in more gain than pain). At best Helpful, at worst Meh, and so far never a Disaster. We’ve introduced this health check model to several other companies as well and heard similar results, so we figured it’s time to write an article :o) Who the health check model is for When checking the health of a [squad](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) (our term for a small, cross-functional, self-organizing development team) there’s really two stakeholders: 1. **The squad itself.** While discussing the different health indicators, the squad builds up self-awareness about what’s working and what’s not. The broad selection of questions helps expand their perspective. Perhaps they were well aware of the code quality issues, but hadn’t really thought about the customer value perspective, or how fast they learn. It also provides a balanced perspective, showing the good stuff as well as the pain points. 2. **People supporting the squad.** Managers and coaches that work outside (or partly outside) the squad get a high level summary of what’s working and what’s not. They can also see patterns across multiple squads.  If you have dozens of teams and can’t talk to everyone about everything, a visual summary like this helps you figure out how to spend your time, and who to talk to about what. The first step in solving a problem is to be aware of it. And this type of visualization makes it harder for everyone to ignore the problem. How we do this at Spotify We do basically three things: 1. Run **workshops** where members of a squad discuss and assess their current situation based on a number of different perspectives (quality, fun, value, etc). 2. Create a **graphical summary** of the result 3. Use the data to **help the squads** improve We have several variants, one is simply called the “squad health check model”, others are called things like “fluent@agile game” and “quarterly reflection” (maybe later articles on that). The health check model is an improved version of the old “autonomous squads” quarterly survey mentioned in the 2012 article [Scaling Agile @ Spotify](http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify). Here’s a real-life example of health check output for one tribe:  It shows how 7 different squads in a tribe see their own situation. Color is current state (green = good, yellow = some problems, red = really bad). Arrow is the trend (is this generally improving or getting worse?). Stare at it for a minute, and you start seeing some interesting things: • **Scan each column**, and you see some major differences between squads. Squad 4 is happy with just about everything. Squad 2 is having lots of trouble, but most things are improving. • **Scan each row**, and you see systemic patterns. Every squad is having fun (and it’s even improving)! Motivation is apparently not a problem at all. But the release process is problematic, and the codebase is overall in bad shape. Over time, that will probably reduce the Fun as well. • **Scan the overall picture,** and you see that just about every arrow is up, only two down arrow in the whole picture. That means the improvement process (the most important process of all) seems to be working. This is, of course, just an approximation of reality (“all models are wrong, but some are useful” – George Box). So it’s worth double checking things before taking action. Is Squad 4 really in such great shape, or are they just optimistic and not seeing their own problems? Most squads think they are delivering good value to their customers – but how do they know? Is that based on wishful thinking or real customer feedback? In this particular case, squad 4 was actually formed just a week before the health check and they were definitely in the forming phase, or “on honeymoon”. So both squad 2 and squad 4 needed a lot of support. “Easy to release” was clearly a major issue, so this led to a bigger focus on things like  continuous delivery, and we’ve seen some good progress there. Note that this is a *self-assessment model*, all based on the honesty and subjective opinions of the people in the squads. So it only works in a high-trust environment, where people trust their managers and colleagues to act in their best interest. The data is easy to game, so the key is to make sure there is no incentive to do so. Fortunately Spotify is a pretty high-trust environment and the managers and coaches are very careful to show that this is a support tool, not a judgement tool. How we gather the data We’ve found that online surveys suck for this type of thing. Mainly because it cuts out the conversation, and that’s the biggest part of the value. The squad members gain insights while having the discussion, and the coach gains insights on how to effectively help the squads. The data alone gives you only a small part of the story, which could be misleading. So we (usually agile coaches) organize workshops with the squads, facilitating a face-2-face conversation around the different health indicators. One or two hours is usually enough. To facilitate this we have a physical deck of “Awesome Cards”, each card is one health indicator with an “Example of Awesome” and “Example of Crappy”. [![Squad Health Check - Awesome Cards](https://storage.googleapis.com/production-

More Product, Fewer PMs, Kitemaker, 2023

• This generally means you should have fewer PMs than product teams. How many? Well, it depends
• the founders should still act as the de-facto heads of products.
• **Start together -** meaning, before there is anything written in a ticket or a specification, and before you decide how to start solving something, sit down and talk together across design, engineering, and product/founders
• Problem-solving should not be done primarily by the PM; instead, it should be a collaborative effort involving product, design, and engineering teams.
• Expose everyone to users
• **Beware of how the team is managed -** the often overlooked killer of an efficient product team is micromanaging and harmful KPIs. If you do everything right, but measure your team's performance by how many tickets they close or by story points, you're telling them their job is to close tickets, not build a great product
• **Don't use PM tools -** harsh advice, but having tasks in an issue tracker while the PMs keep user feedback, insights, data, specs, roadmaps in a separate tool that the rest of the team can't find, or don't have access to, is the opposite of what you want.

In My Opinion…, Chris Coyier, 2024

• A writing tip for myself in the future, if I may (and I do): delete every use of “…for me…,” “in my opinion,” “some might disagree,” “I think,” etc. etc. These snippets are a bad habit and make your writing fragile, lacking any conviction, with one eye always over your shoulder. After a while these self-doubting platitudes become road bumps that get in the way of describing the thing that you love

Those Five Spare Hours Each Week., Irrational Exuberance, 2024

• In most CTO roles, you have roughly four options: 1. *Build deep context* – Write code, or otherwise engage in the detailed work within the Engineering organization you lead 2. *Build broad context* – Expand your context outside of Engineering, better understanding your peer function’s work, goals and obstacles. This might be talking with customers, discussing product tradeoffs, understanding how marketing is driving interesting, etc 3. *Improve current systems and process* – Work on your [engineering strategy](https://lethain.com/eng-strategies/), [planning process](https://lethain.com/planning/), or pretty much any existing element of [how your Engineering organization operates](https://lethain.com/tags/executive/) 4. *Build relationships* – [Expand your internal or industry networks](https://lethain.com/building-exec-network/)

How Many Direct Reports Should a Manager Have? | AmazingCTO, Stephan the CTO, 2024

• 
• Berkeley Mono and it really is easier to read. [https://www.programmingfonts.org/](https://www.programmingfonts.org/) **[](https://kellanem.com/notes/push-and-pull)**

It’s All a Judgment Call, Jason Fried ([email protected]), 2024

• It's all a judgment call. Every human decision is a gut decision. The decision itself is the messy integration of many disparate pieces of information, experiences, instincts, stories, and unknowns.

Else Nuances, Sam Lee and Stan Chan, 2024

• Use else if it is part of the core responsibility
• A good rule of thumb is use a guard if it's a special case, use else if its core logic

Push and Pull, Kellan Elliott-McCrea, 2024

• we’ve Pushed. We’ve told people they must do something, on a schedule, in a certain format. But we haven’t Pulled, we haven’t created a sense that the work is valuable

The Best Way to Get Unstuck, Greg Gilbert's notes, 2024

• The cure is simple: do something

A 21-Year-Old Follower Just DMed Me Asking How to Start..., MATT GRAY, 2024

• I score the opportunity from 1-10 against all 11 of my criteria on a document I call the Next Move Matrix (see below). Numbers never lie: harness them to imprint rationality on otherwise emotional decisions.

The Scatter-Gather Process, tottinge, 2024

• Because only one feature is in flight at a time, and it’s always runnable, status tracking is a breeze and the lead time is as short as possible. Even if the team decides to split up the work, it is actually being done in parallel with high-bandwidth communication and frequent integration.
• A multidisciplinary team can do the design together, recognizing issues and opportunities along the way. They can also do the work in deployable, valuable units with end-to-end integration and testing as a normal part of working.
• Where work crosses team boundaries, team members from different teams can work the same feature together, perhaps building the back-end functionality as the front-end functionality is being built; perhaps building the on-device part as the in-the-cloud part is being built. Perhaps building microservices in parallel.

Scaling Engineering Teams Without Traditional Managers, alex gerlic, 2024

• After a few attempts, we landed on creating new tools: a weekly newsletter and a pulse. **Weekly Newsletter **One of the standout solutions we devised was the creation of the “Engineering Gazette.” A weekly newsletter built as a collaborative effort, written and shared by the entire team.
• Regarding feedback, we determined that an efficient way to approach it was to ask all engineers regularly a simple question: ***“What’s preventing you from doing your best work”***
• The “conventional” responsibilities of a manager are distributed across 3 distinct roles: Engineers, Crew Leads, and Coaches.

Product Management Is Broken, a Change Is Coming, Anton Zaides, 2024

• **The PMs will take OWNERSHIP** of their business domain
• Engineers are not involved in the decisions
• PMs don’t make the right decisions
• things need to happen in parallel: PMs will get closer to the business side
• Engineers will be more involved
• **The PMs will SPECIALIZE in the industry and product type**. PM

Why More Physicists Are Starting to Think Space and Time Are ‘Illusions’, Heinrich Päs, 2024

• 

Want to Upgrade Your Brain? Stop Doing These 7 Things Immediately., Benjamin Hardy, PhD, 2024

• Efforts to deepen your focus will struggle if you don’t simultaneously wean your mind from a dependence on distraction.

Play at Work, daverupert.com, 2024

• There’s [some research into why projects fail](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/06/washburn-icse-2016-2.pdf) and over-committing is near the top. Unless everyone is willing to radically cut scope, it puts a lot of pressure on developers to pull a rabbit out of their hat and save the day

The Benefit of Seniority Ought to Be Bandwidth, David Heinemeier Hansson ([email protected]), 2024

• It’s a little like “if you want something done, ask a busy person”. If you want “just enough management, but absolutely no more, hire managers who’d rather be building”.
• As I see it, the goal of the organization is to mix just enough junior talent that it's preparing for the future, with enough of the seniority needed to tend to the present

There Are No Secrets Left, David Heinemeier Hansson ([email protected]), 2024

• He’d always preface any advice with “you know your business better than I do” and “just keep doing what you know is right”.
• investing in things that doesn’t change
• What entrepreneurs need most is confidence, not advice

Most Times, the Best Way to Create Value Is Continue..., Nikita Bier, 2024

• Most times, the best way to create value is continue to double down on the domain-specific insights you've collected over your entire career.

2024 CTO Job Market & Balancing Engineering Cultures | AmazingCTO, Stephan of Amazing CTO, 2024

• *Very interesting and important idea about the coming (?) allocation economy!* **“Even junior employees will be expected to use AI, which will force them into the role of manager—model manager. Instead of managing humans, they’ll be allocating work to AI models and making sure the work gets done well. They’ll need many of the same skills as human managers of today do (though in slightly modified form).**

Trifectas Go All the Way Up, James Stanier from The Engineering Manager, 2024

• Yes, right into senior leadership. One of the most powerful groups that you can be part of as a senior leader is a trifecta. A trifecta is a group of three people from different disciplines who work together to achieve a goal. Typically, this is a group consisting of engineering, product, and UX.

How to Become a Nomad CTO, Sebastian Galonska, 2024

• Letting go of my traditional CTO title opened up a world of new possibilities. I delved into mentoring, coaching, and fractional work. This transition taught me the value of flexibility and the importance of using my experience in diverse, dynamic ways.

Interviews in the Age of AI Ditch Leetcode - Try Code Reviews Instead, chrlschn.dev, 2024

• Replacing leetcode with code reviews as interview can help teams not only better measure candidates on the whole, but also prepare for this shift in how we approach building software by focusing on more relevant skills and those aspects of a candidate that make for a better *human* teammate

Backlog Size Is Inversely Proportional to How Often You Talk to Customers, Zarar Siddiqi, 2024

• Replace planning time with talking to customers
• Don’t spend too much time designing UIs because much like backlogs, they are infested with assumptions. Get a basic UI out the door which uses your current understanding of how a customer might use the app. By [following the basics](https://www.uxtoast.com/design-tips/gestalt-principles-in-ui), it’ll be 60% right and that’s all you need. You can hone the rest through customer feedback. If you think you can’t design UIs, you can. We all use consumer apps and are much more in tune with what a UI should look like than we were 20 years ago.
• Implement account spoofing There will be a case where you will wonder what a specific customer is seeing in production. There is no point even trying to recreate this in your test environment; instead invest heavily in account spoofing, i.e., the ability for an admin user to use the app as if they were a specific production user. This makes testing easy, allows you to diagnose issues effectively and reduces the need on test data, which always has a degree of unreliability in it.
• Page one real estate is critical to a seamless experience The first thing a customer seems when they come to your app should have the most relevant information for that customer, and be sparse in content

Trifectas Go All the Way Up, James Stanier, 2024

• Yes, right into senior leadership. One of the most powerful groups that you can be part of as a senior leader is a trifecta. A trifecta is a group of three people from different disciplines who work together to achieve a goal. Typically, this is a group consisting of engineering, product, and UX.

Choose Boring Technology, boringtechnology.club, 2024

• Choose Boring Technology

Update Zu Feed-Detail, John Cutler, 2024

• Strategy? Me: Yeah. But make sure it helps people focus instead of just look good on a slide

Why You Should Be Afraid of ‘Great Execution’, Roger Martin, 2024

• As I have argued before ([above](https://rogermartin.medium.com/why-execution-is-a-bankrupt-management-concept-211f77c1fc75) and [elsewhere](https://hbr.org/2010/07/the-execution-trap)), the near universal view in management is that there is a thing called *strategy* and a different thing called *execution*, and a belief that once strategy is formulated, it needs to be executed. And the dominant view is that there is a hierarchy of importance. “*A mediocre strategy well executed* is better than a great strategy poorly executed” is the oft-repeated nostrum. I have argued in the pieces cited above that it is illogical rubbish and won’t repeat the arguments here.

Pipedrive Agile Framework A Detailed View, Kadri Pirn, 2024

• Missions Missions are focused engagements to solve a specific customer problem. They have different artifacts compared to classical projects, and a dedicated team runs them. Throughout the mission, the team continuously validates the problem and defines its solution, with more details involved over time
• Tribes Each tribe is accountable for one area of Pipedrive’s services. Tribes are responsible for the full cycle of the service: from defining the customer problem and finding a solution to maintaining, monitoring and improving it until the service is deprecated
• Guilds Guilds are virtual organizational units that consist of members from different tribes with clear goals. They are self-organized units that anyone in Pipedrive can initiate to unify people with similar interests for a specific problem.
• The Launchpad is a purely dynamic team whose size varies depending on internal (priorities) and external (missions) needs. Depending on the tribe’s nature and context, its size is typically between 20% and 33% percent of the tribe’s size. Due to its dynamic nature, it can sometimes be 10% or 90% of the tribe size during short periods. The team takes care of maintenance and support of all the tribe’s services
• Having roles instead of actual positions allows engineers to experience and learn about leadership in a controlled environment

The Radiating Programmer, Jorge Manrubia, 2024

• recurring scenarios: • Communicate what you have been up to periodically. • Communicate progress on projects. • When making decisions, to give others a chance to intervene without being blocked.
• It’s indeed by comparison that *radiating information* shines: instead of having *someone* *pulling information* from you, you *push* the information out there for *everyone*. It might look subtle, but there is a significant difference: the control remains on your side, not anyone else’s.

You Are Never Taught How to Build Quality Software, Florian Bellmann, 2024

• When writing new code, I am not using TDD, but I strongly recommend writing tests **as you write the software**
• In some companies or teams, there are certain QA standards in place. Commonly it's a senior member of a team who is enforcing them for the rest of the group. Most likely they learned the hard way that without QA everything will just become so much harder along the way. Unfortunately even having standards in place is not enough. It happens time and again that teams simply write tests to satisfy project management metrics
• Things I look out for For each new project that I start or join I look out for a QA concept. However small it might be, the team should have thought about it. • What are we shipping? • What do we need to ensure is working? • How do we do that? • Out of which measures do we deliberately opt-out and why?

How to Be Successful, Sam Altman, 2024

• I will fail many times, and I will be really right once” is the entrepreneurs’ way. You have to give yourself a lot of chances to get lucky.
• I am willing to take as much time as needed between projects to find my next thing. But I always want it to be a project that, if successful, will make the rest of my career look like a footnote.
• growth is that the furthest out years are the most important
• **Compound yourself** Compounding is magic. Look for it everywhere. Exponential curves are the key to wealth generation.
• **2. Have almost too much self-belief** Self
• 8. Be bold
• 3. Learn to think independently
• 4. Get good at “sales
• 5. Make it easy to take risks
• **6. Focus** Focus is a force multiplier on work.
• My best advice for communicating clearly is to first make sure your thinking is clear and then use plain, concise language.
• Most people overestimate risk and underestimate reward
• 7. Work hard
• Ask for what you want. You usually won’t get it, and often the rejection will be painful. But when this works, it works surprisingly well
• 9. Be willful
• I believe that it’s easier to do a hard startup than an easy startup. People want to be part of something exciting and feel that their work matters. If you are making progress on an important problem, you will have a constant tailwind of people wanting to help you
• 10. Be hard to compete with
• 11. Build a network
• The best way to make up for your weaknesses is to hire complementary team members instead of just hiring people who are good at the same things you are.
• One of the best ways to build a network is to develop a reputation for really taking care of the people who work with you. Be overly generous with sharing the upside; it will come back to you 10x
• learn how to evaluate what people are great at, and put them in those roles. (This is the most important thing I have learned about management, and I haven’t read much about it
• But somehow or other, you need to own equity in something, instead of just selling your time. Time only scales linearly.
• 12. You get rich by owning things
• 13. Be internally driven

Making It Balance, Jason Fried ([email protected]), 2024

• But when it comes to intellectual, conceptual things like business or software, we have to shift into the imagined sense of balance
• So I imagine. If this was physical, would it balance? I literally think about the center of gravity of an idea, a feature, a button, an idea, a product. Is there too much weight over here? Too much over there? If this whole thing was in stone, would it crash to one side? Or would it stand a chance of staying upright? Would it be at rest, or would it want to fall?

💡 Business Brainstorms 💡- My Favorite Ideas of the Week, Jakob Greenfeld, 2024

• • In my university days everyone had to attend a workshop on stress management.The one golden nugget I took away from it is that stress is 100% a framing issue. • You only feel stressed when you think you can't handle it. • Absolutely nothing wrong with a full calendar, juggling dozens of balls at the same time, as long as you feel chill inside.

Ten Simple IT Security Rules for Early-Stage Startups, Chris Haarburger, 2024

• • Generate and save all your passwords in our password manager, for which we have a company license. Save all company-related sensitive information (passwords, credit card data, bank accounts, etc.) in that account. Don’t save such information anywhere else. • Enable 2-factor authentication based on one-time-password (OTP) for every service that offers 2FA. Sync OTPs using the password manager. Never reveal OTPs on the phone, not even to colleagues or superiors (phishing alert!). The password manager will show you automatically for which services you can enable 2FA and have yet to do so. • Always use unique (i.e., separate passwords for separate services) automatically-generated passwords that your password manager suggests—minimum requirements: 10 characters using letters, numbers and special symbols. On mobile, use a strong passcode to unlock your phone. Avoid being watched when typing passwords. • If there is any sign of a breach on your accounts, change your password to the respective affected service and notify your superior. Generally, don’t trust e-mails and never open attachments from unknown senders. • Encrypt your hard drives using FileVault (macOS) or Bitlocker (Windows) and never leave your machine without locking it. • Watch out for phishing e-mails. If in doubt, ask the sender on another channel if the e-mail is actually from that sender, especially if the e-mail is about transferring money. • Only use our company Google Account (Gmail, GDrive) to store files, not your laptop hard drive. Only data from your Google-account is backed up regularly. • If you need to share passwords/credentials, always use the “share” feature in the password manager. Don’t send passwords via text/e-mail/WhatsApp/ • Perform all regular software updates for apps and operating systems on your computer and smartphone. • SAAS tools: Only use software that the company provides. When sharing data with 3rd parties, don't share publicly. Instead, always restrict sharing to specific individuals.
• • Generate and save all your passwords in our password manager, for which we have a company license. Save all company-related sensitive information (passwords, credit card data, bank accounts, etc.) in that account. Don’t save such information anywhere else. • Enable 2-factor authentication based on one-time-password (OTP) for every service that offers 2FA. Sync OTPs using the password manager. Never reveal OTPs on the phone, not even to colleagues or superiors (phishing alert!). The password manager will show you automatically for which services you can enable 2FA and have yet to do so. • Always use unique (i.e., separate passwords for separate services) automatically-generated passwords that your password manager suggests—minimum requirements: 10 characters using letters, numbers and special symbols. On mobile, use a strong passcode to unlock your phone. Avoid being watched when typing passwords. • If there is any sign of a breach on your accounts, change your password to the respective affected service and notify your superior. Generally, don’t trust e-mails and never open attachments from unknown senders. • Encrypt your hard drives using FileVault (macOS) or Bitlocker (Windows) and never leave your machine without locking it. • Watch out for phishing e-mails. If in doubt, ask the sender on another channel if the e-mail is actually from that sender, especially if the e-mail is about transferring money. • Only use our company Google Account (Gmail, GDrive) to store files, not your laptop hard drive. Only data from your Google-account is backed up regularly (dumped to as NAS every night). • If you need to share passwords/credentials, always use the “share” feature in the password manager. Don’t send passwords via text/e-mail/WhatsApp/ • Perform all regular software updates for apps and operating systems on your computer and smartphone. • SAAS tools: Only use software that the company provides. When sharing data with 3rd parties, don't share publicly. Instead, always restrict sharing to specific individuals.

Balancing Engineering Cultures Debate Everything vs. Just Tell Me What to Build, Adam Fishman, 2024

• Shifting Out of a “Just Tell Me What To Do” Culture
• To break free of the “debate everything, do nothing” culture: 1. Help people operate in the “gray area” 2. Introduce the FG scale 3. Incentivize outcomes 4. Evaluate how decisions are made and who makes them And to break free of the “just tell me what to build” culture: 1. Incentivize outcomes and feedback 2. Provide context and a venue for discussion 3. Codify the expectations across engineering and product
• • Incentivize outcomes and feedback • Provide context and a venue for discussion • Codify the expectations across engineering and product
• To break free of the “debate everything, do nothing” culture: 1. Help people operate in the “gray area” 2. Introduce the FG scale 3. Incentivize outcomes 4. Evaluate how decisions are made and who makes them

100% User-Supported, Stephan Ango, 2024

• In the short term, VCware tends to [subsidize pricing](https://stephango.com/quality-software) to acquire users. It’s easier to grow if your product is cheap or free. But this generally comes at the cost of hoarding user data, and locking in customers. Once you’re in you can’t get out.
• To keep raising money, VCware must paint an increasingly enormous vision of their future, which becomes impossible to live up to. This leads to increasingly disparate priorities that gradually make the product worse. What starts off as a useful app becomes burdened with crap.

Measuring Developer Productivity Real-World Examples & How Much Architecture Is “Enough?” | Amazing CTO, Stephan Amazing CTO, 2024

• For me, performance management always tries to solve the wrong problem. The problem is bad managers, who don’t help their reports, don’t support them, don’t care, don’t talk about expectations, don’t hold people accountable, don’t give feedback and don’t fire reports and fight hard for their promotions. So instead of getting better managers or training them, they force performance management on everyone

Nontrepeneur Derek Sivers, Taylor Troesh ([email protected]), 2024

• The Programmers’ Credo: we do these things not because they are easy, but because we thought they were going to be easy
• A key trait of nontrepeneurs is the pursuit of freedom over power.
• What would you do then, if you didn’t need the money and didn’t need the attention?

The One With Go 1.22 Everywhere, Golang Weekly, 2024

• [Go 1.22 Released](https://golangweekly.com/link/151202/18bd8ca107) — Keeping in tradition with *most* even numbered Go releases landing in February, Go 1.22 is here! In theory, the upgrade is as simple as updating the version in `go.mod` (just be careful of any [`net/http.ServeMux` breakages..](https://golangweekly.com/link/151203/18bd8ca107)) whereupon you'll be able to enjoy a variety of improvements:

Thoughts 8 — Simplicity, Progress, Culture, Separate Concerns, 2024

• Easy: how quickly you can achieve what you want Simple: how quickly you can understand the model
• In his Rails World keynote, DHH [talked about how](https://www.youtube.com/watch?v=iqXjGiQ_D-A&t=778s) the low interest rates we had for over a decade were a likely cause of the success of complex, over-engineered tools and the hyper-specialization of software jobs

ChatGPT Interview Cheating & Some Mistakes I Made as a New Manager | Amazing CTO, Stephan Amazing CTO, 2024

• Amen. *“Agile seems to devolve into a micromanagement tool, especially under clueless management who don’t have any proper technical background. [..] Agile’s championing of the constant intermingling between business and engineering people usually results in the business people dominating the engineering folks.”* **Engineers and CTOs need to get back control of what they are doing.**

You Couldn't Know, hey.com, 2024

• You had to go through the shit to learn the shit. Sidestepping it would have just landed you in some other shit. And then you'd have wished you had listened to different advice.
• Learning is experiencing and doing. It’s not dodging, following, or forgoing.
• You wouldn’t have your sage advice today if you hadn’t had the stupid experiences then! In fact, answering the question would erase present you from existence. Because if you were different then, you wouldn’t be the you you know now.

How to Hire High Potential People & Ten Rules for Negotiating a Job Offer | Amazing CTO, Stephan of Amazing CTO, 2024

• Try to separate their actions from those of their team or the circumstance

Town Hall #20 Pinball, Taylor Troesh ([email protected]), 2024

• • [SQL)](https://taylor.town/xml-sql) • [A Simple SRS Algo (in Ugly SQL)](https://taylor.town/flashcasts-srs-algo) • [An Antidote to Subscription Fatigue](https://taylor.town/lifetime-licenses) • ☆ [Frugly vs. Freemium](https://taylor.town/frugly)

You Don’t Need More How-To Advice — You Need a Beautiful and Painful Reckoning, Tim Ferriss, 2024

• I want a better-than-average career, I can’t simply “go with the flow” and get it. Most people do just that: they wish for an outcome but make no intention-driven actions toward that outcome

The ZigZag Model of Vision and Strategy, Stephan Schmidt, 2024

• The tech strategy follows from the tech vision
• My ZigZag Model of Vision and Strategy is simple. There are three groups of vision and strategy: Business, Product and Technology. Each group has its own vision and strategy. But they depend on each other.
• The product strategy is several steps

Nontrepeneur Steve Wozniak, Taylor Troesh ([email protected]), 2024

• Humor is closely related to the creativity and invention that we’re born with. It’s that spirit of thinking out something a little bit different — making up your own jokes.

Problem-Solving Tools for Product Makers, Matt Lane from Matthew’s Newsletter, 2024

• Anytime people talk about a scarcity of time, energy, knowledge, or money, you know you are close to Point A.
• Sometimes when we don't know how to go forward on something, we can use a counterintuitive technique. It can be easier to come up with three or more ways to do something instead of just one way. That's because when we make room for many options we can allow ourselves a bad option. Articulating what doesn't work can spark new ideas simply by contrast. Also, design is never about one thing, it is about many things.
• the Possible Paths tool, we have Criteria for rows, Paths for columns, and Aspects for cells.

Hooks, Towel Bars, and Software, Jason Fried ([email protected]), 2024

• We aim to make hooks. I want our products full of hooks. Simple, flexible, you-can’t-do-it-wrong hooks. Hooks that just work, no fuss

First Things as CTO in New Company & Simplicity in a Legacy Environment | Amazing CTO, Stephan Amazing CTO, 2024

• Major changes need to be addressed in the first three months. You learn about everything in the first two months, then think what needs to be done, then announce it and do it. With three months in, you’re still “the new one.
• The manager is the new shaman, explaining why the sun goes up and the moon goes down and everyone goes “Ah, ok”.

Developer Productivity and Happiness Framework From LinkedIn & Claude 3 Claims It's Conscious | Amazing CTO, Stephan from Amazing CTO, 2024

• Haven’t heard the term, but love it. *“Product engineers [..] own the product, and are responsible for its successes and failures.”* Developers should own the product. **Rename all your engineers now.** Bonus point: You’re tied to product and revenue and things will get much easier with the CEO

Chart the Course, Set the Pace, Hold the Line, David Heinemeier Hansson ([email protected]), 2024

• So to be bold, you must have insight – or you're just delusional. Credibility is built on pushing for a reach and then actually making it. If you're constantly pushing for the impossible, and none of it happens, you're a clown. Get out of here.
• the less you think you can do, the slower you're moving. The only counter to this is to be ambitious, bold, and impatient.
• Always look for a good bargain, when good quality is available at a great price, but never be cheap

Avoiding Pile-Ups, Jason Fried ([email protected]), 2024

• When you work on really long projects — say 3, 6, 9 month projects — or projects that don’t have any end in sight, “we can do that later” typically means you’ll get to it eventually, as part of the current project
• Long time frames give you invisible space to pack away unrealistic amounts of work. Since later is so far away, there’s no harm in kicking the can down the line. In other words, later makes a pile at the end.
• relatively short time frames, later means something else entirely. There’s no time for later. It’s now or not. Later doesn’t mean we’ll get to it at the end of this cycle. It means we’ll drop it. Later means another time, not this time

Developers Are on Edge, David Heinemeier Hansson ([email protected]), 2024

• My guess would be that just like agriculture went from requiring the participation of 97% of the world's population in the age of subsistence farming to the mere 2% required for our industrial processes today, so too will go the way of the programmer.
• So while it's hard to do, it's useless to worry. The Future is out of your hands and out of your control. No profession has ever successfully resisted automation or redundancy in the face of technological advancement over the long term

The Most Important Skill in Startup Engineering Leadership, Daniel Mangum, 2024

• there is a singular skill that ultimately decides the success of a leader, and thus their team: **pacing**

Update Zu Feed-Detail, John Cutler, 2024

• Show up at every review and review your work from an outcome perspective. You will not get fired. Start with, "To remind you, the goal here was _____ and they key hypothesis is/was that ______.
• Write up good goal-focused one-pagers as if you were starting efforts without something specific to build (starting with an objective). Just
• Do whatever you can to interact with customers, even if it is for something you just have to get done
• Figure out how to instrument what you ship. At a minimum, that will give you some experience measuring impact (even if no one pays attention

Developer Productivity via Humans | Words on Testing | Amazing CTO, Stephan from Amazing CTO, 2024

• Good points. *“Too many flaky tests. Too much time spent getting the tests to pass after making a tiny change that I knew was correct but the tests didn’t. Too many integration tests that made people wait 20, 30, 40 minutes “* Myself I’ve changed my testing approach. More pure unit tests, some E2E tests that run fast without mocking. But microservices and a tech zoo make this hard. Me with only Postgres, a breeze to test

Why You Need a Macro Architecture + Brilliant Jerks in Engineering | Amazing CTO, Stephan from Amazing CTO, 2024

• case for `memcached`. Show them the tool and ask the candidate to add one feature. Make the developer log into a system with SSH and change the code (in a VM). This should make it much more difficult for the candidate to use ChatGPT. **And it tests for code reading and understanding, something most interviews miss,** although much of development work is reading your (old) code and other peoples code to form a plan what to do.

💡 Business Brainstorms 💡- My Favorite Ideas of the Week, Jakob Greenfeld, 2024

• 

Agile in the Age of AI, hups.com, 2024

• So cross-functional teams are great, but not as important as in the past, since knowledge isn't really the bottleneck any more. A team of 1-2 people + AI has access to most of the knowledge they need.
• Why 2 people? Why not 1? Because it's nice to have another human to talk to, and easier to deal with things like vacations and sick leave.
• One consequence of AI-empowered teams is that we'll likely have smaller teams, and more of them.
• So developers essentially become mini-product owners, if I use Scrum terminology. Their job is to decide what code needs to be written, not to write it
• Daily Standup and Sprint Planning become essentially the same thing.

Follow Curiosity, Jakob Greenfeld from Play Permissionless, 2024

• Curiosity is the best guide. Your curiosity never lies, and it knows more than you do about what’s worth paying attention to
• And you will waste a ton of time researching that you could also spend executing.
• It’s easy to come up with dozen of criteria that seem important, assign weights to them, and then start ranking business ideas. Unfair advantages, easy to sell, low friction asset production, recurring revenue, no crazy hours, income potential, minimal customer input to get value, how proud will you feel about building your public profile around this, … The problem with this approach is that you will always be second guessing since you know deep down that all your ratings are completely made up. You will most likely never start executing or stick to it, since no idea seems perfect if you look at it like this.

The Tarzan Method, James Stanier from The Engineering Manager, 2024

• • *Stagnating*: You have low impact and low scope compared to where you want to be. You are likely in a role that is not challenging you or satisfying you, and you are not making the impact that you want to make. Staying in this zone is not good in the long run. For you, it means that you are going to grow continually more dissatisfied with your work. It also becomes a vicious cycle: the less satisfied you are, the less you are likely to do good work, and the less opportunities that you are likely to get. You need to move out of this zone as soon as possible. • *Stepping up*: You are in a period where you are primarily focused on increasing your scope so that it can lead to a larger impact in the future. The ways that this can typically happen are by taking on more responsibility, such as by getting promoted, or by taking a vine swing to a different, often smaller, company that is offering a bigger role than you currently have. You can commonly see this happen when someone moves from a bigger company to a smaller company for a more senior role, such as a director of engineering at a public company moving to smaller private company as a VP of engineering. • *Skyrocketing*: This is where you are in a role that is both offering you a continued increase in *both* scope and impact. For example, you may be in a leadership role in a start-up that is growing extremely fast around you. When you're in this position, the best move is to stay where you are and continue to grow with the company. This is the most desirable position to be in, but it is also the most rare. • *Skilling up*: This typically follows a *stepping up* period where you are primarily working on improving your performance and impact through learning new skills. This can be done by doubling-down where you are and investing in your own personal development, or by taking a smaller role at a bigger or more challenging company that will push you to learn new things.

April 20, 2024, Chris Coyier, 2024

• > Your challenge is finding the compelling problem in your topic, and clearly presenting it up front. That problem might be deeply buried under a bunch of boring facts and informational details. It might be hard to figure out what it is, and hard to describe once you’ve found it. The

Why You Need a "WTF Notebook", Simpler Machines, 2024

• Every time I join a new team, I go to the next fresh page, and on top of that page I write: "WTF - [Team Name]." Then I make a note every time I run into something that makes me go "wtf," and a task every time I come up with something I want to change. For two weeks, that's all I do. *I* *just write it down.* I don't tell the team everything that I think they're doing wrong. I don't show up at retro with all the stuff I think they need to change. I just watch, and listen, and I write down everything that seems deeply weird.

101 Additional Advices, Kevin Kelly, 2024

• Most arguments are not really about the argument, so most arguments can’t be won by arguing
• What others want from you is mostly to be seen. Let others know you see them.
• To make a room luxurious, remove things, rather than add things.
• Forget trying to decide what your life’s destiny is. That’s too grand. Instead, just figure out what you should do in the next 2 years.
• In a museum you need to spend at least 10 minutes with an artwork to truly see it. Aim to view 5 pieces at 10 minutes each rather than 100 at 30 seconds each.
• To tell a good story, you must reveal a surprise; otherwise it is just a report.
• When you are right, you are learning nothing.

You Are What You Read, Even if You Don’t Always Remember It, Jim Nielsen, 2024

• > the goal of a book isn’t to get to the last page, it’s to expand your thinking. I
• You Are What You Read, Even If You Don’t Always Remember It

OKRs and Product Roadmaps, Roman Pichler, 2024

• Sample goals are acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. The
• The fourth row lists the product’s *features*. These are the outputs that are required to meet the goal. The fifth and final row captures the *metrics* to determine if a product goal has been met.

How to Coach an Employee Who Is Performing Well, Claire Lew, 2024

• Give *choice* that aligns with their core motivation.
• Understand their core motivation.
• • When has it been a time when you’ve felt most motivated in the work that you were doing? • What three events in your life would you say have had the biggest impact on you and why? • Who do you admire most in your life, and why? • What do you value more than anything else? • What would you say most deeply motivates you?
• Connect their work toward *progress* toward their core motivation.
• • When has it been a time when you’ve felt most motivated in the work that you were doing? • What three events in your life would you say have had the biggest impact on you and why? • Who do you admire most in your life, and why? • What do you value more than anything else? • What would you say most deeply motivates you?

Inbox Ten, boz., 2024

• In information work [the cardinal sin is to block another team](https://boz.com/articles/dont-break-build). You are one person and they may be many which means every second wasted risks being multiplied. We should all aspire to develop reputations of increasing leverage.
• On the other hand, if you aren’t careful you could spend the whole day unblocking others only to find you haven’t made any progress of your own. You cannot allow the [urgent to overtake the important](https://boz.com/articles/portfolio) and many of these channels convey only the urgency of a task.

I'm 36, Sarah Larsen, 2024

• The Physiological Sigh: One of the fastest ways to calm down. • 1 deep inhale through the nose • 1 short inhale to top up • 1 long exhale to empty lungs Just 1-3 cycles emphasizing the exhale will offload the max amount of CO2, slow your heart rate & relax you in real time.
• If you want to curb stress, you need to curate your thoughts. Run them through Jon Acuff's 3 filters: • Is it true? • Is it helpful? • Is it kind? If they're not accurate, not serving you and making you feel worse... Discard them immediately.
• Joe Dispenza's mental rehearsal: To perform at your best, you gotta visualize success. Imagine mastering your situation with vivid clarity. Engage all your senses. Feel the triumph and gratitude associated with it. Regularly rehearse this scenario to reinforce those circuits Your browser does not support the video tag.
• Mel Robbins' 5-Second Rule: To break the cycle of anxiety and change your stress habits, simply count down from 5. 5-4-3-2-1. This exercise: • Activates your prefrontal cortex • Interrupts your habitual thought loops • Shifts your brain from fight-or-flight to action mode
• Tim Ferriss' Fear-Setting Exercise: Conquer your fears by knowing them. • Define your fears for clarity • Brainstorm prevention • Plan for damage repair • List the benefits of taking action • Consider the costs of inaction Watch Tim explain it in detail: Your browser does not support the video tag.

The Danger of “What's Next?”, Deb Liu, 2024

• I’d like you to do something for me: Take stock of *now*. While this might seem like an odd assignment, I encourage you to give it some thought. Take a few moments and jot down a list of things you love about your *now*.

The Discovery Illness, Marcus Castenfors, 2024

• Essentially, Discovery is about the collaboration between the Product Manager, the Product Designer, and the Tech Lead to discover the right solution to build before writing any scalable code.
• Typically, this involves talking to end-users, customers, and stakeholders to gauge their needs and then ideating, prototyping, and validating solutions—quickly. The last word is key here.
• Practice slicing on all levels: A) slicing the problem to be solved, B) slicing the solution you intend to build, and C) slicing what to deliver.
• The fundamental recommendation is to be “proactive” rather than “reactive” when dealing with stakeholders—try always to be one step ahead and to anticipate stakeholders’ needs.
• When transitioning to the product model, stakeholders might start to feel a lack of control, fearing they are missing out. Hence, they begin to dip their noses in, asking to be involved in decision-making and asking tough questions about what you are prioritizing—ultimately slowing you down.

Scrum's Unintended and Gradual Disconnect From Product Management, Maarten Dalmijn, 2024

• We now see Product Managers working outside of the Sprint together with Product Owners. In such an arrangement Product Owners are trapped in the Sprint bubble and usually granted less ownership over maximizing the delivery of value than the Product Manager.

Update Zu Feed-Detail, linkedin.com, 2024

• We kept Scala alive. Over the years, we always had to make sure that we have 2-3 people knowing Scala are in that team. As the hype dried down, it was harder and harder to get the right developers. People leave, but technology stays. We fucked up.
• A few hard guidelines are important. There should be only a few and these should be strict.

How I Do (And Don’t) Prepare a Talk for a Tech Conference, Chelsea, 2024

• I don’t worry about eye contact.
• I don’t do a lot of memes, gifs, puns, or cultural references.
• Instead of starting with self-intro, I consider the start of my talk to be The Hook. From
• I don’t show code, mostly.
• Instead of providing overarching context, I explain new ideas in the form of examples.
• I don’t start with “why you should listen to my talk.”
• I do very little self-intro.
• Instead of gifs, puns, memes, or cultural references, I stay focused on offering tools.
• I don’t define “empowering engineers to make design decisions.” I tell a story about a launch pad tower that was 4x harder to maintain because the damn door was on the wrong side.
• Instead of focusing on eye contact, I invest in other stage presence concerns.
• Instead of showing code, I focus on talk-friendly content.
• Regardless of order, throughout my talk prep, I focus on one guiding principle: **What new skills do I want my audience to have, and know how to use, when they leave this room?**

Mocking Is an Anti-Pattern, Stephan Schmidt, 2024

• isolation is the core of the problem, not the solution. The bugs of the IO code you want to test, arises from the interaction with the service. If you mock that, you don’t test the reason for your bugs.
• There are several things you can do instead of mocking: • More unit testing • Easier to Test IO • Just do IO • Separation of logic and services / IO • E2E integration tests *Then after you have done all of that, and you still need more tests, go with mocking.*

How Unit Tests Really Help Preventing Bugs, Stephan Schmidt, 2024

• When you have low code coverage or no measuring of code coverage at all, unit tests are not going to help (contrary to a small number of E2E tests). To benefit from unit tests, you will need to measure and raise code coverage. If you have no code coverage, start with a goal of 10% coverage. Then increase by month or quarter the coverage level by 10%. Reaching 70% is straightforward, so aim for that at first.

Moving Up to Product Director, Richard Mironov, 2024

• Directors focus much more on • **Managing people**: lobbying to fund positions; job descriptions and interviewing; onboarding/coaching/mentoring/career planning; celebrating and merchandizing wins.  For me, shepherding a group of 4 or 5 or 6 high-performing products folks is a full-time job by itself. • **Building bridges and trust with other functional groups** (Engineering, Design/UX, Marketing, Sales, Support…)  Constant updates and roadmap reviews and status; frequent re-mapping of company goals to product decisions; empathetic listening.  Endless polite explanations for why [no one gets everything they want when they want it](https://www.mironov.com/4laws1/). • **Portfolio-level coherence**, pulling together the roadmaps and strategies for each of the team’s products.  Trying to align the company strategy (top-down) with individual products and teams (bottom-up) so that we deliver economic value as well as releases. • **Reframing** technical processes in terms of [**money, trade-offs, and likely business outcomes**](https://www.mironov.com/moneystories/) for the C-suite, which is more interested in “[when does that turn into revenue?](https://www.mironov.com/digits/)” than “how are we building things?”
• And therefore Directors have much less time to: • Talk with actual customers/users/buyers, directly learn and sense the market.  We have to trust our extended teams (product + design + engineering) to do the essential work of [continuous development](https://www.amazon.com/Continuous-Discovery-Habits-Discover-Products/dp/1736633309?ref=mironov.com). • Stay current on technical details, development plans, “exactly how this application does X or integrates with Y.” • Make product-level trade-offs, do primary (hands-on) analytics, nurture an individual product or capability over time.

This Is the Only Strategy Framework You Need. Period., Bandan Jot Singh, 2024

• Where do we aim to be in 3 years' time, and how does this goal compare to our current state as a company?
• What support do we require to execute these actions effectively?
• What makes our organization better suited than others to address these opportunities?
• How will we measure our progress and know that we are moving towards success?
• Which target customers do we believe we can effectively serve within these opportunities, and why?
• What specific actions will we take to maximize our chances of success in these opportunities?
• Which risks do we need to mitigate along the way, and how will we do so?
• Under what circumstances would we reconsider our chosen actions during the 3-year period?
• Which market opportunities, i.e. customer needs, do we need to address to achieve our goals, and why are these the right opportunities?
• What distractions must we avoid to maintain focus on our selected actions?

A company is essentially two things a group of people..., Jason Fried, 2024

• A company is essentially two things: a group of people and a collection of decisions. How those people make these decisions is the art of running a business.

CPTO - How to Make It Work, Stephan Schmidt, 2024

• I often hear there is no person with the skills of a great Product and great Tech person. The skills are too stretched. This is a misconception. The CPTO does not need detailed product and tech craftmanship skills. Just like the CEO who does not know about details of technology, details of product, details of finance, and details of marketing (they are usually good at one thing, e.G. sales or business development or a visionary). But they can manage a CTO, CPO, CFO and CMO nevertheless. Thinking there is no person with the skills for the CPTO role is based on misconceptions about that role. For me it would be impossible to manage several product leads and UX/UI, or come up with a product strategy. I have not the skills to manage those, I lack the craftmanship to give guidance. As Steve Jobs, I could tell someone “This feature does not work this way” but could not help making it better through craftmanship. As a developer, I also struggled to manage DevOps, Data and QA when I became a CTO for the first time. The solution was not to become excellent at all of them, but to learn about all of them to some degree and hire or promote great leads into each role.

DevEx What Actually Drives Productivity, Nicole Forsgren, 2024

• The Three Dimensions of DevEx Our framework distills developer experience to its three core dimensions: feedback loops, cognitive load, and flow state (illustrated in figure 1).
• Accurately measuring the full range of developer experience requires not only capturing developers' perceptions and workflows across these dimensions, but also overall KPIs (key performance indicators) or "North Star metrics" that capture the bigger picture. Table 1 Illustrates this approach, by pairing comprehensive KPI metrics with specific examples of perceptual and workflow measures along the three dimensions.

I Don’t Like the Term “IC” Either, Jim Nielsen’s Blog, 2024

• [yourself an IC”](https://robinrendle.com/notes/stop-calling-yourself-an-IC/).

The Magic of Small Engineering Teams, James Temperton, 2024

• 2. They run themselves
• 1. They need to be genuinely small
• Each quarter, every small team at PostHog outlines their goals and projects for that period. We prefer goals orientated around what teams will ship, rather than more abstract goals like "increase conversions by 10%". Our executive team will give feedback on this to keep everyone on track.
• 3. They have one leader
• Because we’re engineering-led, product teams are always led by an engineer.
• Managers have a different remit. They’re more focused on the happiness of direct reports and setting the right context for people to do their jobs, onboarding new hires, and discussing performance issues with the executive team.
• A team lead’s remit is deliberately more product-focused.
• 4. They have their own mission
• The [growth team’s mission](https://posthog.com/teams/growth) is to maximize the number of people who get value out of PostHog, and help them realize and leverage all the value we offer. The [infrastructure team’s mission](https://posthog.com/teams/infrastructure) is to make deploying, scaling, and managing PostHog easy, fast, and reliable.
• As well as a main mission, each small team also sets: • Long-term goals and key metrics • What features or processes they own • A target customer (they can be external or internal)
• 5. They’re flexible
• If someone feels the need to be in more than one small team, that likely means we need to hire.
• **Fuzzy ownership** This isn’t unique to small teams, but we still mitigate against it. If a product or project doesn't have a clear owner, our [fuzzy ownership process](https://posthog.com/handbook/company/fuzzy-ownership) encourages people to create a PR and find a solution. If a problem is big enough and it doesn't have an owner, we sometimes form a temporary team just to solve that problem. We also [actively encourage](https://posthog.com/handbook/values) people to step on toes in a low-ego way.
• **Speed over seamlessness** Small teams allow us to ship fast. But the tradeoff here is that we tolerate some level of not-so-great integration in exchange for speed. This isn't a problem unique to PostHog. AWS is a great example of a very, very big company that favors speed over integration.
• You’ve got to hire right
• **Overlap** Some overlap is inevitable, especially when teams work on features that are used across multiple products. We mitigate this by being [aggressively transparent](https://posthog.com/founders/how-to-run-a-transparent-company). We also have a list of everything we do [and who owns it](https://posthog.com/handbook/engineering/feature-ownership), so it's easy to see who someone should talk to about a shared problem.

Stuck in Technical Debt? Do This, Stephan Schmidt, 2024

• First, decide if the technical debt is strategic or accidental. If it is strategic, it might be a good thing. If it is accid ental, get rid of it. I wrote about this in [“Accidental vs. Strategic Technical Debt”](https://www.amazingcto.com/strategic-deliberate-accidental-technical-debt-good-thing/).
• Second, find out the reasons and drivers for your technical debt. You can’t fix the problem if you are not aware of the drivers that drive the problem. I wrote about this in [“Reasons for Technical Debt—What drives technical debt?”](https://www.amazingcto.com/three-drivers-reasons-for-technical-debt/).
• Third, you may live in a culture of technical debt. With that culture in place, you can try to fix technical debt, but it feels like fighting a Hydra, slaying one head and another pops up. I wrote about cultures in more detail in [“Engineering Cultures of Technical Debt”](https://www.amazingcto.com/engineering-cultures-of-technical-debt/).
• If you have a leaky bucket, fix the bucket before you pour in water. For technical debt this means:
• • **Stop the line!** Call out an emergency. You’re now in crisis mode. • **Create a vision** how golden the future is after the team got rid of technical debt, what it means for developers, how it enabled the company to succeed. Lead developers to that vision! • No more shortcuts. Make it clear to everyone that this is an engineering organisation, and you don’t do shortcuts. Features are developed the way they are intended to be developed (“No SQL in controllers”). • Create a culture of craftsmanship, write it down and roll it out. • To fix technical debt, reduce new feature development to 20% until the problem is fixed. • Send out a questionnaire to all developers asking them to rate all systems/packages/parts of your application to low/high technical debt. • Every developer needs to read the Refactoring book ([“Too Many Developers Get Refactoring Wrong”](https://www.amazingcto.com/too-many-developers-get-refactoring-wrong/))-introduce a policy of constant refactoring ([“Boyscout rule”](https://innolution.com/resources/glossary/boy-scout-rule)) • Restructure QA: Developers write all tests and are responsible that their code works. QA does code reviews of all tests.
• **Then fix technical debt**: • Make individuals (leads and ICs) responsible for technical debt in parts of the application (Directly Responsible Individuals - DRI) • Upgrade all your dependencies to the newest version. • Rewrite if necessary, but be aware of [how rewrites fail](https://www.amazingcto.com/why-rewrites-fail-and-how-to-be-successful/) • When new as an engineering manager, best to fix technical debt problems in the first six months. Then you’re still part of the solution, after six months you’re considered part of the problem. • Add all the linting and static checking you can get. For me in Go this is *staticcheck, golangci-lint, nilaway, arch-go, gosec, govulncheck and nancy*. • Make tests a requirement, set the goal of branch test coverage to 80% - write tests or start by let an AI write tests for you. • **All code** needs to go through a code review before it reaches (No, all code!). You write or delegate a code review guide and checklist (short). Code reviews are NOT about naming conventions (see static-checking above). • Fix technical debt problems one by one. Keep a track record on how great you are doing to keep people motivated. Keep the vision in everybody’s mind. Talk about the golden future.

Will Figma Become an Awkward Middle Ground?, dive.club, 2024

• I don’t know about you, but that’s a pretty big departure from how I typically work. In reality, **this quadrant feels more like a toy** than something that will meaningfully impact my design process.
• By jumping from text prompt to polished components, we’re capping our ability to own the part of the process that we’re uniquely qualified to do better than AI.
• Designers who can code spend more time sketching and less time in Figma.
• But you know what AI *will* be great at? • Turning wireframes into frontend code (limited logic) • Wielding (and extrapolating) your design system • Creating beautiful visuals from screenshots and mood boards
• **It’s important that we isolate critical thinking from these outputs.**
• **Too much critical UX thinking gets lost** when you make the jump from natural language straight to Figma components.

Ship / Show / Ask, Rouan Wilsenach, 2024

• But the adoption of Pull Requests as the primary way of contributing code has created problems. We’ve lost some of the “Ready to Ship” mentality we had when we did Continuous Integration.
• There’s an approach to software branching I’ve used with my teams. It’s worked really well, so I’d like to share it with you.
• The rules • Code review, or “Approval”, should not be a requirement for a Pull Request to be merged. • People get to merge their own Pull Requests. This way they’re in control of whether their change is a “Show” or an “Ask”, and they can decide when it goes live. • We’ve got to use all the great Continuous Integration and [Continuous Delivery](https://martinfowler.com/bliki/ContinuousDelivery.html) techniques that help keep the mainline releasable. Take [Feature Toggles](https://martinfowler.com/bliki/FeatureToggle.html) as one example. • Our branches should not live long, and we should rebase them on the mainline often.

The Missing Tool, dive.club, 2024

• We just need a new tool. One that empowers us to make **low-level visual edits** ***without*** **going through an engineer and** ***without*** **writing syntax**.
• Laser-focusing on the QA process is the way designers cross the production chasm.
• you *CAN* cross... 👉 It's contributing simple CSS directly to production.

90% of My Skills Are Now Worth $0, Kent Beck, 2024

• 90% of My Skills Are Now Worth $0...but the other 10% are worth 1000x
• I do *not* have the answer for which skills are in the 90% & which are in the 10%

Moving From Services to Products, Richard Mironov, 2023

• It's my long-standing, strongly-held assertion that tech companies must choose [**either a services model or a product model**](https://www.mironov.com/4law2/).  Companies trying to do both will be fundamentally misaligned at the executive level, and make contradictory demands of their functional groups
• every department/function behaves differently at a services company versus a product company.
• An Anonymized Example Let’s imagine a B2B software company building corporate expense management applications.  Their $20M run rate is 60% license revenue and 40% services.  Looking for a [big exit](https://www.mironov.com/investor-value/), the CEO’s (and Board’s) stated goal is to **grow** ARR while **reducing** services revenue: $28M next year with less than $6M in total services, then $35M with $30M+ in pure ARR. Under the hood, we see typical challenges for a half-services/ half-product company: • Some license deals actually include pre-sold custom integrations or multi-year services bundles or human-powered analytics services.  So [pure ARR](https://www.mironov.com/arr/) is about 50% of total revenue. • The Customer Success (CS, *aka* post-sales implementation) team runs on a project model, staffing new projects as they finish current ones.  They are overwhelmed with existing commitments and new deals. • The largest clients treat Customer Success as an outsourcing resource, with a constant stream of “we need you to do *vaguely related thing X* to keep us happy.”  Some clients don’t actually use the application themselves, instead having CS as their fingers-on-keyboards running reports or entering data or interpreting data or building CFO-level presentations.  To them, the company looks like an agency rather than a software vendor. • Since CS moves from one project to another, there’s no ongoing CS staffing for in-production customizations or integrations *–* which periodically break or need revisions.  So the core Engineering team is often pulled in for emergency fixes, without context, on code they didn’t write.  A product roadmap exists, but we notice that more than half of R&D effort is actually spent on these non-core repairs.  Planning is futile; Engineering and Product are disheartened; everyone complains about a [lack of innovation](https://www.mironov.com/discovery/). • Updating or upgrading the core software platform is increasingly difficult.  Every major client is on a different version, with assorted undocumented extensions and clever workarounds that assume the underlying tech will never change.  So improving the underlying architecture means testing against every customer implementation *–* with fingers crossed.  And no one is excited to migrate.  The core application is aging, fragile, unscalable.  Enhancements have ground to a halt. So unwinding our services business will be slow, risky, frustrating. What Does Success Look Like? Talking about a repeatable product model is mostly [philosophy](https://www.mironov.com/philosophy/) until we start measuring progress.  My two best metrics are: • **TIME TO VALUE** (TTV): the total clock/calendar time between a customer signing a purchase order and end users getting the primary value they've been promised.  For our expense management application, TTV is the number of calendar days after signing when most employees can successfully request travel reimbursement.  There will be a few items that we wait for the customer to do *(single sign-on setup; employee notification)* but we strive to reduce/eliminate everything else (connection to their finance system, sample employee invitation, logo upload, report aggregation).  Could we finish everything on our side in 6 hours rather than 6 days or 6 weeks or 6 months? • **TOTAL IMPLEMENTATION EFFORT** (TIE): in hours or days, the total effort by all of our internal groups to get the next customer into production.  This excludes ongoing technical support, but includes set-up; configuration; matching charts of accounts to expense types; drafting custom employee emails for HR; and migrating expense data from legacy systems.  Reduce from 250 hours/client to 175 to 110 to 60? • Harder to measure, but an end goal: **INCREASED SALES VELOCITY,** which is the average time to close the next deal.  Can we speed up the sales cycle and **reduce per-deal sales effort** with self-run demos, [clearly posted pricing](https://www.mironov.com/boseu/), free trials, [fewer choices and configurations](https://hbr.org/2023/08/how-the-science-of-choice-can-boost-innovation?utm_source=Kromatic+Innovation+Blog&utm_campaign=83d40d6c55-GOOD_READS_CAMPAIGN_2023_09_18&utm_medium=email&utm_term=0_df0635017f-83d40d6c55-711154551), improved UI/UX, default setups, wizards? A move toward repeatable products shifts our discussion from how to close a **few** very large deals to the **aggregate** revenue from dozens of increasingly similar customers.  This is a whole-company discussion, not a narrow technical distinction. Department by Department… We should expect lots of push-back from each of the affected corporate groups  — especially Sales and Customer Success — as we shift company-level goals and metrics.  So IMO the #1 determinant of success is very clear: ***CEO-led executive-level agreement that the whole company will make this change***. Pretending it’s primarily a product/engineering challenge is assuring failure.  Is the CEO willing to push hard for a whole year, repeatedly make the case, anticipate dissent, let some shiny deals go, and stay the course? **CORPORATE-WIDE** It’s important that we approach this major change with eyes wide open.  Some honest assessment questions to ask: • When will our packaged products be ready to support the company’s entire revenue target?  Are we there today?  Have we done enough hard-nosed analysis and forecasting that the GTM groups agree with?  If revenue dips next quarter, will we revert to urgently selling services? • Almost immediately, we’ll need a “stop the bleeding” plan, which means not signing any NEW contracts that include custom services.  Do we have the stomach to enforce that?  *(It’s unlikely that we’ll cancel committed in-flight projects, but every new item undercuts our resolve and internal agreement.)*  This isn’t an intellectual question, but a C-suite behavioral question when faced with a shiny new opportunity. • Product development always takes longer than we planned.  How much leeway do we have? • Should Finance carefully track true ARR and services work on existing deals?  Should services be reclassified as a cost center? **EXTERNAL SERVICES PARTNERS** Our customers’ needs and demands don’t disappear just because we want to change our business model.  They are used to us happily agreeing to their next request.  Where will these go?  I’d recommend identifying (wooing) at least two pure-play consulting or services firms that do good work in our space, and bringing them projects that customers will pay them for.  This will be wildly unpopular with our Customer Success group, but might look like: • Training services partners on our platform, architecture, APIs, methodology • Considering a jump-start by “lending” a few of our best CS folks to partners • Making ongoing referrals contingent on quality and TTV and customer feedback • Identifying abandoned old projects that we struggle to support, so that we can pass them on to our service partners – along with customer notification of ongoing support fees to the partner A fallback is to spin out the service group into a separate legal entity (not just a distinct operating group under the same P&L) with a plan to add at least one competing services provider. **CUSTOMER SUCCESS (Integrations/Implementation)** This group takes the brunt of a changed company strategy.  They’ve been delivering revenue/margin/growth for years.  Their goal is now to do **less**, not do more.  We need to honor and appreciate their contributions • Create CS bonuses based on faster TTV rather than increased hours invoiced.  Have MBOs around clear documentation of built solutions. • Involve CS in every step of the migration and upgrade process.  They know these customers better than anyone else in the company. • Shift accounting treatments to move revenue into licenses.  (For instance, reduce separately invoiced services and raise license prices to offset it.)  Growing CS is no longer our goal: it becomes a cost center, not a profit center. • For customers with services included in their current contracts, rebundle a Gold versi

Wealth = Have ÷ Need, Derek Sivers blog, 2024

• Wealth, **feeling like you have plenty**, is an equation. WEALTH = HAVE ÷ NEED

💪 Is That Candidate Motivated? How Do I Find Out? | Amazing CTO, Stephan from Amazing CTO, 2024

• “Here’s a repo you’ve never seen before. Here’s how to build and run the tests in this repo. There’s a bug: what we’re observing is X, but we want to see Y instead. Find the bug and maybe even write some code to fix it.”

Steve Jobs Swore the 10-Minute Rule Made Him Smarter. Modern Neuroscience Is Discovering He Was Right, Jessica Stillman, 2024

• The late Apple boss intuited something that neuroscience is now proving -- walking makes your brain work a little bit better, helping you crack problems that stumped you while sitting.
• If you haven't solved a tough mental problem after 10 minutes of trying, stand up and [go for a walk](https://www.inc.com/jessica-stillman/the-science-of-why-you-do-your-best-thinking-while-walking.html).
• Whenever you have to come up with a new idea or solve a problem, however, you need [a more open, loose mental state](https://www.inc.com/jessica-stillman/einsteins-secret-for-coming-up-with-breakthrough-ideas-do-a-whole-lot-of-nothing.html) where your mind can make novel connections and discover paths around obstacles. Just sitting there struggling for long periods of time leads to frustration, not eureka moments.
• "You can't ruminate, because your attention can't stick to one problem for too long because you also have to pay attention to where you're walking," Storoni continues.

Technical Debt Can Investing in It Unlock 2x Team Impact?, Fergus Doyle, 2024

• Technical debt: Can investing in it unlock 2x team impact?

Take Back Control From Product Management, Stephan Schmidt, 2024

• Take Back Control From Product Management

Tech Strategy. AI IDEs. Highperformers., Stephan from Amazing CTO, 2024

• *“If your strategy isn’t seen and understood, it’s as if it doesn’t exist at all.”* Towards your CEO and your reports! Talk, talk, talk, you can’t overcommunicate. If you talk about your strategy and developers finish your sentences, then they’ve got it.
• *“Use storytelling.”* You’re the modern story teller.

We Did All This Discovery — Now How Do We Decide?, Ryan Singer •, 2024

• To help us to eliminate (not forever, but for the purpose of making a decision now) I've found one technique very helpful. The trick is to flip things around. Instead of describing the *good* that will happen by doing an idea, we look at what goes wrong when we *don't* do it. To make that flip, we can ask two simple questions: 1. Knowing the customer can't do what's in the idea today, **What are they doing instead?** 2. **What's bad about that?**