Out Of Scope - #1

Bugs are officially cancelled

Welcome Back

Welcome to the 2nd issue of Out Of Scope!

We launched last week with #0 and we have 685 subscribers (as of writing this) here already! Thank you all for being here and your support. I value all of your feedback and suggestions, so feel free to leave me a note via this form or directly via email. ❤️

I was OOO most of this week skiing in Colorado, but don’t worry I was still able to work that into some programming dad jokes.

Emily Kager @EmilyKager

I think my brother enjoyed tackling me a little too much 🙄

---

Following up on those bugs! 🪲

I shared a tweet in last week’s newsletter about never tracking bugs and a suggestion to “just fix them” for laughs, but a followup conversation I had with my friend (and expert rollerblader), P.Y., justified a longer discussion about this.

Allen Holub @allenholub

I do wonder why anyone thinks that it’s a good idea to not just fix a bug the moment you become aware of it. Bug-tracking systems have always struck me as weird. Don’t track them; fix them.

Most of us working in a production codebase know how unrealistic this sounds. To name just a few reasons:

• We often create tickets to gather more information on bugs and communicate between teams

• We need to be able to prioritize more important bugs over the rest since we don’t usually just have 1 bug at a time

• We need to balance releasing on schedule with having bug-free code

• The dev teams don’t find every bug themselves. Even with great tests! Some bugs are device-dependent, region-dependent, etc. Also QA and users find bugs that need to be communicated back to the dev team

• Some bugs are impossible to “just fix” and might need refactors or weeks of investigation

• You usually inherit thousands of bugs as soon as you start working on a legacy codebase

• You may find a bug you have no context on so you file it for another team

• Shit comes up! Best laid plans to go fix a bug can quickly be blown out by interviews, unscheduled and scheduled meetings, fires to put out, help requests, presentations + demos, more urgent feature work, etc and alas no bugs get fixed.

I think a lot of software thought leaders spend much more time writing about writing code than actually writing code. It’s like when old rich white dude politicians claim they can fix the problems plaguing our country. It’s possible, but I’m going to be wary that they are likely quite a bit off of the current pulse. There are idealistic (and unrealistic) ideas of how we can write perfect software in a vacuum, pessimistic ideas that nothing can ever improve, and then somewhere in the middle, which is where I think most of us live.

No devs like to be shipping janky software and watching tickets pile up but in many cases feature teams are rushed to keep shipping the next thing. Giving a team time to fix bugs and close out older tickets is good for the product and morale. Where there’s code, there will be bugs, but I think we can do better with some meaningful changes:

• Slowing down feature dev work with fewer WIPs for less context switching and to leave more buffer time

• Weekly bug fixing time budget or dedicated fix-it weeks

• Incentivizing fixing bugs by rewarding it in performance

• Budgeting time for collaboration and testing (but like I mentioned before testing does not bug-free code make) for higher quality code from the get-go.

TLDR if we want better software we should give people the time they need to do and reward doing the right thing. Seems simple enough to me but this may require larger org culture overhauls.

Would love to hear anything unique your teams are doing around bug budgets and processes!

---

ICYMI

How are we feeling about FAANG (and similar) promo processes? I saw this tweet about the common faults of what we are actually incentivizing through the current promo process.

Luke Metro @luke_metro

The more I talk with friends at FAANG, the more I am convinced that the career ladder of virtually every large tech company incentivizes outcomes that are totally unrelated to the business interests of the company.

The OP goes on to clarify that he has noticed that FAANG senior engineers’ career success is too tied to “impact” meaning there are many important projects that won’t get you promoted and hence they won’t be worked on. I broadly agree that not having measurable “impact” will drive people away from certain projects and this can be the dark side of formulaic promo criteria at big tech companies. I think we also tend to view these promo processes as more meritocratic than they really are. You still need to be visible and on peoples’ good side enough to get advocated for (manager, peers, committee members). On the flip side, people being promoted without a clear process or criteria like what often happens at smaller companies is not great either and opens the door for more bias. I think it says a lot that common advice I’ve heard is to get a promo through getting a new job rather than working towards promo (or better comp) at their current company. Comp + promos go hand in hand and companies should be reevaluating and improving their processes to reward people doing well and make sure we are incentivizing the right things.

This week, DHH had a meltdown about cancel culture again because.. *checks notes* he was asked to share the stage at RailsConf with contributors of his choosing. Will this man stop tanking his own reputation at some point or does he just love playing the victim that much?

jenn @jennschiffer

dhh is an absolute riot for this one lol

Justin Yorke @bangfalse

@jennschiffer

I loved this tweet about hiring junior devs. Why do we force junior devs to jump through so many hoops in hiring when we know we will be teaching them on the job?? I have a few questions around exactly what projects you would be pairing in, but I agree with the overall simplification of the interview processes and think it could be applied to other levels as well.

Monarch Wadia @monarchwadia

How I test junior devs. Step 1: I look for proof that they have coding skills. I mainly look at GH and LI. I almost never look at portfolios or resumes Step 2: a 60-90 minute pair programming interview on their own project Step 3: If OK, I send an offer Thats it #TechTwitter

You’ve heard it before! The Great Resignation is happening and the engineering hiring market is HOT 🔥 so engineers are leaving their jobs left and right. The average tenure is plummeting 📉 but companies are so thirsty for talent, they don’t seem to care about that. Will be interesting to see how this plays out long term.

Tyson @rad_fax

tech workers be like "some personal news: after an incredible journey at ______ these past 3 months, i'm beginning a new adventure! some thoughts on everything i learned: 🧵 1/59"

Last but certainly not least, a great thread that includes many of the software products that have teams in Ukraine and how you can help:

Asia Orangio stands with 🇺🇦 @AsiaOrangio

I'm seeing a lot of people who are surprised to learn their favorite software has been built and/or marketed by a Ukrainian team. Here's a running list of them (plus how you can help Ukraine fight back):

That’s it, folks. Stay safe + healthy and I’ll see you next week.

Emily