How I Think About Work Now (vs. Ten Years Ago)
How has your approach to work evolved over your career?
After 15 years of building things, I’ve shifted from optimizing for speed and quick wins to focusing on work that compounds. These principles aren’t rules—they’re guidelines I follow when I remember to.
The Principles I Try to Follow (Most Days)
What are the key principles for building meaningful products?
Focus on building things you’d use, leverage your unique advantages, ship early but not broken, and automate repetitive tasks. These principles prioritize impact over activity.
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
How do priorities shift as developers gain experience?
In your 20s you optimize for speed and looking smart, in your 30s for impact and sustainability, and eventually for meaningful work with people you enjoy. It’s a shift from motion to progress.
Why This Approach Works (For Me)
Why focus on being intentional with effort rather than just working hard?
It’s not about working less—it’s about ensuring your work actually matters. Put maximum energy into what’s important and minimum into everything else.
The Reality Check
Do these principles always work perfectly in practice?
No. I fail at them constantly—still overengineering, taking difficult clients for money, shipping things I’m not proud of. The point isn’t perfection but having a north star.
Start Where You Are
How should someone apply these principles to their own work?
Pick one principle that resonates, try it for a week, and adjust based on your reality. The best principles are ones you develop yourself through experience.
Frequently Asked Questions
How has your approach to work evolved over your career?
How has your approach to work evolved over your career?
After 15 years of building things, I’ve shifted from optimizing for speed and quick wins to focusing on work that compounds. Early career was about looking smart and moving fast; now it’s about ensuring the work actually matters and creates long-term value. These principles aren’t rules—they’re guidelines I follow when I remember to.
What are the key principles for building meaningful products?
What are the key principles for building meaningful products?
Focus on building things you’d actually use, leverage your unique advantages, ship early but not broken, and automate repetitive tasks. The core philosophy is prioritizing impact over activity. Every feature you don’t build is a bug you don’t have to fix and documentation you don’t have to write.
Why is it important to build things you'd personally use?
Why is it important to build things you'd personally use?
Personal investment shows in the final product. 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 and ensures authentic problem-solving rather than just feature implementation.
How do you identify and leverage your unique advantages?
How do you identify and leverage your unique advantages?
I used to hide my generalist background, thinking I needed specialization. Being able to code, design, and understand business is actually my advantage. Whatever makes you different is probably your strength. I can prototype and ship entire products solo in a weekend—that’s valuable, not normal.
What's the difference between shipping early and shipping broken?
What's the difference between shipping early and shipping broken?
Ship the smallest thing that provides real value, not just anything that technically works. The key question: “Would I be embarrassed if this was the only version that ever existed?” If yes, it needs more work. MVP doesn’t mean “barely functional.”
How do priorities shift as developers gain experience?
How do priorities shift as developers gain experience?
In your 20s you optimize for speed and looking smart, in your 30s for impact and sustainability, and eventually for meaningful work with people you enjoy. It’s a shift from motion to progress. Life’s too short for boring problems or difficult people.
Why focus on being intentional with effort rather than just working hard?
Why focus on being intentional with effort rather than just working hard?
It’s not about working less—it’s about ensuring your work actually matters. Put maximum energy into what’s important and minimum into everything else. The goal is making sure the work you do creates real value rather than just appearing busy.
Do these principles always work perfectly in practice?
Do these principles always work perfectly in practice?
No. I fail at them constantly—still overengineering, taking difficult clients for money, shipping things I’m not proud of. The point isn’t perfection but having a north star to navigate by when you notice you’re off course.
How should someone apply these principles to their own work?
How should someone apply these principles to their own work?
Pick one principle that resonates, try it for a week, and adjust based on your reality. The best principles are ones you develop yourself through experience. These are just what I’ve learned so far—your lessons will be different.
What's the most important mindset shift for building meaningful products?
What's the most important mindset shift for building meaningful products?
Move from optimizing for activity to optimizing for impact. Delete more than you add. Learn from what actually happens rather than what you planned. Trust your gut but verify with data. Make decisions reversible so you can move quickly without permanent consequences.
Building the future isn’t about following someone else’s playbook. It’s about developing your own through deliberate practice and honest reflection.