About Me
Software and Aerospace Engineer, 10+ years programming
I strive to be impactful and effective in my life merging the technical and philosophical to see and bring about a vision for a wise and secure future. I do this by being disciplined and reflective.
Focuses
- True “engineering” - figuring out what is actually needed, then solving that
- Application Development, user-facing, any stack (with a strong preference towards functional programming and a good developer experience)
- Enabling effective communication of difficult topics
Principles
Experience & Accomplishments
Over the years I've accumulated many principles of good engineering, and software engineering in particular:
- The single hardest part of building a system is deciding precisely what to build.
- Work backwards from user pain.
- Productivity is not measured by you, it is measured by your customers. Did they find what you did valuable?
- Test your ideas as soon as possible. Building a product is a science. Everyone thinks they're aligned until it's too late.
- If you don't have a specification, then all you have is a vague idea. Code is just a lossy projection of your specification.
- Quality in software is defined by our ability to change it.
- Code is not an asset - it's a liability.
- Your data model is your destiny - ask what the atomic unit of work is in your domain
- Dependency is the key problem in engineering development, at all scales.
- First make it work, then make it right, then make it fast.
- It is almost always impossible to implement a technical solution to a social problem.
- The devil is in the defaults, choose them wisely.
- No one will remember if you're 2 weeks late, but they will remember if you ship a bad product.
- You can't inspect quality into a product, you must build it in.
- Make the simple things easy, and the complicated things possible.
- Cutting scope isn't lowering quality - there's always more work than time. Shipping on time means shipping something imperfect.
- The first response to a new idea should be “Maybe Later”. Maybe, because it must be evaluated. Later, because it shouldn't disrupt current work.
- Favor people over processes. Don't just embrace entire systems, use the components that work for your situation.
- When a measure becomes a target, it ceases to be a good measure.
- Think in trade-offs and bets, not right vs wrong
Some of my favorite long-term problems to work on are:
- How to best track an idea for its whole lifecycle.
- How to distribute the benefits of the future (technology, philosophy) with the places of the world where it hasn’t yet reached
- How to evaluate what the most effective use of my time is across my life.
- How to build a moral system, from first principles. And can it even exist?
- How to make a company where everyone wins, build that culture and system.
- Designing a programming language which is both useful for building real applications and rigorous mathematically.
- How to get people talking politics with each other in a constructive way again, finding a way out of high conflict