"Hey how does the foobulizer work again?"
Ugh not this again. You've been answering this same damn question for months. How are they still not getting it?? 🙄
You take the gnasher, connect it to the third function call from the left on a full moon, or the fourth one from top, if it's Sunday, then you plug into the fantalizer, add 3 lines of code using the in-house configuration language built from JSON, stand on your right leg, hold the left nostril, and voila: the foobulizer.
I mean seriously, are they all stupid?
Your team is smart.
When you get (or ask) the same question over and over, that's a symptom. The problem is the codebase. Or the architecture. Or the data model. Or the docs.
Your team can't help itself. They need you.
Fantastic job security aaaaand that's why senior engineers get nothing done. There's no time. 💩
When you answer the same question 3 times, write it down. Share the link.
When they ask again, edit and share the link.
Your doc won't always answer all the nuance of a question but it helps. Gets you on common ground, makes the chat more productive.
If your team keeps asking a question, write a doc.— Swizec Teller (@Swizec) February 4, 2021
If they keep asking, build the magic function that does the thing. Make it [easily] discoverable in your codebase.
If you don't, they *will* find the wrong way 😉#seniormindset
And the more you write, the less you have to keep in your head. Mine has the memory of a goldfish 😇
You know what's even better than up-to-date docs? Not needing docs.
Imagine if instead of a complex 6 step process you could start the foobulizer with
We used to have this problem at work. We still do but not with that part 😛
Verifying insurance was my first introduction to "Holy shit health tech is something else".
The process goes like this: Get your info, maybe use what exists, talk to an API, see if it's valid, check a sea of inscrutable codes, decide if your insurance supports this appointment at this time (yes it changes), and a bunch other details.
You don't want to deal with this as a user.
Heck, I didn't wanna deal with it as a programmer! Confusing, terrible, makes-no-sense.
We had an
Insurance module, but it was hard to hold. You had to call the right functions in the right sequence at the right time.
Get it wrong and the company doesn't get paid.
I got it wrong. Five times 😅
Edge case after edge case, bug after bug, meeting after meeting. 3 of us working on this stupid thing.
We had docs, we had code, yet we couldn't make it work.
Until one day the dude who grokked the business logic said "Screw this, this is bullshit."
He built a new function:
And oh my god it was beautiful. Cut through all the crap. You call this method, give it a user and an appointment, and it does it all for you. Standing on the right leg holding its left nostril and all! 😍
Nobody has asked an insurance question since.
The Magic Function is a high level method that does the thing the whole thing and nothing but the thing.
Forget reading and understanding docs. Forget writing and updating docs. Just make it work.
Why is it called The Magic Function principle?— Swizec Teller (@Swizec) February 4, 2021
Because of this quote from Penn & Teller. *you* do the work so the rest of your team doesn't have to pic.twitter.com/eM7B32L7p4
You do the work so your team doesn't have to. Like Penn & Teller say:
Sometimes magic is just someone spending more time on something than anyone else might reasonably expect. ~ Teller of Penn&Teller fame
You write The Magic Function when you see that code always goes together. You always make this DB update after that API call. You always call these 3 functions together. You always ...
The Magic Function frees your team from that complexity. Instead of worrying about the details, they focus on their problem. 🧙
Best part: they'll find your function on their own. No questions, no confusion.
Engineers always find a way. Help them find the way.
The opposite of The Magic Function is the unix philosophy – lots of small composable utilities.
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Expect the output of every program to become the input to another, as yet unknown, program
How you read this depends on your idea of "one thing".
Is one thing to verify insurance, or to call an API for 1 out of 50 different ways it needs to be called depending on circumstance? 🤔
It's fractal. Single responsibility all the way down. A magic function calls other magic functions.
You wouldn't wanna think about optimizing DOM updates to draw a button, just like your HTML rendering shouldn't think about where the HTML is from.
Write functions, mostly magic. Think fractals.
PS: how to start a 1928 Ford is a 20min video. These days you press a button and go. When's the last time you read the instruction manual for a car?
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.
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.
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
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️