Why Working With Me Is Not Easy
If you're a software developer thinking about working with me, you should know upfront: I'm demanding. I expect deep thinking, not surface-level implementation. I believe in Elon Musk's principle that all requirements are stupid and should be challenged. You need to balance being challenging with doing your duty.
Working with me requires consistent production paired with deep introspection about the customer and the product—not just building software. This balance is difficult. It takes tremendous practice and discipline to get it right.
You Must Understand the Product Tremendously
This is non-negotiable. You can't write good software if you don't understand what you're building and why it matters.
I don't care if someone asks you to work on something—you have to get into the mindset of the person using it and go through all their pain. You need to experience their frustrations, understand their workflow, and feel their daily challenges.
Think About All the Stakeholders
Software doesn't exist in a vacuum. You need to think about multiple realms of impact:
- The person using it - Get into their mindset. Understand their pain points, their workflow, their daily frustrations. Don't just implement features—understand why they need them.
- The people who administer the system - Think about their pain. What happens when something breaks? How do they monitor it? What's their operational burden? Your code will live in their world.
- The end person who benefits - Not just the user operating the software, but the person who ultimately gets value from it. Who is the real beneficiary? What outcome are they seeking?
- The investor - What are they expecting to get out of this machine? What's the return? What's the business model? Your code is part of an investment, and you should understand what success looks like.
I expect all software developers to think about this and understand it. Otherwise, they can't possibly do work for it. They can maybe implement a function, but then they become a robot; they become essentially a de facto LLM.
What Deep Technical Thought Actually Means
When I say I expect deep thought, one of the first questions I hope you'll ask is: "What's the open standard?" "What's the protocol for this?"
I expect you to understand what the protocol is and what the open standard is. You don't have to memorize exact pieces of information, but you have to understand why the technology exists, why the OpenSpec was built.
You need to have a pretty good understanding of that, and then look at some of the libraries there. Look at the people who committed to them to understand who the people are that are actually doing the work.
This doesn't take that long—maybe 20 minutes.
Understand the companies that are investing in these groups. What are the open forums for these technology stacks that you're going to be working with?
So when you go to work with a library, you have a pretty good understanding of what those pieces are. You're not just throwing in a piece of code and executing on it. You're taking ownership of that knowledge.
The trade-off is to get as much value as you can with as small investment as possible. But I would argue that the overinvestment in reading for half an hour in quiet with all your phones turned off, everything turned off, and just reading is going to win.
The Bottom Line
If you want to work with me, you need to be more than a code implementer. You need to be someone who thinks deeply about the product, understands the stakeholders, knows the technology stack, and takes ownership of the knowledge you're using.
Otherwise, you're just a robot executing tasks. And that's not what I'm looking for.