|
TooMuchAbstraction posted:But man, there are some things you don't realize are hosed up about your life until you're able to get outside of them for a bit. This is part of the reason I didn't take a vacation by myself last December when I had a week off that my gf didn't; I was afraid I'd just keep going and never come back lol 
|
#
?
Aug 29, 2019 22:12
|
|
|
|
| # ? May 18, 2024 04:06 |
|
|
CPColin posted:This is part of the reason I didn't take a vacation by myself last December when I had a week off that my gf didn't; I was afraid I'd just keep going and never come back lol I took a 2 year semi-retirement when I turned 30 where I worked on interesting things, generally enjoyed myself, and lived off what I had saved the previous 6 years. Set me back career-wise, but it was a good period of self-discovery.
|
|
#
?
Aug 29, 2019 22:18
|
|
|
opposable thumbs.db posted:We also had one poster (Careful Drums) get permabanned. Oh  *looks around some more* OH 
|
|
#
?
Aug 30, 2019 16:40
|
|
|
Munkeymon posted:Oh Had this exact reaction starting last night...like 18 hours later I’ve read the entire loving thing and Jesus Christ Do not recommend.
|
|
#
?
Aug 30, 2019 19:02
|
|
|
Well with a recommendation like that how can I not! edit: ugh pokeyman fucked around with this message at 03:02 on Sep 1, 2019 |
|
#
?
Aug 31, 2019 01:37
|
|
|
The site does literally read Something Awful....
|
|
#
?
Aug 31, 2019 02:02
|
|
|
Wow is that not a happy thread.
|
|
#
?
Aug 31, 2019 06:41
|
|
|
Dang. It's hard to know when people are trolling vs actually projecting real-life issues 
|
|
#
?
Aug 31, 2019 14:33
|
|
|
How many hours/week is too many? I like my company and I like the project I'm working on, but we're always behind on deadlines. edit: My life consists of work and video games; I don't have a significant other, kids, or pets. The only real tradeoff I get between working more/less is my motivation to exercise before or after work. Faith For Two fucked around with this message at 09:39 on Sep 3, 2019 |
|
#
?
Sep 3, 2019 09:23
|
|
|
Faith For Two posted:How many hours/week is too many? I like my company and I like the project I'm working on, but we're always behind on deadlines. I cannot tell you how much is too much for you, I can only tell you how much is too much for me. During a day, my creative fuel will be running low after about 5 hours of work, sometimes a bit longer, sometimes shorter. Work can be seen as "present in the office". Exercise in the middle of the day extends my ability to write code, sitting down and meetings has a tendency to shorten it. Any social interaction is coming from the same resource pool. So yeah, I work short days but tend to gravitate to places that value output over time spend.
|
|
#
?
Sep 3, 2019 10:13
|
|
|
Faith For Two posted:How many hours/week is too many? I like my company and I like the project I'm working on, but we're always behind on deadlines. Your edit makes me wonder - do you want any of those things (a partner, a family, a pet)? How about hobbies other than video games? Your work should leave you enough time and energy to pursue exercise and a hobby of your choice, as well as a social life. How many hours are you working? Also, every software company I've ever worked for has had a backlog of tasks so long as to be actionably infinite. This is where having a good PM who prioritizes things appropriately comes in. If you are constantly being assigned work you can't complete, that's a sign of a bad PM who thinks sweat can make up for a lack of proper planning. Crunch and/or 60 hour weeks should not be the norm, they should be seasonal-at-best. Writing software is not digging ditches, it can't be scaled up without a hit to quality. An aside, Basecamp has an interesting idea where there is no shared backlog and every stakeholder must maintain their own backlog if they want a task to be part of an upcoming sprint. Otherwise, every sprint planning is done from a clean slate, prioritizing work only based on the current state of the software. Personally I think this is a great idea, along with a last in, first out approach to bug fixes.
|
|
#
?
Sep 3, 2019 13:24
|
|
|
Faith For Two posted:How many hours/week is too many? I like my company and I like the project I'm working on, but we're always behind on deadlines. If you're working more than 40 per week on a regular basis you are working too much imo. Especially if you're not getting paid overtime
|
|
#
?
Sep 3, 2019 13:39
|
|
|
I've been writing software for ~20 years for several different companies (SaaS, consulting, FTE with non-tech companies) and there is only one constant: the backlog never goes away. Don't ruin your physical and mental health trying to make it go away. 40 hours per week is plenty, anything above that is warranted in exceptional circumstances only or if you are being paid for those hours (contract work, after hours on call pay, etc).
|
|
#
?
Sep 3, 2019 13:46
|
|
|
I'll second Keeton in that even 40 hours a week is more than I can spend actually being productive. I worked roughly 7:30-3:30 to avoid rush hour traffic, and by the end of every day (and halfway through Fridays) I could tell that I was spending at least twice as much time on my work as I should have been, and possibly accomplishing negative work. It's not a hard-and-fast rule -- sometimes I have good days and get a ton done, but they tend to be followed by bad days where I mostly just sit around and read. I used to feel guilty about this, but a) none of my employers have ever complained that I'm not getting enough done, and b) there's no sense wanting something (the ability to be productive for longer every day) that I'm clearly not going to get.
|
|
#
?
Sep 3, 2019 15:28
|
|
|
Burn-out can be very subtle and insidious because even if you feel motivated and energized at work your body can disagree all of a sudden. Furthermore, a lot of software work is highly creative and the research is very clear that we can benefit from being idle mentally for a while. It took me a long time to understand that my raw productivity is probably better by not working and that I should spend another hour or two per day to lift or exercise substantially in some way. Productive employers understand that mental and physical well-being of its engineers matters much more than raw hours of butts in seats. The remainder are basically body shops and companies that are so far behind their work they'll likely never catch up even if everyone was super productive for 80 hours / week.
|
|
#
?
Sep 3, 2019 15:50
|
|
|
Faith For Two posted:How many hours/week is too many? I like my company and I like the project I'm working on, but we're always behind on deadlines. 41, barring exceptional circumstances. There are a lot of reasons that teams don't meet deadlines, but "we didn't put in enough hours" is never a valid reason, barring something exceptional like people are just completely slacking off and not delivering.
|
|
#
?
Sep 3, 2019 15:54
|
|
|
40 hours is the only way to stay sane. Occasionally exceeding that for glory and money is fine. Regularly exceeding that is a one way ticket to burnout. You're not gonna actually get 60 hours of work done in a 60 hours of working anyway.
|
|
#
?
Sep 3, 2019 16:01
|
|
|
The key thing to explore is "missing deadlines". That's generally a solvable problem without working unpaid overtime. Are the deadlines real deadlines (i.e. "we're launching a space shuttle", or "this has to be done prior to the start of tax season because of changes to the tax code"), or are they arbitrary? The former can fall into the "okay, we need to work overtime" category, but it can also be ameliorated by addressing some of the issues I'm going to bring up momentarily. If the deadlines are arbitrary, who is setting them? Does the team who is actually delivering the work have any input? If not, this is a big problem. The people working on the software can tell you what they can reasonably get done. No one else can determine that with any degree of accuracy, especially when there's a big gulf between "technically straightforward" and "conceptually straightforward". An example is adding better validation/error reporting to the front end of an application. Conceptually, it's very easy. However, depending on myriad factors that are completely invisible to someone who isn't deep in the guts of the application, that may be technically challenging. Someone who doesn't know that will say "that should only take a few hours to do!" when in reality it could be a few days (or more...) of work to implement properly. If the team has buy-in on deadlines, but still misses targets, then you need to look at why. Is everyone getting pulled away because of critical bugs every day? Then you need better testing. You also probably need to do more incremental delivery, even if the big thing you're working on isn't done. If it's not done, put a feature toggle in place and turn it off. But don't expect that you can work on something in isolation for a few weeks or months and then deliver it without having weird regressions elsewhere in the application. Too many emergencies/outages? Better monitoring/alerting/resiliency (and also better testing, why not?). Some amount of "oh poo poo" unplanned work is inevitable, but you need to minimize the amount and ensure that there's an "oh poo poo" factor built into any estimates. If the team is missing targets because management keeps changing the targets and disrupting work-in-progress, then you need better PM processes. If you bring these issues up and get pushback that everything is fine and developers just need to buckle down and work harder, there is nothing you can do. Bail ASAP.
|
|
#
?
Sep 3, 2019 16:22
|
|
|
New Yorp New Yorp posted:If you bring these issues up and get pushback that everything is fine and developers just need to buckle down and work harder, there is nothing you can do. Bail ASAP. ^^ A great post. Also, regarding arbitrary deadlines: sometimes, the deadlines are not really deadlines so much as visibility checks: the stakeholder wants to see their feature to know if it's going to be right for their customer or use case. If this is the situation you are in, there are a lot of things you can give them other than fully-featured software. Things like: - wireframes - pixel perfect mockups - real prototypes of a subset of functionality (minimum viable product) - fake prototypes (build the UI first with static data, demo it, then build out data storage) - video demos showing expected functionality (esp. if your QA / merge process is a bottleneck) These things take additional work, but often it's worth doing in order to get feedback earlier in the process.
|
|
#
?
Sep 3, 2019 16:57
|
|
|
The biggest warning I can relay for "fake" requirements are from sales or product trying to woo prospective customers or even demos (common when pitching to VCs or to the public). Sometimes it makes sense to drop everything to get demos right, but many sales folks under the gun will try to bend back office workers to help them out with a rather long shot prospect and may not have done the proper due diligence for qualifying the lead. We have to trust others sometimes with issues relating to what customers actually want, but we don't all have the luxury of working with awesome people in every nook and cranny of the company and you may want to very diplomatically push back. Better product and sales people will help you out as an engineer stick to features and requirements that are better accomplished on your terms as an engineer deliver value. In a reactive position there is not really a vision anymore and sales / product is unable to dictate that your company's features are even relevant. When your company has missed a big, important ball or you are being disrupted, it's almost always a complete shitshow for engineering as technical debt accrues fast and product / sales need to control the narrative again. Great product and sales folks won't help if your product / service doesn't really fit the needs of the market either or the addressable market is too niche (then you wind up being professional services / MSP for some company and you're not a product company anymore in terms of revenue and investors downgrade your valuation hard).
|
|
#
?
Sep 3, 2019 17:20
|
|
|
Jose Valasquez posted:If you're working more than 40 per week on a regular basis you are working too much imo. Especially if you're not getting paid overtime This, with the caveat that if you are getting paid proper overtime rates, feel free to stack the paper.
|
|
#
?
Sep 5, 2019 19:11
|
|
|
I guess another way to word my question is: if you had infinite work to do, and no other personal obligations, how much would you spend working? Also, I’m salaried. Im probably not going to finish the stuff I was supposed to do this sprint, but I’ll be less-behind if I work over the weekend. Some of my coworkers have said they’ve been working weekends. Some of our deadlines are real. We’ve had to start inviting directors and project managers to our sprint demos.
|
|
#
?
Sep 5, 2019 22:09
|
|
|
Faith For Two posted:I guess another way to word my question is: if you had infinite work to do, and no other personal obligations, how much would you spend working? So basically you are now going to calibrate your velocity that if the entire team works 7 days this is what you can do. But the PO will hear this is how much can be done in a Sprint. Carryover to get to a velocity is expected of the system.
|
|
#
?
Sep 5, 2019 22:15
|
|
|
quote:I guess another way to word my question is: if you had infinite work to do, and no other personal obligations, how much would you spend working? Assuming a typical salaried position in corporate America, the generally agreed-upon ~40 hours/week, sometimes a little more, sometimes a little less. Even that is pretty padded by overhead and "wasted" office time. Far fewer than 40 actual dev-hours a week. My personal obligations, or lack of, is irrelevant. There is always more work to do. The reward for finishing work is almost always more work. You've got to self-impose limits or else you'll burn yourself out. That means that yes, deadlines get missed and features get descoped. Managing and negotiating that is part of the normal product-engineering relationship. I know that I personally hit a productivity wall where just "working" more hours isn't actually generating any value, and in some cases is subtracting value with sloppy code, bad tests, missed cases, spinning in circles trying to debug something stupid, etc. Mental fatigue is very real. So, so, so many times I've just walked away from something I'm struggling with at 5-6pm and come back in the morning and had an "ah ha" moment with fresh eyes and a clear mind. If your team is consistently working long hours and weekends, that is a staffing and/or prioritization issue for management. That is not sustainable. The more you play in to it and given in to pressure, the more you set the expectation that you will do it again in the future. A healthy and mature engineering team pushes back on product and management to manage expectations and set realistic deadlines. Management has to feel the expense of changing directions, requirements, and priorities. Management has to feel the limitations of an understaffed or underfunded team. Management has to feel the costs of shortcuts and technical debt. If the engineering org just burns the candle at both ends to deliver on unrealistic expectations and doesn't bubble up the problems to product and management, you're just setting yourself up to do it again. Not to say there is never crunch time, but that's the exception not the rule. Guinness fucked around with this message at 22:29 on Sep 5, 2019 |
|
#
?
Sep 5, 2019 22:17
|
|
|
Guinness posted:Assuming a typical salaried position in corporate America, the generally agreed-upon ~40 hours/week, sometimes a little more, sometimes a little less. Even that is pretty padded by overhead and "wasted" office time. Far fewer than 40 actual dev-hours a week. My personal obligations, or lack of, is irrelevant. Speaking of being understaffed, how common is it to lose out on talent because they asked for too much money? One applicant in particular rejected a job offer because it was less than what they currently were making in CA. (I’m in Texas somewhere).
|
|
#
?
Sep 5, 2019 22:26
|
|
|
Faith For Two posted:Speaking of being understaffed, how common is it to lose out on talent because they asked for too much money? Were they asking for too much, or were you offering too little? Was it for sure about compensation, or maybe the candidate got bad vibes about the work culture (speaking of long hours and such) but it was easier to stall on comp? That's a bit of a rhetorical question, but regardless, you're not going to hire everyone you extend an offer to for any number of reasons. Maybe their expectations are unrealistic, maybe they just didn't love the place after interviewing, maybe they aren't excited by the product, who knows. Losing one candidate after the offer stage is normal. If you consistently get your offers turned down, it may be time to introspect a little. Guinness fucked around with this message at 22:34 on Sep 5, 2019 |
|
#
?
Sep 5, 2019 22:32
|
|
|
If you are like a lot of companies I know you’ll talk ball park compensation ASAP with the recruiter. If your minimums are way above what they had budgeted they’ll end discussions fast. I left the Southeast because 90%+ of my calls were ending at that stage and the actual opportunities to get me much higher / more enjoyable work were very few and far between anyway and I do better as an on-site worker as a person and an engineer.
|
|
#
?
Sep 5, 2019 23:40
|
|
|
Guinness posted:If your team is consistently working long hours and weekends, that is a staffing and/or prioritization issue for management. That is not sustainable. The more you play in to it and given in to pressure, the more you set the expectation that you will do it again in the future. All correct but I wanted to expand on this point a little. At any job, you should never give 100% day-to-day. You should be expending on average ~80% of your personal capacity, with some days more, and some days less. This way, if you get into an actual emergency, you have 20% extra capacity to pitch in to help solve the problems. All these numbers are made up, btw, just for the sake of argument. If you're working 100% (or worse, 110% or 120%, with 100% based on a 40 hour workweek), and something extraordinary comes up, there's nothing more you can do. Plus, you are likely to be too burnt out to help. Consistently exhausting yourself takes its toll. It might take a few months or even years to show up, but it will, and if your workload is set up to expect that level of commitment, you will be in a very bad place. Good management understands this and wants healthy, happy employees.
|
|
#
?
Sep 5, 2019 23:45
|
|
|
Faith For Two posted:I guess another way to word my question is: if you had infinite work to do, and no other personal obligations, how much would you spend working? At work? No more than if I had a finite amount. The poo poo I have to do at work is boring and I'd rather tinker on personal stuff than slap more of it on my tray. And sleep. Love that sleep.
|
|
#
?
Sep 6, 2019 07:10
|
|
|
Another option is to put in the number of hours defined by your employment contract. Then like others suggested if you want to grind more you can do personal projects or professional development. Imagine if instead of working 50h/week you worked 40h and put 10h into your own software product. That could become a nice side hustle.
|
|
#
?
Sep 6, 2019 11:28
|
|
|
Faith For Two posted:Speaking of being understaffed, how common is it to lose out on talent because they asked for too much money? Expecting a CA tech salary to transfer neatly to anywhere else in the world is unrealistic. That person is being silly. More generally though, it's happened to me (as the hire-er) several times. Some people just see themselves very differently than you do. I wish them luck, and hope there's an organization out there that has that kind of role, but it ain't us.
|
|
#
?
Sep 6, 2019 13:20
|
|
|
good jovi posted:Expecting a CA tech salary to transfer neatly to anywhere else in the world is unrealistic. That person is being silly. Ah, but have you considered that "NUMBER NO GO DOWN! NUMBER ONLY GO UP!"?
|
|
#
?
Sep 6, 2019 14:14
|
|
|
There’s reasonable CoL adjustment and there’s expecting me to take a 100k salary cut. Without numbers, it’s hard to say he was being silly.
|
|
#
?
Sep 6, 2019 14:51
|
|
|
I just recently got a job offer from a company in a Scandinavian country, the recruiter said it was around "75th percentile" for senior dev salaries over there. I declined, because the amount of money I have left over after taxes and normal cost of living expenses would have decreased to about 10% of what it is right now (taxes over there are about 2x higher and CoL in that city was also much higher than it is for me right now in Estonia). The recruiter seemed quite surprised at this - he actually sent me an e-mail asking if it's really true that I'm declining because of the salary. I wonder if he thought I was being unreasonable.
|
|
#
?
Sep 6, 2019 17:45
|
|
|
vonnegutt posted:All correct but I wanted to expand on this point a little. https://erikbern.com/2018/03/27/waiting-time-load-factor-and-queueing-theory.html I'd temper your suggestion a bit though by saying that for each of your areas of responsibility, your organization should have enough slack to turn urgent things around quickly. This is the reason that the Google SRE model, for example, uses the "on-call engineer" approach of teams having a dedicated interrupt handler, so other folks on the team can actually push to 100% without having qualms about it.
|
|
#
?
Sep 7, 2019 15:00
|
|
|
Vulture Culture posted:This is the reason that the Google SRE model, for example, uses the "on-call engineer" approach of teams having a dedicated interrupt handler, so other folks on the team can actually push to 100% without having qualms about it.
|
|
#
?
Sep 7, 2019 15:11
|
|
|
On a previous team, my team members were far too intimidated by the complexities of our organization (we were incident commanders for anything and everything touching cloud infrastructure for a F10 and there was no ticket we assigned that wasn't visible to a CTO/CIO of a $10Bn+ LOB) on top of the fear of pissing off our CTO / CIO customers that everyone escalated to me for almost any issue. I spent about 30%+ of my time training, 30% of my time in meetings or interviews, 50% handling incidents, 30% coding, 10% in 1-on-1 with my team and it was never going to be enough to have the team meet the demands while not burning me out into atoms. Shortly after I left, the team's contract wasn't renewed and they were re-assigned. It is not good for business to rely upon hero engineers and even in small organizations the practice should be discouraged with an open-by-default communication policy and selecting for over-communicating, high-signal-to-noise ratio employees.
|
|
#
?
Sep 7, 2019 17:47
|
|
|
For high-level salaries, cost-of-living starts to matter less. So if $200k in California gets you $100k in Texas, resulting in the same standard of living, you need to think about intangibles like swapping California’s beautiful weather for the baking deserts of Texas, and living next door to Republicans. You might put up with that for $200k in Texas, but a lateral move is pointless.
|
|
#
?
Sep 7, 2019 21:59
|
|
|
Not that living next to Californians is great either fwiw
|
|
#
?
Sep 8, 2019 00:06
|
|
|
|
| # ? May 18, 2024 04:06 |
|
|
Working remotely makes it a lot easier to live next to basically nobody though.
|
|
#
?
Sep 8, 2019 00:11
|
|