|
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.
|
# ? Sep 30, 2016 22:02 |
|
|
# ? May 13, 2024 10:31 |
If you work more than 40 hours, you are making the rest of us look bad.
|
|
# ? Sep 30, 2016 22:05 |
|
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.
|
# ? Sep 30, 2016 22:11 |
|
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.
|
# ? Sep 30, 2016 22:22 |
|
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.
|
# ? Sep 30, 2016 22:26 |
|
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.
|
# ? Sep 30, 2016 22:28 |
|
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.
|
# ? Sep 30, 2016 22:36 |
|
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?
|
# ? Sep 30, 2016 22:47 |
|
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.)
|
# ? Sep 30, 2016 22:48 |
|
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?
|
# ? Oct 1, 2016 03:24 |
|
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?
|
# ? Oct 1, 2016 03:41 |
|
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 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.
|
# ? Oct 1, 2016 04:31 |
|
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.
|
# ? Oct 1, 2016 06:04 |
|
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. I moved to MA though. 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.
|
# ? Oct 1, 2016 06:15 |
|
ToxicSlurpee posted:I just have to 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.
|
# ? Oct 1, 2016 09:15 |
|
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.
|
# ? Oct 1, 2016 14:14 |
|
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).
|
# ? Oct 1, 2016 14:23 |
|
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?
|
# ? Oct 1, 2016 15:33 |
|
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. 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.
|
# ? Oct 1, 2016 15:35 |
|
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
|
# ? Oct 1, 2016 15:42 |
|
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 |
# ? Oct 1, 2016 17:04 |
|
Gul Banana posted:how is coming in later but starting later going to get more work done? Hughlander posted:Why were there fires? Was code shipped without adequate QA? 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
|
# ? Oct 1, 2016 17:51 |
|
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.
|
# ? Oct 1, 2016 17:57 |
|
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. 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.
|
# ? Oct 1, 2016 18:44 |
|
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).
|
# ? Oct 1, 2016 19:13 |
|
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. 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.
|
# ? Oct 1, 2016 19:27 |
|
Sounds like a place to run from really fast.
|
# ? Oct 1, 2016 20:55 |
|
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.
|
# ? Oct 1, 2016 23:41 |
|
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 |
# ? Oct 3, 2016 18:47 |
|
Just ask 'em. Sitting around and making assumptions will ruin your
|
# ? Oct 3, 2016 18:57 |
|
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.
|
# ? Oct 3, 2016 19:01 |
|
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 |
# ? Oct 3, 2016 19:24 |
|
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 |
# ? Oct 3, 2016 21:08 |
|
Personally I would nag. Mention it at the stand up every day, harass on a public slack channel, etc.
|
# ? Oct 3, 2016 23:47 |
|
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. 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 |
# ? Oct 4, 2016 01:56 |
|
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.
|
# ? Oct 4, 2016 06:44 |
|
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?
|
# ? Oct 4, 2016 14:10 |
|
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.
|
# ? Oct 4, 2016 20:00 |
|
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?
|
# ? Oct 4, 2016 21:37 |
|
|
# ? May 13, 2024 10:31 |
|
That sounds similar to how Pivotal Labs works, including the emphasis upon pair programming.
|
# ? Oct 4, 2016 21:48 |