Navigation Menu

Skip to content

Instantly share code, notes, and snippets.

@chrisdickinson

chrisdickinson/ladder-thoughts.md Secret

Last active June 15, 2023 17:52
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save chrisdickinson/659f7e3a233a0fef9cf07fb9e35af118 to your computer and use it in GitHub Desktop.
Save chrisdickinson/659f7e3a233a0fef9cf07fb9e35af118 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
ladder-thoughts.md

you are not a senior engineer, you do senior engineer things

This list is a (flawed, incomplete) set of ideals that ICs try to live up to. The Platonic Ideal of a Senior Engineer would do all of these things all of the time.

However, we're human, so it can be expected that we will do some of these things, some of the time, & according to our circumstances on any particular day. That said, it is expected that ICs always do their best to live up to these ideals, at all experience levels.

A senior engineer:

  • has basic programming chops

    • seriously, these can be very, very basic, people do not need to master coding through-and-through to be a senior programmer
    • table stakes is: writes their code to be understood by other people
    • programmers will, over the course of time, develop a menagerie of useful trivia - this is excellent but its value is 10% in application and 90% in transmission to other programmers
    • code is usually the least important contribution an engineer can make

  • has a focus on communication

    • can be relied upon - endeavors to do what they say they will do
      • it's not expected that things work out the way they planned, naturally
      • follows up with people when plans change
    • works with others to address problems
    • admits mistakes and makes earnest apologies

  • introspects & improves themselves and others

    • takes and integrates feedback from others
    • seeks to filter and frame their feedback for others in such a way that it maximizes its utility to the person receiving feedback
      • considers rapport & rapport-building an important element of feedback
    • considers:
      • the value of their time and where it can be invested to have the most impact
      • the value of taking time off and how it impacts their ability to continue functioning
      • how working extra hours affects their co-workers
    • accepts that they will be wrong, & plans for it
      • they will hedge bets, minimizing the impact of being wrong
      • they will recognize personal biases and consider how they may affect their decision making

  • considers the impact of their work

    • on themself (how much of their ego is tied up in what they're working on?)
    • on their co-workers (does this affect what my co-worker is working on now? how are they likely to receive this work?)
    • on the organization as a whole (does this advance the goals of the organization? what does this work make possible?)
    • on the people using their code (does this work make life better for people using npm?)

  • knows that the only 10x programmer is a (good) teacher with 10 students

    • the best programmers pull other people in and give them a stake in the work
    • they work alongside, not above (CD: I stole this from jeff. thanks jeff!)
    • they level up everyone they work with, and give them the courage to tackle tasks on their own
      • they do not soak up the work from the rest of the team
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment