Swizec Teller - a geek with a hatswizec.com

    How to own projects like a senior engineer

    The best skill you can learn is ownership.

    Swizec Teller published ServerlessHandbook.dev avatarSwizec Teller published ServerlessHandbook.dev@Swizec
    The best skill you can learn as an engineer is ownership.

    Take the task and crush that thing. All the way.

    Ownership means that when YOU grab the project, it will get done. No matter what.

    Unless it's no longer a priority. Then you drop it like it's hot. This is harder than it looks.

    Overcoming obstacles

    At its core, ownership is about overcoming obstacles.

    How good are you on your worst day? When the code hates you, production is on fire, user story makes no sense, and half your day is spent helping others?

    That's when ownership shines.

    You find time with your Product Manager – PM – to clarify the story, you work around the bad code, make time to fix it, and add "fixme" stories to the backlog. When that fails, you find people with more context and ask questions.

    You can google for library questions. You have to ask for codebase questions.

    Swizec Teller published ServerlessHandbook.dev avatarSwizec Teller published ServerlessHandbook.dev@Swizec
    @acemarke Google for library questions
    Team for project questions

    imo

    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 over 14,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. ✌️

    Excuses and reasons

    Steve Jobs liked to share a great story about ownership:

    When your office isn't cleaned, you ask the janitor why.

    "Office was locked and there's no key"

    And that's fine. That's a good excuse. You can't clean an office without the keys.

    But when you're a certain level, that's no longer fine. Why didn't you go find the key? Why isn't there a backup? If all else fails, why didn't you pick the lock?

    An excuse is when you say "I couldn't do it because of X". A reason is when you say "It was delayed because X. When I tried Y and Z that didn't work, I'm trying W next unless you have a better idea"

    Your job is to ensure that office is cleaned. Figure it out.

    "it wasn't in the story"

    As an engineer, your job is to solve problems, not to mindlessly fulfill requirements like a drone.

    Own the process. The whole process. Be the project manager you want to see in the world.

    You get the project. You read the spec. You ask questions.

    Many questions. Until you are sure you understand both the spec and the spirit of the spec.

    When your PM says "Send user a message at 9am", she doesn't know to also ask:

    • What happens in different timezones?
    • What if our server is down at 9am?
    • What if the messaging service is down?
    • What if the database was corrupted?
    • What if the cronjob runs at 9:01am?
    • What if it runs at 8:54am?
    • What if we have to send 1000 messages and that blows through our rate limit?
    • What if sending 1 message out of 100 fails?
    • What if we want to analyze sends later?

    Finding those hidden requirements is your job my friend. You're the expert and distributed systems are inherently flaky 😉

    When you ask, the PM might say "Not a business priority right now, thanks for asking".

    Which is a lot better than getting a text on your Bahamas vacation at 10am saying "Hey our business is down because we tried to send 10,000 messages in 1 second and it locked the database, what the fuck?"

    And she's not gonna ask that your React component follows basic accessibility guidelines. That's on you.

    Own the outcome, not the work

    The second best skill you can learn, is to let go.

    Swizec Teller published ServerlessHandbook.dev avatarSwizec Teller published ServerlessHandbook.dev@Swizec
    The second best skill you can learn is to let go.

    Let others write code their own way. It’s gonna be fine.

    Just because you own the project, doesn't mean you have to do it alone. Get help!

    Notice what I said earlier:

    Your job is to ensure that office is cleaned.

    Ensure, not clean.

    You take the responsibility. You don't have to take the work. Doing the work might even be a bad use of your time!

    Do you have to build that component you've built a thousand times or can someone else do it with your guidance while you focus on bigger things?

    When shit hits the fan, opt for speed. When there's time, train others.

    Surgical teams

    I like the surgical team analogy.

    You're the lead engineer for this project and the rest of your team is there to help.

    You own the outcome.

    If the patient dies, your fault. If the patient lives, your fault. If there's complications, your fault. If you publish a report, your name first.

    But it's a team effort.

    Nurses prep the patient, an anesthesiologist administers drugs, a team preps the tools, an assistant hands you the right thing at the right time, a trainee opens the patient up and closes them back, ...

    You planned it all. From start to finish.

    Described the tools you'll need, the team, the procedure, talked with the patient, managed risk, delegated tasks, helped when there's questions.

    And then you do the hard part. The critical part. The part that needs an expert. The bit only you can do.

    Be the expert my friend. Own the outcome.

    Cheers,
    ~Swizec

    Did you enjoy this article?

    Published on July 2nd, 2021 in Opinions, Leadership, Mindset, SeniorMindset

    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 over 14,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. ✌️

    Have a burning question that you think I can answer? I don't have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

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

    Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.

    Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first 💰 on the side with ServerlessReact.Dev

    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 bySwizecwith ❤️