Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Pollyanna
Mar 5, 2005

Milk's on them.


love2get inundated with Slack alerts about bugs found in my PRs and side effects from other tickets getting deployed while I'm off for two days to interview at a different company. Real good reminder of why I'm leaving.

Adbot
ADBOT LOVES YOU

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me

CPColin posted:

Cool, thanks. The stuff I was proposing is pretty simple. The code that's there now includes all kinds of stuff for performing inserts and updates, but nothing ever calls it. It led to me scratching my head for a bit, wondering what the code was doing, because of how much extra functionality was available, relative to what was actually necessary.

Also, all the code does stuff like this: (new PersonFactory()).GetPersonById("xyz"). Like, everything is constructing these factory instances and nothing ever uses them for more than the one call. All the factory classes extend an abstract base and have to provide implementations for a bunch of stuff.

If you aren't using EF for everything, it's added complexity to add it now to only use for simple things. Creates discontinuity, I would be against adding it just to save a few lines of "SELECT * FROM X WHERE ID = @ID".

CPColin
Sep 9, 2003

Big ol' smile.
Well you gotta start somewhere; you're bound to have some stuff using the old system while the new system gains traction.

My motivation here started with looking at the existing factory classes, thinking, "Wow, this code is really repetitive and duplicated all over. Maybe it could be cleaned up?" and then realizing that, if I'm going to file something to clean up the code, I should probably see what sort of existing solutions are out there.

I mean, here's one of the methods:

code:
        public Person GetPersonById(int id)
        {
            Person SingularInst = null;
            SqlConnection conn = ConnectionManager.GetConnection();
            SqlCommand comm = conn.CreateCommand();

            comm.CommandText = "getPersonById";
            comm.CommandType = CommandType.StoredProcedure;

            SqlParameterCollection SPParams = comm.Parameters;
            SPParams.Add(new SqlParameter("@ID", SqlDbType.Int)).Value = id;

            try
            {
                conn.Open();
                SqlDataReader Reader = comm.ExecuteReader(CommandBehavior.CloseConnection);

                while (Reader.Read())
                    SingularInst = BuildPerson(Reader);
                Reader.Close();
            }
            catch (Exception e)
            {
                throw new Exception("Database Layer: " + e.Message);
            }
            finally
            {
                conn.Close();
            }
            return SingularInst;
        }
The GetPersonByName() method is exactly the same, but with different procedure and parameter names. The two equivalent methods that return multiple results are almost exactly the same, but build up a collection in the while loop.

Anyway, it didn't come up during sprint planning and our PO is out for a month, so v:shobon:v

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me

CPColin posted:

Well you gotta start somewhere; you're bound to have some stuff using the old system while the new system gains traction.

My motivation here started with looking at the existing factory classes, thinking, "Wow, this code is really repetitive and duplicated all over. Maybe it could be cleaned up?" and then realizing that, if I'm going to file something to clean up the code, I should probably see what sort of existing solutions are out there.

I mean, here's one of the methods:

code:
        public Person GetPersonById(int id)
        {
            Person SingularInst = null;
            SqlConnection conn = ConnectionManager.GetConnection();
            SqlCommand comm = conn.CreateCommand();

            comm.CommandText = "getPersonById";
            comm.CommandType = CommandType.StoredProcedure;

            SqlParameterCollection SPParams = comm.Parameters;
            SPParams.Add(new SqlParameter("@ID", SqlDbType.Int)).Value = id;

            try
            {
                conn.Open();
                SqlDataReader Reader = comm.ExecuteReader(CommandBehavior.CloseConnection);

                while (Reader.Read())
                    SingularInst = BuildPerson(Reader);
                Reader.Close();
            }
            catch (Exception e)
            {
                throw new Exception("Database Layer: " + e.Message);
            }
            finally
            {
                conn.Close();
            }
            return SingularInst;
        }
The GetPersonByName() method is exactly the same, but with different procedure and parameter names. The two equivalent methods that return multiple results are almost exactly the same, but build up a collection in the while loop.

Anyway, it didn't come up during sprint planning and our PO is out for a month, so v:shobon:v

Even if it is somewhat redundant, there is value in consistency. There's a lot of room to clean that up without throwing in new technologies. EF is especially contentious in this sort of scenario. EF is convention over configuration, in that it has a strong opinion on how your DB should work. If you already HAVE a DB that does not match this opinion, this is a bad move. They will likely conflict and will cause more trouble than it's worth.

B-Nasty
May 25, 2005

CPColin posted:

My motivation here started with looking at the existing factory classes, thinking, "Wow, this code is really repetitive and duplicated all over. Maybe it could be cleaned up?" and then realizing that, if I'm going to file something to clean up the code, I should probably see what sort of existing solutions are out there.

I mean, here's one of the methods:


Yeah, that's pretty bad. It probably says a bit about your coworkers that they didn't at least try to write their own basic ORM or DBHelper that would at least handle 70% of that repetitive cruft. That said, don't do that either, just use something like Dapper. Assuming you aren't doing anything crazy in that mapping method (BuildPerson), the equivalent function using Dapper would be about 3 lines.

Put me down as another EF hater. I know and like SQL, and I like to use it to efficiently CRUD the data that I want rather than loading a complex object graph to update a few fields.

Blinkz0rz
May 27, 2001

MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Pollyanna posted:

love2get inundated with Slack alerts about bugs found in my PRs and side effects from other tickets getting deployed while I'm off for two days to interview at a different company. Real good reminder of why I'm leaving.

Your code not working and being called out for it is a good reminder of why you're leaving? If that's the case, unless the call-out was exceptionally rude you're in for a world of disappointment no matter where you go.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...
Do you get paged for PRs or something?

CPColin
Sep 9, 2003

Big ol' smile.

Skandranon posted:

Even if it is somewhat redundant, there is value in consistency. There's a lot of room to clean that up without throwing in new technologies. EF is especially contentious in this sort of scenario. EF is convention over configuration, in that it has a strong opinion on how your DB should work. If you already HAVE a DB that does not match this opinion, this is a bad move. They will likely conflict and will cause more trouble than it's worth.

B-Nasty posted:

Yeah, that's pretty bad. It probably says a bit about your coworkers that they didn't at least try to write their own basic ORM or DBHelper that would at least handle 70% of that repetitive cruft. That said, don't do that either, just use something like Dapper. Assuming you aren't doing anything crazy in that mapping method (BuildPerson), the equivalent function using Dapper would be about 3 lines.

Put me down as another EF hater. I know and like SQL, and I like to use it to efficiently CRUD the data that I want rather than loading a complex object graph to update a few fields.

Okay, thanks. I'll take a peek at Dapper.

spiritual bypass
Feb 19, 2008

Grimey Drawer
I wish more languages had something like HugSQL. You just put your queries into SQL files and it generates all the function boilerplate for you.

Hughlander
May 11, 2005

Blinkz0rz posted:

Your code not working and being called out for it is a good reminder of why you're leaving? If that's the case, unless the call-out was exceptionally rude you're in for a world of disappointment no matter where you go.

Depends...

Hey @Blinkz0rz I know you're (On Vacation | Puking your head off) But I filed a bug in your code #237894.
@Blinkz0rz You're still not in but PR 329847 finally got deployed so now we can unblock the other thing.

They're not in. It's totally inappropriate to be using a real time communication tool for those purposes. E-mail it or wait till the're in. It's just a dick move sending push notifications if you know the person is going to be inconvenienced by them. (Due to them being sick err on vacation err finding better employment.

Messyass
Dec 23, 2003

Skandranon posted:

EF is convention over configuration, in that it has a strong opinion on how your DB should work. If you already HAVE a DB that does not match this opinion, this is a bad move.

EF is good and doesn't deserve all the hate, but this is true.

Pollyanna
Mar 5, 2005

Milk's on them.


Blinkz0rz posted:

Your code not working and being called out for it is a good reminder of why you're leaving? If that's the case, unless the call-out was exceptionally rude you're in for a world of disappointment no matter where you go.

"Bugs found in my PRs" is more akin to "there's a bug and your PR was up last so let's say it was from yours". Though I have gotten sloppy recently just due to burn-out and lack of interest...I guess you're right, yeah. Also what Hughlander said, plus they seem to have just forgotten that I was out.

genki
Nov 12, 2003

Pollyanna posted:

"Bugs found in my PRs" is more akin to "there's a bug and your PR was up last so let's say it was from yours". Though I have gotten sloppy recently just due to burn-out and lack of interest...I guess you're right, yeah. Also what Hughlander said, plus they seem to have just forgotten that I was out.
On the plus side, at least your interview went well...?

Blinkz0rz
May 27, 2001

MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Hughlander posted:

Depends...

Hey @Blinkz0rz I know you're (On Vacation | Puking your head off) But I filed a bug in your code #237894.
@Blinkz0rz You're still not in but PR 329847 finally got deployed so now we can unblock the other thing.

They're not in. It's totally inappropriate to be using a real time communication tool for those purposes. E-mail it or wait till the're in. It's just a dick move sending push notifications if you know the person is going to be inconvenienced by them. (Due to them being sick err on vacation err finding better employment.

I dunno, in my mind that's sort of part of what you get when you put Slack/Hipchat/Flowdock/whatever the gently caress on your phone. You can 100% ignore every single message that comes in while you're out of the office. It's easy. You can even put up OOO statuses in Slack (I'm sure the competitors have the same feature) that changes your notification setting so you don't get bothered unless someone DMs you and even those you can turn off. When I go on vacation I disable Slack notifications entirely at the OS level.

What I'm trying to get at is that if you get annoyed at things that fall in the scope of everyday working life, the problem might be you (Pollyanna) and not the job or coworkers.

raminasi
Jan 25, 2005

a last drink with no ice
Yeah why are you even on your work slack while on vacation.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...
Notifications come in to your phone if someone @ mentioned you. You have to remember to turn that off, then remember to turn it back on when you're "back".

Xarn
Jun 26, 2015
I installed work IM on my phone exactly once.

It was there long enough to send a message along the lines of "Got stuck at the doctor for longer than expected, won't be there for the meeting" to rest of my team.

Virigoth
Apr 28, 2009

Corona rules everything around me
C.R.E.A.M. get the virus
In the ICU y'all......



Volmarias posted:

Notifications come in to your phone if someone @ mentioned you. You have to remember to turn that off, then remember to turn it back on when you're "back".

Don't install that poo poo on your phone. Ever. Same goes for e-mail. You should be getting paged if something is wrong via PagerDuty or another source if someone REALLY needs your attention.

Steve French
Sep 8, 2003

Volmarias posted:

Notifications come in to your phone if someone @ mentioned you. You have to remember to turn that off, then remember to turn it back on when you're "back".

Or just leave it off permanently, like I did. Too many goddamn distractions.

Achmed Jones
Oct 16, 2004



If you don't want to look at Slack, then don't. Half the point of asynchronous communication mechanisms like Slack is that you can ignore stuff when you're heads-down. At my org at least, a Slack message is way less "this needs attention" than an email.

Pollyanna
Mar 5, 2005

Milk's on them.


I gently caress up just like anyone else when I get burned out. It's not exactly a stretch to imagine that organizational and procedural difficulties would be a burden on engineers, considering that's why the grand majority of the office has already left.

As for slack, I'm using the OOO feature now :) and it turns out that bug was caught by the feature tests, but wasn't stopped from deploying since we deploy even if feature tests fail - they're run completely separately from the other tests and aren't a part of the dev workflow. That should probably change. The other theory is that the tests didn't catch it, which is a completely different, more legitimate problem.

AskYourself
May 23, 2005
Donut is for Homer as Asking yourself is to ...
I like EF for basic and simple CRUD stuff but it fall on it's face when you do batch processing. Reason is there is no batch processing built in so if you want to update or delete all the rows where a certain value is equal to something it has to issue individual statement for every row so it's really inefficient. It play really nice with Dapper since you can generate your POCO and re-use them in Dapper and have it synch and stuff.

For efficient large data processing you really got to work with sets of data, no way around that.

CPColin
Sep 9, 2003

Big ol' smile.

CPColin posted:

Yesterday at 4:54, one of my coworkers emails me (as opposed to commenting in the ticket) to say we should talk about this plan before we "tear apart" the code, because other stuff in the codebase uses the same structure. Also, "I like that it's at the bottom of the list for now."

This same coworker is perfectly embodying the karma of my own rough start with Scrum. Yesterday, we were planning a sprint and got down to a item on the backlog that's a reasonable size, but isn't all that complicated. She balked at bringing it into the sprint, because she thought it was going to take longer than a sprint to finish. I pointed out that backlog items aren't supposed to take more than a sprint, so we should break it into tasks and then split it.

I showed off the acceptance criteria I'd already filled out, on the assumption that somebody would suggest just turning those into the tasks. It didn't really work out that way and the tasks became: 1) Figure out what data needs to be moved around, 2) Write the code that moves the data around, and 3) Write the controller for the job that'll wake up on a schedule and run the other code.

Okay, fine, not optimal, but I'll work with that. We started doing our estimate of hours and the same coworker said the middle task would take "days and days of work." I pointed out that tasks were supposed to be one-day affairs and she proposed breaking it into: 1) Design the code, 2) Write the code, and 3) Test the code. Agilefall!

(I finally managed to get the team to break out parts of the research and code that could be done separately, whereupon that coworker said, "Just put eight hours on everything!" So yeah, karma.)

Edison was a dick
Apr 3, 2010

direct current :roboluv: only

Achmed Jones posted:

If you don't want to look at Slack, then don't. Half the point of asynchronous communication mechanisms like Slack is that you can ignore stuff when you're heads-down. At my org at least, a Slack message is way less "this needs attention" than an email.

Then you get chewed out by someone who doesn't understand what asynchronous means for not replying to their messages immediately.

Meldonox
Jan 13, 2006

Hey, are you listening to a word I'm saying?
Let me tell you how much I love process. We had a mandatory halt for all development and delivery for most of this past week for projectwide retros and postmortems because we had an unprecedentedly rocky release and now basically everything this sprint is carryover that's going to push into stabilization, aside from the stuff that's so crucial that some poor bastards have to work all holiday weekend.

Ironically a couple of the big takeaways once everyone got together to synthesize all the feedback were that people lose too much development time to meetings and let too much stuff sit until stabilization.

I get that a lot of teams needed a come-to-Jesus talk and some quality time reviewing why they're underperforming, and I really can't say when would have been better, but I'm concerned that the last development sprint of a release may not have been it.

Pythagoras a trois
Feb 19, 2004

I have a lot of points to make and I will make them later.

Meldonox posted:

but I'm concerned that the last development sprint of a release may not have been it.

If that was my company, there'd be a very real chance that 'last week' would be another month of late nights when we've had a rocky lead up and are only addressing it at the 11th hour.

pigdog
Apr 23, 2004

by Smythe

CPColin posted:

This same coworker is perfectly embodying the karma of my own rough start with Scrum. Yesterday, we were planning a sprint and got down to a item on the backlog that's a reasonable size, but isn't all that complicated. She balked at bringing it into the sprint, because she thought it was going to take longer than a sprint to finish. I pointed out that backlog items aren't supposed to take more than a sprint, so we should break it into tasks and then split it.

I showed off the acceptance criteria I'd already filled out, on the assumption that somebody would suggest just turning those into the tasks. It didn't really work out that way and the tasks became: 1) Figure out what data needs to be moved around, 2) Write the code that moves the data around, and 3) Write the controller for the job that'll wake up on a schedule and run the other code.

Okay, fine, not optimal, but I'll work with that. We started doing our estimate of hours and the same coworker said the middle task would take "days and days of work." I pointed out that tasks were supposed to be one-day affairs and she proposed breaking it into: 1) Design the code, 2) Write the code, and 3) Test the code. Agilefall!

(I finally managed to get the team to break out parts of the research and code that could be done separately, whereupon that coworker said, "Just put eight hours on everything!" So yeah, karma.)
This sounds like a pretty normal activity where you were able to slice the story thinner, which is good. Research/learning tasks are pretty reasonable to timebox. Not really seeing anything outrageous about what you were describing.

Regarding the ER thing it's not such a great idea to introduce an ORM in an existing system. Duplicate code is always bad however and the similar methods should be using the same code from a common wrapper or utility class or something.

Pollyanna
Mar 5, 2005

Milk's on them.


The higher ups/office leads are forcing my team to move to Scrum away from our currently well-adjusted Kanban process. We have chafed heavily against the forced shift and now our PM is leaving. On the bright side, I anticipate a company I interviewed with last week to make an offer!

CPColin
Sep 9, 2003

Big ol' smile.
Just discovered that parts of the code already use EntityFramework! So what the hell was my coworker objecting to? :psyduck:

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!

Pollyanna posted:

The higher ups/office leads are forcing my team to move to Scrum away from our currently well-adjusted Kanban process. We have chafed heavily against the forced shift and now our PM is leaving. On the bright side, I anticipate a company I interviewed with last week to make an offer!
I gleefully await your closing story about all this where the company's building capsizes and sinks into a hole in the ground behind you as you walk away to your new job. A string quartet solemnly plays its last requiem from the roof as the ground swallows the building whole.

A more productive conversation: were you actually using Kanban for major, new feature development or was this in support of an existing product? I had gotten the impression Kanban was more suited for the latter than the former, so I was curious how this might have worked out.

Vulture Culture
Jul 14, 2003

I was never enjoying it. I only eat it for the nutrients.

Rocko Bonaparte posted:

I had gotten the impression Kanban was more suited for the latter than the former, so I was curious how this might have worked out.
They're different things. Scrum is appropriate for heavily timeboxed feature development where time to delivery is paramount but scope is fluid. Kanban is a quality-first, "it's done when it's done" methodology that optimizes for reduced waste through just-in-time delivery and improved flow. Neither is more appropriate than the other for implementation/maintenance SDLC phases in any general sense.

Vulture Culture fucked around with this message at 16:53 on Oct 10, 2017

Pollyanna
Mar 5, 2005

Milk's on them.


They want us off Kanban because everyone else uses a lovely, heavily timeboxed Scrum that cares about nothing but metrics. We're also the most productive but most inscrutable team in the office, so I think they're just trying to get super corporate. I'm not having it, and I'm leaving anyway so who cares anyway? They'll fail, I'll sit back and laugh.

Flat Daddy
Dec 3, 2014

by Nyc_Tattoo
The startup lingo cargo culting at my company is hilarious. Someone here must've read that you should always start with an MVP. So version 1 of everything is always MVP now.

I'm literally working on a full-featured rewrite of an existing application and caught a PM calling it the MVP of the rewrite.

AskYourself
May 23, 2005
Donut is for Homer as Asking yourself is to ...

CPColin posted:

Just discovered that parts of the code already use EntityFramework! So what the hell was my coworker objecting to? :psyduck:

Maybe it use Linq but not Entity ?

Gounads
Mar 13, 2013

Where am I?
How did I get here?

Pollyanna posted:

They want us off Kanban because everyone else uses a lovely, heavily timeboxed Scrum that cares about nothing but metrics. We're also the most productive but most inscrutable team in the office, so I think they're just trying to get super corporate. I'm not having it, and I'm leaving anyway so who cares anyway? They'll fail, I'll sit back and laugh.

How many of the other scrum teams overcommit and roll stories from one sprint to the next?

Pollyanna
Mar 5, 2005

Milk's on them.


Gounads posted:

How many of the other scrum teams overcommit and roll stories from one sprint to the next?

Literally all of them, and it's a common complaint among the higher ups. Their solution has been to make everyone log their work down to the minute.

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Gounads posted:

How many of the other scrum teams overcommit and roll stories from one sprint to the next?

God I hate this so much.

Person 1: "So you mean the last 4 sprints we hit about 50 points each sprint but we never make the sprint because the PO is insisting we put 75 points in the sprint and then acts disappointed we don't do more than 50."
Person 2: "well, we could start over estimating stories?"
Person 3: "You mean we didn't already?"
Person 4: "Can we have a coffee break?"

CPColin
Sep 9, 2003

Big ol' smile.

AskYourself posted:

Maybe it use Linq but not Entity ?

Just looked more into it. It's definitely using EF to do database queries. Weird.

This same coworker is the one who was resisting breaking up a backlog item into tasks. Then, when we finally did it, said, "Just put eight hours on all of them." I just realized that that left us with three tasks of eight hours each, which somehow combine into a backlog item that's going to take longer than a (three-week) sprint to complete. Gonna bring it up in the next retrospective, because if an item feels like it's going to take that long to do and the broken-down tasks add up to a few days of work, we're either estimating the tasks too low or we're not listing all the tasks!

Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



Pollyanna posted:

Literally all of them, and it's a common complaint among the higher ups. Their solution has been to make everyone log their work down to the minute.

"Hahaha 'solution'" also "oh god run"

Adbot
ADBOT LOVES YOU

Pollyanna
Mar 5, 2005

Milk's on them.


Munkeymon posted:

"Hahaha 'solution'" also "oh god run"

I know, right? :shepicide:

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply