4 ms·

>1. “I’ll Just Fix It”. As a senior: it’s reckless. For the sake of my own sanity and enjoyment of my work, I have realised that I sometimes have to do this. I

>1. “I’ll Just Fix It”. As a senior: it’s reckless. For the sake of my own sanity and enjoyment of my work, I have realised that I sometimes have to do this. I'm not talking about massive 2 week tasks but rather something done in 30mins - 1h. I call them pallet cleansers and when there is a particularly hard task that has me stumped I'll do one of them to give my brain some time to passively process the more difficult one. I have also told my manager point blank that they can get on board or start looking for a new engineer because I would leave otherwise. Thankfully, they're a good manager and are completely fine with it as long as my main work gets done on time and I somehow communicate it (standup, slack, jira, etc).

62 1y ago
[dead]
hamdingers 1y ago
This one's just wrong, unless the author is using a novel definition of senior. Senior engineers are exactly who I trust to "just fix it" when they notice a problem, even one outside their immediate domain. Sure the bar is higher, but that's still their job. If this was about staff or architects, then it would make sense.
- itsnowandnever 1y ago
  I think the author didn't account for different types of engineering orgs at different points in their lifecycle. "just fix it" at an enterprise massive company as a junior is fine but a senior would know "if you fix it, you own it" and it could cause downstream issues with what your team does or owns at the company. whereas at a startup, if you're relying on junior devs to "just fix it"... good luck with that
  - mschild 1y ago
    Even at an enterprise its absolutely possible. I work for one after all. My team owns the product anyway though and my "just fix it" tasks are 99% of the time annoyances that I encounter in my day-to-day work. For example, we run a Jenkins instance for our platform that has bi-weekly production releases. We write announcements in slack when there was a release with a list of PRs and links to the tickets in Jira. That used to be manual work. At one point I was annoyed by it and took 30 minutes to write a 15 line script to automatically take the merged PRs, create a Jira link and announce it in our slack channel.
- 28304283409234 1y ago
  Aaaaaactually, those are principal engineers. With them, there are flips back!
- PaulKeeble 1y ago
  If anyone is going to spot that the easy fix turns out to actually have more implications its the senior engineer. To some extent it comes with a battle hardened wince to "this is a 30 minute fix" knowing full well it sometimes isn't and to look for the foot guns.
  - Ancapistani 1y ago
    This - and how to deploy that “easy fix” in a way that watches for unexpected consequences, and with a plan in hand to mitigate them or revert the change without undue disruption if necessary. As I go through this thread, one word keeps coming to mind: discernment. The more senior you become as a SWE, the more you’re expected to know what to address, when, and how to address it. The actual addressing of the problem is table stakes, and as you move from senior to staff you’ll find yourself directing more and implementing less.
elephanlemon 1y ago
It’s funny that you get (or got) pushback for basically doing extra work. If you were to just take a break and do nothing at all, people would just assume you were hard at work on the main issue.
- mschild 1y ago
  At a previous job my manager complained. They weren't mad about the extra work itself but rather that I didn't go through the entire change process. That meant writing a user story, creating a ticket, bringing it to refinement, agreeing with colleagues that it's something we should do, planning for it in a sprint, etc, etc. For large tickets/tasks/projects that makes sense. However, I outright refuse to go through this process for a minor annoyance that needs 2-3 lines of code and 30 minutes until its in production. Since then I steer clear of companies and teams that have an incredibly strict sprint schedule were no unplanned work, even if its tiny, is allowed. I hate that way of working and refuse to do it.

62 1y ago

[dead]

hamdingers 1y ago

This one's just wrong, unless the author is using a novel definition of senior. Senior engineers are exactly who I trust to "just fix it" when they notice a problem, even one outside their immediate domain. Sure the bar is higher, but that's still their job. If this was about staff or architects, then it would make sense.

itsnowandnever 1y ago
I think the author didn't account for different types of engineering orgs at different points in their lifecycle. "just fix it" at an enterprise massive company as a junior is fine but a senior would know "if you fix it, you own it" and it could cause downstream issues with what your team does or owns at the company. whereas at a startup, if you're relying on junior devs to "just fix it"... good luck with that
- mschild 1y ago
  Even at an enterprise its absolutely possible. I work for one after all. My team owns the product anyway though and my "just fix it" tasks are 99% of the time annoyances that I encounter in my day-to-day work. For example, we run a Jenkins instance for our platform that has bi-weekly production releases. We write announcements in slack when there was a release with a list of PRs and links to the tickets in Jira. That used to be manual work. At one point I was annoyed by it and took 30 minutes to write a 15 line script to automatically take the merged PRs, create a Jira link and announce it in our slack channel.
28304283409234 1y ago
Aaaaaactually, those are principal engineers. With them, there are flips back!
PaulKeeble 1y ago
If anyone is going to spot that the easy fix turns out to actually have more implications its the senior engineer. To some extent it comes with a battle hardened wince to "this is a 30 minute fix" knowing full well it sometimes isn't and to look for the foot guns.
- Ancapistani 1y ago
  This - and how to deploy that “easy fix” in a way that watches for unexpected consequences, and with a plan in hand to mitigate them or revert the change without undue disruption if necessary. As I go through this thread, one word keeps coming to mind: discernment. The more senior you become as a SWE, the more you’re expected to know what to address, when, and how to address it. The actual addressing of the problem is table stakes, and as you move from senior to staff you’ll find yourself directing more and implementing less.

elephanlemon 1y ago

It’s funny that you get (or got) pushback for basically doing extra work. If you were to just take a break and do nothing at all, people would just assume you were hard at work on the main issue.

mschild 1y ago
At a previous job my manager complained. They weren't mad about the extra work itself but rather that I didn't go through the entire change process. That meant writing a user story, creating a ticket, bringing it to refinement, agreeing with colleagues that it's something we should do, planning for it in a sprint, etc, etc. For large tickets/tasks/projects that makes sense. However, I outright refuse to go through this process for a minor annoyance that needs 2-3 lines of code and 30 minutes until its in production. Since then I steer clear of companies and teams that have an incredibly strict sprint schedule were no unplanned work, even if its tiny, is allowed. I hate that way of working and refuse to do it.