AggressivelyPassive

You do know, what nationality means, right?

You monster.

In my experience, that’s not a problem of commitment, but rather budgeting and priorities.

There’s always something more urgent than that one refactoring ticket, but you also don’t want to effectively delete a clear indication of a problem.

Wrote my master thesis this way - didn’t have enough ram or knowledge, but plenty of time on the lab machine, so I let it do its thing over night.

Sorry, lab machine ssd.

If you’re running enough images on the same machine to make that a relevant point, you have absolutely no excuse not to provide common base images.

Basically, there are two scenarios here: you’re running some service for others to deploy their images (Azure etc), then you want isolation. Or you’re running your own images, then you should absolutely provide a common base image.

There’s also the infamous gender of “Taucher”, for the non-germans: in German forms, the “diverse” gender is written “divers”, which was auto-translated to “Taucher”, which is a guy in a diving suit.

It literally means “comparison-wise”, so there’s no more explicit translation, I guess.

That may be an artifact of my native language. In German the term vergleichsweise (Vergleich meaning comparison) is used like that and sometimes these constructions spill over to my English writing.

It also depends on the age of the company.

My current company is comparatively young and only really grew above the 100 people mark a few years ago. There are people who only worked here for 10-15 years, but are so integral as head-monopoly, that they might as well have been there forever.

In my old company, there were developers retiring that worked literally their entire lives for the same company.

That doesn’t mean he or his fuck ups are free.

A bad architecture means slower development, more bugs, less reliability. All of which cost money.

Funny thing is, this is essentially the same here for me - I just don’t have the standing right now to push such an effort through.

We’re not in a “fast changing” market at all, it’s dog slow actually. But our customers are currently shitting money and often just want to get things done. We don’t even have to “get a foot in the door”, they’re holding the doors open for us - and some have years of contracts already.

Currently, our revenue is limited by the amount of developers, or rather the amount of developer output (however you want to meter that). The problem is, essentially our revenue is made by renting out devs by the hour. Our proposals (and contracts) usually say “We’ll buid this thing within 1000 dev days at 1000€/day”, as long as our rates and time estimates are competitive, we can charge full market price.

Now comes the bummer: If we would build a common platform/product/library, we would need to invest a certain amount of dev time and then roll that investment over to the external costs. So we might say only 500 dev days for this project, but each dev now costs 1500€/day. The sum total is much lower, but our clients will argue, that 1500€/day is totally unreasonable. We also might choose a license model, were we license our own software, but many clients don’t want to buy licenses, unless it’s something like MS, Oracle, etc.

It’s infuriating.

I’m currently trying to convince some managers, that we could at least build some of the more general components in a way that would allow us to build a small toolbox or library, so that we at least have something like common starting point, but even that gets opposition, because some of the project leads are totally convinced that a) their absolute vanilla project is super special and b) the existing of a toolbox means use of that toolbox is enforced by threat of violence.

Unfortunately, it can make sense to the business (in a way) to not properly collaborate.

I’m currently at a company that essentially does projects for various customers, that are all relatively similar. From what I’ve seen, my department could easily fit 60-80% of all projects into one customizable product. Instead, each project reinvents the wheel and starts from scratch. Why? Because it currently doesn’t matter. The market is full of demand and if we can charge 1000 dev days to start from scratch instead of 500 to use an existing base, then that looks better on someone’s paper.

Yes, it is.

Basically he’s trying to frame something obvious and well out of his control as something he did. Which is typical manager behavior.

You don’t claim to be an expert farmer just because the apple tree in your garden, that’s twice as old as you are, happens to grow an apple.

This is illusion of grandeur in action.

I have to deal with a similar guy. He reports directly to the COO and is considered an expert in his field.

If I wrote his code in my former job, my boss would have asked me, if I’m having problems at home.

Countless variables named tmp, i, j, k, x, value, etc., atrocious error handling (Java, he does no null chess, but simply wrap everything in a try/catch nullpointer block), and tons of spelling mistakes.

Oh and tests are evil.

Well, from experience I can say that scrum and a (good!) Scrum master can really turn things the right way.

Even something as simple as being the impartial moderator can be invaluable, given the borderline-autists many developers are (won’t even exclude myself there). A pointless 30min meeting can become a valuable sync up.

Apart from that a (again, good!) Scrum master can organize a lot of stuff away from the developer. The job literally means removing impediments and I’ve had the luck to work with one SM, who really took that seriously.

It’s not a management position, btw. At least it’s not supposed to be. It’s supposed to be on the same level as the devs. Unfortunately (and that’s the part where you are right), this position and scrum in general were churned through the corporate buzzword grinder so often, that it’s almost meaningless now and often enough just means pointless meetings and pointless metrics (ironically measured in “story points”).

Wait, are you talking about a scrum master under a different name or an actual position above that?

That very much depends on your workflow and team setup. Repo admin for me means “can alter who and how branches can be merged”. That’s usually a job for lead devs.

Bitbucket also doesn’t enforce these rules properly. You can simply change the rules, merge, then change back.

The only way around that is to restrict every developer account into oblivion and only have an ops guy as repo admin, but I think most ops teams have better things to do.

Yes, but Gitlab doesn’t allow for easy access rules.

Basically, OPS wants full control of the repo, since they are the ones being blamed if something goes wrong. There’s no way to enforce, that only a certain set of users can make changes to a branch - all such restrictions can be circumvented rather easily. So the solution is a shadow copy of the repo that only gets updated on release and Argo only deploys a specific tag (i.e. release).

We’re not talking about just some enterprise microservice, but stuff in the public administration/government sphere. The tradeoffs are a bit different there.

The setup could make sense, if there’s a separate repo that’s pull only. Our ops guys pull our ArgoCD repo, so we can do the actually work, but they control what’s deployed on production.

However, this seems not to be the case here.