No zero days, to avoid listless guiltSome days when I’m not getting anything done, I’ve got this lingering guilt that I’m having a “zero day”. This prevents me from fully enjoying whatever activity I’m doing. I’ve tried just giving myself permission to enjoy whatever I’m doing, but it just doesn’t work. Ostensibly I’m taking time off and recharging, but it doesn’t feel like that at all – it feels like pushing through. This can lead to a negative feedback loop, where I’m constantly trying to recharge, but just getting more tired.I’ve found the only way is to get some good work done first, then I can be fully immersed in whatever fun slacking-off activity I dive into.

Leave tasks unfinishedI can’t overstate how much this one helps me. I try to leave a task 90% finished at the end of a working session. It feels slightly worse than closing out the work, but it makes starting the next day 10x easier. Having a quick win when I start coding is a massive boost, and it immediately gets me into the flow state. It can’t be too easy though, if all I have left is to run git commit, that’s not enough. Ideally it’s something where I know exactly what I need to do, that will take 5-10 minutes.

I used to have the view that Scrum is a useless batch of meetings, that sucks the life and productivity out of the dev process.Now, after seeing it from an adjacent (but not subjugated under it) perspective, I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.Most of us here are not in that category. I’d wager a majority of HN readers can’t help but to seek out understanding of the business, where this piece fits, what it interacts with. For us, specifying everything upfront is useless. Estimating stuff is irritating because we need the flexibility to make smart decisions during dev. Retro meetings are lies because we can’t say “stop with all this and let me work”.But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision. That’s what scrum is; it feels like micromanagement because it is. It forces junior-performing devs into a productive state - maybe 5% of what you’d get out of a senior-performing dev without scrum, but it’s something non-negative.

When I walk my mind is somehow mapping my physical location in the world to the content, down to the sentence. If I rewind an audio book I can fairly often remember where exactly I heard a particular sentence. The precise street corner or park trail I was on, to like a 10 feet precision. I do not otherwise have strong memory. WTF brain.Does anyone else have this experience? I guess this is a peak into how 'memory palaces' work and how people memorize huge volumes of information?

Finally, the circuit breaker motivates teams to take more ownership over their projects. As we’ll see in the next chapter, teams are given full responsibility for executing projects. That includes making trade-offs about implementation details and choosing where to cut scope. You can’t ship without making hard decisions about where to stop, what to compromise, and what to leave out. A hard deadline and the chance of not shipping motivates the team to regularly question how their design and implementation decisions are affecting the scope.

When people ask for “just a few hours” or “just one day,” don’t be fooled. Momentum and progress are second-order things, like growth or acceleration. You can’t describe them with one point. You need an uninterrupted curve of points. When you pull someone away for one day to fix a bug or help a different team, you don’t just lose a day. You lose the momentum they built up and the time it will take to gain it back. Losing the wrong hour can kill a day. Losing a day can kill a week.

Thanks for writing Micheal, I’m also 30-something ex-Google SWE and currently all-in on solo dev bootstrapping, so your blog is one of my (many) big inspirations.As you note, I do think if your primary objective was to catch up to SWE compensation, your project idea filter was probably not optimal. But it’s still great that you have the spark of something with TinyPilot. One thing I see repeatedly in the indie hacker community is hockey stick success where people struggle to get the engine going but often once they find the spark it takes off. The ten year overnight success.Also worth noting many indie hackers add part time stable income such as contracting as their finances require.If people are looking for a straightforward path where they leave their SWE job and quickly get similar stable income as a bootstrapper, they’re in for an unpleasant surprise. But if you can “make it” you control your own destiny , face unique challenges demanding true creativity, and have uncapped upside in a way you’ll never get at BigTech .I do think content businesses are an easier launch point . Adam Wethan of Tailwind and Nathan Barry of Convertkit are both examples of bootstrappers who self-funded by starting with info products. I think one mental trap for solo devs is to over identify as SWE and not as online entrepreneurs with SWE skills as a particularly helpful asset.Wish you and TinyPilot the best of luck and look forward to future updates.

The biggest issue for me is that medium makes me feel like a cash cow. The way it wants me to pay every step of the way, the way it hijacks copy/paste to insert its own marketing. The account it wants me to create. The trackers it inserts everywhere. You missed the step of making something great that people actually feel good about paying for. The grassroots "for users by users" community feel that other platforms still manage to tap into. A site you'd be proud to be part of and happy to pay for. The problem with an X-views paywall is: you annoy me so much that even if there's good content behind it I'm long gone before I ever find out because you've already pushed me away. It just has this "all about the money" feel that I deeply hate.Also, not every author is out to make money. My personal blog is not monetized at all. It's more my way of outreach for my day job in tech. And I'd never want to put my readers through this experience. Free content should be exempt.The other points like the quality of content dropping because you recommend the wrong stuff, yeah they dropped the value proposition even more. But they weren't the real problem.

I really liked Shopify's remote model of not closing offices, but turning them into "ports" for teams in major cities to get together throughout the year for planning, team building, and retreats. You had an official place to get together, enjoy the perks of tech company offices, but with the intention of deep short bursts of interaction rather than focused work.

Five years from now, I think we will not see "remote only" for a large company and think "ooh, they value their employees I guess", but rather, "uh oh, they like to think of their employees as being like virtual servers, easy to spin up and easy to shut down the moment you don't need to pay for that capacity".

Perhaps the best piece of advice I ever got from Jeff Bezos was this: Invest in things that don't change. His example was that customers won't wake up one day and wish shipping was slower or the selection of goods poorer. So investing in logistics and warehousing was investing in things that don't change, and will continue to pay dividends for decades.

Beware the simple question: “Is this possible?” In software, everything is possible but nothing is free. We want to find out if it’s possible within the appetite we’re shaping for. Instead of asking “is it possible to do X?” ask “is X possible in 6-weeks?” That’s a very different question.

Search engine indexing is key to content discovery in the knowledge creation domain, but in a mobile-first world, it is extremely difficult to pull content across the walled gardens, whether or not there is a profit incentive to do so.

That’s it. That’s the only pro I could think of. What were some cons?• From January 1st, 2021, there was a “judge” behind my head, forming impressions and making “hmmmm” and “ummmm” noises when I picked up a book, failed to read on a consistent, schedule, etc.• I felt as though I could not pick up more difficult books and gain from them, as I felt that any longer and/or more difficult book would throw me off my path. I wanted to do some of the classic “Hard Books” ™ in 2021, and that never happened.• I also started to have the completely irrational thought that it somehow “wouldn’t count” toward the challenge if I just picked up and read something that I enjoyed, but that was immensely short. This included most poetry (though I did read some) and most graphic novels (ditto). This is a damn shame, because I would have loved to delve more into both of these genres, and will be doing so a lot more.

This is problematic because a project without a corresponding goal is known as a “hobby.” If you’re not committed to or haven’t fully articulated the outcome you want, you must be doing it just for fun. And if you have a goal without a corresponding project, that’s called a “dream.” You may desire it with all your heart and soul, but without an active project, you are not in fact currently making any progress.

You can easily see how failing to make this distinction leads to common frustrations: if you have a project that you think is an area (for example, the book I’ve been “writing” for a couple years now, that feels like a never-ending part of my life), it will tend to continue indefinitely. If you have an area that you think is a project (for example, a health outcome like “losing X pounds”), you’ll revert right back after it’s been achieved, because you didn’t put in place any mechanism for maintaining the standard.

I used to be very interested in Software Architecture, in fact I've read many of the papers cited here.When I did a startup many years ago, I committed the mistake of paying too much attention to the architecture of the software [1] I was writing, and not enough attention to the product/customer side of it.The last couple of years I've been de-emphasizing software architecture as an interest, and have been paying much more attention to how product teams build successful products, what the patterns are, etc. I was lucky enough to work at Facebook for a while and got to see (and learn) a very successful working model of product development.So, while I'm not saying that software architecture is not important (it is), also pay attention to the product/customer side: what choices (software, organizational, hiring, business) allow you to move fast and iterate, to release early and often, to run A/B tests, etc.I think good software engineers are just as much product guys (and data guys) as they are software guys.

Growth hacking and lowest common denominator experiences are their problems, so we should avoid making them our problems, too. We already have various tools for enabling growth: the freedom to use the software for any purpose being one of the most powerful. We can go the other way and provide deeply-specific experiences that solve a small collection of problems incredibly well for a small number of people. Then those people become super-committed fans because no other thing works as well for them as our thing, and they tell their small number of friends, who can not only use this great thing but have the freedom to study how the program works, and change it so it does their computing as they wish—or to get someone to change it for them. Thus the snowball turns into an avalanche.

I've had this discussion with peer engineers working at other tech companies, FANG (Facebook, Amazon, Netflix, Google), as well as at smaller startups. Most teams and projects - however large or small - all shared a similar approach to design and implementation:Start with the business problem. What are we trying to solve? What product are we trying to build and why? How can we measure success?Brainstorm the approach. Get together with the team and through multiple sessions, figure out what solution will work. Keep these brainstormings small. Start at a high level, going down to lower levels.Whiteboard your approach. Get the team together and have a person draw up the approach the team is converging to. You should be able to explain the architecture of your system/app on a whiteboard clearly, starting at the high-level, diving deeper as needed. If you have trouble with this explanation or it's not clear enough, there's more work required on the details.Write it up via simple documentation with simple diagrams based on what you explained on the whiteboard. Keep jargon to the minimum: you want even junior engineers to understand what it's about. Write it using clear and easy to follow language. At Uber, we use an RFC-like process with various templates.Talk about tradeoffs and alternatives. Good software design and good architecture are all about making the right tradeoffs. No design choice is good or bad by itself: it all depends on the context and the goals. Is your architecture split into different services? Mention why you decided against going with one large service, that might have some other benefits, like more straightforward and quicker deployment. Did you choose to extend a service or module with new functionality? Weigh the option of building a separate service or module instead, and what the pros and cons of that approach would be.Circulate the design document within the team/organization and get feedback. At Uber, we used to send out all our software design documents to all engineers, until there were around 2,000 of us. Now that we're larger, we still distribute them very widely, but we've started balancing the signal/noise ratio more. Encourage people asking questions and offering alternatives. Be pragmatic in setting sensible time limits to discuss the feedback and incorporate it, where it's needed. Straightforward feedback can be quickly addressed on the spot, while more detailed feedback might be quicker to settle in-person.