[wincy]

This is so weird. Aren’t you just selecting for obedience and unnecessary hoop jumping? It seems like this would also select the kind of engineers who aren’t willing to say “no, that’s a dumb approach, we shouldn’t do that, here’s an alternative”?

When I was a Junior dev one of the first lessons my boss taught me was to always always speak up if something looked off to me. Maybe I’d get an explanation and be enlightened or maybe I’d actually sniffed out a mistake or code smell. It always seemed like a win win.

But if the entire job is based on “here swallow this bullshit pill before you’re let in the door”, isn’t it going to be hard to get the devs who are allergic to bullshit?

[tartoran]

> isn’t it going to be hard to get the devs who are allergic to bullshit

Maybe that’s what they want, namely a self selection of devs who will be happy and okay inside an org that is filled with bullshit.

[camgunz]

> This is so weird. Aren’t you just selecting for obedience and unnecessary hoop jumping?

Mostly it selects for people who can turn this on when needed, which honestly is a critical skill. Sometimes life is just bullshit, either you're a person who makes that easier for everyone or you're a person who makes that harder for everyone. But an inability to get past it is a red flag.

[QuercusMax]

Example: I work in medical devices, a regulated space. My job is 50% normal software engineering, and 50% dealing with BS regulations. It's part of the job. You can get annoyed at it, but it won't go away, and the job can be very fulfilling if you can get past the BS part.

[airbreather]

How many devices do you see or design have implicit state in the software controlling them?

(if it is not explcitly defined, and there is state based behaviour, it is by definition then implicit)

At the moment I'm trying to overcome the inertia on this issue in the general process/industry sector with child standards from IEC 61508 - 61511 and 62061.

I am guesssing you apply the medical standards IEC 60601?

Or at design of devices at component level then IEC 61508?

Interested to know how it fits in to the overall Functional Safety approach.

[QuercusMax]

I work on software as a medical device, so I have no idea about hardware safety controls. I have to deal with change control boards and approval matrices for every new build we push, though.

[aristofun]

> It seems like this would also select the kind of engineers who aren’t willing to say “no, that’s a dumb approach, we shouldn’t do that, here’s an alternative”?

This is exactly the reason why any big enough company is eventually going to s*hit

And why founding team doesn’t stay long in a successful startup.

[nicoburns]

> And why founding team doesn’t stay long in a successful startup.

Doesn't the founding team get to determine the hiring practices?

[aristofun]

It's not that they have much choice once company grow in complexity beyond something that a small group of people can possibly handle.

[Kon-Peki]

There's only 24 hours in a day.

[nicoburns]

Well sure, but one would expect the founding team to do the early interviews, and then setup the process that's followed by later hires, no? Also, I would have thought that hiring would pretty much top priority. The employees make or break a company.

[aristofun]

Business processes and traditions are not a source code. It always changes and evolves with people and millions other factors.

One of the factors — it’s too risky for a big company not to hire based on obedience.

[langsoul-com]

Tech interviews are optimised for big tech. Those devs won't care so much when you slap 3x total compensation on their ass.

[ryandvm]

> Aren’t you just selecting for obedience and unnecessary hoop jumping?

Let's be real, that's exactly what most mid+ companies are looking for.

[jeffrallen]

> obedience and unnecessary hoop jumping

This is what makes you successful in some large organizations, unfortunately.