Working in Development: Leaving sounds like a great decision.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›3 »

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Having worked in a couple 'agile' teams, and just this week gotten my PSD I, I feel good saying that the unfortunate fact of Agile in general is that it's a paradoxical management structure more than a development practice. Because for Scrum/Kanban to succeed what you really need are:
-Commitment to the process from the organization as a whole
-A team of qualified, motivated individuals

The problem is that almost every project will lack the first at some level, generally due to politics. And having the latter will likely mean success *regardless* of what methodology you're using to get there.

But since Agile is the buzzword lately, everyone wants to be 'Agile' so they try really hard to cram mediocre developers into their homegrown "Agile but" framework, and things fall apart as a result.

Agile is communism - seems pretty reasonable on paper - but introduce actual human fallibility and it's a clusterfuck.

# ¿ Jan 22, 2016 15:42

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 07:20

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Here's a general question that's somewhat an inversion of my previous statement:

How *do* you make Agile work when there are drastic skill discrepancies amongst the development team? It seems like that's the other thing somewhat inherent to development is that you will have strong talent on one end of the team's spectrum, and dead weight on the other - whether it's for "coast until retirement" career folks or just "if it isn't something I learned in school then it will take me 9 hours to do basic things" or any of the other usual bad-dev tropes.

My experiences repeatedly is that you either end up in a situation where the better devs turn into tacit janitors - let the bad devs write horrendous code, come in as mentors/reviewers/whatever and clean it up. Or you end up with the better devs just getting the work done super quick and the bad devs sit on their hands 40 hours a week feeling left out.

I mean obviously "only hire talented people" is a great answer, but that's not realistic at all, so what's the real-world solution?

# ¿ Jan 25, 2016 14:41

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Messyass posted:

Yeah, TFS has a 'capacity per day' field that works very well for that purpose.

In the end though, hiring talented people is really what it's about. Remember "individuals and interactions over processes and tools"

I haven't yet seen anyone really read that as anything other than "a million meetings, both scheduled and ad hoc, are great because INTERACTING!"

# ¿ Jan 25, 2016 17:45

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

spacebard posted:

Other than pair programming, as a dev lead I made sure to provide technical details in stories (before the story was groomed or estimated). Not a strict blueprint but a general idea as to how a story should be approached. This helped normalize estimation and made other secs more confident to pick up stories on their own. And then I had "office hours" where I was available. This usually reduced my focus to 50-60% though.

On the team I'm on now we are expected to estimate just on the story and hardly review acceptance criteria, in hours, then create sub-tasks on Jira afterward. Seems sort of backwards to me.

The latter is a huge part of my current struggles, almost exactly. We get some reasonably broad "hey here's a feature/bug/etc" and then it's a total crapshoot after that. If it's a bug that's previously been investigated, we tend to have decent analysis notes(depending on who investigated) - but if its a feature it tends to be big-picture and only a couple of us even ask questions looking for specifics. Acceptance criteria? Made up on the fly by the QA team that'll be testing the feature~

# ¿ Jan 25, 2016 19:05

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Finster Dexter posted:

My previous job was running an on campus team of developers, and we had about 6 full-timers, and about 12-18 students. The best student developers were always the Info Systems majors from the business school, because their curriculum spent significant chunks of time creating software solutions for real-world companies in the local area. The IT major guys were usually pretty good, too.

CS majors were good kids, but they could always be counted on to submit pull requests that contained some kind of overengineered, impossible to maintain solution that would be guaranteed to break when faced with edge cases and be super-hard to refactor. Most of my time was spent training them in basic design patterns and un-teaching them some of the horrible habits the CS dept seems to love like monolithic methods and classes, inherit all the things, etc.

Like all a modern CS department would need to do is teach C#/java, basic design patterns, SOLID, algorithm analysis (Big O), RDBMS, and stuff like that. Leave the compiler writing and other stuff to graduate courses, IMO.

Speaking as a self-taught developer who never got a proper education, I'd totally be down for turning DEVELOPMENT into a trade school skill, whereas Computer Science prances back to the land of algorithm theory, etc, in academia. I've met way too many people with Masters of Comp Sci. on their resume who will shout all day about 'Separation of Concerns!', 'Dependency Injection!', and the like, but then ask them to *implement* anything and it turns into a muddled mess because they spent more time memorizing abstract flowcharts describing good patterns, rather than learning the HOW to implement them and WHY to use them in practical terms. "You must unit test!" they cry - then write a unit test where they mock the method-under-test to return string.Empty, then assert that it returns string.Empty - at which point they pat themselves on the back about 'Good code coverage.'

# ¿ Feb 1, 2016 19:44

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Ithaqua posted:

None of those things are part of academia. Sometimes bad developers get masters degrees to try to mask that they're bad.

What I'm saying is that people go so goddamn hung up on these *ideas* without *practical application* that means a drat, that they end up figuring if they can quote SOLID or draw a Factory Pattern, that's all that matters. Want to develop software? Great! It's a cool job! But learn it by *DOING IT* not by *reading about it*. The constant fallback of the bad developer to tropes and terminology just points to me as a failing of spending too much time *reading* about how nails work, rather than hammering wood together.

# ¿ Feb 1, 2016 22:25

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Doh004 posted:

I think I effectively just killed the goddamn title of SCRUMMASTER from our team.

Good riddance.

One of our team members already managed to completely devalue that title because he insisted the person using it was a pretender attempting to take away from his title, Scrum Lord

# ¿ Mar 7, 2016 19:56

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

ratbert90 posted:

What in the gently caress? Why aren't they using git like the rest of the same world?

TFS is a 'scary' thing to move away from when you have a pile of developers who have spent most of their careers on TFS(which tends to be combined in a .NET shop, so tight IDE integration + GUI) and try to put them on not just a jump to DVCS(which itself already requires a bit of re-education) and ALSO lose a lot of that integration. I'm hoping Visual Studio trying to tighting up Git integration will end up making this an easier sell to Management. Right now it's "We are going to have to send the entire development team to a multi-day class to learn this new tool, and we have to migrate projects with years of commit history over to a new repo, and....that's around the point where risk outweighs reward in management's eyes.

# ¿ Apr 15, 2016 23:10

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Someone linked Bob up above, I'll follow up on this conversation with his words of wisdom on the matter:

quote:

I have been consistently disappointed by the quality of CS graduates. It�s not that the graduates aren�t bright or talented, it�s just that they haven�t been
taught what programming is really all about.

[...]

Of course, that�s the most extreme of a series of disappointments I�ve had while interviewing graduates. Not all CS graduates are disappointing�far from it! However, I�ve noticed that those who aren�t have something in common: Nearly all of them taught themselves to program before they entered university and
continued to teach themselves despite university.

An education will make you a *better* programmer if that's your thing, but it won't *make you a programmer*. And I think a lot of what's being described when we all look down our noses at :airquote:

web developers :airquote:

is the fact that there's an entire *breed* of coder who has never HAD to think about memory. Ever. And whose first line of problem solving is 'check stack overflow' or 'maybe there's an NPM package for that', rather than simply *considering the problem*.

Apparently schools these days don't even touch the old languages? It's all Java/Python? Look, I'm self-taught, so I'm one of the unwashed masses here - but goddamn if I don't thank fate every day that I started with C / C++ and fought my way through pointer errors, THEN moved onto languages where I could apply the same *thinking* without having to do the actual code around taking care of my memory.

# ¿ Jun 30, 2016 00:06

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

KoRMaK posted:

You also have to have the drive to want to hack through that, which I don't think everyone possess.

Ding ding ding.

# ¿ Jun 30, 2016 15:11

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

I'm personally a big fan of folks who debug by sticking a stdout-or-equivalent after every single line of code.

# ¿ Jun 30, 2016 16:39

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Vulture Culture posted:

don't knock trace logging, especially for distributed systems

There's benefits, maybe just not first-resort on some of this for your average boring LOB application:

code:

public int Foo()
{
	//Console.Debug("Start Foo()");
	var x = 1;
	//Console.Debug("x = {0}", x);
	x = x * 2;
	//Console.Debug("x = {0}" x);
	//Console.Debug("calling Bar()")
	Bar(ref x);
	//Console.Debug("x = {0}", x);	
	return x;
}

I get needing to do this in some cases, it's just as a goto approach for "hey I've got a weird bug where my app is off-by-one" it just seems so much like overkill compared to either just reading through the code or, maybe, using the debugger.

# ¿ Jun 30, 2016 19:25

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Could the talk about personal projects also be one about *how* he goes about his work?

We have a guy at work who tends to grab a task off the board, disappear into a hole for half the sprint, then finally pop up with buggy, poorly patterned, buggy-as-all-hell code.

I spend a ton of time cleaning up after him, because he's very much the 'personal project' sort of person, loves talking about the random toy he's playing with this week, and it reflects in his work. Every single week it's a new framework, a new style guide, a new library, a new whatever and some side project he did with it. So he will come in and just blindly start replacing libraries with new versions with breaking changes and then leave it to the rest of the team to clean up in his wake when a pile of regressions get introduced.

# ¿ Jul 20, 2016 20:20

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

KoRMaK posted:

Ew, oh my god. Why do you guys enable that behavior?

Management reshuffle means the new boss doesn't understand the team dynamics yet. He's got the contractors with him(because he'll spend 8 hours a day with them dealing with their "could you please show me how to write functions? ok great, could you please check that in for me?") and I'm outnumbered for the time being. The fact that we regularly have "oh hey I just blindly updated a nuget package because Nuget packages are 100% safe to update by major versions and wait what do you mean ASP is delivering assembly binding errors....uhhhh sorry I'm busy looking at stuff can you please fix that?" isn't really understood very well yet.

It's a matter of time, since he got kicked off a different project to join ours because he consistently tended to go "two week sprints mean I can deliver to QA at 2PM the day before the sprint ends!", and he's doing the same thing again. But really wants to push the issue with management to argue about how he is doing *all* the work for the project and he thinks that's unfair. Except that everyone pretty much knows he goes "oh I'm working so hard I'm putting in 4x9's!!! ok it's 10AM on a Friday by guys can't OT!" as he rapidly checks in all his work and suddenly there are bug reports within 30 seconds of anybody looking at it :v:

# ¿ Jul 21, 2016 02:26

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

spacebard posted:

I think it's time to add some branch permissions to the repo.

It's funny you should mention branching!

We have *constant* issues with merge issues while working in a single branch. We're on TFS, and the team doesn't compulsively Get Latest and then *review* the diff before checking in. So especially when two different devs have added files, we just have stuff randomly get dropped from the project, etc.

Dude's solution? Clearly every single dev should create a brand new branch every single sprint for every single slice of every single story they're working on! More branches, less problems!

:smithicide:

# ¿ Jul 21, 2016 13:09

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Gounads posted:

Never dealt with tfs, but In the git world, that's very normal.

TFS (TFVC for the spergs) does not play nice with this strategy.

# ¿ Jul 21, 2016 13:14

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

I have that same weird crazy work-ethic, combined with a history in 'service' work, and goddamn is continues to throw me for a tailspin that I can literally just say "Hey I'm not going to be here few days, I'm about to take my girlfriend to the ER, I'll let you know later what my week looks like"

# ¿ Aug 5, 2016 00:25

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

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 got pulled aside by my manager after I returned and got told that it was unacceptable behavior to take sick time like that and that I was being difficult and unreliable. I quit soon after, and then the company laid off most of its staff a month after that.

Some people are assholes. Don't let them lord you around.

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

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

ToxicSlurpee posted:

To be fair though that's an easy mistake to make that can be explained by inexperience. I kept making that mistake at work because there I write Java but came from C#. stringOne == stringTwo is a comparison in C# but is a reference equals in Java.

Someone keep me honest here, but I thought the variance in behavior(compared to Java) is because *it doesn't matter* in C# due to the fact that identical strings are aliased under the hood? A quick peek at Linqpad suggests this to be true - ==, Equals(), and Object.ReferenceEquals() will all return true for two strings with the same value.

# ¿ Aug 28, 2016 06:14

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

MisterZimbu posted:

- When an actual business requirement changes and you have to dig through all of your old tests and figure out which ones need to be modified

I'm not in a TDD environment right now, so I'm curious - wouldn't it be easiest if the change is a *change* and not an extension/reduction of requirements, to just make the change in the code and *then* see which tests start hollering that the output has changed? I mean is the TDD philosophy so strict that *everything* has to be done test-first? Because yes, I could certainly see that in a large enough, thoroughly tested enough, codebase finding the [n] tests that are affected by a change to a requirement *before* making that change in the code...would be a headache.

# ¿ Aug 29, 2016 22:49

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

sarehu posted:

Why are you so insulted? Unless you're rage quitting there's no reason not to give notice.

I think it's the asymmetry he is calling out.

The concern is that if you, the worker, don't give plenty of notice and opportunity to replace you, you're at fault.
But the employer can basically say "get the gently caress out" at a moment's notice and you're expected to leave and be owed nothing because obviously, if they gave notice to you, you might HARM THEM.

Hilariously, today was the last day at my job(I have another lined up in a week) and when I gave notice, my boss literally tried to shame/beg/guilt/inspire me into not-quitting and/or giving him 3-4 weeks notice instead of 2 - but I held firm and...that was pretty much the last conversation we ever had.

Is it usual for Fortune 500s to *not* exit interview their outgoing technical staff?

# ¿ Sep 17, 2016 05:35

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

redleader posted:

On the subject of job titles: my work has decided to introduce the title of "senior developer", and I'm apparently one of the lucky ones. I think this is laughable, as I have only four years of experience at only one company, in total. (I'd class myself as "middling intermediate developer" at best.)

How will the "senior developer" title look on my CV? I'm picturing some recruiter looking at this idiot quote-unquote senior developer with fuckall experience and binning it immediately. Obviously, titles are bullshit, but do they know that?

It's can be looked at the other way too, right? Some people have an affinity for the work, and getting 'bumped up' quickly can be a show of talent. There aren't exactly standards across the industry about what makes a 'senior' - most places seem to feel it is some equation of actual skill and/or time in the field. Quickly moving upwards, if you have references to back it up, can easily be a show of "I'm just good at this stuff".

# ¿ Sep 26, 2016 15:13

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Reminds me somewhat of a developer I worked with briefly: an 'expert' about performance matters. So yes, his framework's data access and SPs were *lightning fast* - they were! But you had to make 60 calls per pageload to the exact same SP with slightly tweaked parameters - and so any possible performance benefit over just having a larger single call with a table-valued-parameter was completely lost.

# ¿ Sep 29, 2016 12:37

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

MisterZimbu posted:

This reminds me of a former DBA I had who refused to put indexes on tables because they slowed down queries too much, and provided us a "data access layer" that was pretty much C# code that concatenated together parts of SQL statements.

See, I've also run into DBAs who go "performance troubles? fuckit, slap another index on that massive table!" and then get a little grumpy and not-my-problem-ish when you tell them that table performance on large bulk modifications is unacceptable

# ¿ Sep 30, 2016 00:17

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

You mean the sort of thing where almost anything you do with software, while employed, is contractually the property of your employer, related to your work or not?

# ¿ Oct 1, 2016 03:24

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

nelson posted:

That's what the piece of paper says. Along with other creative works. Whether they'll try to enforce it is another matter, and probably directly proportional to how successful it is or whether it can potentially compete with their products.

Eh, I once pushed back when an employer tried to introduce a "everything creative you do is ours" contract, with a retroactive clause. I'm more than happy signing over "hey, anything I do with SOFTWARE that possibly pertains to WORK STUFF is yours" contract, because it makes sense. But as soon as it encroaches on "I write software as a profession, but if I write a novel in my personal time, the company owns it" type territory, I get reasonably defensive. And I haven't seen another contract yet that attempts to enforce ownership on *all* creative works, except those that possibly have anything to do with my actual job, which is fine by me.

# ¿ Oct 1, 2016 06:04

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Coincidentally, I got an email that the CodeWars guys have spun their execution and analysis engine into http://qualified.io - which is a nifty idea to prevent this very confusion.

# ¿ Oct 6, 2016 21:25

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

I am currently appreciating the workflow process I find myself surrounded by, where while doing planned work, the greybeards take it upon themselves to 'fix' the older code, introduce a dozen new critical showstopper bugs, and then just toss them into the backlog to be worked on in a future sprint. And then we wonder why we can't make deadlines and why every release ends up in a mad-dash all hands on deck QA overtime week.

# ¿ Dec 14, 2016 14:51

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Dirk Pitt posted:

This is what we do. If someone finds a rhythm, don't disturb. Keep your kanban board up to date and everything is fine. Don't overthink it.

But the Agile Coach told the team standup is absolutely critical to the Agile Process and enabling an Agile Team to work like Agile is supposed to work!

# ¿ Feb 2, 2017 13:52

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

A few months back I started a new job involving acting as a technical resource for 9 scrum teams. My first major deliverable was simply to try and write up a set of common standards all team should be following, with the understanding we'd then be able to, at the end of the year during evaluation time, measure the improvement over the year. I felt patronizing to actually include 'Use Source Control' as a bullet point on the list. I felt, in TYOOL 2017, it was a freebie. I felt reinforced by the fact that in the first week, everyone had helpfully pointed out where in the corporate TFS/Git servers their projects resided.

And then I found out that huge swaths of the work, while TECHNICALLY residing in source control, hardly ever gets used. Instead many teams tend to use shared folders on the NAS to do their actual work, and in some cases will go 6 to 9 months before bothering to put their latest changes into source control - and when they do, inevitably it is the exact structure of
/Code
/code old
/code old old
/New Code
/New Code old

that also gets checked in, making the source control itself a cacophony that nobody understands, further getting people to just grab a copy and work from a shared folder.

# ¿ Apr 8, 2017 13:17

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

I recently spent a few months contracting at a place that did SAFe across...9? teams that were all vaguely interrelated to a handful of end-user products. Every 3 months was a 2-day, full-work-stop, 'PI planning' meeting that meant that, at a guess, over 120 development staff(QA, dev, etc) sat in a room and did little more than talk about what the broad plan for the next 3 months was, and broadly speaking, management's attitude was "we will tell you WHAT we need and WHEN we need it, and you better deliver."

In one case, one of my sister teams pointed out everything in their backlog, said 'we have 100 points of capacity for this PI', and management said 'but we need this 150 points worth of features'. The team pushed back - 'sorry, we just can't do that' - and management's response was 'well, maybe if you re-organize your backlog, you can make it work.' Unsurprisingly when we went to the hilariously cultish Fist of Five show of hands, that team almost unanimously reported 1 or 2, and management was very upset they were being downers.

# ¿ Apr 27, 2017 04:49

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

There's a sudden discussion at work around BDD - and so I played around with the general principle today and...can anyone here explain what in the hell I'm misunderstanding or missing about all of this? It seems like an extra layer of complexity, which means an extra layer in which poo poo can get hosed up, all for the sake of...'translate all of our requirements into a series of limited DSL definitions'?

# ¿ Apr 27, 2017 23:58

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Illusive gently caress Man posted:

I really hate this thing, and I feel like it must be a well known stupid thing with terminology around it, but I'm not sure what it's called or the best way to describe it.

I'm part of Org at BigCompany, and the high-ups in Org issue some edict like 'all products in Org must now X'. X is not fully described, and now there are dozens of teams all attempting to X, and all of them interpret X slightly differently and implement things differently and it's a waste of everyone's goddamn time. Like, if you're gonna issue these edicts, loving understand what you're asking for first and maybe even put together a team specifically for providing an implementation of X for all products in Org.

Allow me to solve for X:

'Agile' ?

# ¿ May 9, 2017 23:13

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Volmarias posted:

... much.

So long as you speak fluent English, nobody cares. Despite the noise about the veil ban, Denmark - just like the rest of the Nordics - is still hilariously liberal compared to the rest of Europe (and the world, really).

Plus, from the perspective of someone wanting to immigrate, they have one of the simplest processes for folks who earn decent wages such as developers - since so long as you have a job waiting for you that pays around 60k USD annually, you pretty much automatically get a visa.

# ¿ Nov 21, 2018 22:39

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Hughlander posted:

For what it's worth every employer I've ever been at in the US has followed the same except in the cases of sexual harassment. I've had to write up multiple 'Personal Improvement Plans' over the years including things like, "Stop being a dick to people." And including leading to terminating someone when they were still a dick to people.

The weirder cultural divide is that in Europe a lot of this carries the force of law. Such as aforementioned Norway - where the *fastest* way to get fired from a permanent position - without breaking any laws - pretty much involves:
-Show up drunk, get a warning
-Show up drunk, get a warning
-Show up drunk, get ordered to rehab
-Don't go to rehab
-Show up drunk

Firing someone seems to pretty much be a 'bring in a lawyer' type process.

Even in a probationary period at the start of employment, there still has be a solid and documented reason to terminate the employment, it just doesn't need be quite so drastic.

# ¿ Feb 1, 2019 08:13

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Keetron posted:

You are Dutch! And wrong.
An employee can quit on the spot (terminate the contract) for similar reasons as an employer can: extremely disruptive behavior. For example, my BOL quit his management job when he was in a meeting where basically a new CEO stripped him publicly of all his mandate but made explicit that he would be still held responsible for the results. So my BOL got up, said "This will make it impossible for me to do my work and I quit effective immediately." and left the meeting. There was probably other things ongoing as well. In general it has to be a "severe" reason such as an employer insulting, threatening or intimidating an employee. Violence in the workplace is also a good enough reason.

Let me add that a notice period can be contractually expanded to three months and is often done so for crucial IT workers. People are expected not to sabotage things as employees are not expected to be assholes, it is simply not done. Also, we have a legal minimum of 20 days of paid leave, usable only for vacations and relaxing, that are used after quitting a job to shorten the notice period. Many companies allow for 25-30 days a year, some up to 45. This is vacation time, sickleave is not deducted from that.

Oh yeah even outside of the firing stuff the labor laws over here are antithetical to the American workplace experience. If I recall correctly, it's actually law that somewhere between July and October an employer *must* ensure you receive 3 consecutive workweeks of time off for vacation - and if you for example become sick a week into your vacation and a doctor certifies such, you get those days back.

# ¿ Feb 1, 2019 20:39

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Keetron posted:

Yes, that is because vacation is determined to be for relaxation and you cannot do that when you are sick, duh.

Yeah, it's inconceivable to the American worker. All employees at my company receive the legally mandated 25 workdays, not calendar days, of vacation in the year, and the company tosses an extra 5 as a benefit.

I could have worked for 20 years at my old Fortune 500 and only been accruing like 20 days per year.

# ¿ Feb 1, 2019 21:51

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Tab8715 posted:

Has anyone ever gone from working the in US where you typically only have 2 Weeks Vacation with Public Holidays to Europe where you have 20+ days of mandatory vacation?

I can't imagine what that'd be like, I almost wouldn't know what to do with that much free time.

It's really, really weird. In 2017, my PTO amounted to a 10 workday vacation and a few scattered days around the holidays.
In 2018 after becoming an expat a few months into the year I took I think 25 vacation days? This year I have 35 to burn.
The general usage is to go traveling. South Europe seems to be trendy amongst the people I know. But in general, put in american terms, just imagine a 3-week-long Labor Day Weekend. It's a lot of getting together with friends and drinking somewhere.

Che Delilas posted:

I work in the US and we went from 25 days general PTO to unlimited (this year, we'll see how management tries to abuse that). I typically spend mine on long weekends plus one longer vacation, that's a good balance for me.

I've always seen unlimited PTO as a trap. Like a big 'you just try and take more than the previous amount allotted!'

# ¿ Feb 2, 2019 23:06

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

I did a 6-month stint at a place that worked under SAFe. It was ridiculous. During the 3-day-long Increment Planning, management largely would show up and go 'here are the features we need by the end of this increment'. The teams would go to their boards and estimate out their pieces of work, and then come back and give a confidence assessment to management on their ability to deliver. When in one case over half the teams basically said 'no loving way we can deliver all of that', management asked them to just *estimate harder* or *trim down* what they thought would need to get done, because they couldn't possibly give on the requested features.

It was both fantastic and terrifying to watch the most grizzled team lead (of, naturally, the most critical team of which most other projects relied upon in some way) stand up and talk down to the regional VP over the idea that by just 'reorganizing' the stories, they could somehow make them fit into the timeframe.

Shortly thereafter we had a full weekend of 'OPTIONAL' overtime. And around the holidays I watched them bully a colleague into cancelling the first week of his holiday vacation because a bug had come up in his (admittedly lovely, super siloed, 'stay away from my code') section of the project and they needed it fixed before New Years.

Around that time is when I told my headhunter I wasn't going to extend this contract and that he should start finding me something else to do when it ran out.

# ¿ Feb 24, 2019 18:15

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 07:20

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

My Rhythmic Crotch posted:

This has to be the most pervasive misunderstanding about Agile / agile - the point isn't that you get finished code faster. I've wanted to give a talk where I work that basically is just a list of stupid rear end things people think agile does, and that would be Thing #1.

I think it's just a basic problem of management hearing what they want out of the 'why is agile good' pitch. 'Release every 2 weeks' sounds REALLY GOOD when you stick your fingers in your ears about the rest of things.

I tend to try and talk to folks about it in terms of an engineer's triangle: Budget, Release Date, Feature Set - choose two. And that first one especially comes with a *lot* of caveats(Brooks, etc) and is generally also fixed - a team is a team is a team, barring some OT here and there. And so you really get to pick a date or a feature, but not *both* - which is what most management wants to do. If you want a specific feature, you ask the team to tell you when they can commit to having it done. And if you want to be able to say 'Version X on March 23!' then you're going to have to have the team tell you what they can commit to having in that release.

# ¿ Feb 24, 2019 19:48

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›3 »