Skip to content

Instantly share code, notes, and snippets.

@tjstebbing

tjstebbing/blogpost_principles.md

Last active May 8, 2023 13:20
Show Gist options
  • Save tjstebbing/27fcd1dc7e4ea2444f92707b1f50467f to your computer and use it in GitHub Desktop.
Save tjstebbing/27fcd1dc7e4ea2444f92707b1f50467f to your computer and use it in GitHub Desktop.
Download ZIP
Raw
blogpost_principles.md

+++ categories = ['thinks'] date = '2019-11-27' description = 'Perfection vs Pragmatism' slug = 'perfection-vs-pragmatism' title = 'Walking the Tightrope: Perfection vs Pragmatism' +++

Walk the Tightrope: Perfection vs Pragmatism

  • Every engineer wants their service / function / foo to be great, pure engineering pefection.
  • Your enemies are: lack of information, limited time on the task.
  • Create solutions that are appropriate to time / urgency (are pragmatic), then create a roadmap for future (to perfection).
  • Every component (service, function etc) has a roadmap from day one! (ROADMAP.md), 'the next 5 steps to be a better Foo' (this replaces 'tech debt')
  • Every component roadmap aligns with the broader engineering roadmap, the next person to work on the 'Foo' component can read the roadmap and understand the intended direction (and not just complain that it's 'crap'). As priorities change items from these component roadmaps will bubble up into our backlogs as appropriate.

See the Forest for the Trees

  • Always be able to explain how your current task fits into the bigger picture (team/company goals).
  • Always be aware of project deadlines and how the company is tracking to meet our obligations.
  • Understand why what you are working on today is a priority and how it fits in to the bigger picture.
  • If you don't understand these things, it's your responsibility to ask.

Travel the 'Happy Path' last

  • New engineers code the happy path, and then if you're lucky consider edge cases.
  • Consider Postel's Law: "Be conservative in what you send, be liberal in what you accept"
  • Document the edge cases, the unhappy paths first, and assign them a risk rating.
  • Write tests and code defensively against the top 80% (80/20 rule) (don't spend time defending against nuclear winter in your config-parsing library, be pragmatic).
  • Your last test should be your happy path.

Measure twice, cut once

  • So much time gets spent solving the wrong problems, creating solutions for problems that don't exist.
  • Think outside the box, the best solution is when through discussion you identify the problem doesn't exist.
  • Hold your ideas in a loose hand, be willing to 'use a pencil in space*'.

Do the dirty jobs

  • Be the kind of person who does the jobs noone else wants to do, especially as you become more senior (humility is a sign of real maturity).
  • Debug the hard problems,
  • clean up the coffee cups,
  • unblock your workmates,
  • let the new person have the glory and be the kind of person who finds enjoyment in the success of others.

Value Empathy

  • You spend the bulk of your waking life with your workmates, Care for eachother, dare I say Love one another like your family.
  • Be a good listener.
  • Know when to back off (respect privacy / people's boundaries).

Postel's Law: "Be conservative in what you send, be liberal in what you accept" applies to human interaction as much as engineering:

  • Take things in good faith (don't be easily offended)

  • Don't intentionally give offence

  • Be Real

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment