As a tech lead or eng manager, you so frequently get request from above or from other teams to drop what you are doing and work on this thing they need, *now*.
During my 4 years at Uber after asking these questions, 9 out of 10 times it turned out it wasn't really urgent:
1. "What is the impact of this work you're asking for?" If the impact is unclear: sorry, but we can't do the work. Why would we?
Just this question made the requester realize half the time they just think it's urgent, but don't know what the work will actually result in.
2. "Do you have a spec that is agreed with stakeholders?" A writeup answering the "why" and the "what" that is signed off by relevant business folks.
I've seen so much engineering work thrown out as later the business goes "that's not what we wanted, why didn't you tell us?"
3. "We're not committing to any work before we have done a rough estimation."
With #1 and #2 done, many stakeholders will come and say "drop what you're doing, this is a 3-day work we need ASAP."
Hold your horses. You don't make estimates: the team doing the work does...
4. Make the cost of dropping what you're doing very clear.
This cost is always forgotten by the person coming with the request. But it's a relevant one: wrapping up work, onboarding to the new work, then later onboarding to the old work. Plus a hit on morale for a sudden change!
Uber has some very hectic times when there were reasons we needed to do some new work ASAP. Like a regulation change that means the company would be banned from operating in a region if not building something.
Even in such a place, most "urgent" things turned out to be noise.
The way I always approached these requests was to educate the person coming with them, and have them realize their work is actually not as urgent or as important or as impactful of what the team is already doing.
Doing so meant building empathy both ways, and less hard feelings.
A huge upside of this approach: when committing, you *can* commit with a very high certainty that you will not be interrupted with your work.
The alternative: take on this "super urgent" work, then someone else comes along saying " I need you to drop what you are doing *now*..."
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Many bootcamps are (and will be) going out of business as we are entering a time when college grads with years of study, plus internships, are finding it hard to get entry-level dev jobs.
Bootcamps were thriving at a time when there was a shortage of even new CS grads. Pre-2022.
The only bootcamps I can see surviving are ones with industry connections. That is, bootcamps that have contracts or very warm connections with companies where they place new grads to.
These do exist, but are rare. It's often companies advertising it as e.g. apprentice routes.
This project is an Apache 2.0 license that is pretty permissive. Literally anyone can take it and run with it, so e.g. continue maintaining it or evolving it.
Don't forget that Atlassian isn't even a profitable company! They keep making losses. So yes they need to prioritize.
A positive aspect of open source is that with a permissive license you can always "take control" in case the project stops being maintained; or e.g. changes in a direction you disagree with.
It gives you a way out. Those relying on this library are not locked in, even now.
Originally, I planned to publish @EngGuidebook with a tech publisher. After 2 rejected it, I got a contract from the 3rd one.
They did an editorial review, offering advice how to shape the book (to make it more marketable).
I appreciated the advice. But I hated all of it. This:
The editorial board was pushing me to write a book that followed the structure of this publisher and akin to a schoolbooks.
Exercises! Word of the day! Quote famous people (because if they say it people will take it more seriously).
I had a vision for the book. This was not it.
After this editorial review - and after being pushed more and more to turn the book into something that felt absolutely out-of-character for me (e.g. use more "Alice and Bob" examples), decided there is no point for me to work with a publisher.
Imagine a tech conference having no CFP, as they reach out to speakers directly. They successfully attract some of the most heavy hitter men speakers in tech, and 3 women speakers.
Now imagine my surprise that 2 of those women are FAKE profiles.
They do not exist.
Nada.
I contacted speakers I know about this.
They had no idea.
One of the fake women profiles is supposedly a core Ethereum contributor, and a staff engineer at Coinbase.
No such contributor, no one heard of her at Coinbase now or before.
Why do this?
Sad to say but going forward if you are invited to speak at a lesser-know conference: do your diligence… if other listed speakers actually exist?!
This is a paid online conference, large number of (paid) attendees, workshops sold out.
One of my best productivity investments: an active noise cancelling, over-the-ears headphone. Makes a massive difference in a shared office, when traveling, and even when working at home (when there are small noises).
I am reminded how useful it is on the days I don’t have it.
I only recently realized why I’m not particularly productive working from certain rooms: because there’s some baseline noise that makes it harder to focus. Not when putting the headphone on.
I settled with the Bose QC 700 (had the 35 before) but so many solid ones these days.
Just to make it clear this is not an ad in any form, just sharing how this tool works very, very well for me.
Surprised when I see people use non-over-the ear and non-noise cancelling headphones in my shared office. I get far more productive when I lock out the small noises.
Firebase's authentication endpoint is having an outage, meaning that apps that built on Firebase are simply not working (eg @excalidraw) Users just don't see their data.
It's been about 2 hours. Incidents like this degrade the perception of how reliable a cloud data store is.
Imagine if DynamoDB didn't work for 2 hours. Well, you could ask "what zone doesn't it work? What region?" and you can have a plan B via cross-region (or cross-zone) replication (and you should!)
So this wouldn't happen.
With Firebase: customers have no such option. This is bad
This outage is an unfortunate reminder that an abstraction like Firebase is nice and convenient: but if you are building an app that needs true reliability: roll up your sleeves and don't use this approach which can fail in a way you cannot do anything. You really cannot.