|
Pollyanna posted:A job ago, I had to take a few days off and then go home early one day while I was recovering from/dealing with a kidney stone. The pain made it impossible to concentrate, the pain medication made me extremely nauseous (hydrocodone/morphine, opiates are the worst), and the nausea medicine made me extremely drowsy, so there was no way I could operate well until I was fully recovered. I worked for a startup a while back. A fellow goon had to have like *emergency* surgery and the doctors told them to bedrest and no-stress for 3 months. Company told them they could have 3 weeks off and then they needed to either come back or stop getting paid. Later that year I had a major medical event, I had strict orders to spend 20 minutes, 6 times a day doing physical therapy. Company went "welp, you need to spend 2 extra hours at work every day to make up the time you're spending not doing work". Goddamn, never again. NEVER AGAIN.
|
#
?
Aug 6, 2016 01:02
|
|
|
|
| # ? May 10, 2024 00:04 |
|
|
My pod is super roomy and everything, and my team basically just wants you to mention that you're not coming in if you're staying home sick (official company policy is unlimited sick days, within reason). For reference, a former team mate of mine who transferred across the country had their boss pushing them to do deployments while they were immobile at home in bed in a cast. Fortunately, I was able to convince them to change teams, post haste. Bongo Bill posted:If you can't think, you can't work. If you can't work, then your job is to recover. The best and fastest way to recover is to stay home and rest. Similarly, if you being out or being hit by a bus makes that much of a difference to your team's performance, that's not your fault, that's your team's fault for making you a single point of failure.
|
|
#
?
Aug 6, 2016 04:06
|
|
|
Lots of places don't have the budget to get sufficient coverage for their release processes. Despite the will of the masses to move toward automated release management, there's an army of people that want every step approved and documented by a human. To them, I say that I really hope your manual release and integration process is worth the opportunity cost and orders of magnitude lower velocity of innovation compared to most companies that capitalize sufficiently well for their development.
|
|
#
?
Aug 6, 2016 05:24
|
|
|
Volmarias posted:Similarly, if you being out or being hit by a bus makes that much of a difference to your team's performance, that's not your fault, that's your team's fault for making you a single point of failure. Not excusing awful managerial behavior, but this depends on the size of the company. If you're in a lean startup there are not many redundancies built into roles, which sucks, but it is what it is.
|
|
#
?
Aug 6, 2016 15:42
|
|
|
We used to have a pretty loose working from home policy until a year or so ago. It was pretty nice to have when you're feeling sick or coughing up your lungs / blowing snot all day, but not feeling so awful as to be entirely unable to get any work done. I guess someone was abusing it and like with everything else our managerial approach is to reprimand/punish everyone rather than to deal with the problematic person that's just going to find other ways of being problematic.
|
|
#
?
Aug 7, 2016 02:55
|
|
|
speng31b posted:Not excusing awful managerial behavior, but this depends on the size of the company. If you're in a lean startup there are not many redundancies built into roles, which sucks, but it is what it is. Best to just leave it a function of headcount.
|
|
#
?
Aug 7, 2016 04:59
|
|
|
Vulture Culture posted:Lean methodology doesn't say anything about redundancy in roles. In fact, the first bullet point under Eric Ries' Lean Startup principles is "eliminate uncertainty," which welcomes risk management where appropriate. Lean is not a cost-reduction strategy. Eliyahu Goldratt's The Goal itself, which developed much of modern Lean methodology out of the Theory of Constraints, focused on properly identifying and resolving production bottlenecks. Certainly, having a situation where a single human can go out and tank the entire production line is not a good strategy for reducing bottlenecks. I don't know that that was a reference to Lean as a formal business methodology as much as lean as an adjective.
|
|
#
?
Aug 7, 2016 05:02
|
|
|
Vulture Culture posted:Lean methodology doesn't say anything about redundancy in roles. In fact, the first bullet point under Eric Ries' Lean Startup principles is "eliminate uncertainty," which welcomes risk management where appropriate. Lean is not a cost-reduction strategy. Eliyahu Goldratt's The Goal itself, which developed much of modern Lean methodology out of the Theory of Constraints, focused on properly identifying and resolving production bottlenecks. Certainly, having a situation where a single human can go out and tank the entire production line is not a good strategy for reducing bottlenecks. The respond might have been inappropriate because the OP was using lower-case "lean" instead of upper-case "Lean," but I concidentally got to read a thread today about upper management adopting a scaled agile model "not for efficiency."
|
|
#
?
Aug 8, 2016 23:15
|
|
|
I take it that you were introduced to SAFE then? Run
|
|
#
?
Aug 8, 2016 23:42
|
|
|
necrobobsledder posted:I take it that you were introduced to SAFE then? Run I've had that gun pointed to my head for a few years. They're now trying to roll it out to a hardware QA organization, where it's really bonkers. I'm writing code so it at least makes a little bit of sense. I'm not saying it's the smart thing to do, just that it at least makes sense. For the other folks, I have been struggling to try to get them advice. I don't know how the hell they should scrum.
|
|
#
?
Aug 9, 2016 01:31
|
|
|
Cuntpunch posted:I worked for a startup a while back. A fellow goon had to have like *emergency* surgery and the doctors told them to bedrest and no-stress for 3 months. Company told them they could have 3 weeks off and then they needed to either come back or stop getting paid. It went over well. He basically told me that the expectation for his normal salary employees is that if they have to missing something here he just expects they'll make it up there later and as an intern he's just going to treat me the same way. Thank god, since my surgery created new complications and my two days off is quickly turning into a week+ off. He said we'll just keep track of the time so I don't get overpaid. So much stress gone not having to worry about getting canned for poo poo beyond my control. edit: He also solidified an extension on my internship for the rest of the year in the midst of this taking time off process and basically said congrats you're here for another year in the midst of all this so I'm feeling pretty appreciated at the moment.
|
|
#
?
Aug 9, 2016 17:36
|
|
|
That sounds to me like they like you and might be offering you a job some day.
|
|
#
?
Aug 9, 2016 18:49
|
|
|
Tomorrow I get to tell management that you can't expect board bringup to happen in less than a month. 
|
|
#
?
Aug 16, 2016 03:26
|
|
|
ratbert90 posted:Tomorrow I get to tell management that you can't expect board bringup to happen in less than a month. The intermittent manager tried to tell me "I'm not allowed to put my foot down." Hey guess what? You can't be 2 months late on delivering hardware and then expect me to still get everything done with 2 less months. I have had this poo poo pulled on me in the past, and I refuse to let it happen again. It's nice to be the senior engineer. I don't choose too many hills to fight on, but this one is a big one.
|
|
#
?
Aug 16, 2016 14:06
|
|
|
I have a question about mobile development careers. I work in video/multimedia production. And it seems like quite a few employers these days are starting to ask for "After Effects/Maya professionals with mobile development experience". Is it really becoming common for companies to expect people to know high level video development/3D asset creation AND mobile development? Or is just a case of recruiting departments these copy/pasting long bulleted lists of job responsibilities that they don't know very much about? Because if anyone were to ask me, video/3D object development and mobile development are two very different skillsets.
|
|
#
?
Aug 16, 2016 14:33
|
|
|
I did it and went crazy and now we have a temp policy that enforces tickets of no more than the equivalent of 3 hours. Break that poo poo up. Ugh. We'll see how this goes.
|
|
#
?
Aug 16, 2016 14:33
|
|
|
Bragpost: by the end of today, I will have completed 7 story points (which are estimated at about 1 story point per dev day) in the space of two afternoons. I wonder if my tech lead will be okay with me taking a couple vacation days for an impromptu long weekend.
|
|
#
?
Aug 16, 2016 15:28
|
|
|
I need some perspective on something that happened to me at work recently. Three months ago I pivoted a bit into a full-stack development gig. The company I was hired into was a bootstrapped "skunkworks" of sorts, created to work on projects to help diversify the company's portfolio and make it less reliant on its current bread-and-butter. The three of us joined up understanding that we'd be largely autonomous, able to work with the latest and greatest and choose the best way to implement things. The reality of this arrangement reared its ugly head last week when we demonstrated our MVP to one of the company's founders. We'd been working on this thing for about two months, and functionality-wise it had all of the basic functions needed for this particular product. It was a pretty typical Angular2/Django stack that was written to best practices on all ends and would have been a solid foundation to iterate upon moving forward. Unfortunately, this founder is incredibly old-school. He desperately wants to remain involved in product development but all of his development sensibilities originate from around 2010 when jQuery was hot. He doesn't "get good feelings" about SPAs, REST APIs, TypeScript, SCSS, or anything like that, and he assumes that they're somehow less security-oriented than server-rendered approaches. We had answers for every one of his concerns that came up during the demo, proving we'd done our research on the viability of our stack, but he just couldn't accept any of it. Not to mention the fact that he balked when he saw our CI dashboard showing our build process; there's no CI to speak of with the company's main product and we think a large part of it is the founder's belief that tests "can just be simple python tests you manually run before deployment"  This leads into the next day, in which my boss (the CTO), during a meeting with the founder, requests a timetable on how long it would take to port the entire solution into a Django-rendered app. I calculated 10 weeks, my boss passed it on to the founder, and the founder signed off on it. The founder also dictated the rest of the stack, declaring that it had to be written with jQuery, vanilla JS, and vanilla CSS. We were lucky to get out of it with our Kubernetes setup and use of AWS for hosting, but we suspect it's only a matter of time. I was certainly disheartened when the decision came down to port everything, though my initial reaction was more along the lines of "well, as long as they're signing the checks...  ". Based on my boss and other coworker's reactions, though, apparently this is a Pretty Bad development? The way they explained it, the founder basically came in and shat all over everything by forcing a stack change so far into what was an otherwise smooth-flowing project, revealing the level of micromanaging that we'd have to work under going forward. This revelation ran counter to the mission we'd been sold, and so my boss and coworker (who are way more experienced in stuff like this than I am and have a way lower tolerance for bullshit like this) have lost all steam and are now looking for new opportunities.So I mean, is this a pretty typical reaction to something like this happening? I'm freaking out a bit because I just started this gig and thought I'd be done with job searching for a couple of years, but with the rest of the team slowly on their way out I now have to dive back into the cesspool that is technical recruiters and resume-scanning algorithms and just ugh. I mean, worst case, I could probably migrate to the main HQ and join the development team to work on our company's main project. But I've talked with people who work over there and have learned that it's a hell of its own brought about by years of this same founder's micromanaging. I don't foresee good things coming of a decision to get involved in that.
|
|
#
?
Aug 16, 2016 15:37
|
|
|
Band together, write recommendation letters for each other, and tell that rear end in a top hat to gently caress off and let you work.
|
|
#
?
Aug 16, 2016 15:49
|
|
|
melon cat posted:I have a question about mobile development careers. I work in video/multimedia production. And it seems like quite a few employers these days are starting to ask for "After Effects/Maya professionals with mobile development experience". Mobile games can be in 3d? We use Maya for our asset creation pipeline.
|
|
#
?
Aug 16, 2016 15:50
|
|
|
Lol cmon, you wrote all that and you don't already have the answer?CPColin posted:Band together, write recommendation letters for each other, and tell that rear end in a top hat to gently caress off and let you work.
|
|
#
?
Aug 16, 2016 15:51
|
|
|
It's a pretty typical thing to happen honestly in my experience - engineers try to change things up with a new effort demoing best practices and new technologies that implement a subset of a current product. Management is risk-averse now when they may have been a bit more risk-taking in the past, so they want to stick with things they can understand at least because they may be forced to learn this crap themselves because they expect some turnover. This comes up pretty often even when a company is acquired - I've been part of a few acquisition periods and losing 50% of your engineers within 2 years isn't uncommon. Be glad you were able to do any of it and take it as a great learning experience. So if I'm getting it right, they basically want what it looks like using stuff other engineers already know and maintain like the existing legacy codebase + the CI system? Sounds like you effectively spent that time working on CI / CD and re-designing some pages and it's pretty bad on paper from a business perspective if you ask me. For what it's worth, I built a site I was pitching around in jQuery + Django back in 2010 and if I had moved forward I'd be excited to see someone working with me trying to port it all to Angular2 / React by now. Being averse to technology change is not really the spirit of a good technology person IMO. There's probably more to the story that keeps the folks at the top from trying anything new besides lack of familiarity with the technology. Heck, maybe he's just scared of the Javascript framework fatigue problem, and that's kind of a legitimate concern.
|
|
#
?
Aug 16, 2016 15:59
|
|
|
Hughlander posted:Mobile games can be in 3d? We use Maya for our asset creation pipeline.
|
|
#
?
Aug 16, 2016 16:00
|
|
|
ChickenWing posted:Bragpost: by the end of today, I will have completed 7 story points (which are estimated at about 1 story point per dev day) in the space of two afternoons. The team's estimates being bad is not a cause for celebration. Make sure you bring it up during the retrospective.
|
|
#
?
Aug 16, 2016 16:04
|
|
|
necrobobsledder posted:So if I'm getting it right, they basically want what it looks like using stuff other engineers already know and maintain like the existing legacy codebase + the CI system? Sounds like you effectively spent that time working on CI / CD and re-designing some pages and it's pretty bad on paper from a business perspective if you ask me. And going back to CI, the main office has no CI whatsoever. They manually test and deploy, but their staging environment and production environment are completely out of sync so it's been an exercise in futility to integrate a smaller feature (that we also worked on prior to now) into their system. They've spent so much time in a constant state of firefighting that they've never bothered to take time to streamline any of their process. It doesn't help that the importance of CI is misunderstood by the founder, so there's certainly no push from the top to improve anything. necrobobsledder posted:Heck, maybe he's just scared of the Javascript framework fatigue problem, and that's kind of a legitimate concern.
|
|
#
?
Aug 16, 2016 16:09
|
|
|
ChickenWing posted:Bragpost: by the end of today, I will have completed 7 story points (which are estimated at about 1 story point per dev day) in the space of two afternoons. In those situations it's amazing how quickly management understands that points != time, but in the reverse they can't quite grasp the concept.
|
|
#
?
Aug 16, 2016 16:16
|
|
|
Ah, that makes more sense now. Basically, they have no resources to train anyone already around to learn any of this stuff, nor is there any management impetus to do so because of the current quagmire of trying to keep your head above water, so it's more effective on the whole to have you guys rewrite as much as possible for someone already around to take it over instead of bringing on more people externally. I expect that in another 3 years they'll be calling me up for "devops consulting" after the current batch of "devops = silver bullet" managers are done and over with the latest solution to their terrible company engineering cultures.
|
|
#
?
Aug 16, 2016 16:15
|
|
|
Ithaqua posted:The team's estimates being bad is not a cause for celebration. Make sure you bring it up during the retrospective. This ChickenWing posted:Bragpost: by the end of today, I will have completed 7 story points (which are estimated at about 1 story point per dev day) in the space of two afternoons. Also, no! Get back to work what the heck man. Obviously whoever estimated it did a poor job, you don't get the rest of the week off for that lol My manager has a story about how when he was starting out he had a guy on his team that after a 1 hr meeting ended 30 minutes early went back to his desk and zoned out. When manager asked what he was doing the guy said "well I thought that I get that time back to myself since we got it done so early"
|
|
#
?
Aug 16, 2016 16:18
|
|
|
melon cat posted:That's what I thought as well, but a lot of the postings I'm seeing seem to expect more than Maya for mobile game asset creation. As in, they expect you to know how to code/create a mobile app from scratch AND create videos for marketing it. Can you link a handful? All I can imagine is a weird wording for a technical artist or a tools engineer.
|
|
#
?
Aug 16, 2016 16:38
|
|
|
Ithaqua posted:The team's estimates being bad is not a cause for celebration. Make sure you bring it up during the retrospective. Yeah we tend to estimate worst-case, plus we're still honing down from what we used to have, which was fairly ludicrous. It's been better since we've started on a lowest-bidder story point system rather than consensus-based
|
|
#
?
Aug 16, 2016 16:44
|
|
|
ratbert90 posted:The intermittent manager tried to tell me "I'm not allowed to put my foot down."
|
|
#
?
Aug 16, 2016 16:45
|
|
|
Hughlander posted:Can you link a handful? All I can imagine is a weird wording for a technical artist or a tools engineer.
|
|
#
?
Aug 16, 2016 16:59
|
|
|
ChickenWing posted:Yeah we tend to estimate worst-case, plus we're still honing down from what we used to have, which was fairly ludicrous. It's been better since we've started on a lowest-bidder story point system rather than consensus-based Lowest estimate is an awful idea. A better solution is to identify what causes your estimates to be so wildly out of line with reality and solve that problem. Getting 7 "days" worth of work done in a few hours means that your estimates are worse than inaccurate, they're totally useless as a metric for planning. It could be that your stories are too big to begin with and need to be broken down further so they can more accurately be estimated. It could also be that everyone has it in their brains that "1 point = 1 day". That's bad. Points are relative to the other stories, not equatable to days or hours. "Is X bigger or smaller than Y?" That's why some teams use t-shirt sizes instead of points. [edit] Of course, for teams just getting started it's perfectly natural for estimates to be crazily wrong. But that shouldn't last for more than a few sprints. If you're still having that problem, you need to seriously look at why it's happening and correct the behavior that causes it. New Yorp New Yorp fucked around with this message at 17:25 on Aug 16, 2016 |
|
#
?
Aug 16, 2016 17:18
|
|
|
ChickenWing posted:Yeah we tend to estimate worst-case, plus we're still honing down from what we used to have, which was fairly ludicrous. It's been better since we've started on a lowest-bidder story point system rather than consensus-based I'm confused by that last part. I say 1 or you say 12 we just go with 1 rather than discuss why there's such a variance and see what our assumptions are? Or were you before just saying ok 6! Consensus during estimations seems rather key or there are probably vastly different expectations in the task.
|
|
#
?
Aug 16, 2016 17:36
|
|
|
Maybe he's just a 10x developer
|
|
#
?
Aug 16, 2016 17:42
|
|
|
IAmKale posted:That's the thing, we weren't working on a redesign of an existing product. This was an entirely new project that we were building from the ground up. Integration with the old system would have had to take place at some point, but in the near term we would have built and maintained it. Yeah, it's stupid for them to give your team a "skunkworks" type of project, then balk when you picked the best tools for the job and they didn't match the existing system. Best case scenario is for your team to insist that this is the best course to take, but it sounds like your founder is pretty stuck in his ways and unlikely to budge. ChickenWing posted:Bragpost: by the end of today, I will have completed 7 story points (which are estimated at about 1 story point per dev day) in the space of two afternoons. What do you do for tasks that take an hour? Or fifteen minutes? Do those get one story point (and the expectation of taking one dev-day), too?
|
|
#
?
Aug 16, 2016 18:02
|
|
|
rt4 posted:Maybe he's just a 10x developer Points are a level of effort not time. Even if they do it in 1/10th the time there should be an agreement to the effort required.
|
|
#
?
Aug 16, 2016 18:06
|
|
|
Our current system works like so: Read the story. Discuss assumptions, elicit further information from BAs as necessary. Ensure everyone has enough info to estimate. Everyone provides a point count, somewhere between 0.5 and 3 (higher means it should almost certainly be more than one story). The person who put up the lowest number of points gets assigned the story next sprint (this is the key), valued at the number of points as the next-highest estimate,so if I estimate 0.5 and my coworker estimates 1, I get it at 1. For ties, one of us gets it at 1, determined by whoever has the least number of points, or if that's equal then whoever hasn't recieved a story in the longest amount of time. Previously, it was typical planning poker. Same discussion part as above, but after everyone provided a point count we had to come to a consensus on point costs, including discussion with severe outliers, then stories are assigned after everything is estimated. We were having issues with really inflated point costs due to a bunch of reasons, and our new approach has curtailed that somewhat. Ithaqua posted:Lowest estimate is an awful idea. A better solution is to identify what causes your estimates to be so wildly out of line with reality and solve that problem. Getting 7 "days" worth of work done in a few hours means that your estimates are worse than inaccurate, they're totally useless as a metric for planning. 1) Our devs work at vastly different speeds, and for some these estimates are accurate. Plus, people tend to pad out their stories a little because we occasionally have problems interfacing with other teams/the DBA/etc. 2) We are explicitly encourage to estimate with the expectation that one point = one day of development, plus some QA time, plus some BA time. I'm not saying it's the optimal approach, but it's the best we've managed for our team since I started on this project. Let me tell you about the sprint (7 business days) in which I completed 29.5 story points with the same assumed 1 point = 1 day comparison. I did work full tilt for the duration of that sprint, but drat if it wasn't a silly bunch of estimates.
|
|
#
?
Aug 16, 2016 18:16
|
|
|
It's also just plain hard to perfectly quantize development. Sure anybody experienced and worth their salt can give you estimates on how long it will take but, well, sometimes poo poo just goes wrong and that easy three hour task turns into a time devouring behemoth. Which then breaks some piece of legacy code that an intern wrote six years ago and never documented but when you fix that a security hoke crops up anddd.........
|
|
#
?
Aug 16, 2016 18:22
|
|
|
|
| # ? May 10, 2024 00:04 |
|
|
The problem, again, is that the team is being told to estimate in terms of time. They shouldn't be. The estimates are supposed to be in terms of relative size/difficulty. The team should be able to complete a consistent amount of points every sprint. Individual speed shouldn't factor into it. The fact that different people work at different rates is the exact reason for this. If you complete 5 points in 5 hours and someone else completes 5 points in 10 hours, you're still accomplishing 10 points of work in 15 hours. I'm not saying that estimates are supposed to be perfect and infallible -- you will absolutely over/underestimate. I'm just saying that the degree to which your estimates are off are indicative of a severe problem with the way you're doing estimation. The team's velocity will be higher some sprints, lower others, but you should be able to determine an average velocity that's fairly consistent if you're estimating properly. Stories also shouldn't be assigned, but should be grabbed by whoever is available in order of priority within the sprint, but that's another story entirely. New Yorp New Yorp fucked around with this message at 19:19 on Aug 16, 2016 |
|
#
?
Aug 16, 2016 19:16
|
|
