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
Doc Hawkins
Jun 15, 2010

Dashing? But I'm not even moving!


revmoo posted:

Anyone working more than 40 hours is literally lowering their market value by cutting their own hourly rate. It's nonsense.

Worse: they're lowering our market value.

Full unionism now.

Adbot
ADBOT LOVES YOU

Polio Vax Scene
Apr 5, 2009



If you work more than 40 hours, you are making the rest of us look bad.

Greatbacon
Apr 9, 2012

by Pragmatica

Polio Vax Scene posted:

If you work more than 40 hours, you are making the rest of us look bad.

I've got a colleague who openly admits to staying late in the office because he has nothing better to do at home.

It is simultaneously hilarious, depressing, and aggravating.

revmoo
May 25, 2006

#basta
The issue is that this industry attracts super-spergs like flies, so you get people that are truly passionate about technology working insane hours because it's a source of recreation for them. They get to build a Tower of Babel that is woven from their sheer autism using all these exotic technologies and weird/unique methods, when in reality they're over-engineering EVERYTHING, and their opinionated attitudes poison the well for everyone else that isn't full-blown autistic. It's maddening, and it has to be the worst part of working in this industry.

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

revmoo posted:

The issue is that this industry attracts super-spergs like flies, so you get people that are truly passionate about technology working insane hours because it's a source of recreation for them. They get to build a Tower of Babel that is woven from their sheer autism using all these exotic technologies and weird/unique methods, when in reality they're over-engineering EVERYTHING, and their opinionated attitudes poison the well for everyone else that isn't full-blown autistic. It's maddening, and it has to be the worst part of working in this industry.

Unless, of course, you embrace it. Give in.

revmoo
May 25, 2006

#basta

Skandranon posted:

Unless, of course, you embrace it. Give in.

You know I could, but it's always some poo poo loving project like a web application that handles construction bids or some equally boring topic.

Eggnogium
Jun 1, 2010

Never give an inch! Hnnnghhhhhh!

revmoo posted:

The issue is that this industry attracts super-spergs like flies, so you get people that are truly passionate about technology working insane hours because it's a source of recreation for them. They get to build a Tower of Babel that is woven from their sheer autism using all these exotic technologies and weird/unique methods, when in reality they're over-engineering EVERYTHING, and their opinionated attitudes poison the well for everyone else that isn't full-blown autistic. It's maddening, and it has to be the worst part of working in this industry.

This is the perfect distillation of why I left my last job.

Hughlander
May 11, 2005

necrobobsledder posted:

I was meaning that nothing could get people to be flexible (if you stay later, no big deal coming in later, for example) in an environment where there were constant fires and one of the biggest problems with schedule slip was because nobody had any urgency to finish their tasks and low performers just couldn't get canned. The situation was how people think government employees work, except this is private sector.

So far it all sounds like management issues not employee issues.

Why were there fires? Was code shipped without adequate QA?

Why was there schedule slip? Did the employees estimate their time correctly? Was there iteration to understanding the full team velocity?

Or in both cases did a manager/pm/po say "we are shipping on x date with y features" and it's the employees job to warp reality to match?

Doc Hawkins
Jun 15, 2010

Dashing? But I'm not even moving!


It's basically a crime against your own humanity to work really hard for an employer. If you have no life and want to write software 24/7, at least have the decency to go home and write it for your own benefit.

(Offer valid only in California or other jurisdictions with un-hosed employer-employee IP law.)

Cuntpunch
Oct 3, 2003

A monkey in a long line of kings
You mean the sort of thing where almost anything you do with software, while employed, is contractually the property of your employer, related to your work or not?

nelson
Apr 12, 2009
College Slice

Cuntpunch posted:

You mean the sort of thing where almost anything you do with software, while employed, is contractually the property of your employer, related to your work or not?
That's what the piece of paper says. Along with other creative works. Whether they'll try to enforce it is another matter, and probably directly proportional to how successful it is or whether it can potentially compete with their products.

ToxicSlurpee
Nov 5, 2003

-=SEND HELP=-


Pillbug
I suddenly feel quite happy that the company I work for's policy on that sort of thing is "we don't give a poo poo what you do in your spare time. Get another job, do side work, whatever...just don't work for somebody that competes with us."

I just have to :psyduck: so hard at a company that says if you write code for them and go home and write a book they own it. To me that's an enormous "DO NOT EVER WORK HERE" sign.

Cuntpunch
Oct 3, 2003

A monkey in a long line of kings

nelson posted:

That's what the piece of paper says. Along with other creative works. Whether they'll try to enforce it is another matter, and probably directly proportional to how successful it is or whether it can potentially compete with their products.

Eh, I once pushed back when an employer tried to introduce a "everything creative you do is ours" contract, with a retroactive clause. I'm more than happy signing over "hey, anything I do with SOFTWARE that possibly pertains to WORK STUFF is yours" contract, because it makes sense. But as soon as it encroaches on "I write software as a profession, but if I write a novel in my personal time, the company owns it" type territory, I get reasonably defensive. And I haven't seen another contract yet that attempts to enforce ownership on *all* creative works, except those that possibly have anything to do with my actual job, which is fine by me.

leper khan
Dec 28, 2010
Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Doc Hawkins posted:

It's basically a crime against your own humanity to work really hard for an employer. If you have no life and want to write software 24/7, at least have the decency to go home and write it for your own benefit.

(Offer valid only in California or other jurisdictions with un-hosed employer-employee IP law.)

I moved to MA though. :saddowns:
At least I had the good sense to put a couple projects in my prior invention/exemption list when I signed on. But when I finish those I'm basically at the mercy of my employer.

What am I supposed to do, support some terrible open source thing? That doesn't seem entirely palatable. Pretty sure I'd need some drat permission slip from my employer to even do that. IP rights are completely hosed.

Doc Hawkins
Jun 15, 2010

Dashing? But I'm not even moving!


ToxicSlurpee posted:

I just have to :psyduck: so hard at a company that says if you write code for them and go home and write a book they own it. To me that's an enormous "DO NOT EVER WORK HERE" sign.

The courts have upheld it these agreements in most states, and they benefit the companies, and people need jobs more than companies need workers, so it's become an industry standard to hand them out to everyone.

What really offends me, and what I hear too often, is folks claiming that IP agreements are intended to "protect" the company from the claims of ex-employees. That's when you know that you're dealing with the kind of amoral shithead who thinks that it's A-OK to lie to people's faces whenever their legal knowledge tells them they can't be held liable for lying, and that you work for a company who hires amoral shitheads to be their lawyers.

I've never had to deal with that one personally, but I have seen an acquiring company send someone to "educate" the acquired engineers about IP, who then pretended she didn't know that IP agreements are unenforceable in California.

leper khan posted:

What am I supposed to do, support some terrible open source thing? That doesn't seem entirely palatable. Pretty sure I'd need some drat permission slip from my employer to even do that. IP rights are completely hosed.

At least the open source work might boost your salary at your next job.

leper khan
Dec 28, 2010
Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Doc Hawkins posted:

At least the open source work might boost your salary at your next job.

True. Would definitely give me more experience in specializations I'm interested in, too. I just can't stand most Free Software folks. Could probably take a look at freebsd. :shrug:

revmoo
May 25, 2006

#basta
The worst thing on my employment contracts is that I'm contractually obligated for a year after I leave to notify my company where I'm working for the express written purpose of allowing them to contact my new company and tell them about the non-compete I signed.

All my coworkers just signed it. I made them write me a severance and include a bunch of extra concessions. I also made them strike binding arbitration out so if they feel like loving around with my severance I get to take them to big boy court.

The non-compete is 4 loving years. Fortunately I made them carve it down to just the industry they're in (and I have zero interest in working in this industry again probably ever).

Gul Banana
Nov 28, 2003

necrobobsledder posted:

I was meaning that nothing could get people to be flexible (if you stay later, no big deal coming in later, for example) in an environment where there were constant fires and one of the biggest problems with schedule slip was because nobody had any urgency to finish their tasks and low performers just couldn't get canned. The situation was how people think government employees work, except this is private sector.

how is coming in later but starting later going to get more work done?

Doc Hawkins
Jun 15, 2010

Dashing? But I'm not even moving!


leper khan posted:

True. Would definitely give me more experience in specializations I'm interested in, too. I just can't stand most Free Software folks. Could probably take a look at freebsd. :shrug:

You mean like GNU/FSF types? I don't have any statistics to back this up, but I think most open source code is MIT licensed and written by people who share your distaste.

MrMoo
Sep 14, 2000

revmoo posted:

The issue is that this industry attracts super-spergs like flies, so you get people that are truly passionate about technology working insane hours because it's a source of recreation for them. They get to build a Tower of Babel that is woven from their sheer autism using all these exotic technologies and weird/unique methods, when in reality they're over-engineering EVERYTHING, and their opinionated attitudes poison the well for everyone else that isn't full-blown autistic. It's maddening, and it has to be the worst part of working in this industry.

I do the insane hours and recreation side but I still get hassled when the "exotic technologies" are things like C++11 or Apache Log4j2, I deliberately go out of my way to make super under-engineered stuff that is really simple and just barely does the task at hand but is rock solid stable (because it doesn't do anything). Nobody cares as it just means other people mistakes become more apparent now. I've got to five years without a production bug following this model :shrug:

speng31b
May 8, 2010

revmoo posted:

The issue is that this industry attracts super-spergs like flies, so you get people that are truly passionate about technology working insane hours because it's a source of recreation for them. They get to build a Tower of Babel that is woven from their sheer autism using all these exotic technologies and weird/unique methods, when in reality they're over-engineering EVERYTHING, and their opinionated attitudes poison the well for everyone else that isn't full-blown autistic. It's maddening, and it has to be the worst part of working in this industry.

In this scenario, where are the lead devs who put a stop those "exotic" tech choices before they ever get off the ground, because they obviously hurt maintainability? Or the code reviews that firmly but kindly remind people that their "weird/unique methods" may be clever, but don't meet the clearly defined standards that exist for well-documented reasons X Y and Z?

Seems that for this to be a real problem, either A) the patients are running the asylum or B) these "exotic" technologies and "weird/unique" methods are actually the right tools for certain jobs. Seems like most of the time when A) is the problem, it has to do with companies not offering advancement paths for devs that aren't management. So you end up with people who really just aspire to be personally great devs, and aren't fit for management, forced into management.

speng31b fucked around with this message at 17:19 on Oct 1, 2016

necrobobsledder
Mar 21, 2005
Lay down your soul to the gods rock 'n roll
Nap Ghost

Gul Banana posted:

how is coming in later but starting later going to get more work done?
That part is mostly about addressing the "any hours more than 40 / week means you're slime" crowd rather than team impedance mismatches that I was addressing.

Hughlander posted:

Why were there fires? Was code shipped without adequate QA?

Why was there schedule slip? Did the employees estimate their time correctly? Was there iteration to understanding the full team velocity?

Or in both cases did a manager/pm/po say "we are shipping on x date with y features" and it's the employees job to warp reality to match?
Fires were operational in root cause typically after decades of ossification of operations being about resistance to change (despite a total lack of effective redundancy, testing HA, or other things good companies have been doing since the early 90s). Most applications were barely more difficult to write or architect than a demo blog application from the Rails and Django tutorials. Other problems included access (developers threw support to a super low-skill offshore team) and improper lifecycle management of software in complex configurations (DNS TTL refresh fixes for AWS ELBs changing IPs, long-lived instances being shutdown by AWS, etc.). With so many moving pieces and ineffective architecture, our effective availability was about 95% and software failures worsened that. In sadder news, that was a resounding success compared to teams that had applications purely internally hosted - moving to AWS reduced their raw cost chargebacks 40%, availability was up another 12%, and teams of dozens of engineers dedicated to handling high-priority incidents that happened daily were reassigned freeing up $30MM / yr on actual engineering.

Schedule slip was most frequent from needing more and more check-offs for any form of change in software or infrastructure and perfect JIRA usage and guru-level agile training won't turn waterfall across cross-functional teams into agile. A lot of meetings got delayed from so much decision-making needing top-down approvals and not enough availability of SPOF decision-makers. In one case a really low-risk, 2-line bug fix that took a guy 2 days took 14 sprints to get approval to deploy in prod and during the 14 sprints I clocked 500+ man hours dealing with it (we didn't have the approvals to do the automation for that part either, it was that fix or manually fix 200+ servers daily).

In short though, bitching about bad management at big companies is just a waste because the failures are hardly unique from each other yet little changes so it's either systematic to being large, old, and growing primarily through M&A than organic growth.

I can just leave it with this article that bitches better than me though https://aeon.co/essays/you-don-t-have-to-be-stupid-to-work-here-but-it-helps

ToxicSlurpee
Nov 5, 2003

-=SEND HELP=-


Pillbug

Cuntpunch posted:

Eh, I once pushed back when an employer tried to introduce a "everything creative you do is ours" contract, with a retroactive clause. I'm more than happy signing over "hey, anything I do with SOFTWARE that possibly pertains to WORK STUFF is yours" contract, because it makes sense. But as soon as it encroaches on "I write software as a profession, but if I write a novel in my personal time, the company owns it" type territory, I get reasonably defensive. And I haven't seen another contract yet that attempts to enforce ownership on *all* creative works, except those that possibly have anything to do with my actual job, which is fine by me.

Yeah that at least makes sense; where I'm at it was pretty similar coupled with a "do not work on outside things on the job and do not use company resources for outside stuff." I don't remember all the details because I read every word, though "well that's reasonable," and signed for the job. They own everything I do at work which is fine and I have no idea what the hell I'd use the thing I work on at work for anyway. I'm not a lawyer but I think that's the baseline of IP law anyway; if somebody pays you to make something they own it by default unless a contract specifies otherwise.

Hughlander
May 11, 2005

necrobobsledder posted:

That part is mostly about addressing the "any hours more than 40 / week means you're slime" crowd rather than team impedance mismatches that I was addressing.

Schedule slip was most frequent from needing more and more check-offs for any form of change in software or infrastructure and perfect JIRA usage and guru-level agile training won't turn waterfall across cross-functional teams into agile. A lot of meetings got delayed from so much decision-making needing top-down approvals and not enough availability of SPOF decision-makers. In one case a really low-risk, 2-line bug fix that took a guy 2 days took 14 sprints to get approval to deploy in prod and during the 14 sprints I clocked 500+ man hours dealing with it (we didn't have the approvals to do the automation for that part either, it was that fix or manually fix 200+ servers daily).

But from these two paragraphs you'd be a moron for an individual contributor to work 50-60 hour weeks. It's not going to fix the disfunctional processes you outlined there. It's not the ICs fault that half a year deployments are considered ok. If he put in 10'hour days and the fix got out after 11 sprints it's not a win for him. And there's no reason to basically slutshame people for following their employee contracts.

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!

necrobobsledder posted:

Schedule slip was most frequent from needing more and more check-offs for any form of change in software or infrastructure and perfect JIRA usage and guru-level agile training won't turn waterfall across cross-functional teams into agile. A lot of meetings got delayed from so much decision-making needing top-down approvals and not enough availability of SPOF decision-makers. In one case a really low-risk, 2-line bug fix that took a guy 2 days took 14 sprints to get approval to deploy in prod and during the 14 sprints I clocked 500+ man hours dealing with it (we didn't have the approvals to do the automation for that part either, it was that fix or manually fix 200+ servers daily).
You and me need to get a beer. All the beer.

necrobobsledder
Mar 21, 2005
Lay down your soul to the gods rock 'n roll
Nap Ghost

Hughlander posted:

But from these two paragraphs you'd be a moron for an individual contributor to work 50-60 hour weeks. It's not going to fix the disfunctional processes you outlined there. It's not the ICs fault that half a year deployments are considered ok. If he put in 10'hour days and the fix got out after 11 sprints it's not a win for him. And there's no reason to basically slutshame people for following their employee contracts.
I do agree it's stupid to work extra when everything is structurally against you succeeding, but with enough things going wrong a couple extra meetings per week really adds up and nobody wants to be thought of as a blocker. So everyone overtasks themselves yet nothing seems to get done as the quality of work drops. It's common in highly unfocused organizations undergoing migrations / transformations.

The specific situation was if you didn't work extra hours (for completely stupid reasons) that you were likely to be fired. My manager called up someone under me that was refusing to work through the weekend and prepared the paperwork to fire him (right to work state, yeah....) until he made a concession to check back in that night for a couple hours. I saw another contractor that was great to work with, helped out everyone that was working those 50+ hour weeks, but because that ate into the story points he could accomplish per sprint, he got let go for "underperformance." My team's performance in story points went down about 20% because he was instrumental for breaking down silos for us, so he delivered more value across functions than in just a silo. Secondly, the job description was to be on-call and fix broken crap that wasn't your design. Lastly, extra hours worked were factored into your IC year-end bonuses. I never got the steak dinners that were written into company policy for working on the weekend when requested by the client though so I could literally sue for breach of contract over a matter of steak dinners.

Xarn
Jun 26, 2015
Sounds like a place to run from really fast.

necrobobsledder
Mar 21, 2005
Lay down your soul to the gods rock 'n roll
Nap Ghost
Yeah, didn't see how things were really until like 6 months in and I was getting too overworked to be able to think straight enough to perform in an interview and had already moved to a place where I had to do only remote gigs. Then I found out my manager and a couple of my subordinates were serious Trump supporters and I aimed for about a year in savings before quitting.

Pollyanna
Mar 5, 2005

Milk's on them.


I'm beginning to wonder if it's something I'm doing that's keeping my co-workers so long reviewing my PRs. This is yet another long-living PR with pretty significant changes where it's at the stage where all its waiting on is approval from my co-workers, but it's stagnant because of some unknown reason.

I'm going to guess that I'm the one that hosed up. There's two PRs open. The first PR is one big one inherited from another engineer who left the project, and ended up requiring a good amount of refactoring to accomplish in a sane manner. That refactoring occurs in the second PR, which merges into and is based on yet completes the first - it has a relatively large-scale refactoring of our views and a JavaScript snippet we use to display graphs. This is the one that's taken over a month and almost 100 comments to finish reviewing, and the one my co-workers say is extremely big and hard to review the entirety of. I had done the refactoring PR as a way of "leaving things better than I found them".

Did I fuckup by making my PR too big for my co-workers to handle? Should I have not attempted to refactor and improve what I was given to work with, or just punted a tech debt ticket to refactoring it into the backlog?

If it helps, the PR is mainly splitting up a 600 line file into sub-files and partials, writing a class to make it easier to display a piece of UI, and specs for the latter. Any new code is maybe 150-175 lines, including specs.

I'm setting aside some time tomorrow to meet with my co-workers on what I can do to work better with the rest of the team, and where I can improve, because I'm paranoid that they're starting to get frustrated with me over the PR.

Pollyanna fucked around with this message at 18:51 on Oct 3, 2016

spiritual bypass
Feb 19, 2008

Grimey Drawer
Just ask 'em. Sitting around and making assumptions will ruin your marriage work environment

Gounads
Mar 13, 2013

Where am I?
How did I get here?
For refactoring / cleanup type work, you need to make sure the bar is being set at the right place and that bar might be a different place than new work. There's the "perfect" solution and the "better than what was there" solution. Make sure you all agree which bar you're measuring to.

Space Kablooey
May 6, 2009


Sometimes your PR is huge/intricate and they just can't be bothered to read all that and prefer to review the easy ones. Splitting the huge PR into multiple, smaller, less complex PRs could work.

The times that I have had success with getting big PRs pushed is when I talked with my project lead beforehand, and we both agreed that it was going to be a lot of code.

Space Kablooey fucked around with this message at 19:27 on Oct 3, 2016

Pollyanna
Mar 5, 2005

Milk's on them.


It sucks too cause the massive PRs we've had have both been mine, both inherited and dating from before we had any good dev practices or a good workflow/properly scoped tickets. I know that it's not personal, but I can't help but feel I'm the common factor here.

I'll talk to them tomorrow.

Pollyanna fucked around with this message at 21:18 on Oct 3, 2016

return0
Apr 11, 2007
Personally I would nag. Mention it at the stand up every day, harass on a public slack channel, etc.

Che Delilas
Nov 23, 2009
FREE TIBET WEED

return0 posted:

Personally I would nag. Mention it at the stand up every day, harass on a public slack channel, etc.

Also try and make it personal. Tell them how poo poo they are at programming if they can't even review a little proposalAsk specific individuals about specific pieces of the proposal, and if you can make them areas that these individuals know well (for example there's one guy in my company that I go to when I need to ask about a device integration, a different one for data feeds, etc, because each of those people has done the most/most recent work on such things). This has the side effect of automatically breaking down what might be too large a project into smaller pieces.

Asking in stand-ups and multi-user slack channels can help but it also gives people tacit permission to passively ignore the issue. If you ask specific people, 1-on-1, they can still refuse because they're too busy (or too self-important, but hopefully you're avoiding those people anyway), but at least then you can move on to the next person knowing that the last one isn't going to be of any help.

Edit: Oh. Pull Request. Right. Well, most of what I said still applies?

Che Delilas fucked around with this message at 07:25 on Oct 4, 2016

Chamook
Nov 17, 2006

wheeeeeeeeeeeeee
Our rule of thumb is that PRs shouldn't touch more than 12 files, and a lot less is preferable, and we will outright decline a PR if it's too big. This is for C# code, and we're considering reducing the number of files allowed for an F# PR. It's had the effect of making reviews faster and easier because it doesn't take a lot of time to review an individual PR so people are more likely to get it done in between other tasks.

Sagacity
May 2, 2003
Hopefully my epitaph will be funnier than my custom title.
Agreed. Having many smaller PR's instead of one big honking PR would be my preference. I won't object to people cleaning things up, but if it's one of these massive refactors that touch a lot of files then it starts obfuscating all your *real* changes and potential logic bugs that may have crept in. At some point my eyes will start glazing over and it becomes really hard to reason about any of these changes.

I assume you still have passing tests, right? :smug:

Pollyanna
Mar 5, 2005

Milk's on them.


We only recently have tests at all, man.

I've kinda fallen off the wagon re: good PR practices, so future PRs will be well split up. We're also establishing dev practices for the entire team to make sure stuff like this doesn't happen again.

Cancelbot
Nov 22, 2006

Canceling spam since 1928

To contrast with PR chat, where I work is hard on the single branch approach:

- We use mercurial, everything goes into default
- Every commit must be releasable, if it is not you use a feature flag
- Nearly everybody pairs, we're experimenting with mobs

Does anyone else do this?

Adbot
ADBOT LOVES YOU

necrobobsledder
Mar 21, 2005
Lay down your soul to the gods rock 'n roll
Nap Ghost
That sounds similar to how Pivotal Labs works, including the emphasis upon pair programming.

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