Remote Work Best Practices
Recently, I’ve been surprised to note how many companies aren’t just returning to offices (ugh, open offices are the worst!), but are still actively unwilling to do remote work well.
Here are some hints for things that I’ve learned can be helpful, after working remotely for a few years at a variety of companies - some that were remote-first or remote-only, and some that didn’t have mature practices around it:
Against Demo Driven Development
Some folks love doing demo days, but I find it sometimes gets in the way of actual work, creates more work in the long run, and/or can be downright demoralizing (especially to backend teams). Here’s why.
What is demo-driven development?
• Building something specifically to be able to show it off
• Rushing to get stuff in before an arbitrary deadline
• A way to get people motivated by an audience (positive) or shame (negative)
Vibe Coding
Some observations on vibe coding
I get a lot of questions about working with LLMs. Something I hear people discussing a lot is whether AI-generated code is better, or worse, or just more evil than human-generated code. I don’t think it’s an either/or question. To me, it’s just another tool: like most tools, there are ways to use them for good, or as weapons.
I think vibe coding is great if you need to write a one-off script that isn’t intended to be part of production code. For example, I asked Claude to help me come up with ways to generate fairly large test data sets for my last project, and it decided to write me a script to do it. This worked beautifully for what I needed, and saved me a ton of time. I did have to iterate on the prompt a bit to get it to do what I wanted, and that was a little nerve-wracking, so I saved off the different versions of the code (because sure enough, sometimes it got worse in ways I didn’t expect).