|
LLSix posted:Maybe at least some of their developers are working on ongoing improvements to their recommendation algorithm? Don’t look at them all at once. Tag bugs with all relevant projects, then only look at the tags you care about (e.g. the thing you’re actively working on, or considering actively working on). You will never solve the overall problem so long as ingress is higher than egress, but you don’t have to if you’re focused. Ignore the rest. Now if the bug count for the thing you’re actively working on never goes down, you’re hosed.
|
#
?
Apr 13, 2024 21:35
|
|
|
|
| # ? Apr 30, 2024 05:08 |
|
|
Bug lists growing over time is the natural state of software. The only way to avoid it is to either be in pure maintenance mode with zero feature development or to arbitrarily close unfixed tickets. The actual bugginess of your software is hopefully not increasing over time, but you will continue to discover existing problems and if your code base is getting larger as time passes then there's just more places for bugs. Approaching project management with the expectation that open bugs will decrease is just incorrect.
|
|
#
?
Apr 13, 2024 22:06
|
|
|
Plorkyeran posted:arbitrarily close unfixed tickets. Also don't do this, it pisses people off for no benefit.
|
|
#
?
Apr 13, 2024 23:17
|
|
|
It's been an entire week since it was reported and it hasn't been fixed yet so clearly no one cares about it.
|
|
#
?
Apr 14, 2024 00:05
|
|
|
I work in the media steaming space and I am pretty confident there’s a bunch of work been going on at Netflix around the delivery of live stream events etc but who knows.
|
|
#
?
Apr 14, 2024 01:48
|
|
|
LLSix posted:On which topic, any advice for how to not stress out about an ever-growing bug list? My most visible responsibility right now is prioritizing which bugs to work on from an ever-growing list. The team doesn't have enough developers to keep up with how fast they come in so most days it feels like I'm rearranging deck chairs on the Titanic as I watch our bug list get longer and longer. (I've been reporting the problem upwards for over half a year and it seems like management understands there is a problem but also won't be providing any help.) The best solution I've seen is to write a policy that says "bug tickets not fixed after one year will be closed. Ticket openers have 36 hour grace period to reopen them" or similar If nobody has fixed the bug in one year, it's not worth fixing The policy (signed off, in writing by your boss) gives you political cover to ignore bug tickets. Also after one year, especially for UI bugs, they're likely unreproducible edit: pokeyman posted:Also don't do this, it pisses people off for no benefit. *taps one year cut off for unresolved bug tickets policy* Hadlock fucked around with this message at 03:22 on Apr 14, 2024 |
|
#
?
Apr 14, 2024 03:19
|
|
|
Hadlock posted:If nobody has fixed the bug in one year, it's not worth fixing Yeah I've heard this said many times before and I think it's total loving horseshit. For one, it assumes some level of correct prioritization, which is pretty shaky to begin with. Some bugs are due to broader issues that are pretty significant in scope to fix, and it's useful to keep around and track what bugs exist related to some broader issue, and then know when they are fixed. What if people took the same approach to any other sort of work? Any feature or improvement we dreamed up more than a year ago but haven't done yet must not be worth doing.
|
|
#
?
Apr 14, 2024 03:24
|
|
|
peeps act like their prioritization is 99% accurate and i've never seen prioritization be more than like, 20, 30% accurate
|
|
#
?
Apr 14, 2024 03:27
|
|
|
Steve French posted:Some bugs are due to broader issues that are pretty significant in scope to fix, and it's useful to keep around and track what bugs exist related to some broader issue, and then know when they are fixed. Bad example, but we were on flux 1 for whatever reason, and every 90 days it's auth key would silently expire and prod deploys would fail until someone manually logged in to the cluster and restarted the pod which would fetch new valid creds A bug ticket got filed for this initially but eventually it became a line item in the quarterly architecture review "upgrade to flux 2 and here's one reason why" I'm not sure keeping a database of weird problems fixed by upgrading big sections of infra/code (  broader issues) as bug tickets is useful to anyone. Maybe in that case the solution is to mark it "won't fix" and then say why (flux 2 pulls new creds when old ones expire and we're migrating to that in Q4)Not sure what your personal example is (we all have one) but in that case the knowledge lived in/was managed by a living architecture doc/prioritization spreadsheet
|
|
#
?
Apr 14, 2024 03:33
|
|
|
Hadlock posted:Bad example, but we were on flux 1 for whatever reason, and every 90 days it's auth key would silently expire and prod deploys would fail until someone manually logged in to the cluster and restarted the pod which would fetch new valid creds That was one example of reasons why a bug might not be fixed after a year but still be relevant. There are many such possible reasons. There's a lot of reasons why a bug might reasonably be marked as won't fix / closed, and I just don't think that "well it's been a problem for a long time and so past-us hasn't thought it was important enough and past-us has never done us dirty" is one of them. There are likely new bugs filed all the time with a shittier severity to repair cost ratio, look at the actual things that matter to the prioritization of the bug rather than picking some arbitrary threshold to just close poo poo for no good reason. You questioned the value of keeping a database of weird problems around ("weird problems" is a bit dismissive of what actually might be significant problems! who knows?! if they're insignificant then close them for that reason, not for age), I question the value of closing bugs that haven't been fixed.
|
|
#
?
Apr 14, 2024 04:43
|
|
|
Yeah, to generalize what you're saying: If you know the solution to a bug and can't implement it, mitigate it as best you can with retries or docs or warnings, and put the real fix up as a task to tackle in the future.
|
|
#
?
Apr 14, 2024 04:50
|
|
|
Steve French posted:if they're insignificant then close them for that reason, not for age), I question the value of closing bugs that haven't been fixed. 1) there's nothing stopping someone from reopening a ticket. Annoying but if it's reopened it's a good indicator that it's still broken 2) going back to my other point, how many tickets are still reproducible after a year? How much time is wasted sending a ticket off to a dev who struggles to reproduce the problem? Or is someone on the team validating tickets quarterly to make sure there's not a bunch of tickets that need to get closed. There's a lot of overhead on sitting on top of 1000+ tickets and juggling the product managers needs I think this also depends on how mature your team is (average tenure) and what your turnover rate is. If you're supporting like, Gmail, which probably doesn't change a whole lot, or if you're implementing gemini, the gmail team probably cares a lot more about bug tickets, whereas the gemini team has completely rewritten the codebase from scratch three quarters in a row
|
|
#
?
Apr 14, 2024 05:08
|
|
|
If a bug can’t be reproduced, close it because it can’t be reproduced, not because it’s old
|
|
#
?
Apr 14, 2024 05:17
|
|
|
I guess we just work in totally different levels of stability; the reproducibility rate of bug tickets after 6 months is less than 50%. Seems like a tremendous amount of time wasted prioritizing and assigning tickets, and making sure they're high enough quality your reports can effectively work on them. If reproducibility after 1 year is 95% then it's a different argument
|
|
#
?
Apr 14, 2024 05:28
|
|
|
How would you know what the reproducibility rate is if you just close everything sight unseen? Also when other teams get their bugs closed on timeout they will stop filing bugs. The system works!
|
|
#
?
Apr 14, 2024 07:37
|
|
|
Ultimately, the number of defects in your software isn't really connected to the number of open bugs in your issue tracker. Each bug ticket represents an opportunity to fix a defect and make your product better. If you're going to throw out those tickets without even looking at them why would you bother accepting them in the first place? Just let people email you their feedback and then don't make tickets for them. Automatically closing old tickets on a timeout sure as heck sounds like "someone added metric targets around the number of open tickets and then Goodhart's Law came into full effect".
|
|
#
?
Apr 14, 2024 09:47
|
|
|
Hadlock posted:I guess we just work in totally different levels of stability; the reproducibility rate of bug tickets after 6 months is less than 50%. Seems like a tremendous amount of time wasted prioritizing and assigning tickets, and making sure they're high enough quality your reports can effectively work on them. Maybe we do, but even then I think it's not quite a different argument: the original point I'm arguing against is "bug tickets not fixed after one year will be closed." and "If nobody has fixed the bug in one year, it's not worth fixing". It's the assumption that a year-old bug wasn't fixed because it wasn't worth fixing that gets me. If we're saying instead, if a bug is over a year old, then it probably isn't relevant or reproducible anymore, then that is a different thing that I'm somewhat more on board with. Even then, there are likely far better indicators of whether a bug is still a bug than merely how long ago it was noticed and filed. Whether there's any recent activity on the ticket is an obvious one. "bug tickets with a year of inactivity will be closed because they're probably not reproducible" is a far cry from the starting point here and a policy I'd be much more likely to accept. And for what it's worth, yeah, I work on a large product with a large legacy codebase, primarily on the server side, and in my world it's absolutely not a good assumption that a bug more than a year old is no longer reproducible. And also: Hadlock posted:1) there's nothing stopping someone from reopening a ticket. Annoying but if it's reopened it's a good indicator that it's still broken Hadlock posted:The best solution I've seen is to write a policy that says "bug tickets not fixed after one year will be closed. Ticket openers have 36 hour grace period to reopen them" or similar Emphasis mine
|
|
#
?
Apr 14, 2024 16:35
|
|
|
shrike82 posted:i also wonder whether the users who post their work wins on it, get any benefit from it. i'm past 40 and peers my age generally treat it as a CV profile website.
|
|
#
?
Apr 15, 2024 20:31
|
|
|
Love Stole the Day posted:Once or twice a month you'll get a message from a big name company. They'll give you the expedited, red carpet treatment through their hiring loop. Not sure if this is a serious post. I've been on LinkedIn for... probably more than a decade, and what you describe has happened I think kinda once, maybe, ever
|
|
#
?
Apr 15, 2024 21:07
|
|
|
During the good times that was pretty accurate for me. More recently it's been quarterly instead of monthly Your profile might not have enough popular keywords recruiters are looking for, or you're not logging in enough to get collected in the search query pool
|
|
#
?
Apr 15, 2024 21:42
|
|
|
Word is that how prominent you are in LI search results also depends on how often you reply to recruiters. If you want more attention, be good about saying no thanks to every message.
|
|
#
?
Apr 15, 2024 21:44
|
|
|
jaete posted:Not sure if this is a serious post. I've been on LinkedIn for... probably more than a decade, and what you describe has happened I think kinda once, maybe, ever ultrafilter posted:Word is that how prominent you are in LI search results also depends on how often you reply to recruiters. If you want more attention, be good about saying no thanks to every message.
|
|
#
?
Apr 16, 2024 03:33
|
|
|
Yeah I go through each week and tell every recruiter their top of range is 50k too low
|
|
#
?
Apr 16, 2024 04:11
|
|
|
I'm not really big on LinkedIn, but I do kind of like having a place that's for professional work sort of posting stuff. A coworker of mine from another country posts blog posts periodically about technical investigation stuff, and that's kind of interesting to read periodically; and I've made some posts of my own along the same lines. I don't really spend much time on there or anything, but I do think there's some niche there.
|
|
#
?
Apr 16, 2024 05:09
|
|
|
Dunno, my feed on mastodon/twitter brings in lot more articles of much bigger quality than I've seen in LinkedIn. OTOH I don't curate my LinkedIn feed at all (I am only ever there due to how their website sets up the back stack on android), so maybe it would be better if I did.
|
|
#
?
Apr 16, 2024 10:35
|
|
|
I ignore the gently caress out of LinkedIn while I’m employed, I hate thinking about job hunting. But that’s probably not a good idea, because every job ends eventually 
|
|
#
?
Apr 16, 2024 14:23
|
|
|
Pollyanna posted:I ignore the gently caress out of LinkedIn while I’m employed, I hate thinking about job hunting. But that’s probably not a good idea, because every job ends eventually always be interviewing
|
|
#
?
Apr 16, 2024 15:41
|
|
|
leper khan posted:always be interviewing
|
|
#
?
Apr 16, 2024 15:47
|
|
|
Do you always-be-interviewing folks just leave your open to work banner up on LinkedIn? How are you getting interviews? Id like to join your ranks. I don't have any glaring issues with where I work but it's a 2nd tier t/c for sure.
|
|
#
?
Apr 16, 2024 15:58
|
|
|
a dingus posted:Do you always-be-interviewing folks just leave your open to work banner up on LinkedIn? How are you getting interviews? Id like to join your ranks. I don't have any glaring issues with where I work but it's a 2nd tier t/c for sure. apply to a couple jobs a week. if you get too many interviews cut back. too few, try to figure out whats wrong with your materials or amp up the applications
|
|
#
?
Apr 16, 2024 16:02
|
|
|
leper khan posted:apply to a couple jobs a week. if you get too many interviews cut back. too few, try to figure out whats wrong with your materials or amp up the applications This seems exhausting as gently caress. Wii Spawn Camper posted:I’m getting anxiety about it just from reading this thread. How do you do it? Future-quoting this because yeah. Falcon2001 fucked around with this message at 16:25 on Apr 16, 2024 |
|
#
?
Apr 16, 2024 16:06
|
|
|
Falcon2001 posted:This seems exhausting as gently caress. you can reduce the effort you put into a job application to near zero if you dont care much about the outcome.
|
|
#
?
Apr 16, 2024 16:09
|
|
|
I’m getting anxiety about it just from reading this thread. How do you do it?
|
|
#
?
Apr 16, 2024 16:23
|
|
|
Interviewing is pretty much exactly like the talking part of dating, you'll suck at it if you're out of practice as you won't know what to say at first and ask awkward questions or spend too long thinking about the answers or how to summarize the last 20 years of life into an endearing 6 sentence story about success and overcoming adversity For interviews you need to gain their trust, then take control of the conversation and prove you're the best choice. I have a very standard story I like to tell about my career and career progression that checks all their boxes. Then you just need to pass the technical part of the interview. Once you figure out what you're going to say it's just 20-30 minutes on the phone on auto pilot. For the job you want there's usually about 20 obvious questions "what do you do" "what do you want to be doing in 5 years" "tell me about the time you had a conflict" "tell me about a project you were the lead on" etc etc. If you can weave those answers into your story you can spend less time answering awkwardly phrased questions and more time learning about the team and talking about next steps By throw away interview #5 you'll probably have cycled through 95% of the questions and by throw-away interview #10 you'll have your spiel memorized and be well on your way to fine tuning it
|
|
#
?
Apr 16, 2024 16:33
|
|
|
Wii Spawn Camper posted:I’m getting anxiety about it just from reading this thread. How do you do it? im also in games, so the expected outcome of not doing this is significantly worse. as mentioned, it becomes much easier to do interviews as you get more used to them. and its a lot less stressful to have practice interviews you dgaf about than for your first interview in a couple years to be for your dream job. it also gives you a feel for the market. i can identify in my calendar the point when hiring slowed down. having a leading indicator that you need to start preparing for the next layoff is very powerful.
|
|
#
?
Apr 16, 2024 16:39
|
|
|
The market changes from under you, in ways you'd never pick up if you're not pressure-testing your story. For a lot of years my story was "I've done a lot of tech jobs and I'm good at most of them, so my bosses always point me at their biggest problem. I honestly do not care if that's staff engineering, managing a struggling team, or building something important that's missing, as long as I'm doing it at a good company", and that absolutely does not resonate with hiring managers anymore
|
|
#
?
Apr 16, 2024 16:56
|
|
|
always be interviewing is great advice, but it's kind of like 'have a great github portfolio' in that it's no big deal at all to do when you have no responsibilities, but gets really obnoxious when other people have legitimate claims on your time. it's probably much more sustainable to hit the circuit on a cadence (say, yearly). of course i don't do that either, but it at least isn't a non-starter
|
|
#
?
Apr 16, 2024 17:16
|
|
|
Thanks for the replies. My current role feels super draining and I’m really burnt out, and as a result I’m finding it impossible to stay motivated and put effort towards finding a new job during my personal time. I’m fine with interviews themselves, it’s the getting interviews part that sucks.
|
|
#
?
Apr 16, 2024 17:35
|
|
|
Vulture Culture posted:The market changes from under you, in ways you'd never pick up if you're not pressure-testing your story. For a lot of years my story was "I've done a lot of tech jobs and I'm good at most of them, so my bosses always point me at their biggest problem. I honestly do not care if that's staff engineering, managing a struggling team, or building something important that's missing, as long as I'm doing it at a good company", and that absolutely does not resonate with hiring managers anymore ...what the hell are they looking for instead? Typing code real fast?
|
|
#
?
Apr 16, 2024 18:06
|
|
|
|
| # ? Apr 30, 2024 05:08 |
|
|
Rocko Bonaparte posted:...what the hell are they looking for instead? Typing code real fast? probably conviction in how you want to deliver value
|
|
#
?
Apr 16, 2024 18:14
|
|