|
Our product owner is also our chief sales engineer, and he spends most of his time doing the latter. It's not really his fault, he was a sales engineer before we started on scrum and they just dumped another full time job on him; of course he's not going to give it the time it needs. But our stories were bad. Our stories were just broad product roadmap objectives that we would have to break down enough to at least think about, during the planning meeting. There were never any acceptance criteria, and nothing was even prioritized correctly. As in, every planning meeting the product owner would change priorities on us, usually after we had nailed everything down. Because he never did product owner poo poo every day like product owners are supposed to. All this made planning excessively painful and frustrating, to the point where I was afraid we were going to lose some of our most experienced people because they really don't have to put up with bullshit if they don't want to. That's changed lately; the rest of the product team has recognized some of the problems and have spent a lot of time the past couple sprints grooming the backlog. They will go through and create well-defined requirements, to the point where they're basically user stories that we can work on and show during review. They will send poo poo that's too vague back to the product owner and get something reasonable. They talk to us ahead of time to get our opinions on things, before planning (the way the product owner is supposed to), so they can come up with decent stories. This effort on their part has turned sprint planning from something I intensely dread to something that's, dare I say it, productive. I still don't like it, it's a long-rear end meeting and those are always draining, but I no longer come away from it hating everything and thinking about finding a new job. The rest of the team seems much more upbeat about the situation too. The process is still far from perfect, but the difference so far has been night and day.
|
#
¿
Jan 1, 2017 02:49
|
|
|
|
| # ¿ May 10, 2024 10:26 |
|
|
Iverron posted:Did anyone blame the Devs for "missing" things when the stories were quarter-assed? Because that sounds pretty familiar. There was some whining from the product owner about tasks being on the board for such a long time, as if he expected vague epics to get done in two weeks just because we were doing two week sprints. But we haven't been officially reprimanded for not getting things done or anything like that. I think that's partly because we do make lots of incremental progress on our tasks (they're just huge epic tasks so at the high-level overview of the product roadmap it doesn't look like it moves very fast). And partly because we're on a skeleton crew and we have approximately 8 years of new development in our "our customer wants this soon" pile, and they know if they start yelling at us about their complete inability to plan or staff correctly, people are just going to get a new gig that at least pays better, and the company is going to be in even more dire straits. It sounds kind of bad writing this out but really the situation isn't really stressful. We are so far underwater when it comes to imminent fetures and overpromises that there's no amount of extra effort we could put in that would even make a significant dent. So it's just, get done what we can get done, and let the business people deal with the consequences.
|
|
#
¿
Jan 1, 2017 21:16
|
|
|
New Yorp New Yorp posted:Yes. Bugs should be prioritized, given point estimates, and assigned to sprints. Ideally, the product owner will agree that bugs come first and that they shouldn't be delayed just to get more new features, especially since bugs tend to beget more bugs and make it harder to implement new features in the first place. We're trying a thing where product gives us their priorities and we then inject stuff we know needs to happen into that list where we think it should go and then pull from that. We will then have a brutal cage match to agree on the final sprint goal. Note that this does not mean we're taking the same amount of tasks from the product team and just piling on more poo poo, product priorities are getting sacrificed as we decide that this bug or piece of technical debt is more important. So far it seems to be going pretty well; we're getting stuff into the sprint that circumstances were forcing us to do (and therefore not just faking it by committing to extremely light sprints just to leave time for us to do "non-sprint work"). Product hasn't bitched at us for not getting enough features into the sprint (yet; we'll see what happens when we try to make the argument that we can't get any features into a sprint because of our crippling technical debt that we simply cannot let sit anymore, that'll be a fun day). Interested to see where this goes.
|
|
#
¿
Jan 4, 2017 03:27
|
|
|
smackfu posted:The tricky bit is that sometimes the people suggesting zero point bugs are also suggesting that bugs should be extremely rare. That most things that passed acceptance criteria should only have features to change them, not bugs. So in that environment, bug points are not that important and whether they are zero on principle or given points doesn't really matter. The one blaring alarm in my head when I started learning about Agile methodologies came from this idea, that bugs were going to be very rare. My first question was basically, "that's nice but what about the real world?" In an ideal situation you might be able to get close to that but how often do you get "ideal?" I'll just go ahead and treat bugs like they exist and require work.
|
|
#
¿
Jan 5, 2017 03:19
|
|
|
Pollyanna posted:"I'm sorry but the reality is that story points ultimately reflect a unit of time and I just won't accept less than 35 points per sprint." All this does is make points meaningless to me; I just dynamically adjust the value of a point in my head so that I can always bring in the "correct" number of points without actually changing the amount of work I pull into a sprint. Incidentally this kind of thing turns me into an active clock-watcher, rather than just focusing on the work, because when they demand this kind of thing they always try to interpret it as you making a promise rather than an estimate, and gently caress putting in one minute of unpaid work for people like this.
|
|
#
¿
Jan 30, 2017 22:56
|
|
|
Iverron posted:My current gig would just say 1 point per dev per day and then schedule 10 points per dev per sprint and wait why is this project behind schedule I've found a problem that most people, devs and management alike, is not taking into account everything that isn't "designing the feature and writing code for the feature." Documentation, testing (and I mean writing unit tests, not dumb testing), communication with stakeholders, deployment tasks, meetings, emergencies, and just general everyday interruptions. "This will take me about a day" usually has an implied "uninterrupted" tacked on, but people don't consciously realize it. Seems that these days most companies would rather run with a skeleton crew, because it's easy to see the cost difference between "3 devs" and "4 devs, a devops guy, a couple of support techs" on the company expense report, but it's not so easy to figure the cost of a feature or product taking three times as long to develop.
|
|
#
¿
Jan 31, 2017 03:43
|
|
|
Gildiss posted:stand-down meetings 
|
|
#
¿
Jan 31, 2017 04:28
|
|
|
Today was "agile".txt Meeting (with people around the globe, so it started... early...) Meeting Meeting (wait when was I supposed to write code again?) Product owner passive-aggressively whining at me about features we're "having trouble" getting done:
For the first complainer, being very generous, 20% of that list qualifies for "things we've been having trouble" getting done, and I don't really feel very generous about this. For the rest, you're the goddamn product owner, you have complete control over the feature priority. If you want us to work on a feature, put it in the backlog somewhere near the top. I haven't even seen some of this poo poo it's been so buried and all of a sudden we're having trouble getting it done? gently caress off. This person is incapable of tact, this is not the first time he's said poo poo that made me start my reply over several times so I didn't put my proverbial foot in my mouth. Second employee's complaining now, the last day of the sprint, when the features we've been working on have been on the wall and in our feature tracking software for two weeks. They had the opportunity to participate/negotiate when we finalized the sprint work, you had the opportunity to look at the work we've been doing every single day since the sprint started and you even come to most of the stand-ups so you maybe should have noticed that nobody was giving status on your pet project. The hell of it is, it is legitimately important and urgent. Only problem is everything else we're working on is important and urgent too, and I don't like being complained to when the inevitable happens and something doesn't make it in. The only upside was that my boss is fully aware of the situation, the reality of our capacity, and is advocating to the complainers on the team's behalf. Also not blaming or holding us to account for poo poo like this, because we're not doing anything wrong. Still pisses me off.
|
|
#
¿
Feb 8, 2017 07:16
|
|
|
COOL CORN posted:"Why should we pay that much for software that will do the work for us? We're already paying you to do it!" "You're paying me to do that, or you're paying me to do all the other poo poo I could be doing for you while this piece of software that doesn't cost nearly what my salary costs does it instead. Also, how the gently caress are you in charge of anything more important that what to eat for lunch if you don't understand what opportunity costs are?"
|
|
#
¿
Mar 2, 2017 22:39
|
|
|
To be more practical: I've had success explicitly enumerating their options when this kind of thing comes up. "Okay, if you want me to do this now, then other projects A, B and C will be delayed by at least X weeks. Does that work for you?" Of course, by "success" I mean "they agreed and then pretended to forget about changing the deadlines for projects A, B and C when the original ones came around." At least until I shoved their email in their face because I got that agreement in writing after they agreed to it verbally because I knew they were a two-faced piece of poo poo.
|
|
#
¿
Mar 3, 2017 00:38
|
|
|
Task to fix bug was prioritized #1 because of looming deadline. Bug symptoms are well-defined but the circumstances to get it to occur are not. I work on bug, reproduce bug, nail down the exact set of circumstances, fix bug. Sprint nearly over at this point, we roll out. Boss complains that this bugfix doesn't fix all the other bugs that may exist with this brand new, hideously complex feature that's barely been tested in a realistic environment yet. I resist the urge to tell boss to kiss my rear end, and instead remind him that if he wants us to work on things, they should be at least mentioned during planning. They were not, this one very specific bug was prioritized and it was emphasized that it MUST BE FIXED BY A CERTAIN DATE, so that's what I focused all my effort into doing. Not, you know, finding and fixing any of the other bugs that weren't in the task at the top of the list. Make things clear when we plan, if you want us to work on more bugs, put them in the goddamn list.
|
|
#
¿
Mar 7, 2017 09:20
|
|
|
revmoo posted:This post just screams systemic issues at your company. Yes it does, and there certainly are, mostly related to communication. We have consistent problems getting things defined, there's always some kind of issue that should have been prioritized right at the top and talked about during planning that we only hear about two days into a sprint. Fortunately when we push back against bullshit they usually listen, and we aren't held to account when too many things are promised to too many customers on too short a timeline without consulting engineers first.
|
|
#
¿
Mar 8, 2017 05:59
|
|
|
My Rhythmic Crotch posted:- "You may be required to work on your time off if business needs dictate it" "And YOU may be required to answer a strongly-worded letter by the labor board, or a court summons. JUST SAYIN" j/k I'd never say that I'd just refuse to work if I were taking time off.
|
|
#
¿
Mar 9, 2017 07:53
|
|
|
Just saw the plan for our post-remodel office layout. Current situation: rows of cubicles with high cube walls at our backs. Noise is a problem sometimes but we don't hear every employee in the office all of the time. I'm sure everyone can make a good guess as to what the new plan involves (hint: the word "collaborative" features prominently). 
|
|
#
¿
Mar 11, 2017 01:48
|
|
|
Vulture Culture posted:At one of my previous jobs I was bothered enough by the proximity to my coworker's conversations that I built walls for my desk out of multi-ply corrugated cardboard and management never had the balls to ask me to take it down They're also putting us right next to customer support, because when they can't figure something out it's too much of a burden to walk 50 feet to the other side of the building to talk to one of the devs (or, you know, send an email or talk to us via Slack which we all have). What's that? Constant ringing phones with no walls or distance to mitigate the sound at all are a nightmare for the devs? gently caress YOU. They actually pushed for everyone using a single monitor because "more monitors isolate you." Dev department head had to kick and scream to get them to back off on that so we probably aren't even going to be able to arrange ourselves in own section the way we want. Shoulder-to-shoulder in the center of the room, basically, and if they don't let us rearrange it ourselves then I'm probably just gone at that point. There's no reason to ignore the devs' input on the layout (especially in our own section, jesus gently caress) this completely if they want us to do actual work. I'm more than half convinced it's pure theater, they're going to bring in some money that thinks they know what a small development company should look like and try to get us bought. God I'm so pissed. Che Delilas fucked around with this message at 05:58 on Mar 11, 2017 |
|
#
¿
Mar 11, 2017 05:49
|
|
|
Volmarias posted:Eject! Eject! They've said it's "not set in stone" yet, and it's at least half a year away, so there may be time for me to conduct a campaign to get them to pull their heads out. I may have to resort to linking to Forbes articles since they don't seem to want to listen to the people that are actually creating the products they sell, but I'm going to give it a try. But if they keep being stupid and insist on taking away a reason I have to put up with substandard compensation? Yeah, I'm out.
|
|
#
¿
Mar 11, 2017 22:13
|
|
|
piratepilates posted:What's so great about this company versus others that you want to stay after they pull dumb moves like this? Right now? It's interesting work, they're flexible about hours (meaning both that we can start & end the day when we want AND they don't bitch about a less-than-40-hour-workweek), we have choices about what we work on (meaning who takes which feature and we can decide to inject our own work into the schedule if it's something we need to do or will help us), all of my co-workers including my direct boss are pretty great people, we can work from home when we feel like it, and the office is an environment that's generally conducive to getting poo poo done. The downsides are substandard compensation and the fact that the product owner is on the other side of the country and very disconnected from the team, which causes minor annoying problems but nothing we can't ignore or work around. Right now the balance of good vs. bad is such that rolling the dice on a new place feels like a pretty low-percentage move on my part, unless another company offered me a stellar compensation package (which hasn't been on the table for the opportunities that have come my way). Now, if my current place does this dumb poo poo with the office layout (which not only makes our lives miserable but sends a strong message about either how little they value the developers, or as I said before that they want to put on a play to potential acquirers), that would tip the scales quite a bit. Hughlander posted:It's nice they're giving you 6 months to find a job like that... I saw the plan at like 5:00 yesterday, so next week I'll be getting some more detail about how much their hearts are set on sabotaging dev productivity. It shouldn't take much for me to figure it out, and if it's clear there's no improving the coming situation then yeah, my plan is to start sending out applications next weekend and have a nice low-pressure job hunt.
|
|
#
¿
Mar 12, 2017 07:29
|
|
|
Volmarias posted:That's... sort of the minimum for a good tech company, not outstanding. I expect all of these things, I don't get delighted by them. Lot of bad tech companies out there though, which is why I have been content (don't believe I used language that implied I was delighted with them) to stay where I am. But again, dark clouds on the horizon.
|
|
#
¿
Mar 12, 2017 12:55
|
|
|
Volmarias posted:Yes, but you can also be content at a place that won't underpay you. Vulture Culture posted:Your goal is to figure out how to filter the good companies from the bad ones, not just to give up and point to the numbers game as the reason why you can't have better. Of course I can have better, but as I keep saying there's risk involved that so far I haven't been willing to take, how is that hard to understand?
|
|
#
¿
Mar 13, 2017 01:04
|
|
|
Volmarias posted:I'll admit that I did end up with that job briefly, but then I got out after less than a year and became much happier (and better paid) at the next one. Welp, had a nice long meeting with bossman and have basically been told that the ship has sailed and that they ignored pretty much all of our needs as devs. It's a political decision, whether that's because they want to sell the company or they just want to be trend-followers doesn't really matter to me at this point. We got one (potential) concession to mitigate visual distractions in the form of medium-height walls between our individual work spaces, but nothing to help with the noise. To add insult to injury, they're spending a LOT of money on brand new furniture (we have pretty drat good desks already), again all for the sake of appearances. No money for market rate salaries though  None of this is happening until the end of the year. So as someone else already suggested, at least I have a nice number of months to find a job that will pay me significantly better, even if it's also in a boiler room. And I'm starting the hunt this weekend. Screw this.
|
|
#
¿
Mar 13, 2017 21:25
|
|
|
Product team: "Can we start using points instead of sizes so we can better measure velocity?" Us: "Okay but we've tried this before and it was a bookkeeping headache and it was used by management to ask questions like, 'You got less done than last time, why didn't you do better?' and 'You did X points last time, can't you pull in more stories this time so you can do X+5?'" Product team: "We promise we won't do that, it's just so we can plan better, pinky swear." I'm sure you don't need to read the rest of this post, but here it is. [Sprint 1] Product: "You got X points done, cool." [Sprint 2] Product: "You only got X-Y points done, you underachieved this time." Wow two whole data points and you've already got a perfect bead on our velocity, eh? Oh, also 
|
|
#
¿
Apr 6, 2017 00:44
|
|
|
Clanpot Shake posted:Not keeping the test means you trust
|
|
#
¿
Apr 10, 2017 01:19
|
|
|
KoRMaK posted:Here's a dumb thing I made because I've been watching too much game of thrones Rollout Is Coming™
|
|
#
¿
May 5, 2017 21:54
|
|
|
We released a UI update to one of the sections of our product last week. This update has been in development for at least a month and a half and has been shown in review at least three times and has received praise and some feedback each time. Today one of our pro services people saw it and said it looks retarded. Someone from pro services has been to each review where this update was shown and they had ample opportunity to comment on the way it looked and how the current version was used. They did not. We took issue with this. Edit: What really burns me is that there is something we can do to make the situation better: we can get these features onto a UAT environment earlier, because it's hard to get a feel for new poo poo when it's just being shown to you. But what's going to end up happening, and I KNOW it will happen, is that we'll spend the extra effort to get it onto the UAT environment and tell the rest of the company exactly what's updated and how they should get to it, and they just won't. They're not going to bother. At least if we do that we can tell them to pound sand if they bitch after it goes live. In any case they were way over the line with their comments today. Che Delilas fucked around with this message at 06:50 on May 12, 2017 |
|
#
¿
May 12, 2017 06:46
|
|
|
Plorkyeran posted:Yeah, it's always a little offputting when you finally ship a feature that people have been regularly asking for for years and the only reaction you get is people no longer complain about it not being there. This kind of thing happens all the time - also when some customer throws a pissfit every week for a feature to be delivered and when you do they don't actually use it for 3 months or they haven't even gone live on their end yet so the urgency ended up being completely artificial. I've learned to focus on internal sources of satisfaction rather than external. Customers are going to gently caress up, they're going to delay, and they're going to generally not appreciate your work, particularly in proportion to your effort. They're certainly not going to appreciate important yet not-flashy things like validation, robustness, and infrastructure improvements. They're certainly not going to notice when you pay down a piece of technical debt. Most of the time the best you get is a reduction in the number of support tickets. But dammit, when I track down and fix a bug that has caused small but significant inaccuracies in our reporting that have existed for years, or if I make it easier to add new hardware integrations to our SAAS offering, I'm goddamn proud of myself and I don't need <Random CTO for Douchebag Customer #7281> to tell me that I'm doing a good job.
|
|
#
¿
May 24, 2017 19:27
|
|
|
Pollyanna posted:I read about the can-ban on LinkedIn this morning. I would like to requisition one (1) can-ban for the team with plans for deploying it to the rest of the office tomorrow. It must be Agile and password-protected. I don't want any hackers hacking our service-oriented architecture. The most important part is that you have a good keikaku*. *keikaku means plan
|
|
#
¿
Jun 6, 2017 18:49
|
|
|
Pixelboy posted:Compared to....? Probably compared to what we've heard/read about Amazon.
|
|
#
¿
Jun 9, 2017 22:57
|
|
|
necrobobsledder posted:Personally, I make less than I did in 2013 because I moved to a different region and because I switched industry verticals away from rent-seeking companies. We're expected to write unit tests for our own code at my company, not each other's, but we don't have any dedicated QA staff and we do functional testing for our own poo poo and sometimes each other's. It works out one of two ways. 1. Your team (all devs) writes enough tests and do enough code review and QA so that releases land fairly well, and people (sales/marketing/product management) complain you aren't getting enough done. 2. Your team skimps on testing and QA to get more features out the door, releases faceplant regularly, your customers become your QA department, and people (customers/customer support) complain you keep breaking their poo poo. Whether 1 or 2 wins depends on the clout of the people involved, and how long it's been since you had a particularly bad #2 (HEH). At my company we tend to lean toward 2 because we have a million features various people want at any given time. As devs we don't really get any direct flak for problems that stem from this way of operating. At most, our direct boss asks us how we can be better about the quality of our releases, and the answer the entire team gives him is always the same: We need to slow down, and we need QA from people who don't know the minute details of a feature's implementation, because we have an inherent, unavoidable bias and don't WANT to break our own code, as much as we realize it has to be done. Even without blame, it's a source of constant, low level stress for most of us, myself included. I wouldn't recommend 'understaffed with no plans to change that any time soon" when looking for an employer, in general.
|
|
#
¿
Jun 27, 2017 03:23
|
|
|
Plorkyeran posted:The ability to take as long as I feel I need to get something into a shippable state with only rare deadlines is definitely one of the things I really like about my current job. Meanwhile: "Hey Che I know we talked about slowing down and doing more deliberate release cycles with builds on UAT/staging environments for a certain amount of time, but we want you to release this new feature as a hotfix because customer wants it and will be annoyed if they don't have it (i.e. The situation for every customer and stakeholder on the planet that will exist until the heat death of the universe)."
|
|
#
¿
Jun 28, 2017 01:03
|
|
|
Jo posted:If I switch things up and point them at a node directly instead of the load balancer, all the requests magically work. Between that and the intermittent nature of the failure, it seemed pretty compelling evidence that there was something FUBAR'd with the load balancer. Again, though, OPS is very insistent it's fine and the problem is in our application. As Gul Banana said, if you've already eliminated your code as a variable and Ops is still refusing to help, then the only way forward is to go over their head. They're blocking you and you can't proceed with this functionality until they fix whatever's wrong on their end. Keep in mind they may have legit reasons for not helping right now but if that's the case they still shouldn't be telling you it's your fault.
|
|
#
¿
Jun 30, 2017 08:37
|
|
|
lifg posted:So does version control, dev environments, testing, release tagging, security, compiler warnings, passwords, locking your car door, wiping your rear end, and bathing. Ask me about my revolutionary 10-step plan to speed up your whole life!
|
|
#
¿
Jul 20, 2017 21:33
|
|
|
There are a couple people like that where I work but the spend the majority of their time at their desks and don't have constant conversations. When they do though, boy, time to go get coffee or something because you sure as poo poo aren't concentrating on anything. There was a project manager who was in my row that has a "I'm trying to speak to an auditorium without a microphone" volume as his default speaking voice. He rarely talked about work, and almost made me quit. After one day, when he told the same 30-minute story about his broken toilet I'm not even slightly exaggerating to five separate people, I told my boss in no uncertain terms that I was miserable and thinking about leaving because of this guy specifically. I was not the only one who had complained about him - every single person even remotely near him had made similar complaints over the weeks. He was moved to a small office on the other side of the building and life was suddenly and measurably better for the whole team.
|
|
#
¿
Jul 23, 2017 00:10
|
|
|
necrobobsledder posted:One example someone I think at Yahoo gave for why they ended remote working is that they saw from outside a room there were a couple engineers in a large room that started with a question. Another engineer overhears them and chips in and they're on a whiteboard. In another half an hour there's 6 engineers coming up with something. And that something wound up being a new product at the company. Sounds like a case for a decent-sized room with a whiteboard and some open doors, not for ripping out all the walls in the building. It doesn't matter how awesome your whiteboarded ideas and collaborative design sessions are; if there's nowhere you can go to sit down and write the loving code, without being interrupted by everyone else's collaborative design sessions, all those amazing ideas aren't going to get built well or quickly enough to matter. This story pisses me off because of the last part: "And that something wound up being..." It doesn't bother explaining how much work was done by engineers actually building this alleged product, probably concentrating really hard and not being constantly interrupted by phone calls and random conversations other people were having. It jumps from "meeting" to "now there's a new product." It emphasizes maybe 2% of the loving development process. It's like making a case for the whole company just sitting in a conference room all day coming up with ideas - surely if we're all in one room in front of a screen, new products will spring to life fully formed from our collective rear end in a top hat! We don't even need desks! Not mad.
|
|
#
¿
Jul 26, 2017 08:41
|
|
|
My company's main product relies upon thousands of lines of SQL stored procedures with dozens of conditional blocks that all (mostly) terminate with a GOTO FINALIZE_TRANSACTION. Getting in there to modify or add (never remove!) logic always feels a little Lovecraftian.
|
|
#
¿
Aug 21, 2017 22:52
|
|
|
ChickenWing posted:Oh poo poo test implementation looks like it's working the way I wanted it to gently caress yeah demo isn't going to be a complete failure hype hypeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee Repeat after me: "Works on my machine."
|
|
#
¿
Sep 6, 2017 21:35
|
|
|
Keetron posted:I: Then we cannot be [sure] the data is the same. We have been doing it like this for a while, trust us, it cannot be done differently! Argh this statement is so frustrating to read!
|
|
#
¿
Sep 8, 2017 22:36
|
|
|
Portland Sucks posted:What is the relationship between developers and stuff like not knowingly violating CAL licensing when it comes to ethical workplace behavior when your bosses thought process is essentially "oh yeah we know that's bad we'll get to it later when we're not as busy working on actual projects." Would you just look the other way and let the company worry about it? Asking for a friend. This aint legal advice blah blah. The gendarmes over at the BSA would like you to rat out your company forthwith, but seeing as you've (apparently) already raised concerns to your bosses, a sudden raid from the BSA at this point might result in you coincidentally getting fired for "poor performance" or some other vague yet legally rear end-covered reason. Tough call though. For me I'd think it'd depend on how directly it affected me and how blatant it was. I would have trouble running like obviously cracked versions of core tools (visual studio) to do my day-to-day work, but I might not care so much if it was some piece of software installed on a server. At minimum I'd keep raising the concern, find articles about the "true cost" of being non-compliant and send them to your bosses, and generally cover your rear end in paper. I would personally also flat-out refuse to run any cracks or keygens on my work machine if asked; if they want to install software on my box while I'm not there, they can, but I'm not going to do that particular dirty job for them. It's not my job at the end of the day to police the company for software license compliance (unless, you know, I was hired to do that). I highly doubt, though I can't be certain, that I would face legal or financial repercussions for NOT instantly blowing the whistle (and conversely I'm very sure that I would lose my job if the company found out I did blow said whistle). You'll have to figure out where you land on the morality scale. Also you could actually talk to a lawyer about your obligations and risks if it's bugging you enough, a short consultation won't be that expensive for piece of mind, and you might even find a free one.
|
|
#
¿
Sep 10, 2017 01:16
|
|
|
Gounads posted:What is an 'office director' Certainly it must mean a director in charge of the engineering teams in the office, rather than some idiot who keeps the coffee stocked and moves chairs around who has no business making any technical or engineering process decision at all. Right?
|
|
#
¿
Oct 11, 2017 17:51
|
|
|
Rubellavator posted:I know I've definitely seen some db columns at work that contain sql queries, but I tried not to think about what they were used for. Probably used to query a different database with code snippets in it that can be used to generate fully-formed desktop applications.
|
|
#
¿
Oct 14, 2017 07:00
|
|
|
|
| # ¿ May 10, 2024 10:26 |
|
|
I have the ability at my company to configure my dev machine (and corresponding in-development code) to point directly to our live database, and so does every other dev. We have an article in our wiki that tells us how. That article mostly consists of sentences like, "If you are thinking about doing this, DON'T. If you really need to, think hard about it, and then DON'T. If you absolutely, positively need to, talk to the senior devs about it, clear it with the boss, and then DON'T." It's been done a couple of times during my tenure, and only one person has ever wiped out our production database . That one was before my time, but as I understand it, it wasn't particularly fun.
|
|
#
¿
Nov 7, 2017 22:53
|
|