It's hard to formulate career goals in your first decade or so as an engineer; there is just SO MUCH to learn. Most of us just kinda wing it.
But this is a goal that I think will serve you well: do a tour of duty at a startup and another at a bigco, in your first 10y as an eng.
Besides the obvious benefits of knowing how to operate in two domains, it also prevents you from reaching premature seniority. (charity.wtf/2020/11/01/que…)
The best gift you can give your future self is the habit of regularly returning to the well to learn, feeling like a beginner.
Most of us hate feeling like beginners. We associate it with anxiety, with failure, with not being good enough.
If you want to have a long, rich, rewarding career in tech, the best thing you can do is consciously retrain yourself to lean into curiosity and its discomfort. 🙃
If you're five years in to your career and only just starting to feel secure in your skills, it might seem batshit to walk out the door and drop yourself in the deep end of a completely different pool.
But that's exactly why you should do it. 💦🌊
You haven't spent five years memorizing docs pages and programming minutiae, you've spent five years learning how to *learn*. You're just starting to get good at it!
It will be so much faster & easier the second time. Soon you'll feel restless and uneasy *without* any novelty.
[[Btw -- no, you don't have to job hop to grow. It is TOTALLY possible to develop as an engineer at one company for 10+ years, especially if it's growing fast.
It's also possible to job hop yet never feel stimulated or challenged, or like anyone is investing in you/your career.
What's important is, does the work continue to stimulate you and push your boundaries, and occasionally scare you a little? 🙃
You can also have multiple roles within the same company. I've stayed at jobs for 5-6 years before, but never the same role more than ~2 years.
It also makes a big difference if you have a manager that cares about you and invests in you, and considers if their job to make sure this company continues to be the best place for you to learn and grow for as long as possible.
Those are a career accelerant too.
Sadly, they don't seem to be very common. Thus my advice here is aimed at the median case, where most of us sit, without devoted managers or mentors in our corner.
It is not a template. It is a framework that may be useful to some, and not others, and that's okay. ☺️]]
Back to the main plot: where should you work first, the bigco or startup?
Again, this is highly variable. But here are some reasons for doing bigco first:
* startups have fewer resources to dedicate to mentorship
* whereas bigcos tend to invest in a LOT of structure
(At Facebook, a friend once quipped that FB engineering was a highly oiled machine optimized for taking thousands of E3s (new grads) and churning them into E5s (senior engineers) as quickly as possible. Most of the energy of >=E6s went towards shepherding this transformation. 🤣)
God dammit I keep fucking up the Twitter threading. 🤬
So there's that. There's also the fact that, as far as I can tell, the more senior you are, the less likely some of them are to hire you. This probably isn't true of Netflix, but it def was of FB.
They flat did not know how to interview, hire, or retain senior engineers, and bewailed how much "retraining" an engineer from, say, Google (or anywhere else) needed.
You might get in as a line manager or an E5, but higher level hires were rare and successful ones rarer still.
But there are some very compelling reasons to work at a bigco.
* it's worth seeing how these large distributed systems and successful organizations work from the inside. There is no substitute for experience.
* the pedigree. It will open doors and pave your way. Maddeningly so.
* and the money. It's lifechanging, esp for those of us who came from nothing or had massive debt. I lived paycheck to paycheck before FB, and now I have a house and retirement account.
I could *never* have done honeycomb if not for my time at FB.
There's no shame in using your skills to provide for yourself, your family, and your community. There is no shame in craving security -- none. Even if it does mean selling your soul for a spell.
If that's you, you'll get no judgment from me. BUT.
If you're selling your soul, look hard at lifestyle inflation.
I know too many people who took the gig to get out of debt, then find themselves a few years later living paycheck to paycheck on that 500k salary. Or they went from 150k to 800, and now "need" 400k just to live.
I am not a financial advisor. 🙃 But at least maybe keep tabs on what the going rate is for your skills in the non RSU based economy. It can be really crushing to find your dream job and realize you can't afford to take it.
It's all 10x words if you feel trapped. Are trapped.
Lastly, remember that bigco isn't all FAANG. Those companies have so many applicants that they can turn people away for whatever rando whim of the day.
There are companies like Capital One, Amex, Nordstrom, etc that do great work, pay good money, and look shiny on a resume.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Let's talk about OpenTelemetry, or "OTel", as the kids like to call it.
I remember emitting sooo many frustrated twitter rants back in 2017-2018 about how *behind* we were as an industry when it comes to standards for instrumentation and logging.
Then OTel shows up.
For those of you who have been living under a rock, OTel is an open standard for generating, collecting, and exporting telemetry in a vendor agnostic way.
Before OTel, every vendor had its own libraries, and switching (or trying out) new vendors was a *bitch*.
Yeah, it's a bit more complicated to set up than your standard printf or logging library, but it also adds more discipline and convenience around things like tracing and the sort of arbitrarily-wide structured data blobs (bundled per request, per event) that o11y requires.
Several people asked this. It's a good question! I will share my thoughts, but I am certainly not religious about this. You should do what works for you and your teams and their workflows. 📈🥂☺️
1) "assuming you have good deduplication"... can a pretty big assumption. You never want to be in a situation where you spend more time tweaking dupe, retry, re-alert thresholds than fixing the problem.
2) having to remember to go futz with a ticket after every little thing feels like a lot of busywork. You've already committed some code, mentioned it in #ops or wherever, and now you have to go paste all that information into a task (or many tasks) too?
@beajammingh the title particularly caught my eye. for the past month or two i've been sitting on a rant about how i no longer associate the term "devops"** with modern problems, but with fighting the last war.
** infinitely malleable as it may be
yes, if you have massive software engineering teams and operations teams and they are all siloed off from each other, then you should be breaking down (i can't even say it, the phrase is so annoying) ... stuff.
but this is a temporary stage, right? a bridge to a better world.
I've done a lot of yowling about high cardinality -- what it is, why you can't have observability without it.
I haven't made nearly as much noise about ✨high dimensionality✨. Which is unfortunate, because it is every bit as fundamental to true observability. Let's fix this!
If you accept my definition of observability (the ability to understand any unknown system state just by asking questions from the outside; it's all about the unknown-unknowns) then you understand why o11y is built on building blocks of arbitrarily-wide structured data blobs.
If you want to brush up on any of this, here are some links on observability:
Close! "If you're considering replacing $(working tool) with $(different tool for same function), don't do it unless you expect a 10x productivity improvement"
cvs to git? ✅
mysql to postgres? ❌
puppet to chef? ❌
redhat to ubuntu? ❌
The costs of ripping and replacing, training humans, updating references and docs, the overhead of managing two systems in the meantime, etc -- are so high that otherwise you are likely better off investing that time in making the existing solution work for you.
Of course, every situation is unique. And the interesting conversations are usually around where that 10x break-even point will be.
The big one of the past half-decade has been when to move from virtualization to containerization.
Maybe not "full transparency", but I think *lots* of engineers chafe at the level of detail they have access to, and wish they were looped in to decision-making processes much earlier.
One of the most common reasons people become managers is they want to know EVERYTHING. They are tired of feeling left out, or like information is being kept from them (true or no).
All they want is to be "in the room where it happens", every time it happens.
I mean, that's why I got in to management. 🙃👋 And it works! It scratches the itch. Everything routes through you. It feels great...for you.
But you still have a team where people feel like they have to become managers in order to be included and heard.