Pocket Highlights from Klaus Breyer

This page is created by a personal open source project of mine called pocket-highlights to extract my Highlights from Pocket and format them for easy copy & pastable into Obsidian. Read more in my blog post.

The Quiet Revolution of Animal Crossing, Ian Bogost, 2020

• 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?
• 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.
• 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.

https//www.neuenarrative.de/magazin/eine-handvoll-mutige-menschen-machen-eine-lebensdienliche-wirtschaft/, 2020

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

How to Write Usefully, 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, 2020

• 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.
• 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.

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

• 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.
• 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.

undefined, 2020

• Here’s the thing, though: Dropbox absolutely is better than One Drive. Google Apps are better at collaboration than Microsoft’s Office apps. Asana is better than Planner. And, to be very clear, Slack is massively better than Teams at chat. Using all of them together, though, well, it sucks:
• First, chat is the point, not integrating with toolchains that are probably different on a company-by-company basis, which lets Slack’s strengths as a chat client come to the forefront. Second, because Slack is not deeply integrated with a bunch of other applications, it is actually easier for it to horizontally connect different companies. Third, being first actually matters.

Antifragility, 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.
• 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. 
• 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.

http//feedproxy.google.com/~r/37signals/beMH/~3/pqFWQbHjtMQ/, 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)

https//brendancahill.io/brensblog/dereksivers, 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, 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

• 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.
• 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.

If it's a Nice Problem to Have, Don't Solve it Now, 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.

https//www.tiffanymatthe.com/not-extraordinary, 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.

https//a16z.com/2020/09/07/on-productivity-scheduling-reading-habits-marc-andreessen/, 2020

• It’s basically trying to try to fill in all the puzzle pieces for the big discrepancies.A great term is “sense-making”. Essentially, what the hell is happening and why? The world’s an incredibly complex and erratic place and trying to figure that out is kind of a lifetime occupation.
• the D.R.I. For any project, I’ve tried to identify the DRI. Who is the person responsible for delivering the project? If that’s me, then the project itself gets on my calendar.
• The firm is built to accomplish what I want to accomplish. And then my role here is to accomplish that within the context of the firm. And so the short answer is always the same — how do we optimize for the success of the firm? For the projects the firm is involved in, how do I optimize my contribution to that? So, you know, it’s been the same answer to the question every year for 11 years in a row and I don’t think it’ll change anytime soon. I think it’s more of trying to tune against a single goal as compared to trying to rethink the goals.

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.

undefined, 2020

• One engineer’s avoidant emotions turn into dangerous team habits as engineers teach each other to avoid touching certain files, or to pass odd-looking production bugs to the operations team. “This network behaviour is dark magic, let them handle it!”

https//tomtunguz.com/learning-organizations/, 2020

• 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.
• 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

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, 2020

• 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.
• 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.

https//fs.blog/2020/10/why-life-cant-be-simpler/, 2020

• 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.
• 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.

Container orchestration tools explained, 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, 2020

• 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.
• 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.

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, 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 — LessWrong, 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). 

http//feedproxy.google.com/~r/37signals/beMH/~3/A5AMah05B-w/, 2020

• 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?
• 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.
• 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.

Systems design explains the world volume 1, 2020

• 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.
• 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.

My favorite essays of life advice, 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?, Tynan, 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.
• 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.
• 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?
• 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.

http//madeofmetaphors.com/difficult-conversations, 2021

• 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
• 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.
• 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 Dağdeviren, 2021

• 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 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.
• These hidden gems of writing the idea in a structured way and asking people for comments afterward prevents many endless debates
• 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.
• 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

http//madeofmetaphors.com/boundaries-and-infinities, 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.
• 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.
• 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.
• 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.
• 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
• 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:
• 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.
• 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!
• 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.
• 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.

Billionaires Build, 2021

• 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.
• 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 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.
• 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.
• 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."

No Meetings, No Deadlines, No Full-Time Employees, Sahil Lavingia, 2021

• 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.
• 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.”

My goals for 2021, interesting lives, and other considerations, 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

• 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?
• Make it time-based, take regular breaks, and learn what you’re curious about.
• 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?”
• 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
• 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.
• 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.
• file with questions
• 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.

Context switching costs more than we give it credit for., MAYANK VERMA, 2021

• Grouping/responding to all emails is an email function. Even that is further broken down into triaging email function and responding function.
• 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.

Maximizing Developer Effectiveness, 2021

• 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.
• 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.
• 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.

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, 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, 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, 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, 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

• Decrease the importance of yourself. The world does not conform to your desires, and this causes you problems.
• Be a maker who makes something interesting people want. Show your craft, practice your craft, and the right people will eventually find you”.
• 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
• 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.
• Become the best at what you do. Opportunity will seek you out. Luck becomes your destiny.
• 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.
• 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.
• Any end goal will just lead to another goal, leading to another goal. We just play games in life.
• 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.
• 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.
• Happiness is a choice you make and a skill you develop. Happiness is being satisfied with what you have. Success comes from dissatisfaction. Choose.
• Don’t take yourself too seriously, you’re just a monkey with a plan.
• The fundamental delusion: There is something out there that will make me happy and fulfilled forever.
• 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.
• 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.

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 Worked On, 2021

• 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.
• Computer Science is an uneasy alliance between two halves, theory and systems. The theory people prove things, and the systems people build things

https//benbernardblog.com/what-ive-learned-from-10-years-of-personal-projects/, 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.

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

• 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.
• 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.

An interview from alternative universe, Tomas Petricek, 2021

• The most important thing in software design is problem framing and you need a lot of expertise for that.
• 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 problem really only becomes apparent as you try to solve it. So, the key thing is to quickly iterate.
• 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!
• 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.
• the creation of software as a design activity, putting it as a third item on the same level as science and art.
• 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.
• 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.

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

• 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.
• 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.
• 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
• 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.
• 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.

How People Get Rich Now, 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.

undefined, 2021

• Go is more about software engineering than programming language research. Or to rephrase, it is about language design in the service of software engineering.

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

• 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.
• “A great many people think they are thinking when they are merely rearranging their prejudices.”
• 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 (And How to Fix Them), James Clear, 2021

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

A Project of One's Own, 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.
• The
• 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.

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.

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.

Joining hypergrowth startups 😬, 2021

• 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
• 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
• 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.

#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, 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
• 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.
• 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.

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

• Tetlock’s talk on this is subtitled “Ignore Confident Forecasters,” which I think is an excellent summary of his findings.
• Still, there is some evidence that noncontingent, one-big-idea advice is less valuable than more nuanced, complicated advice.
• 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.

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

• 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.
• 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.

Friday Facts #366 - The only way to go fast, is to go well!, kovarex, 2021

• The only way to go fast is to go well!
• 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.

How to Work Hard, 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.

Evil tip avoid "easy" things, 2021

• The guy working on the "hard" thing gets a lot of help and resources, making it easier to succeed – and easier to move on to the next "hard" thing. The guy doing the "easy" tasks gets no help, so it's harder to succeed.
• One thing you want to prevent is people learning to remind you earlier. The way to accomplish it is being very nice when they come late. If people feel punished for reminding too late, they'll come earlier next time, and in a vengeful mood, so with more needless tasks. But if they're late and you eagerly "try to do the best under the circumstances", not only do you put yourself under the spotlight as a patriotic hero, you move the forgetful culprit out of the spotlight. So they'll form a rosy memory of the incident, and not learn the value of coming earlier – precisely what we want.
• Urgent things automatically become harder, a person in a hurry more important. The later it's done, the easier it is to get help (while retaining the status of "the" hero in the center of it all who made it happen.) Under time pressure, the scope shrinks, making the formerly "easy" and now officially "hard" thing genuinely easier. This is particularly useful for the really disgusting, but unavoidable work

On working too hard finding balance, and lessons learned from others, 2021

• 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.
• 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’.

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, 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
• 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.
• 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.

Henry Rollins on defining success, 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.

https//fs.blog/2014/05/hunter-s-thompson-to-hume-logan/, 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.
• 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.”
• 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.

It’s not what you think, The Next Ten, 2021

• 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.
• 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.

Agile at 20 The Failed Rebellion, Al Tenhundfeld, 2021

• 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.
• 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.

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.

M88 คือใคร ทำความรู้จักกับเว็บไซต์พนันออนไลน์ชั้นนำของเอเชีย, 2021

• 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.
• The purpose of testing is to increase confidence for stakeholders through evidence.
• 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.

Buy clenbuterol 40 mcg in UK, 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, 2021

• 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.
• 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
• 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
• 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.
• 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.

https//www.toptal.com/engineering-management/written-communication-workplace?utm_source=newsletter&utm_medium=email&utm_campaign=alphalist&utm_content=20210805&mc_cid=d604b1ae6f&mc_eid=4a755124ef, 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 (Updated 22 July 2020), 2021

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

I ruin developers’ lives with my code reviews and I'm sorry, 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?, 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, 2021

• Don’t write code on the critical path
• 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.

https//www.calnewport.com/blog/2020/03/17/the-deep-life-some-notes/, 2021

• In each of these areas I keep striving to identify the big swings — the actions or commitments that will make the most difference
• 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).

http//feedproxy.google.com/~r/StudyHacks/~3/w9ngI1eqVhU/, 2021

• 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.
• 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.

Why You Should Repeat Yourself, A Lot, 2021

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

https//kennydodrill.net/blog/how-to-be-a-nice-programmer/, 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

http//feedproxy.google.com/~r/StudyHacks/~3/yqnphpfH-Yc/, 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.

Please wait while your request is being verified..., 2021

• The first rule is this: Extra must be balanced against Normal Work. Real stuff still needs to get done.
• 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 second rule of Extra is that it must be aligned with your Normal Work.

https//rachelbythebay.com/w/2021/09/05/clever/, 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 (why I Hate That Name), 2021

• 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
• 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.

They don't even know the fundamentals, 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.
• 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.
• 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:

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, 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, Adam Keys, 2021

• 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!
• 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.)

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

• 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.
• 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.
• 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.
• 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.
• 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.
• 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
• 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.
• 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.
• 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.
• 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
• 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.
• 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
• 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 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.
• 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.

https//ronjeffries.com/xprog/articles/the-noestimates-movement/, 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.

https//www.quastor.org/p/how-whatsapp-scaled-to-1-billion, 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, 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?, Vince Law, 2021

• 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.
• 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.

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.
• 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
• 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
• 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

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, Author, 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

• 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.
• The job of development is to build a theory in your mind about the codebase.
• Working on a functioning app’s codebase does more to increase its quality than adding features.
• Svelte and Typescript are very useful, but the cost of building is always more than you think, especially once the codebase grows.
• 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.
• 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.)
• 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 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.
• 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.
• 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.
• 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.
• 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.
• Avoid using web workers (the web stack’s equivalent for a process) or threads if you can. They make theory-building harder.
• 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
• 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.
• 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.
• Once you have a working app, working on code quality is just as likely to provide as much business value as a new feature.
• 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.
• 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.
• 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?

Why we always end up with waterfall, Stephan Schmidt, 2021

• 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.
• 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.

Product Roadmaps for CTOs, 2021

• 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:
• 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.
• 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.
• 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.

M88 คือใคร ทำความรู้จักกับเว็บไซต์พนันออนไลน์ชั้นนำของเอเชีย, 2021

• 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.
• 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
• 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.
• economic incentives, b) ‘contractual’ obligations, and c) culture. These three tools make up your org design toolbox.
• 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.’
• 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.”

3 Lines of Code Shouldn't Take All Day, adam, 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, 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, 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, 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 Pushed 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, 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 (or how I learned to love my monkey mind), 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, 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.

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)

The Boring Technology Checklist, Brian LeRoux, 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

Unlearning Perfectionism, 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.
• 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.
• 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.

Managing people 🤯, 2022

• 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?)
• 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.
• 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
• 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.
• 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
• 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
• The worst thing that can happen is that you frequently step in, and people disassociate from their work
• 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.
• It's a common misconception that burnouts come from hard work.  Burnout comes from a felt loss of control and/or impact.
• 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
• 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
• Firing should never be a surprise People should never be surprised that they are fired Context changed, new requirements should have been communicated

I relearned typing to save my wrists, zsa, 2022

• 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
• 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
• 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.

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)
• 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.
• 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.

A career ending mistake — Bitfield Consulting, 2022

• 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
• 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.
• 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, 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

• 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.
• Get out of the trap First, you need to lower everybody’s expectations, ASAP. Make and broadcast cuts
• 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?

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
• 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.
• 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?

How to design better APIs, Ronald Blüthl, 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

• 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.
• 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, Engineering Lead, Product Lead, Sales Lead.

Putting Ideas into Words, 2022

• 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.
• 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.
• 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 terrible things I'd do with your money, Tim Daubenschütz, 2022

• 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.
• 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.

Why is selling software so weird?, 2022

• 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.
• 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.
• 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.
• 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.
• 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.

The Things We Did Not Do While Reaching $2M ARR, Philippe Lehoux, 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
• 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.
• , 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

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.

https//www.sequential.dev/posts/be-less-technical/, 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?, 2022

• 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?
• 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.

11 Principles of Engineering Management, Alan Johnson, 2022

• 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.
• 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.

https//ano.ee/blog/the-niche-programmer, 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, 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, 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

• 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.
• Market pressures don’t apply to internal teams, which can be both good and bad.
• 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, 2022

• 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 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.
• 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.

Log Into Facebook, 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, 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, Roman Kudryashov, 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.

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

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.

https//kerkour.com/overthinking#/%2F=, 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, 2022

• 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.
• 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

The New American Micro-SaaS Dream, 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."

Your customers hate MVPs. Make a SLC instead., Jason Cohen, 2022

• 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
• 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.
• 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.

The Mind of a Benevolent Dictator, 2022

• 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
• 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

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

• 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.
• 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.

From idea to paying customer Intro Linen is a tool to sync Linen #blog, 2022

• 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…)
• 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.
• 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.

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, 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, 2022

• 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.
• 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:

The Demo → Demo Loop, Dave Rupert, 2022

• 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.
• 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 energy to suggest change, 2022

• 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.
• 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?

Tiny abstractions with functions in Go., 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.

I talked to Leonardo da Vinci, 2022

• 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.
• 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

Why long-term plans don't work and how to fix them, 2022

• 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.
• 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.
• 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.

The Einstein Principle Accomplish More By Doing Less, Study Hacks, 2022

• 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.
• 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.
• In Search of Your Own Theory of Relativity
• 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.
• 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.

Software Visualization — Challenge, Accepted, Renato Kalman, 2022

• The C4 model is a lightweight and straightforward approach to visualizing software architecture.
• 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)

How we built a $1M ARR open source SaaS, Marko Saric, 2022

• 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
• 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
• 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.
• 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
• 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.
• May: First mention on a prominent site ($1,055 MRR) May started great as we were featured on OpenSource.com

15 best startup marketing practices we say "no" to (while growing our MRR by 1000% in 6 months), 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, 2022

• 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
• 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.

https//www.martinweigel.org/blog/2017/11/13/why-success-stories-are-just-propaganda, 2022

• 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.
• 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.
• 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.

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.
• A much better model for the "sustainable creator" is creating on the side of the one-person business.
• 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
• 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
• 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.
• Buy tools that make you more productive. In my case this means paying for Grammarly, Canva, my note-taking tool (Craft) or Centered app
• Build side projects to learn more about yourself. I have always done this, building dozens of side projects over the years.
• Social media not used as a channel to make a living off
• 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?
• Understand the models of making money
• 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.

How I write React after 8 years, Nessim Btesh, 2022

• 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.
• 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).
• CSS: Use styled components
• 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
• 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.
• ComponentsA typical component is compromised of a folder followed by an index file and a style.js file.
• Security — Authorization into routesSecurity should be managed at the route component, not the children.
• Don’t use (almost) any libraries:
• Centralizing API calls in one place

Publishing your work increases your luck, 2022

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

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

• 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.
• 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.

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 (or how I learned to spend money on ads), 2022

• 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.
• 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.
• 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.
• 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?
• 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?

⭐️ 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

• 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.
• 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.
• 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.
• 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…
• 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?)
• 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.

No distribution, no dice, 2022

• 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?
• 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:

8 Ways to Crank Up Speed in Software Development, 2022

• 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.
• 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.
• Technical Debt is a deliberate decision to implement not-the-best solution or write not-the-best code in order to release software faster.
• 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
• 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.
• Domain knowledge is crucial for any software developer. It helps to understand problems deeper, create better solutions faster and reduce re-work.
• 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, Joydeep Bhattacharya, 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, 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?, 2022

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

The Stair Step Method of Bootstrapping, 2022

• 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.
• 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.
• 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.
• 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.

Less is more agile, 2022

• Worrying about deadlines is dysfunctional. Allen made this point about agile: If you’re not happy, you’re not doing it right
• 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)
• Agile has come to mean doing half of scrum poorly and using Jira

1001 SaaS Product Ideas, Jon Yongfook, 2022

• 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.
• How might we make this faster? How might we make this more relevant to remote work? How might we 10x improve the developer experience?
• 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.
• 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?
• 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.
• How might we make this better for Japanese users? (insert your language here) How might we make this specfically tailored for special diets / religions?
• 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 privacy-friendly? How might we make this into a premium product vs. an infrastructure product? How might we make the pricing easier to understand?

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.
• 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.
• 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.

Be good-argument-driven, not data-driven, Richard Marmorstein, 2022

• 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.
• 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?
• Be skeptical! Have no tolerance for poor arguments made with data. Keep intrinsic motivation alive.
• 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.
• Can you run an experiment?
• 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.
• Are you prepared to do some very very fancy statistics?

Becoming a Systems Architect, 2022

• 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
• 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.

🧠 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.

How leaders should invest their time 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, 2022

• there. In case you are wondering: those crazy ideas come mostly in the form of associations between seemingly-unrelated concepts.
• 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.

Twipped/InterviewThis, 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, Study Hacks, 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, Dave Rupert, 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, 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.

https//fs.blog/second-order-thinking/, 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

• 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.
• 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.

Resources & Tools for Managers, 2022

• 20 Great Open Questions

20. Framing, 2022

• 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.
• There's a commitment to spend time shaping, but not yet a commitment to go into a build cycle.
• 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.
• The principle of treating projects as bets and capping our downside is sound.
• 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."
• 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.

22. Design systems, modularity and interdependence, 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, 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

• 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.”
• 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.
• 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.”

Engineering Org Structures, Joseph Gefroh, 2022

• 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.
• 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.
• 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.
• 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

How To Read A Book, Dmitri Brereton, 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

• 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.
• 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

Work Is Work, 2022

• 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
• 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.
• 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, 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, 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

• every templating language inevitably turns into a very poor programming language over time
• Just know: nobody else is going to do it for you. So what are you waiting for?
• 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.
• 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.

Prototyping to learn, Dave Rupert, 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.
• 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?”
• 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

davidamos.dev, 2022

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

How I Think About Product Management, 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 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).
• 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.

The Prioritization Manifesto, 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
• No” is no to one thing. “Yes” is no to a lot of things. “No” creates optionality.
• Every project pitch should always have a hypothesis statement;

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?, 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?
• 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.
• 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.

Seven Shipping Principles, 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.

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.

You don't need Scrum. You just need to do Kanban right., 2022

• 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.
• 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
• 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.
• 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.
• 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.
• 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.
• 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.

Developing SaaS? Forget Scrum, Check Out Kanban and Similar Approaches, 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:

https//dskelton.medium.com/this-simple-team-activity-builds-psychological-safety-a61759284ddb, 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.
• 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.
• 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.

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

• 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.
• 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.
• 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.
• But one of the CTO/VPE’s most critical roles is knowing when it’s necessary to first go slow to go fast.

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, 2022

• 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.
• 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 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.
• 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.
• 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."

AI will replace middle management before robots replace hourly workers, 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, 2022

• 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.”
• 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.

My take on why goal cascades are harmful and what to do instead, Jason Yip, 2022

• 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
• 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
• Goal cascades are inherently delayed.
• 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.
• Optimal action never comes from simply aligning to top-down goals as they cascade through the organisation.
• Persistent models enable parallel planning

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

• We also researched other tech companies’ engineering principles and values and found things worth emulating or eliminating from our own
• 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
• 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.
• 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

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.
• 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.
• 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.

All Companies are Fucked Up, 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, 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, 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? (Hint Not Much), Study Hacks, 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.
• 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.
• 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.)

How writing helps Doist's asynchronous setup soar, 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 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. 
• We do have meetings to discuss particularly heated topics and succinctly communicate ideas on projects that require high-bandwidth collaboration. 

https//firstmark.medium.com/githubs-cto-on-architecting-engineering-teams-that-scale-cb79dd6132ae, 2022

• 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.
• 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.
• 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.
• 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.
• “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.”
• 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.
• 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, 2022

• 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.
• 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.

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

• 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.
• 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.

https//corporate-rebels.com/asynchronicity/?utm_campaign=tmw-ctocraft&utm_medium=email&utm_source=Revue%20newsletter, 2022

• 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 transparency
• Focus on writing
• Focus on results
• 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.
• Focus on documentation

Staring into the abyss as a core life skill, 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.
• 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.
• 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
• 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

• 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.
• 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.
• 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.
• 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

• 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?
• Scrum Teams became cogs in the machine of the delivery of goods, the software, to the clients.
• As long as the working environment of developers doesn’t change, every approach will fail to bring them relief.

Unpacking Boris, 2022

• 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.
• 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.

What You (Want to)* Want, 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

• 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?
• 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.
• 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.

First time with Basecamp’s ShapeUp, 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, 2022

• The power of complexity debt is that it acknowledges that production code doesn’t live in a vacuum.
• As Kim quotes, in 2003 Ward Cunningham said “technical debt is what you feel the next time you want to make a change”
• 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

What is “engineering for software?”, 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, 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.
• 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.
• the best way to ensure nothing gets done is to design by committee
• 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.

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

• 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
• 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
• 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.
• 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.

Tech leadership mistakes that ruin productivity (and how to fix them), Jason Lengstorf, 2022

• 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.
• 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.’

No-code isn’t scalable. Our learnings at FINN going from 1000 toward 100,000 car subscriptions, Ishtiaque Zafar, 2022

• 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
• 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”.

The 37signals Guide to Internal Communication, 2022

• 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.
• 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.
• 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.

Stand-Up Meetings Are Dead (and What to Do Instead), 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 2023, The Measure of a Plan, 2023

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

https//yehohanan7.medium.com/why-domain-driven-design-203099adf32a, 2023

• 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.
• 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”.
• 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.
• The formal definition of an Entity is: “An object fundamentally defined not by its attributes, but by a thread of continuity and identity.”
• In essence, Accuracy is not very important, but usefulness is!
• “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.
• 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.

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
• 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.
• 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
• Identify and reinforce your “First Team”
• 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.
• 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.
• 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
• 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.
• 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.

Write Admin Tools From Day One, 2023

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

What is a CTO? Job description, responsibilities, and salary expectations, Josh Fruhlinger, 2023

• 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
• 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

Manage like an engineer, Ben Balter, 2023

• 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
• 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?
• 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.

How to write a great extended leave document, Ben Balter, 2023

• Share early and often
• Stuff you touched recently or hope can be picked up while your out
• 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:

"Arbeiten, wie ich wirklich, wirklich will.", Dorit Kowitz, 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.

Leaders show their work, Ben Balter, 2023

• 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
• 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.
• 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
• 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

Software engineering practices, 2023

• 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.
• Automated code formatting
• Documentation in the same repo as the code

We invested 10% to pay back tech debt; Here's what happened, Alex Ewerlöf, 2023

• 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.
• 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.
• TPD trio (tech, people, domain), I was familiar with the tech and people but relatively new to the domain.

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, 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., 2023

• 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.
• 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 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).
• 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!

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, 2023

• 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
• 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

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.

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”

Taking the Initial Phone Screen with Candidates, David Gomes, 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

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, Dave Rupert, 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, 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., 2023

• 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
• 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.
• In a team management role, you’ll be encouraged to lean on your team for technical leadership rather than fulfilling both roles.
• 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.

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

• 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.
• 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.

undefined, 2023

• 1. User Story Map
• The 8 Different Ways to Organize Your Backlog

Inspiration is perishable, 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., 2023

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

How I give formal written feedback, quad, 2023

• for their feedback on drafts of this!)
• I show what I’ve written “Here's what I got! [link to a doc]”
• 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 only share what we agree upon
• 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?”

People can read their manager's mind, 2023

• 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.
• 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.
• 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.

Why backlogs are harmful, why they never shrink, and what to do instead, 2023

• 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”.
• 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.
• 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.
• 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.
• Backlogs exist because they’re a great way to avoid difficult conversations and shift blame away from product to engineering.
• In other words, a product manager’s job is to prioritize ruthlessly, and maintaining a long backlog is anything but good prioritization.
• 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

Getting people to care about what you're building, 2023

• 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
• 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.
• 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

https//vue-mjs.web-templates.io/blog/javascript, 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

Your Success Is Not Your Own What Matters Most As An Engineering Leader, Aditya Agarwal, 2023

• 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?
• 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.

The case for frameworks, 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

• 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.
• 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:

23. Noise factors vs. control factors, 2023

• 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 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.
• 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
• 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.
• 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 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.

https//www.gatesnotes.com/The-Age-of-AI-Has-Begun, 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

• 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.
• 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.
• Reduce the risk as much as possible before building anything
• 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.

Policy on util packages, 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.

https//lucasfcosta.com/2023/03/16/processes.html, 2023

• That approach, creating small constraints, is easier for humans to follow and doesn’t instill a bureaucratic culture into the team.
• 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.
• 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
• 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.
• 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.
• 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.
• 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.
• 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, 2023

• 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.
• 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.
• 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
• 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.

Throwing an Exception 3 types of decision and what to do in each case., Simon Cross, 2023

• 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.
• 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”.
• 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.

What I Learned At Stripe, 2023

• 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
• 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.
• 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, 2023

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

The simplest thing that could possibly work, 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.

undefined, 2023

• Remember those user stories with a format of:As… I want to... To allow...Well, a JTBD story is as follows:[ When _____ ] [ I want to _____ ] [so I can _____ ]Specifically, the when focuses on the situation, the want focus on the motivation, and the can focuses on the outcome

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

• 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
• 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

Running your engineering onboarding program., 2023

• 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
• 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

How to have buckets of time, 2023

• 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.
• 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.
• 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

• 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
• 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
• 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.
• 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.
• 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.

Continuous Flow, Martin Fowler, 2023

• 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.
• 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

The Future of Applications, 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, 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?, 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, 2023

• Projects start with a name, the people involved, and, typically, a kickoff message describing the project in a few hundred words.
• 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
• 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

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!

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

• 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.
• 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.
• 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.
• 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.

https//theengineeringmanager.substack.com/p/fast-forwarding-decision-making?utm_source=substack&utm_medium=email, 2023

• 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
• 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.

https//jchyip.medium.com/the-age-of-cargo-cult-agile-must-end-9408e1d13e1d, 2023

• 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.
• 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”.

Efficiency trades off against resiliency, Nelson Elhage, 2023

• 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.
• 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.
• 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.

Give it the Craigslist test, 2023

• Focus on content and functionality when you’re designing new products; that’s the validation that will build a business.
• 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

Keep the monolith, but split the workloads, Lawrence Jones, 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, 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., 2023

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

How To Design Software Architecture For Startups, Christoph Burnicki, 2023

• 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.
• Consider building reusable things
• Systems that talk a lot to each other - and only synchronously - should not be separated at first, even if their domains suggest it
• Boundaries along sync/async communication patterns
• Move fast and outsource things
• Microservices usually don't work well for startups

The Leverage of LLMs for Individuals, 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.
• 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.
• 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.
• 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., 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.

undefined, 2023

• 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 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.

undefined, 2025

• est-kept secret of the sof
• ch. No code, no ma
• way to pretend that the code you wrote last month no longer exists! Now that it has been stuffed into a container and tucked behind a load balancer it's a ser

On Opening Essays, Conference Talks, and Jam Jars, 2025

• This talk is about X: a compelling problem with consequences for this audience, for which I have some suggested solutions • We’re going to talk about A, B, C, and D, in that order
• Once you know you have a consequential problem for a community and some sense of a solution, you get to play with narrative details. This is the fun storytelling part
• Problems are a destabilising condition that has a cost for a community of readers that needs a solution. Destabilising condition is just a fancy word for “change” here – a change in the status quo. Put another way, a problem is an expected turn of events, that has undesireable consequences, for an audience who will care about it, that we want to explore solutions t

A Vision For Product Teams, 2025

• Most jobs involve some blend of judgement and process, and the process aspects are prime targets for the tools. What remains is the judgement. For a description of this judgement as it pertains to product managers, see the article AI Product Management.
• The Discovery Trio Becomes The Product Team

The Software Engineering Identity Crisis, 2025

• This is where a glimmer of hope emerges. Remember that irony - how we gave away the broader aspects of our craft to specialists? AI is pushing us to reclaim what we once knew: that software engineering transcends mere coding
• What’s clear is that the definition of “software engineer” is expanding, not contracting. The skills that make someone valuable are diversifying. And this creates both challenges and opportunities
• a recent CIO article confirms that development teams are already being restructured to focus on oversight rather than creation

Ask for no, don’t ask for yes, 2025

• When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to, it’s common to reach out and ask them for permission. Don’t. Don’t ask for a yes. Instead, offer a chance to say no, but with a deadlin

Here’s how I use LLMs to help me write code, 2025

• Most of my projects start with some open questions: is the thing I’m trying to do possible? What are the potential ways I could implement it? Which of those options are the best?

The Death of the Stubborn Developer, 2025

• f you’re building a car, you can have all the individual parts 3D printed for you, which is more or less what LLMs are doing for code. But someone still needs to build the car

The Art of Interviewing Your Interviewer to Uncover a Company’s True Culture, 2025

• To get a sense of how the company evolves, ask: “Can you tell me about a time when the company culture had to evolve?” This can reveal how adaptable the company is and whether it’s willing to change in response to new challenges or employee feedback.
• Every company has its flaws, and sometimes, understanding these can be more valuable than hearing about the positives. Consider asking: “What’s something you think the company could improve on?” This question can reveal potential red flags, but it can also show you how transparent and self-aware the company is about its shortcomings.
• A company’s culture is often reflected in how it celebrates success and fosters growth. Ask: “How does the team celebrate when someone reaches a milestone or achieves a significant goal?” This question can give you a sense of whether achievements are recognized and rewarded, or if they’re simply brushed aside in the rush to the next deadline.

How to Negotiate Salary for New CTO Job, Stephan Schmidt, 2025

• If you are asked early on, make it clear you want to fit in, but see yourself on the upper range of their pay scale. If pressed, communicate a range depending on your country say “I’d be very happy for 200k, the bare minimum would be 150k”. Even when they ask, never talk about your old salary, except if it was exceptionally above market.
• What if they reject your demanded salary? If they can’t go with your range, offer options. It’s always better to offer someone some options, “A, B or C,” where they choose one, instead of making it a “Yes/No” demand. Options could be binding the salary to milestones or deliverables:
• Demand more than you are comfortable with. That is the easiest way to get some thousands of dollars for free. Sure, there are heart-stopping minutes, but it is still the easiest way to make lots of money.