Swizec Teller - a geek with a hatswizec.com

    Nobody is coming to save you

    How do you react when you don't like The Process at work?

    Could be anything. How you do deploys, standup, sprints, how stories are defined, how pull requests work, ... anything that has a typical "This is how we do it here".

    Most programmers complain on social media, make a wry joke, and ... suffer. Standups amirite?? πŸ™„ <the crowd goes wild>

    But here's the thing my friend: nobody is coming to save you. You have to fix the process. Mold it to your liking.

    Swizec Teller writing a secret book avatarSwizec Teller writing a secret book@Swizec
    One of my biggest learnings the past few years has been to stop waiting for others to rescue me.

    If you think The Process could be better, just do it!

    Make a tweak, tell others, start doing it that way. Good tweaks stick and become The Process.

    I've written about this before in Why great engineers hack the process and HOW great engineers hack the process. Some readers thought that was a bit aggressive.

    "Yes Swizec, everyone thinks they're the ones who don't need the process. If you think you don't need it, you need it the most!"

    Fair. The Process is for everyone. Even you.

    Except when you cowboy merge a pull request because it's a small copy change, you need to move fast, and there's little value in bothering others for a rubber stamp. 😝

    How you fix the process

    There's two ways to fix the process:

    1. Suggest an experiment. Let's do this for a week or sprint, see how we like it. Low commitment, easy to do, hard to say no. Great when you need others to play along. Sometimes known as a kaizen
    2. Lead by example. Start doing it your way. Show others. If it works and people like it, they'll start doing it your way.

    Here's a few ideas you can try:

    Standups

    Senior Engineer Mindset avatarSenior Engineer Mindset@SeniorMindset
    Standup feels useless, if you don't work as a team.

    Standups are a daily sync with your team.

    Back in the 90's my mom explained it as "Every morning we have coffee together". American commutes make that uncommon on this side of the pond, I think.

    Tech industry has perverted standup into a ritualized meeting that engineers the world over love to complain about as the biggest annoyingest waste of their time.

    It doesn't have to be that way!

    Your manager can read the task manager. They don't need a status report. This is your meeting.

    Hide the Done column and focus on the day ahead.

    Environment vars

    Once upon a time my coworker got fed up with our secrets management. Every day he would come into work and his environment blew up.

    Someone renamed an environment variable. Again. Or added a new one. Ugh.

    Now nothing works, he's blocked from coding, and hunting through .env.sample files to find what changed.

    He wrote a script. It goes through our repos, looks at .env.sample files, copies new variables into .env.local, and talks to AWS Secrets Manager to set the value.

    🀩

    We rely on it daily. Even after he left. Killed half our onboarding docs!

    Deploys

    Similarly I once got tired of the git command dance to deploy all our code across repositories.

    GitOps is fantastic! Checkout staging, merge, check out master, merge, push, integration pipeline handles the deploy itself. Sets up cloud services, builds your code, makes it run.

    A fun and exciting command line dance until you do it multiple times per week across many repositories.

    So I wrote a script: goes through repositories, asks "Wanna deploy this one?", and does the git dance.

    Everyone thought it was silly at first, now they're all using it. I know because they keep adding improvements πŸ˜›

    Write an SOP

    Doing something regularly? Same-ish steps every time?

    Write a Standard Operating Procedure! Step by step instructions on how to do a thing.

    Congratz! Now others can do it. You can take a vacation πŸ₯³

    Perhaps one day it becomes a script. Or automated.

    Design and product validations

    Tired of waiting for product or design to validate your changes? They're the biggest bottleneck after pull requests in my experience.

    Send them a screenshot! Or a video! Even if it's not part of your anointed process.

    Heck, get their feedback before you even open a PR. As early as possible. That way once it's merged and deployed to a staging environment you can be pretty sure they'll be happy.

    Good excuse to do your own manual testing and find any bugs πŸ˜‰

    Plus UI pull requests are way easier to review when there's screenshots. I promise nobody will mind if you take a few minutes to do this.

    Fix others' code

    See a smΓΆl problem in someone's pull request that will take you 5 minutes to fix, but 2 hours for the other person to see your comment ask a followup question that you'll respond to an hour later then they'll make the change and the next day you'll hit that approve button?

    Fix the damn thing. They won't mind!

    And if they do mind never do it again. People can be touchy about their code πŸ€·β€β™€οΈ

    Better is good

    My favorite Obama quote: "Better is good."

    You don't need to fix The Process all at once. It doesn't have to be perfect.

    Just make it a little better.

    Cheers,
    ~Swizec

    Did you enjoy this article?

    Published on July 29th, 2022 in Mindset, Leadership,

    Want to become a true senior engineer?

    Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?

    Leave your email and get the Senior Mindset series - a series of curated essays on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you think.

    The Senior Mindset series

    Get a series of curated essays on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you think.

    it describes my days in a way I have not read before.

    This was a very enlightening article about being a senior engineer.

    Join 15,883+ engineers learning lessons from my "raw and honest from the heart" emails.

    ⭐️⭐️⭐️⭐️✨
    4.5 stars average rating

    Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.

    Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.

    Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help πŸ‘‰ swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.

    Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers πŸ‘‰ ServerlessHandbook.dev

    Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization

    Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections

    Want to brush up on modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog

    Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❀️

    Created by Swizec with ❀️