Swizec Teller - a geek with a hatswizec.com

    The code is not the goal

    Telling engineers that what code their does is more important than what it looks like is a lot like saying dark mode is cancer. I feel it in my gut to be true, but expressing it just right eludes me forever.


    ๐Ÿ‘† me when I say either of those things

    Dark mode is like pointing a bright spotlight at your face, thinking "Oh gosh that's too bright", and putting sunglasses on it. You know, instead of using the damn brightness setting.

    Ok that was easy ๐Ÿ˜›

    Explaining why it's most important for your code to achieve business objectives is harder. I've had many conversations with friends and internet strangers over the past 3 days.

    Here's a recap

    Click through for source
    Click through for source

    Maybe engineers fundamentally don't want to realize that what their code looks like isn't nearly as important as whether it gets the job done.

    The usual argument goes something like, and I quote straight from a reply to my email,

    I don't want to maintain any code that was reasoned to win few races, while the one reasoning was still interested about the project before moving on to some other "race". Stupid analogy that'll appeal to the lazy-minded, and is way too often used as an excuse for subpar Architecture. Don't win a race, win a marathon!

    Dude's right. Maintaining bad code sucks.

    But I think something a lot of folks fail to realize is that it is a luxury to have a product with a codebase so bad it makes you pull your hair out.

    The product survived!

    Yes itโ€™s a big hairy mess now, but it lives

    You now have the ability to fix it. You know where the design went wrong, you know where the traps are, you know what you want

    that is wonderful

    Most terrible architectures, in my experience, arenโ€™t terrible because the code is bad or the engineers sucked.

    Theyโ€™re terrible because the whole product was still trying to figure out what it even wants to be and do.

    Itโ€™s easy to look back and say "that is bad"

    It is impossible to look forward and say "that will be bad".

    Click through for source
    Click through for source

    Here's an old programming maxim

    Make it work, make it right, make it fast

    Your code has a job to do. It needs to work first. Then if it works well enough, you might get time to make it beautiful and fast. Iff that is important to the business.

    Sometimes it isn't and that's okay.

    Another analogy we came up with in a Slack group is that of a commercial kitchen. High pressure environment with tight deadlines where everything has to go just right to produce that perfect meal.

    A lot like an engineering org.

    First thing Gordon Ramsey does when saving a failing restaurant ๐Ÿ‘‰ make the kitchen run smooth. If your kitchen is dirty, disorganized, and a huge mess, your restaurant will fail.

    If your engineering is dirty, disorganized, and a huge mess, your company will fail. No doubt.

    But your code is not your engineering org. Your code is the product.

    An engineer worrying too much about perfect code is like a chef placing peas one by one on a plate of bangers and mash to make sure it looks perfect.

    That's not a chef, that's a food photographer. Takes them 5 hours to make a burger for 1 photo shoot.

    Would you wait 5 hours for the perfect burger at your local pub?

    Of course not. That's ridiculous.

    My main point is this ๐Ÿ‘‰ the code is not the goal. Solving the problem is the goal.

    Peace โœŒ๏ธ

    Did you enjoy this article?

    Published on July 31st, 2019 in Opinions

    Learned something new?
    Want to become a high value JavaScript expert?

    Here's how it works ๐Ÿ‘‡

    Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet ๐Ÿ“–right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

    Start with an interactive cheatsheet ๐Ÿ“–

    Then get thoughtful letters ๐Ÿ’Œ on mindsets, tactics, and technical skills for your career.

    "Man, love your simple writing! Yours is the only email I open from marketers and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. ๐Ÿ‘Œ"

    ~ Ashish Kumar

    Join over 10,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 โค๏ธ