|
It’s a really difficult problem. You have to ask yourself: If nothing else changes in the next {time period}, what will be more confusing - this one file not being correct, or two different implementations living side-by-side? Will a new engineer know which implementation to choose for the next new this type of file?
|
#
?
Feb 4, 2020 17:23
|
|
|
|
| # ? Jun 7, 2024 09:33 |
|
|
dantheman650 posted:Will a new engineer know which implementation to choose for the next new this type of file? What’s the failure mode here? They take 30s to ask the question? If they don’t just check the blame to see which is more recent, then you catch it in review. At which point taqueso posted:Tell them they need to fix all the other ones too.
|
|
#
?
Feb 4, 2020 18:16
|
|
|
taqueso posted:Seems like if this is preventing you from doing good things, it's a process smell. Sounds like a perfectly reasonable and common implementation of scrummerfall to me.
|
|
#
?
Feb 4, 2020 18:23
|
|
|
JawnV6 posted:What’s the failure mode here? They take 30s to ask the question? If they don’t just check the blame to see which is more recent, then you catch it in review. In my experience the more likely failure mode when dealing with software that has a significant legacy is that the new engineer sees that they are different, assumes that whoever decided they should be different had a good reason for it—probably relating to some crusty old code no one wants to touch—and then depending on the kind of engineer they are they either: A) spend a decent chunk of time trying to discern why it was done so they can decide which style whatever they want to add should be in, possibly arriving at the right answer and possibly not or B) don't want to deal with it and so proceed on the assumption that the old style is less likely to break things in unexpected ways. I have found that it takes me a good 1-3 months to convince a new engineer that I am delighted to answer thoughtful questions and save two hours of their time with 5 minutes of mine (I'm mostly in a PM role currently), and some of them still won't just ask unless I poke them regularly to see if they're stuck on anything and then make them tell me what the problem is. I would also say that generally speaking there is a huge amount of (cognitive) work that goes into really starting to familiarize yourself with a complex codebase and anything you can do to reduce unnecessary and distracting complexity is worth doing if you can steal the time to do it 
Wallet fucked around with this message at 18:33 on Feb 4, 2020 |
|
#
?
Feb 4, 2020 18:29
|
|
|
quit hiring poo poo engineers
|
|
#
?
Feb 4, 2020 18:51
|
|
|
JawnV6 posted:quit hiring poo poo engineers No
|
|
#
?
Feb 4, 2020 20:00
|
|
|
JawnV6 posted:quit hiring poo poo engineers Then I won't have a job.
|
|
#
?
Feb 4, 2020 20:05
|
|
|
Protocol7 posted:Then I won't have a job. this. have some empathy mate
|
|
#
?
Feb 4, 2020 20:16
|
|
|
Cognitive overhead is not something only suffered by poo poo engineers.
|
|
#
?
Feb 4, 2020 22:54
|
|
|
JawnV6 posted:quit hiring poo poo engineers Unfortunately I have found it's often the better engineers that are least inclined to ask questions instead of trying to figure poo poo out for themselves. That's probably how they became good in the first place.
|
|
#
?
Feb 4, 2020 23:13
|
|
|
Wallet posted:Unfortunately I have found it's often the better engineers that are least inclined to ask questions instead of trying to figure poo poo out for themselves. That's probably how they became good in the first place. I know personally whenever I would struggle and eventually solve a problem, I would feel more "ownership" over that area of the code. Though I have a self-imposed rule that if I spin my wheels on something for more than a day that I definitely need to rope someone in.
|
|
#
?
Feb 5, 2020 00:15
|
|
|
Wallet posted:Unfortunately I have found it's often the better engineers that are least inclined to ask questions instead of trying to figure poo poo out for themselves. That's probably how they became good in the first place. ??? your perspective is, to use the local jargon, turbofucked where'd you get this definition of "better" where they won't glance at a PR comment or try to work with the rest of the team? is it purely based on ticket count churn or did you smuggle in some other lovely way to measure them?
|
|
#
?
Feb 5, 2020 00:17
|
|
|
JawnV6 posted:where'd you get this definition of "better" where they won't glance at a PR comment or try to work with the rest of the team? is it purely based on ticket count churn or did you smuggle in some other lovely way to measure them? I'm not talking about not looking at PR/ticket comments or other documentation, that's just being a massive moron. I'm also not talking about some bizarro metric. Good people tend to be curious and to like solving complex problems. Most of them got good by being curious and enjoying solving complex problems enough to bang their heads against some of them until they figured out which way was up. A lot of them have a lot more tolerance for grinding themselves against a problem instead of talking to other people than they really should. Basically this is what I see a lot of: Protocol7 posted:I know personally whenever I would struggle and eventually solve a problem, I would feel more "ownership" over that area of the code. Though I have a self-imposed rule that if I spin my wheels on something for more than a day that I definitely need to rope someone in.
|
|
#
?
Feb 5, 2020 01:02
|
|
|
alright, so we've totally lost the "const correctness" context that set this off and we're 100% on some fucken PM's ginned up fantasies about devs separated from that, glad we could post today
|
|
#
?
Feb 5, 2020 01:12
|
|
|
JawnV6 posted:alright, so we've totally lost the "const correctness" context that set this off and we're 100% on some fucken PM's ginned up fantasies about devs separated from that, glad we could post today You think the next person to mess with that code is going to read comments on a PR that was merged forever ago next time this comes up? In the original context we're talking about consistency across separate files; I don't know any developers who are likely to catch that, and I definitely wouldn't have when I was mostly a developer. Maybe the world is just too poo poo for your genius. Wallet fucked around with this message at 01:20 on Feb 5, 2020 |
|
#
?
Feb 5, 2020 01:14
|
|
|
Wallet posted:You think the next person to mess with that code is going to read comments on a PR that was merged forever ago next time this comes up? In the original context we're talking about consistency across separate files; I don't know any developers who are likely to catch that, and I definitely wouldn't have when I was mostly a developer. Maybe the world is just too poo poo for your genius. yeah you were a poo poo developer if you can't notice something like const correctness across the vast, impermeable gulf of... "separate files", hth and yes, if I see something done vastly different in two places, i will absolutely pull up a PR for one of them as part of investigating. or ask a colleague. or respond to an explicit request in a PR. if you're not allowing devs time/space for that amount of digging or polish, you're a poo poo PM and org. for a long, ongoing concern like adding const correctness eventually everyone should be aware of the technical debt and the standard folks are working towards and shouldn't need to go digging every single time. or you can just let folks go hog wild, have no standards or expectations, force push to master/prod, and deal with the resultant chaos, whatever im not ur mom
|
|
#
?
Feb 6, 2020 23:53
|
|
|
JawnV6 posted:or you can just let folks go hog wild, have no standards or expectations, force push to master/prod, and deal with the resultant chaos, whatever im not ur mom yeah it owns. way more fun than doing things by the book. i'm a loose cannon
|
|
#
?
Feb 6, 2020 23:57
|
|
|
Gate stuff or don't, whatever, but a team that doesn't build at least de facto standards is a team that's terrified of interpersonal conflict
|
|
#
?
Feb 7, 2020 00:05
|
|
|
Vulture Culture posted:Gate stuff or don't, whatever, but a team that doesn't build at least de facto standards is a team that's terrified of interpersonal conflict I didn't get a job working with computers so I can yell at people for not following style guidelines. 
|
|
#
?
Feb 7, 2020 00:10
|
|
|
JawnV6 posted:if you're not allowing devs time/space for that amount of digging or polish, you're a poo poo PM and org. There are a lot of levels of standards and expectations between these two things and many places do not have the support from management to allow that kind of poo poo. I can't disagree that that makes them poo poo orgs, but people gotta eat. HTH.
|
|
#
?
Feb 7, 2020 00:23
|
|
|
Rocko Bonaparte posted:Yeah WTF. A coworker and I will sometimes poo poo out code like that and then delete because we know nobody else can maintain it... and we barely could either. The point wasn't critical to his solution, I'm not a Python guy so who knows, maybe that's lean and mean Python. My point is that in almost any non-trivial task, Fizzbuzz included, 'best' is a requirements based assessment and so just flatly stating 'this is the BEST way to do a thing!' tends to show a shortsightedness. Best depends on which metric one is using.
|
|
#
?
Feb 7, 2020 11:30
|
|
|
Company: to make sure you adhere to all standards, use this pre-baked, company specific Spring Boot project. Company a few months later: UPDATE YOUR PROJECTS NOW, A CRITICAL BUG IS FOUND. Product Owner: Why is taking development of simple features so long?
|
|
#
?
Feb 7, 2020 13:13
|
|
|
Protocol7 posted:I didn't get a job working with computers so I can yell at people for not following style guidelines. Why the hell not that's the best part
|
|
#
?
Feb 11, 2020 20:48
|
|
|
ChickenWing posted:Why the hell not that's the best part You implement a build blocking linting tool and then gently caress with the numbers without telling your colleagues. Are you new to this?
|
|
#
?
Feb 11, 2020 21:41
|
|
|
Keetron posted:You implement a build blocking linting tool and then gently caress with the numbers without telling your colleagues. Are you new to this? But then how will I assert my dominance as Alpha Programmer i can only get my dick hard after leaving 30 minor style comments on a critical PR and marking as "Changes Requested"
|
|
#
?
Feb 11, 2020 21:43
|
|
|
ChickenWing posted:But then how will I assert my dominance as Alpha Programmer If you aren't being passive aggressive about everything because you're conflict avoidant then you're doing it wrong. The ol "suddenly linter is enabled on git commit hook" trick works well in my book.
|
|
#
?
Feb 11, 2020 21:59
|
|
|
pointlessly changing the rules based on whatever blog post you read over the weekend works wonders as well
|
|
#
?
Feb 11, 2020 22:12
|
|
|
Sagacity posted:pointlessly changing the rules based on whatever blog post you read over the weekend works wonders as well At my old job there was one guy who was really opinionated with ReSharper and ended up uploading his personal ReSharper config to the whole VCS. It got reverted after a dozen different changesets included a bunch of superfluous style changes.
|
|
#
?
Feb 12, 2020 00:58
|
|
|
You all have PR's that *aren't* just people commenting on any ReSharper analysis items that the original dev overlooked?
|
|
#
?
Feb 12, 2020 10:00
|
|
|
Cuntpunch posted:You all have PR's that *aren't* just people commenting on any ReSharper analysis items that the original dev overlooked? I was legitimately nitpicky about PRs in my old job since I had a coworker who would routinely submit changesets spanning a dozen plus files, with tons of formatting noise. Doesn't matter if it was a simple calculation error or a massive user story, they left the code equivalent of a crater in their wake. Even worse, they would continue to submit changesets to the PR well after it was already signed off by reviewers. So who knows what changesets were actually making it into the codebase? Of course the management there was spineless and basically shrugged at me when I brought it up so that's one of many reasons why it's my old job.
|
|
#
?
Feb 12, 2020 16:36
|
|
|
Protocol7 posted:Even worse, they would continue to submit changesets to the PR well after it was already signed off by reviewers. So who knows what changesets were actually making it into the codebase? I've been frequently frustrated by our PRs resetting approvals on any additional changes but honestly after seeing some of my coworkers' PR practices I don't think I'd ever go back
|
|
#
?
Feb 12, 2020 18:08
|
|
|
ChickenWing posted:I've been frequently frustrated by our PRs resetting approvals on any additional changes but honestly after seeing some of my coworkers' PR practices I don't think I'd ever go back We have a policy that you can modify files after approval, but that emails reviewers an additional diff against what they approved after the fact to be sure they know what was changed. Changing a file that wasn't part of the changeset removes the approval and you need to request it again. It seems like a nice balance.
|
|
#
?
Feb 12, 2020 18:43
|
|
|
Code is art, and in this thesis I shall explain why my linter rules allow my inner peacock to truly shine.
|
|
#
?
Feb 12, 2020 18:51
|
|
|
ChickenWing posted:I've been frequently frustrated by our PRs resetting approvals on any additional changes but honestly after seeing some of my coworkers' PR practices I don't think I'd ever go back Yeah, this is a bare minimum for me. I don't want to sign off on a changeset and find that something else was merged in with my signature on it.
|
|
#
?
Feb 12, 2020 19:13
|
|
|
Awesome Animals posted:Code is art, and in this thesis I shall explain why my linter rules allow my inner peacock to truly shine. Ohh, a 10x developer! a make-10x-more-work-for-everyone-else developer
|
|
#
?
Feb 12, 2020 19:53
|
|
|
Fun downside of being a senior developer: some recruiter emails now come straight to my personal email instead of my linkedin
|
|
#
?
Feb 12, 2020 20:25
|
|
|
Che Delilas posted:Ohh, a 10x developer! Accurate but for different reasons.
|
|
#
?
Feb 12, 2020 20:39
|
|
|
We are moving functionality from system A to system B. Now system A is getting faster and faster and system B is slowing down. Upside: B is a microservice with a postgres database, so there is a ton of room for tweaking the setup. Upside: A is on a platform that will be turned off (hadoop) Upside: B is designed to be modified, very modular making future changes easy and a phased trransition possible Downside: A is a BBOM and removing stuff is really hard, hoping nothing will break. Downside: Why is B so slow these days? We should have stuck with A, A has been going really fast recently.
|
|
#
?
Feb 12, 2020 20:56
|
|
|
Keetron posted:We are moving functionality from system A to system B. You should just permanently move things from A to B to A. Everything is fast! Maybe introduce this as a solution: https://github.com/yarrick/pingfs
|
|
#
?
Feb 12, 2020 22:14
|
|
|
|
| # ? Jun 7, 2024 09:33 |
|
|
Hollow Talk posted:You should just permanently move things from A to B to A. Everything is fast! Maybe introduce this as a solution: https://github.com/yarrick/pingfs The entire development of the internet has been leading to this project.
|
|
#
?
Feb 12, 2020 23:42
|
|