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.
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.
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.
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?
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.
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.
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:
That’s it, folks. Stay safe + healthy and I’ll see you next week.
Emily
The boost to morale from big fixing is a great point. It doesn't feel good to leave bugs un-addressed. Bug buildup might also lead to Broken Window Theory.
Tech companies need to create new departments called Pest Control whose sole purpose is to remove bugs from code