|
Steve French posted:In my experience "process heavy" and "agile methodology" are in no way at odds with each other. A couple of our guys went to a scrum master training camp thing last week, so we're going to be breaking out the kool-aid in the near future. Sounds like a complaint, but I'm honestly hopeful that things will improve - our previous/current state was "we're an agile shop! we have sprints! The manager wants us have long detailed conversations about technical hurdles and feature decisions that involve 20% of the developers in the room during our 'daily stand-ups' which make them take a minimum of 30 minutes!" The manager was one of the ones who took the training and he seems on board with making some big changes based on what they learned. I'm fine with a lot of processes as long as they enable us to get work done, our problem was our processes were almost pure overhead.
|
#
¿
Nov 25, 2015 17:59
|
|
|
|
| # ¿ Apr 27, 2024 19:38 |
|
|
Skier posted:"In typical agile fashion, we've laid out every ticket to be completed in each sprint for the next 12 months." Without asking anyone actually involved in doing the work what needs to be done or an estimate on what it will take for time. What a manager thinks traditional development is: Ticket goes into developer, developer does magic, product comes out of developer in 6 months. What a manager thinks agile development is: Ticket goes into developer and says "sprint," developer does magic, product comes out of developer in 2 weeks.
|
|
#
¿
Dec 17, 2015 09:14
|
|
|
Sarcasmatron posted:Most managers think Agile means cranking out lovely code faster. The last 7-8 years of my career has consisted mostly of having to clean up after failed attempts at Agile. My company has recently begun doing actual agile development. After one sprint, some of the management is upset that we're no longer committing every developer to three separate long-term tasks each, tasks that in the past have dropped into the next "sprint" half a dozen times before getting completely done. What we did commit to last sprint, we (mostly) got done, with more and better testing than we have in the past. We're not doing any less work, we're just focusing on the few highest short-term priorities so that when priorities change we don't have to stop in the middle (or in the first or last 10%) of something else. That last sentence is EXACTLY what Agile is for. The management would rather we just keep making GBS threads out inadequately-tested, buggy garbage because it looks like we're doing more that way. Classic American short-term business strategy: present our customers with an ever-increasing pile of annoyances and almost-adequate features until they get fed up and fire our asses. Fortunately despite their complaining they seem to be willing to let us run with this a while and try to smooth out the process and address the problems. I will say that I love the work environment once we get the managers out of the room and the devs can work together to break out the work items into individual tasks. The product owner and project managers need to stop with the "I'm concerned that we aren't doing enough, we have this deadline and this deadline coming up and we promised this customer this and that" rhetoric, and actually trust the team to organize and know what we can actually get done. If that happens, the whole process should be pretty nice. The passive-aggressive pressure doesn't help anything at all.
|
|
#
¿
Dec 17, 2015 23:37
|
|
|
Volmarias posted:Imagine if they threw a meeting, and nobody came? I can imagine it easily: they would abandon agile and go back to giving us commands and hard deadlines and generally involving us in the decision-making process as little as possible. I'd rather the devs continue to have the opportunity to organize our own work, because so far that part of it has been a really positive experience for us. Axiem posted:One of the things that I really like about where I work is that management is completely on-board with taking the time we need to make things right. As an agile shop, we try to work closely with our client and if new priorities come up, they jump to the top of our kanban, and we still try to provide some value with each story. But once we start a feature, we want to finish it and finish it right, and our management will fight for that as much as they can. I feel like we have a chance to get to where you are, it's just that we're just starting to try it the Agile way and not everyone understands the details or the advantages. They just see fewer items on our board than they used to, so they're worried. The reality is that we weren't getting anything more done before than we are now, we just had a bunch of assigned tasks that kept getting put off. And in the meantime we aren't feeling so goddamn pressured (except during planning, when they pressure us to commit to more. But the rest of the time during the sprint, way less pressure).
|
|
#
¿
Dec 18, 2015 08:55
|
|
|
comedyblissoption posted:How are Agile sprints and commitments in a software development context sane in any way? I'm no expert by far, but I've been digging into lately to try and help my company do it in a useful way. The point of the two week time period is to get a regular feedback loop going, where you can show the stakeholders something and the stakeholders can tell you that yes, this is exactly what we wanted when can we have it, or no, this isn't what we wanted, or it's what we wanted but now we see it we don't like it. It doesn't even have to be a complete feature, maybe the feature was too big to be completely done in 2 weeks. But you can probably build some piece of it in that time, so the stakeholders see it and play with it and tell you about their experiences. It gets you into a rhythm, a pace. Instead of changing the estimated time to deliver a particular feature or product, you change(break down) the features so that they can get done within a pre-defined time period. As teams work together under this constraint, they will naturally develop the ability to estimate and break down tasks. At the end of a sprint, you stop work, you review, get feedback, and re-prioritize. The scrum guy we had come in to our office to help us understand this said it's not about getting work done, it's about the ability to steer. If a particular item doesn't get completely done, for whatever reason, it just goes back into the product backlog and gets re-prioritized with the knowledge that work has already been done on it (so it's either smaller or the team knows more about it and will be able to break it down into sprint-length stories better this time around). But again it's possible that someone will have changed their minds or other priorities supplant it anyway. That's cool, only spent two weeks on it anyway.
|
|
#
¿
Dec 23, 2015 07:26
|
|
|
I should mention that I'm not sold on scrum. In particular I'm not fond of the meetings that bookend each sprint - they're long and tiring and in my specific case our product owner is not fully participating, which is kind of a problem. There are reasons, but I know this will need to get addressed or this process won't work. Regardless, I want to give this methodology a real chance; a couple of sprints, especially with the holidays as a factor (and they are), are not enough.
|
|
#
¿
Dec 23, 2015 07:46
|
|
|
Destroyenator posted:Not meaning to pick on you Che Delilas, you do sound like you've got the right idea... Don't worry it doesn't sound like you're picking on me. The good news for my situation is that pretty much everyone agrees where the pain points are right now (mainly the product owner). Once we lock down the sprint and get the management out of the picture, it's really great because as Destroyenator said we know exactly what we're going to be working on and it's not going to change for two weeks unless an emergency happens. Mostly (there are certain recurring tasks that a couple devs need to take care of but we did take that into account during planning). We've already identified things we could be doing better in terms of communication and organization. In my book that's a success already. I honestly don't think we're doing too badly at this considering it's only been a couple sprints and it's the holidays which means people are bouncing in and out more than usual.
|
|
#
¿
Dec 23, 2015 18:06
|
|
|
ChickenWing posted:My project is actually experiencing this sort of issue as well - our teams are agile, but our backend is still operating waterfall. Thus, when we say "oh we didn't anticipate this in requirements let's ask backend to update real quick" backend says "no changes without a CR and also we're not touching that feature for another three months so uh get hosed I guess?" At my company, marketing doesn't know what the gently caress anymore. They keep wanting to do our same billing for features and give customers promises when it comes to delivery dates that they always have. We haven't done a great job of communicating that we need to work WITH the customers (and probably change our contracts so they take this incremental development into account), rather than just saying "we'll see you in X months." It really is just forcing people to see reality though. It doesn't matter how many months we work on a thing; if we deliver it and they hate it, we're just going to have to make changes and either charge them more (makes the customer hate us), or just fix mistakes and fold that time into the original price we promised (makes the business hate us). I'm really on board with the idea of having the customer be an active part of a continuous feedback loop. At least we don't have one layer of development roadblocking everything though, that sounds hellacious.
|
|
#
¿
Jan 5, 2016 01:12
|
|
|
He's probably thinking of scrum, which is paradoxically pretty rigid during the sprint. But those sprints are short enough that if priorities do change (and they will), it doesn't screw up big plans and deadlines that were set months ago that are still months away. And yeah, it's really great to be able to tell a manager that you aren't going to drop everything and do this big mental context switch just because they found a bug. If it's an emergency we'll cancel the sprint but otherwise put it into the product backlog, prioritize it for next sprint, and let me get back to what I'm already working on. Che Delilas fucked around with this message at 01:20 on Jan 16, 2016 |
|
#
¿
Jan 16, 2016 01:17
|
|
|
Cuntpunch posted:Agile is communism - seems pretty reasonable on paper - but introduce actual human fallibility and it's a clusterfuck. I like the Agile experiment we're running at my company overall for one particular reason - once the planning is done and we actually start the sprint, management gets out of the loving way and lets us work. Most of the time, at least, and if they do start meddling we can politely tell them to butt out. There hasn't been any blowback on us for that so far. It's pretty nice being able to decide how much we can get done and how we get it done, entirely on our own.
|
|
#
¿
Jan 22, 2016 22:17
|
|
|
Largo Usagi posted:But wait for a time leadership will pat themselves on the back and be tell each other, "We did a thing, YAY" And then they will realize there is less of a need for them to be around for development and will try to interject themselves into the process and gently caress it all up. I have seen certain personalities believe that a project will fail without them baby sitting developers for 3 weeks straight. The management at my company doesn't appear to have that particular personality issue. That's not to say it's perfect; my boss for example tends to thrive under stress and exudes this aura of mild panic when something goes wrong. But he also generally responds well when we tell him to back off (politely) and let us deal with it, as long as we keep him in the loop.
|
|
#
¿
Jan 23, 2016 06:06
|
|
|
Finster Dexter posted:I see what you are saying, I think, and yeah, you're right. So, in setting up a PO, Dev needs to establish that they're the department that decides when and how things are worked on, then. Which I also believe. I would argue that the developers and the PO are somewhat separate (in particular, the developers decide how they're going to get something done), but in general, yeah. The PO, or more to the point, a single person, needs to have the authority to be the final say on priorities, and management has to agree that once the team chooses what it's going to work on, that it's not going to change until the end of the sprint (barring extreme emergency). Otherwise the devs are going to just get jerked around by various interested parties and will never get to concentrate on anything. That doesn't mean the PO can't get it wrong or get called to the woodshed by executives if he prioritizes poorly. But if he's doing that he's not doing his real job, which is communicating with stakeholders and with his own company's management and developers and figuring out what the product should BE in the first place.
|
|
#
¿
Jan 29, 2016 22:17
|
|
|
Virigoth posted:Why the hell didn't you leave? I leave / disconnect when the 15 minute meeting time expires. If a manager is running a 60 minute "standup," they do not understand Agile. Therefore, they will not understand an employee walking out of one of their meetings after 15 minutes, and will likely reprimand the employee. gently caress, if a manager is running a standup at all. My boss likes to come in to ours uninvited, but at least he's learned to mostly keep his mouth shut during the thing and ask questions of specific individuals afterwards. Che Delilas fucked around with this message at 03:11 on Feb 3, 2016 |
|
#
¿
Feb 3, 2016 03:06
|
|
|
My current company does not do any kind of time tracking, even just taking rough metrics of our sprint velocity. I feel like this is going to bite us eventually but for now it's nice just getting things done and moving forward with our products without everything being tied to time. My last company (my last boss, honestly) required I keep track of hours worked on every project, in an excel spreadsheet emailed weekly. He absolutely would not accept a total of 8 hours worked on projects in any given day, because people take breaks and use the toilet and otherwise are never head-down writing code for 8 hours in a given day. The whole thing was a trap. He was looking for a reason to not give me a raise next time I asked for one, and what could be better than written evidence. Sounds paranoid, I know, but it wasn't the first time he pulled garbage like that. The whole thing was a waste of effort since I was already 90% out the door and quit soon after.
|
|
#
¿
Mar 6, 2016 23:32
|
|
|
Forward: I'm using the word "task" here when what I mean is "story." We had a sprint recently that we did pretty poorly on in terms of delivery, for a few reasons: 1) We didn't know enough about the existing code for one of the tasks. I had taken a brief look before planning and thought it would take a certain degree of effort, but once I really started digging in to the existing code, there were a lot of little gotchas and branching paths and otherwise things I had to account for, and it is closer to twice as much effort as I expected. 2) We didn't leave any room for bullshit. Meaning, emergencies, outages, and questions/problems from Support that we have to go digging for. Something happens every week and we just need to leave room in the sprint to account for it; when we've done that in the past it's worked out really well. 3) General overcommitment by the team. I said right out that <set of tasks> was my entire sprint, that I was personally full up (I'm basically the only one who works on a particular layer in our team). Team then takes more tasks, some of which require my contribution. I mostly blame our product owner for 2 and 3. His refrain in planning is "I want you to take more of these tasks." We need to start telling him to pound sand but I would like it if he trusted us to not under-commit out of laziness. #1 is the big bugbear though. When we figure out a task is significantly larger than we expect, we should get back with the PO and work out how to break it down and which pieces should get done this sprint and which can be put off. Either that or we don't start a task until we understand it and the relevant systems well enough to estimate and partition it more confidently. Which would require committing to fewer tasks so that we could perform said investigation (or make investigation tasks which go against the whole "deliverable" goal of a sprint item).
|
|
#
¿
Mar 9, 2016 10:19
|
|
|
necrobobsledder posted:At my last job I was the scrum master and I squeezed in more than just status updates and the usual YTB (yesterday, today, blockers) because our daily standup was basically the only meeting my team members had on their calendars for the day usually, so I didn't feel too bad for a fully remote team of 6-7 to extend into 30 min when it might be the only social interaction they have the entire day besides maybe 5 messages in Slack or getting bombarded by customers asking for help troubleshooting a mundane issue. What I found really ate up time was basically one or two people that are just really chatty, but again, if that's really the only social interaction your team gets typically for structural reasons I don't think it's a big deal to bump into 30 minutes. I have a problem with the first one because the standup is just for the team to update each other on what they're doing from day to day. You should limit it to the three questions so everyone who doesn't need to hear whatever else you want to talk about can leave and do work. That's what my team does; we say "okay thanks, standup over" and then whoever has issues can talk about them, either in the current room or they get together in their work areas or whatever. The second one, people were missing the point. You never have "no updates" unless you didn't do any sprint work yesterday and don't plan on doing any today. Those three questions are not hard, and they should always be answerable: "I worked on Story #3 on The Sprint Board yesterday, I will work on #3 today as well. I am blocked by our subscription to one of our key 3rd party web services having expired, can't finish until it gets renewed."
|
|
#
¿
May 10, 2016 18:41
|
|
|
KoRMaK posted:One place I worked at gave the squekers from dog toys to everyone. And we literally stood up. If someone was getting off topic a light squeak could be heard, and as others realized what was going on more joined in until the original derailers are almost defeaned with squeaks. Yeah we had a doll with a voicebox that you could squeeze for that purpose. But when our scrum master quit and they asked me to quasi-take over until they got/promoted a new one, the first time I tried to keep things on track (in planning) I apparently made somebody so butthurt that I got called into the boss's office later over it. I didn't use the doll either, I just said, "hey I think we're getting a bit off topic here, let's take this outside planning" but apparently that was a white glove to the face for at least one of them. So next time I'm just going to let the same two people who always get off topic argue with each other for 40 minutes while the other 13 people jerk off or (like what happened this time) get frustrated and leave. Bossman didn't reprimand me or anything, he just mentioned that there were some people who maybe kinda sorta didn't appreciate my enthusiasm or something. He tried real hard to avoid saying people complained about me having the gall to interrupt when THEIR ISSUE WAS BEING DISCUSSED  but that's what he meant.Seriously, the argument was such bullshit. There was a story, it was more than a sprint's worth of work, we broke it down into pieces, the pieces got prioritized, we pulled one of them into the sprint, and we moved on. 2 hours later one of the stakeholders pipes up with, "wait why aren't you doing all of this thing at once?" and somehow that turned into 40 minutes of arguing that I was not allowed to stop (because one of them was a manager and THEY wanted to talk about it NOW).
|
|
#
¿
May 10, 2016 23:17
|
|
|
ChickenWing posted:I'm using HipChat at my new place and I've had zero problems with it, plus it's got neat integrations with other Atlassian stuff (or so it seems, maybe it's just cleverly contrived). Not that we use it much anyways, we're set up in a bullpen style environment so we just go talk to people if we need to Regarding the bullpen: I'm curious as to how well that arrangement can be done. How loud does it get? Are there any marketing/support people with you (or really anyone with a desk phone, that's my normal metric for "will this person be a constant source of disruption for me?) or is it just devs in the bullpen? Is there a cultural understanding that discourages full-volume conversations? Alternatively, are there enough quiet spaces in you can escape to when you?
|
|
#
¿
May 16, 2016 15:55
|
|
|
ChickenWing posted:If you're the kind of person who loses concentration if anyone talks near you, you'd definitely need headphones. I am, for some definitions of "talk." Some people can hold conversations in the adjacent cube and I don't notice (I do use headphones but I keep those quiet too). Some people talk like they're in an auditorium without a mic, no matter the context, and it's THOSE people I want to strangle. It sounds to me like I could live with such an arrangement, as long as there were an understanding that people don't try to talk to the back of the room.
|
|
#
¿
May 16, 2016 21:00
|
|
|
necrobobsledder posted:Then comes the question of what kind of varnish and then the wood should be. Wood? I don't want to use wood, we need something sleek and shiny (or alternatively concrete and steel beams with construction markings still on everything - gotta keep trying to convince people that Industrial Modern isn't a lovely design for new construction!).
|
|
#
¿
May 27, 2016 08:05
|
|
|
Munkeymon posted:That doesn't sound like it'll satisfy the "Green Construction" bullet point in the mission statement The more stone and metal I rip out of the ground and spend energy to process, the fewer precious trees we will have to cut down!
|
|
#
¿
May 27, 2016 15:42
|
|
|
Khisanth Magus posted:Well, I don't think we will have any problems getting the most important one with a 100% inflexible date done with at least a week where we can test the hell out of it. The thing about all of these things is that none of them are particularly hard or complicated. So I don't think we are being thrown under the bus for this. The one thing you need to do is make it clear that you are doing this work and not let her swoop in and take any credit for it. She didn't "do the hard part" or "lead the team to accomplish this goal" or any of that poo poo.
|
|
#
¿
May 28, 2016 17:49
|
|
|
ratbert90 posted:The sheer amount of programmers that program in C/C++ that have absolutely no idea how memory works is mind loving boggling to me. That's the stuff that you can use with the star key right?
|
|
#
¿
Jun 28, 2016 16:51
|
|
|
Edison was a dick posted:There is a point in there, that it's an effort trade-off on effort spent writing and updating tests when your program changes vs fixing bugs because behaviour changed unintentionally, and that requiring tests reduces development momentum, but I've seen first-hand what the logical extreme is, and once the program gets big enough that it can actually do anything useful, development stalls because without tests everything is always broken. It's not just that everything is always broken. You can fix things that you know are broken. The real hell is all the poo poo that MIGHT be broken, and maybe you don't find out until a customer runs an end-of-month billing report and finds massive discrepancies. If you change something deep in the code base and it doesn't have excellent unit test coverage that defines its expected behavior, you can't have real confidence that you aren't going to break something, especially subtle things.
|
|
#
¿
Jul 7, 2016 08:11
|
|
|
HardDisk posted:Don't get me wrong, I love to goof off, especially on Mondays. And I don't mind being not excited about my job, but I would have liked to be excited enough to come home and put some of my ideas for projects in practice. As it is, I literally come home home, sigh and just proceed to jerk off the rest of the evening. Look man, don't be upset that you don't feel like coming home and coding for 6 more hours after coding all day at your job. By the time I'm done at work my brains are usually leaking out my ears and I simply don't have the mental energy left for any more programming, despite having things I'd like to make. More importantly, I'm certain that if I forced myself to do it anyway, I would burn out extremely rapidly, and my personal projects would probably be mostly poo poo code anyway. It even applies to the end of the day at work. One of the best things I've done to improve my own code quality is learn to recognize when I'm running out of gas and stop before I commit something that's going to shatter the world if it goes live. If that means I stop coding after 6 hours, so be it (I usually have more than that, just sayin). As for your vacation, it usually takes me a bit longer after a vacation to spin back up than it does after a weekend.
|
|
#
¿
Jul 26, 2016 04:16
|
|
|
necrobobsledder posted:But because most business owners don't care about worker productivity as much as output, almost everyone will take the integral of the productivity curve and only ask you to stop once productivity is 0. And because exempt workers officially only count as 40 hours, "productivity" goes up. The exceptions are basically government and the actually decent places to work that miraculously stay in business despite horrific rear end in a top hat competitors that make Hitler and Stalin look like hippies. Productivity only goes up if nobody checks in garbage near the end of the day that takes hours to remember and hunt down and undo, or that gets through your lax or nonexistent QA process and goes live. It's not just that business owners don't care, they don't realize (or believe in) the above scenarios. That's because business owners by and large think of us as factory workers making widgets, and if they can get us to push button A and pull lever C 20% more times during they day, they'll get 20% more widgets. For FREE! Also intangibles like morale and risk and retention require actual thought to estimate their value, so the idiot managers will fall back on the obvious, like TIME_SPENT_IN_CHAIR. I'm lucky in that my boss is pretty good about not doing that, and the freedom is something I'll be loathe to give up in future jobs.
|
|
#
¿
Jul 26, 2016 05:55
|
|
|
Cirofren posted:I used to be at a small web dev shop and the owner/manager would give you a talking to about "what you could do differently" if you showed up at 09:02 instead of 09:00. At the same time he'd work from home and then expect everyone else to be as motivated about his business as he was. Last job I literally got written up for punching in at 9:00 on the dot because "that means you are late to your shift by the time you get to your desk." Yes, I was salaried, yes, salaried people had to punch a loving time clock (okay we used our badges on a digital device but let's be real, it was punching a clock), yes, I had a "shift" as a software developer, and no, I did not answer phones or do real time tech support or otherwise have any responsibilities that relied upon me being in a certain place at a certain time. Current job is the polar opposite. Today, I'm working from home because I didn't get enough sleep and feel kinda crappy. And everybody is loving fine with that. 
|
|
#
¿
Aug 5, 2016 18:14
|
|
|
PT6A posted:How do you get up to 10KLOC in a single class unless your design is extremely subpar? You answered your own question.
|
|
#
¿
Aug 26, 2016 19:35
|
|
|
jony neuemonic posted:Yeah, I've been adding a pile of tests to the legacy code I inherited despite getting a lot of "That's not really part of the ticket..." because I have to verify that I understand this undocumented mess anyway so we may as well get some lasting benefit from it. A good argument for this is that it is a part of the ticket. Because an implicit part of every ticket is, "... while preserving the rest of the expected behavior in the system." Tests are a great way to do that and as you said they make everything easier when you have to revisit that section of the code. It's tough to stand firm when you're under management pressure to get a fix out the door now now now don't worry about making it perfect also let's skip over some of our deployment steps the client is calling every day oh god. I like to invoke past incidents to get them to back off. Like the time we had a stubborn bug in one section of our system. A really smart dev thought he had a solution, so he coded it up a change and did some basic manual testing and rolled it out as a hotfix. Phones started blowing up, oops one of our major clients (who used a different configuration than the client who had the original bug used) suddenly couldn't use the system. Okay roll back and dive back into the code. Repeat several times, until the dev got fed up and put the kibosh on more hotfixes until he was able to refactor and write better tests. The original logic was so arcane and so deeply rooted in so many parts of the system that nobody understood it and any change had the butterfly->hurricane effect. It's still pretty bad, but at least there are SOME tests around it.
|
|
#
¿
Aug 28, 2016 19:25
|
|
|
Vulture Culture posted:A lot of developers have problems internalizing the crazy idea that testing gets a lot faster when you actually get, you know, good at it. A lot of developers have probably also worked with nothing but giant balls of yarn as their dependency graphs for their whole career. "Writing tests takes too long and they take too long to run, because I have to set up the state of the database JUST SO and I have to get real data <here> and <here> so that the third party API calls will return the right messages." Just writing testable code is a skill people don't realize they don't have.
|
|
#
¿
Aug 29, 2016 02:13
|
|
|
KoRMaK posted:im so confused about writing tests first The only signal we care about in this case is "does the test pass?" and otherwise we aren't going to notice it. The benefits for him is as he described, though there's definitely an argument that can be made for leaving out the ones that are always going to pass as long as the class compiles successfully. Still, it doesn't really do any harm to the system. Even the seemingly trivial stuff can be useful, because if you make a change and a "trivial" test starts failing, you know you done hosed up.
|
|
#
¿
Aug 29, 2016 07:38
|
|
|
Gounads posted:I've certainly had the experience of seeing my name pop up after angrily typing in 'git blame' If you're diligent you can prevent that from ever happening.
|
|
#
¿
Sep 30, 2016 17:19
|
|
|
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
|
|
|
nelson posted:What does ITIL stand for? A bunch of horseshit bureaucracy.
|
|
#
¿
Oct 14, 2016 08:33
|
|
|
kedo posted:A company that thinks putting something like that in a contract is a good idea is going to be terrible to work for regardless as to whether or not they'd strike it. I conditionally disagree with this statement. Contracts and employment agreements are generally products of HR and Legal. Legal is Legal wherever you go, they're going to be as broad and weighted towards the company as they think can get away with. HR is almost always lovely, the question is how much power they have. Strike the clauses you don't like, see what happens. If they are fine with the alterations you're probably okay (you know, as long as your manager/co-workers aren't horrible but hopefully you twigged to that during the interview). If your prospective manager comes back trying to argue in favor of them, or if they come back saying something like, "HR has overridden us," then yeah, probably a terrible company to work for (meddling HR is a nightmare).
|
|
#
¿
Nov 3, 2016 04:38
|
|
|
Just bitching a bit. We have lots of features to build, and naturally these tend to get priority over everything but the show-stoppiest of bugs. There are some bugs that generate a lot of error logs and subsequent alerts, but that don't result in any customer complaints or performance problems, so naturally they don't get a lot of attention from the people who are prioritizing. Lately one of the managers has noticed these alerts. He recently complained to me that these alerts are getting ignored by the developers. I reminded him that we have a feature backlog and constant pressure to get all the features done now why aren't they done now everything is highest priority now now now (I phrased it more diplomatically, but that's the basic situation). He indicated that these alerts should be annoying us and that we should want to fix the problems generating them. I said we do want to fix this poo poo, but we don't control the priorities, are you saying we should just decide on our own to let a prioritized and committed task drop from a sprint and work on something that we want to work on? He is apparently used to working at companies where devs would just take care of this stuff because it annoyed them. Dude does this kind of thing all the time: doesn't say straight out that yes, he wants us to work longer hours so we can cram in 'unsanctioned' improvements along with getting our official work done (as if that would ever be appreciated without them adding a "well if you had time to do this random thing why didn't you take the next highest priority from our backlog instead?"). He just talks about what would be nice, what he's "used to," what we as devs could be doing, and then when nobody decides to work a 12 hour day, acts like a disappointed parent. He clearly knows that if he mandates anything or makes his expectations official, people would jump ship, because this company doesn't pay well enough and our product isn't inspiring enough to get us to sacrifice any more of our lives to it than we already do. So he instead resorts to these indirect pressure tactics to get us to feel bad about not doing more. It's really irritating, and while most of the time I can more or less ignore it, this has not been a good week and it's sticking in my craw.
|
|
#
¿
Nov 10, 2016 01:47
|
|
|
HardDiskD posted:You mean it's an optional team building thing and they can build whatever they want for their own personal gain with lodging and food provided by the company, right? http://forums.somethingawful.com/showthread.php?threadid=3607482&userid=0&perpage=40&pagenumber=83#post467207871
|
|
#
¿
Dec 12, 2016 03:54
|
|
|
Just kludge something together; chances are nobody's going to give a poo poo until a new dev comes in who will want to rewrite it in the newest framework of the month anyway. Only half joking.
|
|
#
¿
Dec 16, 2016 00:22
|
|
|
Pollyanna posted:We are Tools, and we GET poo poo dONe
|
|
#
¿
Dec 16, 2016 20:19
|
|
|
|
| # ¿ Apr 27, 2024 19:38 |
|
|
I'm getting dragged into more meetings lately and they're getting more and more pointless. I'm the "interim" scrum master on a "temporary" basis for the last year, which mostly just means I run the standups and am essentially the team lead (though I'm not getting paid any more for that responsibility HA HA HA HA HA). So the real managers with manager salaries schedule me for worthless meetings. The latest one I was scheduled for is an hour to talk about an upcoming requirement. This is easily the most "this meeting could have been an email" meeting yet, in fact the description of the meeting contains everything they'd need to write a goddamn story and get it into the backlog with everything else. Getting real sick of it. I'm actually going to talk to the guy who scheduled this and see if I can stop it from happening; at the very least if he can't provide me with a compelling reason that I need to be there before it actually becomes sprint work, I'm going to just put my foot down and not attend. I've been flexible about these things but I can only go so many days without touching a line of code before I hate everything.
|
|
#
¿
Dec 28, 2016 11:52
|
|