Honestly, there are good reasons to do this.

It's easier to communicate. It's an easy to understand fact that your native language is the one you speak best. Less ambiguities, less misunderstandings, easier to find common ground. Don't forget, most likely if this bothers you, then you're not the average language Joe, but someone with a higher degree of knowledge in a foreign language. Others will not have fun communication in another language over a long period of time.

I have worked in multi-national teams and it's not easy, even if you're all devs. I'm not talking about cultural differences, but the language barrier. It takes a lot more concentration to explain everything in a foreign language, especially if you're translating reqs at the same time.

Mostly it has nothing to do with racism, it's just convenience. It can work, we were a great team, but it takes some effort. If you rubbish these requirements, then you're as wrong as the people wording them in the first place.

No, Scrum is made for the following:

* Managers feel involved with setting priorities and stuff.

* Committing to dates, cause managers like that.

* Posting excuses in tickets, cause the commitments were shit from the start (Yes of course we can finish these 283 tickets in this two week sprint).

I totally agree with the 2nd statement. Camera quality on phones doesn't matter, buy a DSLM :)

Basically what @jestdotty and @lensflare said. If it's small, you can start right away and then document when you know where you're going to. If it's bigger, at least draw a basic design to know how stuff will interact.

What you should always do and I really mean always: if you're using some crazy logic, you should always (repeat: always) and instantly document what you're doing cause even your future me will have trouble sometimes. Document it as if you had to explain it to an idiot or you will hate yourself if you ever have to work on it again. Plus: others will hate you even more :p

@electrineer I'm not sure. I'm German so I didn't care too much, but knowing German definitely helps when reading the tables, cause the table and column names have strange names derived from their German full names, so like the table VBAK will contain header data (K = Kopf) and VBAP will hold item data (P = Position). They have views to make life a bit easier, but it's still far from intuitive.

@Lensflare It starts with funny parts like having to use ~ instead of . for column selection, then you have spaces that matter, as in max(n) gives you an error, cause the syntax is max( n ). It goes on with subselects not working, CTEs should work, but not for me. Then you have certain cases where you can nest functions, sometimes not, so for instance select 'bla' && 'bla' && 'bla' works, select concat( 'bla', concat( 'bla', 'bla' ) ) does as well, but not select case when 1 then 'bla' else 'blo' && 'bla' ... in that case you'd have to work with concat again. it drives you mad cause everything almost any modern DB can do, this shit can't. Reason? OpenSQL is made to act as a layer that can use the query on any kind of database.

@tosensei This is what struck me as well. Why call it "open" when it's the most closed shit you could ever imagine?

I've just started a lease for a BEV for 200€ a month, what do you mean expensive? E-mobility in Germany is super easy and I say that living more or less in the countryside.

EDIT: I have like 250km range, which gets me to more than 10 major cities. I wouldn't consider that a baby step.

I already picked good salary and good family. Can't sleep anyway when you have three kids :D

Oh that looks like a nice way to reach max connections quickly.

First of all, it's not a bad thing to reduce career in favour of kids. Time with your kids is short, they will eventually move out and then it's over.

However, I still think it's important to show your kids that work is important. I want my daughters to work hard in the field they love, not work just for work's sake. Be an example for them, show them that working is nice and fun, but don't force them to do something that you deem to be important.

Never forget that when stuff is for free, you're somehow the product. The company used you to grow big and you used the company to get stuff for free, so after all it's a fair deal. When I'm paying for stuff, I'm a real customer and if I don't like the product anymore, I stop paying for it.

@We3D don't see it as blaming, see it as information concerning the source of the request. ;)

I like all the solutions here, but there is one very important thing to do first. Clearly state in the code comment why you did it like this. Comment it in the code, in the tickets, in the commits, whatever, just make sure that people know who ordered you to do it. Shitty code stays, but so do comments and commits.

So we'll have people here that will say "Things that didn't happen for 100", but trust me, for a short time this works very well. Clients will have no manager to speak to and can't come up with new bullshit ideas. The manager above the manager will know he's on holidays so they will not drop their bullshit as well. However, if this manager was on holidays for like ... three weeks or more, then the next best senior dev would be the target of all management related crap.

Morale of story: Every time you think your manager is shit, remind yourself that management above is at least as crappy or even worse ;)

@jester5537 I feel you, man. We had a system change lately that required functions (MSSQL server) to be used to return some code. We had people write the same function three times, but with different fixed values and I was like "Wtf guys, write a master function and then just call it with parameters, it's not hard. Otherwise a single change will have to be done three times.".

It seems reusing code is not something your co-worker likes. I admit, I have a folder full of small snippets in PS that I use without functions, but I definitely see the advantage of using them.

Seems like you need to forward the mails to the project lead with a totally innocent "Hi, short question: if I do this, we will fail the project, but I'm not sure about the current priorities. Could you please take care of this?"

This is what I usually do. Tell people what will fail and make sure it fails, if they prioritise something else.

There is a special place in hell for people who use implicit joins or implicit converts.

@Wolle Haha, this is honestly the best answer here :D So evil, so subtle.

I feel you, man. It's like constantly reminding people that this shit ain't gonna work, then manager asks why nobody warned earlier. Like ... really?

We've started bringing our own mice and keyboards anyway. You can have a 5€ standard Dell keyboard and if you want something fancy, cause maybe you prefer typing on real keys, then you gotta bring it yourself. Apparently it's too much hassle of IT to keep track of too many different specs. Basically I understand that, but yes, it feels like child games.

EDIT: At least IT is decent enough not to bitch about hardware we brought ourselves, as long as it's only a mouse and a keyboard.

@hitko I only half agree. You can have a manager do that OR you can have a requirements engineer do it. If he knows his stuff, he will press the customer to decide certain things beforehand and deliver a good requirements catalogue.

On the dev side you will have people who know how to build a modular design that can be changed easily and you will have people who build giants monoliths that are a pain to change. A good dev will reduce dependencies, which pays off in the long run.

Yes, the bigger the company gets, the worse it gets. The problem is that when you have 2 people who love their job, they will deliver good code. When you have 20 people, chances are high that at least two just don't give a fuck and then the manager will say "Well does it work? Cause we need that feature asap" ... and then your code is doomed. Honestly, your best bet is to try and be responsible for a small part that is yours and yours alone; then at least you can do it correctly there.

@Oktokolo I'd be happy to say "yes" to your first point. Trust me, I'd be. Devs are humans, but if you push changes without proper testing, you deserve a rant ;)

Honestly it's a pretty common DWH problem. For instance Jack Doe today, tomorrow Jack Smith and after divorce Jack Doe again. So you have Doe as islands and Smith as gap. A good historisation will take care of this and write three entries with normal timestamps. A bad historisation will try to put the Does together, then produce strange results or crash. Just like you'd verify user input in every other language, you must verify that in a DWH environment.

@Oktokolo No I found out that someone got promoted to a senior position without knowing basic problems. Everyone makes mistakes, that's normal, but if you get promoted for just being long enough the company, that's a problem.

@CoreFusionX You're right, I should've been a bit more precise. Max precision is 2 and in a later process it gets transformed again and in that process is rounded, so in the end it's totally ok.

People not thinking of basic things is a real problem indeed. So often it was the other way round, people telling me that float should not be used and suggested totally OTT data types ... for a max precision of 2.

The main problem is: Try finding a dev. If you found one, do you really want to make him a PM or PO? Or would you rather use the skills for actual work. This leaves the other jobs to ... well ... the rest.

@Wolle Let's say yes and no ;) I have my small side projects for these cases indeed. Can never acquire too much knowledge, so I'm always making sure that I book some overtime while I test new features or new ways of doing things. This inflates the costs to correct shitty code even more, so maybe they'll learn one day.

Spoiler: they won't