Skip to content

Instantly share code, notes, and snippets.

@originalhat
Last active February 12, 2021 21:40
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save originalhat/f4fb013b9014ce584403d6ca6f925b8f to your computer and use it in GitHub Desktop.
Save originalhat/f4fb013b9014ce584403d6ca6f925b8f to your computer and use it in GitHub Desktop.
Things I believe

Things I Believe

Inspiration: Things I believe · GitHub

Fundamentals

  1. Make it simple, then make it even more simple.
  2. We're paid to think, not write code.
  3. Articulated your thoughts with others.
  4. Always retrospect on what could have gone better.
  5. Avoid sunk cost; past isn't prologue.
  6. Any task can be understood, broken down, and solved.
  7. Good isn't the same as good enough.

Personal development

  1. Getting paid is good, learning is even better.
  2. Expand your knowledge beyond code. Learn different things. Have hobbies, and close relationships.
  3. Get a good night's sleep, challenge yourself physically, nourish your body.
  4. Seek out oppositional perspectives.
  5. Strong opinions weakly held.
  6. Don't work in isolation. Share your ideas.
  7. Read many books.
  8. Keep good company.
  9. Protect your time. Don't let the priority of others derail your efforts.
  10. Get up early.

People

  1. Always be kind.
  2. Gauge your audience. Some need encouragement, others need a challenge.
  3. Software is not about code, it is about people.

Teams

  1. Team needs come first.
  2. Hire those better than you.
  3. Prioritize trust and alignment.
  4. Teams own outcomes, not code.
  5. Team members who don't align with team objectives should be shown the door.
  6. Embrace healthy discourse.

Leadership

  1. Listen.
  2. Success lands on your team, failure lands on you.
  3. Leadership sets the precedent. Actions speak louder than words.
  4. Always over-communicate.
  5. Delegate. Empower your peers. Set them up for success.
  6. Clearly understand the why. Communicate this over and over again with your peers.
  7. Who you promote is what you encourage.
  8. You can't please everyone.

Process

  1. People over process.
  2. Process can and should be modified to meet the needs of the team.
  3. Keep meetings to a minimum. Make meetings shorter. Have a clear goal and agenda.
  4. Always question past assumptions.
  5. Be willing to try new things.

Delivery

  1. Whatever you're doing, start with the customer in mind.
  2. We're here to deliver value to the business.
  3. Deliver as often and as quickly as possible.
  4. Automate.
  5. Acceptance environments are a smell.
  6. It's better to deliver something imperfect that nothing that's perfect.

Testing

  1. TDD/BDD is an exercise in up-front thinking.
  2. Up-front thinking results in better design.
  3. Business logic in the system requires tests.
  4. Tests should strive to test behavior, not implementation.
  5. Automate. Routine is for computers, originality is for humans.
  6. Test as close to production as possible.
  7. Tests /are production code/.
  8. Understand the different types of tests. Keep them in your toolbox, use where appropriate.

Observability

  1. Production systems should be monitored appropriately.
  2. There's more to monitoring than tracking stats; spend some time understanding how it works.
  3. If alerts aren't actionable, delete them.
  4. Monitoring starts with the customer's experience.

Technology

  1. Most new tech is bunk; vet with caution and clear intentions.
  2. Be realistic.
  3. CS fundamentals and engineering generally don't change much over time.
  4. Tooling choice is generally more pertinent to the specifics of the team.

Code

  1. Code is a liability, not an asset. Aim to have as little of it as possible.
  2. Test are your documentation.
  3. Algorithms have their place. Generally the way we reason about problems is more important.
  4. Build for an ignorant future self.
  5. Optimize for change.

Design

  1. Be skeptical about over the top-design. Simple primitives will generally do the trick.
  2. Push back on requirements that seem excessively complex; you're the advocate for technical simplicity.
  3. A better system is often a smaller, simpler system.

Building systems

  1. Favor a system that allows change over validity.
  2. You probably don't need microservices. Be aware of the costs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment