1/8 Folks conflate dev styles and tools, making conversations about the tradeoff challenging. 2/8 Monorepo-style development is a dev style where multiple projects are placed in the same repo. This gives you easy code sharing, cross-project refactoring, consistency, team mobility and more.

Costs: large repo could result in slower CI and harder-to-maintain code.

1/8 On Remote Work

One of the issues with online communication (chat or email) is that it creates a lot of pressure for the folks at the top of the decision-making hierarchy. 2/8 As with many software-related things, the natural constraints of the physical world are absent. Sometimes the lack of constraints is a good thing but often is not.

1/10 Focus is hard, at least for me.

My mind likes to jump around, so thinking about something for 30 mins is effortful.

Here are some things that help me: 2/10 Block everything.

This isn't as easy as blocking websites and apps. E.g., I need to use YouTube to review content or Slack so send a message, so I use a two-tier blocking.

1/8 My code style is getting simpler with every passing year.

Things I used to be into:
• Functional Programming (category theory etc)
• FRP (first and higher order)
• Domain specific languages
• Proper OOP (Smalltalk etc)
...

Today I barely use anything from the list. 2/8 Most of what I write today is basically "procedural + immutability". Every module has a few public functions. Each public function receives and returns immutable data.

(1/12) My work, to a large degree, is about examining ideas, building mental models, and finding connections between things. This is probably true about most senior software devs. Let me share some of my observations. (2/12) Tools like ROAM/Obsidian/Craft don't help **me** create knowledge. They are good at linking documents together, which helps me remember a lot of detailed stuff. But that's not knowledge creation, it's just remembering. And I think "remembering" is overrated.

(1/9) On task and project management, habits, focus, tools. (2/9) I don't start with projects or tasks. I start with notes and documentations.  Actionable emerges from non-actionable. (This of course applies to new stuff, not to the current list of things you have).

(1/13) Why startups loved Rails, why build tools matter, "thesis–antithesis–synthesis", and why should use Nx for your React and Node apps. (2/13) Ruby on Rails was huge in the startup world because it let you build amazing things in weeks (instead of months or years). Although often we focus on the framework part of Rails, a lot of the value was in the build tool.