Working in Development: Leaving sounds like a great decision.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›434 »

smackfu: Jun 7, 2004

You don't have testers, you do TDD so all the software is perfect.

# ? Apr 25, 2017 02:35

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 08:23

toiletbrush: May 17, 2010

Sagacity posted:

Right. What makes it so hard to just ask for a *single* requirements doc? Is it fear of confrontation or arguing with a superior?

Mostly I think it's the effort involved in understanding requirements that might come from different people in different formats enough to consolidate them, and being too timid/lazy/stupid to challenge or question any of it, even when it conflicts.

To be fair though if you work on a project where there's a bunch of top level execs competing to contribute the most so they can claim the project is their baby, the flood of wildly conflicting and poorly thought out bikeshedding.txt JIRAs can be too much for any sane mind to handle.

# ? Apr 25, 2017 12:57

vonnegutt: Aug 7, 2006; Hobocamp.

toiletbrush posted:

Mostly I think it's the effort involved in understanding requirements that might come from different people in different formats enough to consolidate them, and being too timid/lazy/stupid to challenge or question any of it, even when it conflicts.

To be fair though if you work on a project where there's a bunch of top level execs competing to contribute the most so they can claim the project is their baby, the flood of wildly conflicting and poorly thought out bikeshedding.txt JIRAs can be too much for any sane mind to handle.

I have never understood this. Perhaps it's my former consulting career but there is nothing I love more than shoving a lovely spec back to its owner and asking for clarification. Deadlines get adjusted, deliverables gets adjusted, my life gets easier.

I find it works best if you wrangle it a bit yourself, and try to find a compromise between all the disparities, and present that to whoever. "Ok, so for the chat module, it seems like we need a text editor and real-time message delivery. Probably going to use the plugin that Hendricks wrote for the other thing with the websockets, and our standard auth. Is this what you had in mind?" Most lazy/overwhelmed PMs will just say yes at this point unless its totally wrong, and if you did this whole thing by email, now you have paperwork you can point to if anyone gets antsy.

If there are multiple specs that are completely irreconcilable, then it becomes even easier - you highlight the mutually incompatible parts, present both to the PM, and say, "Which way do you want me to go on this?"

I guess it doesn't feel like coding because it barely involves typing, but reducing the amount of code you even think about writing is one of the biggest efficiency improvements you can make.

# ? Apr 25, 2017 14:23

Gildiss: Aug 24, 2010; Grimey Drawer

vonnegutt posted:

Deadlines get adjusted, deliverables gets adjusted, my life gets easier.

What reality is this in?
Because I want in.

# ? Apr 25, 2017 14:34

toiletbrush: May 17, 2010

vonnegutt posted:

I have never understood this. Perhaps it's my former consulting career but there is nothing I love more than shoving a lovely spec back to its owner and asking for clarification. Deadlines get adjusted, deliverables gets adjusted, my life gets easier.

Same here, I love spotting edge cases and asking awkward questions in client meetings and estimation/planning and whatnot. So many features get dramatically simplified or even cut because stuff has been proposed and sometimes even accepted seemingly without being thought through.

Very few of the BAs/PMs/owners I've worked with have been any good at it, though.

# ? Apr 25, 2017 14:55

Pollyanna: Mar 5, 2005; Milk's on them.

vonnegutt posted:

Deadlines get adjusted, deliverables gets adjusted,

# ? Apr 25, 2017 16:24

Pollyanna: Mar 5, 2005; Milk's on them.

Is it considered normal/kosher to push in changes for an unrelated ticket to your PRs? My coworker was just s out to approve another coworkers PR but he suddenly pushed changes that we didn't expect, and I suggest occasions like that, where stuff goes under the radar, is a cause of unforeseen and difficult to trace bugs and regressions in our project.

# ? Apr 25, 2017 16:36

a foolish pianist: May 6, 2007; (bi)cyclic mutation

Pollyanna posted:

Is it considered normal/kosher to push in changes for an unrelated ticket to your PRs? My coworker was just s out to approve another coworkers PR but he suddenly pushed changes that we didn't expect, and I suggest occasions like that, where stuff goes under the radar, is a cause of unforeseen and difficult to trace bugs and regressions in our project.

I hate when PRs have unrelated stuff in them. PRs are for specific features or fixes. Occasionally, a tiny fix can go in something unrelated, but if it's more than a line or two (with a commit message like "found this tiny error in process, fixed while testing" or somesuch), it needs its own PR.

# ? Apr 25, 2017 16:38

Pollyanna: Mar 5, 2005; Milk's on them.

That other coworker just declined a pull request for a basic copy change due to a bug in a completely unrelated part of the code base. Is it wrong of me to be pissed off over this? It's not even my PR but it's ridiculous for a really simple, basic PR to be rejected because there's a bug in a totally different part of the codebase.

# ? Apr 25, 2017 16:50

a foolish pianist: May 6, 2007; (bi)cyclic mutation

Pollyanna posted:

That other coworker just declined a pull request for a basic copy change due to a bug in a completely unrelated part of the code base. Is it wrong of me to be pissed off over this? It's not even my PR but it's ridiculous for a really simple, basic PR to be rejected because there's a bug in a totally different part of the codebase.

Wait, so he declined because there wasn't unrelated stuff in the PR?

# ? Apr 25, 2017 17:23

Pollyanna: Mar 5, 2005; Milk's on them.

a foolish pianist posted:

Wait, so he declined because there wasn't unrelated stuff in the PR?

The PR and related ticket was a copy change in a modal popover. The PR was rejected because the header for the modal looked different between two different versions of the app (insurance calculators sharing a common but copy-pasted codebase). The header was not the subject of the ticket nor was touched as part of the PR.

# ? Apr 25, 2017 17:26

Space Kablooey: May 6, 2009

Fix that in the parent branch and rebase the PR branch into the fixed parent branch.

# ? Apr 25, 2017 18:19

Pollyanna: Mar 5, 2005; Milk's on them.

HardDiskD posted:

Fix that in the parent branch and rebase the PR branch into the fixed parent branch.

Yes, but that still doesn't excuse declining an unrelated PR.

# ? Apr 25, 2017 18:19

Space Kablooey: May 6, 2009

Wait, your coworker straight up declined and closed the PR?

Edit: TBF I wouldn't also accept the PR until that was fixed, so maybe the horror is me. :shrug:

Space Kablooey fucked around with this message at 18:28 on Apr 25, 2017

# ? Apr 25, 2017 18:22

Pollyanna: Mar 5, 2005; Milk's on them.

HardDiskD posted:

Wait, your coworker straight up declined and closed the PR?

Yep. "These things in another part of the codebase look different. Please change them and put the PR back up. *decline*"

Pollyanna fucked around with this message at 18:28 on Apr 25, 2017

# ? Apr 25, 2017 18:25

Pollyanna: Mar 5, 2005; Milk's on them.

HardDiskD posted:

TBF I wouldn't also accept the PR until that was fixed, so maybe the horror is me.

Why? If a PR for a ticket to change the wording for an element is put up and then declined because the styling is off for some other element, how does that make sense? The error was neither introduced in the PR nor does the PR cause any regressions. Does an existing bug prevent any work at all from being done on a codebase until it is fixed? That sounds like a huge blocker.

# ? Apr 25, 2017 18:32

a foolish pianist: May 6, 2007; (bi)cyclic mutation

Yeah, if the guy wants something unrelated to get fixed, make a ticket, fix the thing in its own fix-branch, make a PR, done.

# ? Apr 25, 2017 18:34

CPColin: Sep 9, 2003; Big ol' smile.

Pollyanna posted:

If a PR for a ticket to change the wording for an element is put up and then declined because the styling is off for some other element, how does that make sense?

It doesn't.

I used to hate declining pull requests, because the interface always just slammed the door shut, compared to having a discussion and trying to work it out. I hated even more when I happened to open a pull request I wasn't added to and found a problem in it that the other reviewers didn't catch. I always felt like such a jerk for butting in and asking for a fix.

# ? Apr 25, 2017 18:41

Space Kablooey: May 6, 2009

Pollyanna posted:

Why? If a PR for a ticket to change the wording for an element is put up and then declined because the styling is off for some other element, how does that make sense? The error was neither introduced in the PR nor does the PR cause any regressions.Does an existing bug prevent any work at all from being done on a codebase until it is fixed? That sounds like a huge blocker.

No, work can still happen in other branches, but I wouldn't merge any until the parent is fixed. Yeah, it is a huge blocker, but something has already failed if a commit/branch with bugs already went into a dev/master branch.

Space Kablooey fucked around with this message at 18:50 on Apr 25, 2017

# ? Apr 25, 2017 18:48

spiritual bypass: Feb 19, 2008; Grimey Drawer

Pollyanna posted:

That other coworker just declined a pull request for a basic copy change due to a bug in a completely unrelated part of the code base.

Reminds me of the job I got fired from back in January. My PRs would get rejected for not meeting their unique coding standards. When I changed one line in a 1000 line JS file, they'd expect me to fix the entire file to match their new style.

# ? Apr 25, 2017 18:51

a foolish pianist: May 6, 2007; (bi)cyclic mutation

HardDiskD posted:

No, work can still happen in other branches, but I wouldn't merge any until the parent is fixed. Yeah, it is a huge blocker, but something has already failed if a commit/branch with bugs already went into a dev/master branch.

This sounds insane. If there's something else broken on master, make a separate ticket and fix separately. Unless you're in a shop where there's only ever 1 bug at a time, in which case get me a job there.

# ? Apr 25, 2017 19:01

Pollyanna: Mar 5, 2005; Milk's on them.

Also, is it normal for someone to hijack one of your PRs? Said other coworker also regularly takes a branch I or my coworker are working on and adds his own commits, often with changes not originally outlined in the ticket. I kind of take umbrage to this cause I'm in charge of my branches and PRs and if something breaks cause someone else adds their own poo poo onto it without my knowledge that's something I personally have to answer for. Please don't loving add to my branch, merge your commits in another branch to my branch, or merge my PRs in without my consent.

Maybe I'm being too hard-rear end here, but it's poo poo like this that leads to confusion and weird regressions and bugs. Also, it's rude.

# ? Apr 25, 2017 19:14

Space Kablooey: May 6, 2009

a foolish pianist posted:

This sounds insane. If there's something else broken on master, make a separate ticket and fix separately. Unless you're in a shop where there's only ever 1 bug at a time, in which case get me a job there.

I'm the horror, then. :v:

Pollyanna posted:

# ? Apr 25, 2017 19:16

ChickenWing: Jul 22, 2010

Oh my god if someone started committing to my feature branch without at least talking to me first I would lose my goddamn poo poo

# ? Apr 25, 2017 19:46

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

HardDiskD posted:

Same.

Forcibly push your version and eliminate his changes.

# ? Apr 25, 2017 19:51

Rubellavator: Aug 16, 2007

Why are people who do dumb things like that so motivated to do them.

# ? Apr 25, 2017 19:59

Mniot: May 22, 2003; Not the one you know

Pollyanna posted:

Also, is it normal for someone to hijack one of your PRs?

Dude, you said your ops team quit en masse a couple days ago. Nothing normal is going on.

Unrelated bug-fixes in a PR isn't an automatic rejection, but it's polite to mention it. Like "fixes bug X. I also had to fix bug Y before I was able to diagnose the problem."

Rejecting a PR because a bug exists elsewhere is moronic. Refusing to merge a PR like HardDiskD says can be reasonable depending on the bug. Sometimes, the bug in master isn't killing anybody but it's impossible to fix when assholes keep merging more code in. At that point, you have to just say "look, this bug is a bigger deal than it looks so it's a P0" (or whatever you call a drop-everything bug).

Touching someone else's feature branch without explicit permission is hosed up. Do they also snatch your keyboard and leave finger-grease smears all over it? Because that's the same goddamn thing.

# ? Apr 25, 2017 20:06

Mniot: May 22, 2003; Not the one you know

Volmarias posted:

Same.

Forcibly push your version and eliminate his changes.

Yesss another use-case for force-push :getin:

# ? Apr 25, 2017 20:08

CPColin: Sep 9, 2003; Big ol' smile.

Mniot posted:

Touching someone else's feature branch without explicit permission is hosed up. Do they also snatch your keyboard and leave finger-grease smears all over it? Because that's the same goddamn thing.

Or pointing at something on your screen and touching it.

# ? Apr 25, 2017 20:52

Rubellavator: Aug 16, 2007

I'm rewriting a significant portion of the web app I've been working on for the last few months. There was a whole application role with screens and reports written for a certain important individual. Turns out the requirements were written without ever really consulting her because she's such a pain to deal with. They just kinda tried to reverse engineer her job and basically everything is wrong.

# ? Apr 25, 2017 21:26

Pollyanna: Mar 5, 2005; Milk's on them.

Fire Fast sounds pretty good right now. Even if it is capitalist dreck.

# ? Apr 25, 2017 21:38

Polio Vax Scene: Apr 5, 2009

I sure do love APIs where the documentation says to pass a blob of JSON but doesn't give an example or any sort of structure to the blob

# ? Apr 25, 2017 21:40

Hughlander: May 11, 2005

Pollyanna posted:

Also, is it normal for someone to hijack one of your PRs? Said other coworker also regularly takes a branch I or my coworker are working on and adds his own commits, often with changes not originally outlined in the ticket. I kind of take umbrage to this cause I'm in charge of my branches and PRs and if something breaks cause someone else adds their own poo poo onto it without my knowledge that's something I personally have to answer for. Please don't loving add to my branch, merge your commits in another branch to my branch, or merge my PRs in without my consent.

Maybe I'm being too hard-rear end here, but it's poo poo like this that leads to confusion and weird regressions and bugs. Also, it's rude.

Just push a new branch name from before his commits and move on. It's the same effect as force push without being aggressive about it.

# ? Apr 25, 2017 21:51

Ghost of Reagan Past: Oct 7, 2003; rock and roll fun

Polio Vax Scene posted:

I sure do love APIs where the documentation says to pass a blob of JSON but doesn't give an example or any sort of structure to the blob

I had to work with an API where the output was--I wish I was kidding--a blob of malformed HTML.

# ? Apr 25, 2017 22:37

Gildiss: Aug 24, 2010; Grimey Drawer

Ghost of Reagan Past posted:

I had to work with an API where the output was--I wish I was kidding--a blob of malformed HTML.

I've had one with an error response with status code 200 type JSON that just had a string "error".

# ? Apr 25, 2017 22:42

jony neuemonic: Nov 13, 2009

Ghost of Reagan Past posted:

I had to work with an API where the output was--I wish I was kidding--a blob of malformed HTML.

The best I've seen was a JSON API half-assedly bolted onto an existing system, so the happy path stuff was JSON but the errors were IIS' default HTML pages.

# ? Apr 25, 2017 22:48

Polio Vax Scene: Apr 5, 2009

jony neuemonic posted:

The best I've seen was a JSON API half-assedly bolted onto an existing system, so the happy path stuff was JSON but the errors were IIS' default HTML pages.

This one prints the stack trace in the error page

# ? Apr 25, 2017 22:55

Clanpot Shake: Aug 10, 2006; shake shake!

I had to provide support for an integration that sent us XML that didn't validate against the schema file they sent us. We had to massage the schema to generate code that would validate the requests they were sending us. You have certainly heard of the company that did this moronic thing.

# ? Apr 25, 2017 22:57

Hughlander: May 11, 2005

Polio Vax Scene posted:

I sure do love APIs where the documentation says to pass a blob of JSON but doesn't give an example or any sort of structure to the blob

Thought I posted this but looks like it got eaten...

It's a blob of JSON. That should mean that it's a opaque bit of data that the API never inspects. That's what 'blob' means isn't it? pass "{}" and it should be perfectly fine, or the person writing the documentation needs to look up the definition of blob.

# ? Apr 25, 2017 23:35

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 08:23

Pollyanna: Mar 5, 2005; Milk's on them.

The one I deal with outputs a 403 forbidden with a massive Python stack trace like this:

code:

{
  "data": {
    "model:" {
      "error":  "Error: Error in API. Please tell <API author> about this. Traceback (most recent call last):\n  File "main.py", line 10, in <module>\n    main()\n  File "library.py", line 7, in main\n    throws()\n  File "other_library.py", line 4, in throws\n    raise RuntimeError('Error in API. Please tell <API Author> about this.') Error: Error in API. Please tell <API author> about this. "
    }
  }
}

# ? Apr 26, 2017 00:16

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›434 »