How I Think About Work Now (vs. Ten Years Ago)
When I started my career, I optimized for speed and immediate results. Ship fast, get paid, move on. Now, after 15 years of building things, I’ve learned to defer gratification and focus on work that compounds. These aren’t rules carved in stone—they’re principles I try to follow when I remember to. Here’s what I’ve learned about doing work I’m proud of while still enjoying the process.The Principles I Try to Follow (Most Days)
1. Build Things You’d Actually Use
Early in my career, I built whatever clients asked for. Now I only work on products I’d personally want to exist. It’s a simple filter that saves everyone time. When I built a recruiting tool recently, it wasn’t because I thought it would sell—it was because I was frustrated with my own job search. That personal investment shows in the final product.2. Use Your Weird Advantages
I used to hide my generalist background, thinking I needed to be a specialist. Turns out, being able to code, design, and understand business is my actual advantage. Whatever makes you different is probably your strength, not your weakness. I can prototype an entire product solo in a weekend—and ship it to paying customers by the following one. That’s not normal, but it’s valuable.3. Ship Early, But Not Broken
I used to ship anything that technically worked. Now I ship the smallest thing that provides real value. There’s a difference between MVP and “barely functional.” The key question: “Would I be embarrassed if this was the only version that ever existed?” If yes, it needs more work.4. Delete More Than You Add
Young me added features to seem impressive. Current me removes everything that doesn’t directly solve the problem. Complexity is debt you pay forever. Every feature you don’t build is a bug you don’t have to fix and documentation you don’t have to write.5. Learn From What Actually Happens
I used to plan everything meticulously. Now I build something basic, watch how people actually use it, then adjust. Real user behavior beats any planning session. My best features have come from watching users do things I never expected with my products.6. Automate the Boring Stuff
Life’s too short to do repetitive tasks. If I do something twice, I write a script. If I do it three times, I build a tool. This frees up time for interesting problems. The time spent automating pays for itself in sanity alone.7. Work With People Who Ship
I’ve learned to quickly identify the difference between people who talk about ideas and people who build them. I only work with builders now. Talkers drain energy; builders create momentum. If someone hasn’t shipped anything in the last six months, they probably won’t start now.8. Trust Your Gut, Verify With Data
Data tells you what happened, not what should happen next. I use metrics to verify my instincts, not replace them. If the data says one thing but your gut says another, dig deeper. Some of my best decisions looked terrible on paper.9. Solve Problems You Understand
I only work on problems I’ve personally experienced. This isn’t limiting—it’s focusing. You can’t fake deep understanding of a problem space. Every successful product I’ve built solved a problem that personally annoyed me.10. Make Decisions Reversible
Instead of agonizing over permanent choices, I structure decisions so they can be changed. Use feature flags, modular architecture, month-to-month contracts. Reversible decisions can be made quickly. Irreversible ones deserve the time.11. Value Capability Over Credentials
The best developer I ever hired was a philosophy major. The worst had a CS degree from MIT. Look at what people have built, not where they studied. Portfolio beats pedigree every time.12. Give First, Ask Later
I share code, connections, and knowledge freely. Not from altruism—it’s the most effective way to build a network that actually helps when you need it. The ROI on generosity is higher than any other investment I’ve made.13. Improve Daily, Don’t Pivot
Big pivots usually mean you weren’t listening. Small daily improvements compound into major evolution. I’ve never had a successful dramatic pivot, but many successful gradual transitions. The product I’m proudest of looks nothing like version one, but every change made sense at the time.What Changed As I Got Older
In my 20s: I optimized for looking smart and moving fast. Quick wins, impressive demos, maximum activity. In my 30s: I started optimizing for impact and sustainability. Better problems, deeper solutions, less motion but more progress. Now: I optimize for work I won’t regret and people I enjoy building with. Life’s too short for boring problems or difficult people.Why This Approach Works (For Me)
This isn’t about being lazy or cutting corners in the traditional sense. It’s about being intentional with effort. Put maximum energy into what matters, minimum into everything else. The goal isn’t to work less—it’s to ensure the work you do actually matters.The Reality Check
These principles sound great, but I fail at them constantly. I still overengineer solutions, work with difficult clients for the money, and ship things I’m not proud of. The point isn’t perfection. It’s having a north star to navigate by when you notice you’re off course.Start Where You Are
Pick one principle that resonates. Try it for a week. See what happens. Adjust based on your reality, not mine. The best principles are the ones you develop yourself through experience. These are just what I’ve learned so far. Your lessons will be different, and that’s exactly how it should be.Building the future isn’t about following someone else’s playbook. It’s about developing your own through deliberate practice and honest reflection.