|
Remote to me was a reaction to a near mental breakdown taking a job in an extremely open office. If the commute wasn’t bad, the work was interesting (not likely in this area), and I got an office / shared office I’d probably go back but everyone has gone full open office in the last 5-10 and I literally cannot do that without medication so remote it is. Also if I lived in California, NYC, etc. maybe the options would be different but remote opportunities in general are vastly more rewarding and interesting work. My current remote gig is by no means perfect but I’ve learned more in the last year than I had in the last 10 working local jobs.
|
#
?
Jul 21, 2019 00:57
|
|
|
|
| # ? May 11, 2024 20:49 |
|
|
|
|
#
?
Jul 22, 2019 17:32
|
|
|
And that engineer's name, was Albert Einstein
|
|
#
?
Jul 22, 2019 18:01
|
|
|
I'm the employee more concerned with the semantics of titles over actually getting poo poo done.
|
|
#
?
Jul 22, 2019 18:05
|
|
|
poemdexter posted:I'm the employee more concerned with the semantics of titles over actually getting poo poo done. The company culture is rubbish and everything I cook up isn't sustainable, but at least I get poo poo done!
|
|
#
?
Jul 22, 2019 18:16
|
|
|
"We are fully devops! The team you will be part of has a frontend engineer, a backend engineer, a tester, a scrummaster, an ops engineer and a product owner."
|
|
#
?
Jul 22, 2019 18:18
|
|
|
I prob told this before in this thread, but I will never be able to forget the manager at my previous job referring to our frontend engineers as "frontenters" with a t. (Yes yes Sheldon it has two t's I know)
|
|
#
?
Jul 22, 2019 18:39
|
|
|
I love having conversations with the PM for a year-overdue project where they ask for something to be changed, I ask that the request be made in writing, they say, "Well I don't know how all this stuff is supposed to work!" and eventually agree not to change anything because we're so far behind. Really M'ing this P.
|
|
#
?
Jul 22, 2019 19:48
|
|
|
Hollow Talk posted:The company culture is rubbish and everything I cook up isn't sustainable, but at least I get poo poo done! Same. Last Friday, I got to listen to two product owners argue if something was a tactical solution or a strategic solution. Most meetings are 20% discussion and 80% how do we properly put this in JIRA.
|
|
#
?
Jul 22, 2019 19:48
|
|
|
I'm more of a backenter myself
|
|
#
?
Jul 22, 2019 19:50
|
|
|
I do mostly frontentering but am not sure if my boss would be cool with me backentering
|
|
#
?
Jul 22, 2019 20:18
|
|
|
Sprint planning meeting today, and 2 engineers had tickets that didn't get done during the sprint because higher priority stuff came up. Manager is like "so what went wrong with these tickets? You guys committed to get the work done but didn't" Several of us are like "that's how agile works, nothing went wrong" This is after *years* of being "agile". She (and managers from other departments) are still obsessed with commitment. You put a thing on a sprint = you must do it... but somehow they also want the higher priority stuff to get done too. I don't even
|
|
#
?
Jul 22, 2019 23:39
|
|
|
When managers are even talking with you about tickets it's already a failure.
|
|
#
?
Jul 22, 2019 23:44
|
|
|
Normally the n+2 boss calls in while the n+1 is there chipping in her 2 cents like this time. It's the dumbest. I firmly believe in the "people over process" thing. We don't have POs and I'm fine with that. I was more agile on my own, doing my own thing, before anyone uttered the words agile here.
|
|
#
?
Jul 22, 2019 23:48
|
|
|
Remind them that this attitude leads to escalation fairly quickly. If they want sprint commitments to be completed in all cases, they will soon find that all tasks in the sprint are relatively small pieces of larger stories, or research and investigation tasks. If they want to reprioritize items during the sprint, then they must choose items to remove of equal value. ("Completion percentage" is just another metric, and we know what happens when you chase metrics.) Choice 1: Why are all these tasks "Determine method to do X?" (Answer: Because there's a 70% chance you'll steal 40% of our time, and this gives us sufficient buffer to still reach completion for a slightly relaxed definition of "done".) Choice 2: I want this prioritized, how many points? Seven? And we're halfway through a 15pt/person sprint, so Johnny I'm going to need you to drop Eggbox and we'll have to restart it next time. Please take the remaining time on Eggbox and add 1pt since we're wasting time to "task switching" by punting. Sadly this requires more than one person not 
|
|
#
?
Jul 23, 2019 00:39
|
|
|
Good points there. I think something that contributes to a lot of the commitment vs flexibility problem is that my boss has like 12 direct reports. She's got so many irons in the fire that she cannot and will not oversee all of the priority changes that happen every single day. Each of us is pretty well in our own little silo without a lot of collaboration on what we do, so we feel like we can make the best call anyway. On a smaller team, she would probably be much more effective and her role could be more accurately described as a PO. As it is now, she's just someone who gets mad about stuff way after it's already happened.
|
|
#
?
Jul 23, 2019 01:41
|
|
|
My Rhythmic Crotch posted:Sprint planning meeting today, and 2 engineers had tickets that didn't get done during the sprint because higher priority stuff came up. The commitment obsession is reasonable in a vacuum. There's supposed to be a deal: you commit to a certain amount of work in a sprint. That way, project leadership can plan around things like dependencies for other teams. Project leadership gets to work with you to set another chunk of commitments at the next sprint boundary. That way, you don't get blindsided with more work than you can realistically handle. So: Take on what you think you can reasonably finish in a sprint, minus some padding. When they come in with a higher-priority item and demand you pick it up in the middle of the sprint, point out that getting it done before everything else is a commitment as well, and ask them what prior commitments they're OK with dropping to make it happen. Don't take "you just have to get everything done" for an answer, and make sure that things are documented in writing somewhere, even if it's just a "per our last conversation I am doing X" email. Make sure your coworkers are on board before this discussion happens. Xik posted:When managers are even talking with you about tickets it's already a failure. 🤷🏻♂️ Ticket = story in some places thanks to badly configured Jira setups. I assume that a dev shop isn't getting "change my email password" tickets. If they are then there are much deeper problems than agile methodology.
|
|
#
?
Jul 23, 2019 03:22
|
|
|
You should write a modern, angry version called the Little Princess. Your manager plays the role of Queen of the Universe. "I command the universe and it doesn't listen  "Our thing right now is making the switch to Kanban, people thinking it's still scrum, meanwhile pushing to get rid of the ~3hr/3wk scrum meetings, and wanting to do it all today. I'm not running either scrum or kanban here, but it sure seems like we need the meetings to discuss priority and to deal with the backlog grooming. Moreover we still need a retro to review process issues, and we should probably try it for a few cycles before we make radical changes. In any case, we have the rooms reserved; no need to cancel those meetings yet. Where we're wasting time is sitting in a room to discuss "priority", and instead of discussing the goals (or "stories" if you must), we spend 80% of the time listening to a few people argue over the complexity, related problems, effort, or solutions. When each task takes 5min to prioritize, we're not going to get through our 500 item backlog now are we? (Sorry I didn't mean to be so analytical up there. Your manager is dumm and should feel bad and we should make fun of her.)
|
|
#
?
Jul 23, 2019 03:39
|
|
|
We recently got together to make the rules for SAFe Program Increments clearer. In case you don't know, SAFe is the opposite to agile and a manager's dream because it gives a false sense of security. PIs are periods of 4-5 sprints you plan company-wide ahead of time. You roughly plan on feature level instead of story level, for that you still got individual sprint planning sessions (which are much shorter than in a company without PI, it has to be said). Anyway, the new rules: - We get rid of the Scrum term "intangible work" and "leaving space for intangibles in the sprint" because that gave some of our people a false idea of there being "space" that can be filled ahead of time. Instead we say every sprint stuff comes up that is unplannable and we need to take that into consideration. - When management disagrees with the outcome of the PI planning event, they only can ask to switch out stuff for other stuff of the same complexity/amount of work, they cannot ask anymore to cram even more into the planning. Honestly it seems to work so far, at least better than it did before we had these explicit rules. Note that there is actual unplannable work, it's not just something used to explain sudden shifting priorities. Our dev teams do most of the ops stuff too and incidents happen when they happen and need to be resolved quickly no matter what.
|
|
#
?
Jul 23, 2019 06:57
|
|
|
We prioritise projects first (hello multi-project environment), then an intermediary (it's me...) talks to the project leads and then to management and this is what is supposed to generate global priorities. This system was introduced because we always had too much stuff in our sprints, and only ever added things. Clearly, the solution is to not call it sprints anymore, and let everybody decide themselves, then try and throw it all together! Also, sales and management just throw in new stuff from the sidelines regardless, of course. I'm curious how this company will develop, and if it will survive when I inevitably give up and move on.
|
|
#
?
Jul 23, 2019 07:48
|
|
|
There's always going to be unplannable work. You don't know what you're doing until you're deep in the weeds. I like the metaphor of the hill that Ryan Singer uses in Shape Up. The trick is to give engineering teams a broad enough mandate to solve a business problem that they can solve the important parts first, get the unknown unknowns out of the way, build features vertically, and trim scope intelligently when it becomes apparent that the sprint will not meet 100% of its aspirational goals. Not doing that is not doing Agile. I wish people would stop pretending there was a way to reduce unpredictability and risk through process and structure. That uncertainty is something that's not just fundamental to the engineering work, but desirable because that risk is what keeps scope from exploding within a sprint.
|
|
#
?
Jul 23, 2019 12:56
|
|
|
Carbon dioxide posted:- We get rid of the Scrum term "intangible work" and "leaving space for intangibles in the sprint" because that gave some of our people a false idea of there being "space" that can be filled ahead of time. 
|
|
#
?
Jul 23, 2019 13:21
|
|
|
Vulture Culture posted:There's always going to be unplannable work. You don't know what you're doing until you're deep in the weeds. I like the metaphor of the hill that Ryan Singer uses in Shape Up. Agreed 100%. At this company, there are a lot of serial dependencies (Group A is going to implement something that Group B needs). Management here spends an enormous amount of time yelling at engineers to 1) "Get better at estimating" and 2) "Deliver, deliver, deliver" so that the knock-on effects of one group being late don't impact all the groups down the line. I'm just a peon, I have no ability to change this culture... but I think a few things could really help. 1) They need to be focusing on the burn down (rather than a set-in-stone, drop-dead date as it seems they are now), and continually updating the projection of when something might be completed. 2) Attach a probability or confidence level to the projected completion date, and communicate that to any stakeholders down the line. 3) Let engineers develop expertise within a few subsystems, rather than continually dumping them into new areas they've never touched before, and then acting shocked when stuff isn't getting done as quickly as hoped for. * A lot of the above chaos happens outside my group. There's no way I would still be here if I was subjected to all of that continually. Space Gopher posted:Ticket = story in some places thanks to badly configured Jira setups. Yep, that's how ours is configured. My Rhythmic Crotch fucked around with this message at 15:32 on Jul 23, 2019 |
|
#
?
Jul 23, 2019 15:21
|
|
|
My Rhythmic Crotch posted:At this company, there are a lot of serial dependencies (Group A is going to implement something that Group B needs). Management here spends an enormous amount of time yelling at engineers to 1) "Get better at estimating" and 2) "Deliver, deliver, deliver" so that the knock-on effects of one group being late don't impact all the groups down the line. Don't just accept this. You're a developer. It's your job to write code. It's perfectly reasonable for management to ask you to write code. Bugs happen, but you fix them, learn from them, and make sure they don't happen again. Someone who writes similar bugs over and over needs coaching to make them a better dev. They're your manager. It's their job to prioritize things. It's perfectly reasonable for you to ask management to prioritize things. Missed priorities happen, but they should fix them, learn from them, and make sure they don't happen again. Someone who consistently mis-plans work in the same way over and over again needs coaching to make them a better manager. If they come crashing into your sprint and demand you work on something that vaults from the bottom of the backlog to "ASAP", ask them what they're OK dropping out of the sprint to allow you to meet all your commitments. Make sure they understand that you're not telling them it won't get done, just that you can't promise that it will get done because they've changed your commitments. They might tell you that you have to get absolutely everything done, including the new unplanned work, no exceptions. If they do that, then in the next sprint planning, tell them you'll need a big story to track unplanned work. Here's the critical part for getting that to work: have one-on-one side conversations with the people you work with until you're sure most people are on board. Don't be afraid to be a lobbyist and line up your support. If the entire team says "this is a problem," the PM should listen and take that into account, just like they would for a story point estimate or T-shirt size. There's a possibility they'll continue to provide project plans that are totally out of sync with reality. If that happens, then you genuinely can't fix the problem and need to look for a new job. But don't write off changing culture until you see it happen.
|
|
#
?
Jul 23, 2019 15:59
|
|
|
brb gonna change the culture of a company with 50,000 employees spread across the globe
|
|
#
?
Jul 23, 2019 17:56
|
|
|
Be a Viking and berserker it if you have to. Valhalla awaits.
|
|
#
?
Jul 23, 2019 19:57
|
|
|
Pollyanna posted:Be a Viking and berserker it if you have to. Valhalla awaits. The modern Viking way is not to make any decisions until everyone is 100% on board. It involves a lot of meetings.
|
|
#
?
Jul 23, 2019 21:15
|
|
|
My Rhythmic Crotch posted:brb gonna change the culture of a company with 50,000 employees spread across the globe Globe's got 7.5 billion people on it, might as well not try to change anything ever. The overall company culture isn't going to dictate how every dev team operates. It should be possible to change the space you're operating in. If not, you need to find a new job.
|
|
#
?
Jul 24, 2019 00:30
|
|
|
Working in Development: Good companies aren't hiring
|
|
#
?
Jul 24, 2019 00:56
|
|
|
Space Gopher posted:Globe's got 7.5 billion people on it, might as well not try to change anything ever.
|
|
#
?
Jul 24, 2019 01:01
|
|
|
My Rhythmic Crotch posted:brb gonna change the culture of a company with 50,000 employees spread across the globe Can't you just try making positive change in your immediate team? If it works it will make your job better, who really cares about the other 50k people. I get some huge things will be out of scope because you don't have the power, but who knows, if things are good for you and other teams notice they might just try to push for the same changes.
|
|
#
?
Jul 24, 2019 01:13
|
|
|
You guys missed a key important thing that I wroteMy Rhythmic Crotch posted:* A lot of the above chaos happens outside my group. There's no way I would still be here if I was subjected to all of that continually. And appear to be filling in the blanks with things you think are happening, like this: Xik posted:Can't you just try making positive change in your immediate team? Or this: Space Gopher posted:Globe's got 7.5 billion people on it, might as well not try to change anything ever. The dysfunction that exists in my team is due to us having a ding-dong manager. The other dysfunction that I described happens in other teams, I rarely if ever see it in person and usually only hear about it, and thus have no influence over it.
|
|
#
?
Jul 24, 2019 03:50
|
|
|
|
|
#
?
Jul 24, 2019 07:00
|
|
|
|
|
#
?
Jul 24, 2019 12:01
|
|
|
My favorite thing about people asking me questions at work is the weird illusion that I actually know the answer, and I didn't just type your question into google and ask if you tried the first result on stackoverflow.
|
|
#
?
Jul 24, 2019 13:37
|
|
|
I will forever maintain that IT/SD is just knowing how to google better than everyone you work with
|
|
#
?
Jul 24, 2019 14:08
|
|
|
ChickenWing posted:I will forever maintain that IT/SD is just knowing how to google better than everyone you work with Being able to filter out bad results is key. I was pairing recently and we had to look up some CSS selector I couldn't remember and when we googled it together I was like "skip w3schools...skip that...skip that...look for the MDN result". Also helping my mom out with tech support, it's clear she doesn't really know where the problem lives. She'll say she has a "PowerPoint problem" when really it's that the projector isn't mirroring her laptop. Being able to articulate the exact problem in a way that will come up with a useful result is a learned skill.
|
|
#
?
Jul 24, 2019 14:20
|
|
|
vonnegutt posted:I was like "skip w3schools...skip that...skip that...look for the MDN result". To be fair, w3schools is great for idiots like me who never bothered to learn CSS and are constantly googling the most basic poo poo when we can't get out of front end tickets. Just not for actual bugs.
|
|
#
?
Jul 24, 2019 14:59
|
|
|
Spent most of the day learning webpack for a site just to find out that I can't use it since the server doesn't support node.js (wpengine).
|
|
#
?
Jul 24, 2019 15:20
|
|
|
|
| # ? May 11, 2024 20:49 |
|
|
Do they expect you to have an external build process for the frontend or something?
|
|
#
?
Jul 24, 2019 15:22
|
|
