Doctors don’t need to beat down other doctors and climb management hierarchies just to advance; they just need to gain more skills and deliver more value.
This is not what I’ve observed with professionals in medical communities. In fact, the only thing keeping the docs from going completely ape is that they have the permanent underclass of nurses to beat on.
That is, a doctor can’t use the superior orders defense to justify killing a patient
Demonstrably false, regrettably. Nurses and others do this, though they are typically tasked with doing exactly what the physician wants or is reported to want, even if it means giving a patient a fatal dosing of an antibiotic.
Doctors may also do the same thing in different guises. It’ll be dressed up in terms of “standard of care” and whatnot, but that’s just clever marketing.
I believe that there should be some kind of professionality in software engineering (if it is indeed ever to become a form of engineering), but basing ourselves on the practices of law and medicine is maybe not a good move.
This is not what I’ve observed with professionals in medical communities.
There’s politics, but it’s not at the same level of intensity, and the consequences aren’t as severe. In the true professions, losing politically means that you get a worse office and, if things go really bad, you might be expected to find another firm in the next 5 years (the “succeed elsewhere” talk). For programmers, it can mean being suddenly fired for no good reason or just no reason.
Are you talking about euthanasia? That, while illegal in this country, isn’t what I was talking about. (Why would anyone use antibiotics for euthanasia, though? Seems like a painful way to go, and risky as hell for the doctor.)
basing ourselves on the practices of law and medicine is maybe not a good move.
That may be true. Medicine requires expensive schooling and isn’t really an option after a certain age (I don’t think that a 35-year-old would get admitted to med school) and law, on the other hand, opened its doors too widely and now has a large underclass of people with third-tier law degrees. I think the actuarial sciences have the best model: difficult exams, no required schooling, and the ability to dynamically control the growth of the profession (through exam difficulty and pricing, in part) according to economic circumstances.
Are you talking about euthanasia?
I presume they’re referring to nurses failing to catch (or noticing but failing to prevent) doctors' mistakes, such as prescribing a fatally high overdose of some medication.
However, this is cherry-picking anecdotes. There are stories of nurses ignoring or modifying unusual (but non-mistaken) instructions from doctors to the patient’s detriment as well. In general, doctors make medical decisions because they are trained to do so. Nurses do not because they are not.
Okay. Yes, that makes sense having reread what he said.
Still, don’t the nurses at least ask the doctor when the numbers look off? I mean, I wouldn’t necessarily hold a nurse legally responsible, but I can’t imagine that a nurse would get in trouble for asking a doctor, “did you really mean 200 mg and not 20 mg?”
They certainly shouldn’t get in trouble, and it’s in the best interests for almost any org even those outside medicine to encourage people to call it out when they see something weird and especially something dangerous. I think in IT we have a lot to learn on the subject - “Crew resource management” procedures from aviation are a particularly good example of doing it mostly-right.
Not particularly relevant, but sorta related, there was this great article examining an occasion when technology and operational procedures went haywire to create a dangerous situation for a patient: The Overdose: Harm in a Wired Hospital. It’s long, but really interesting.
Yeah - I see this is an earlier article in the same series as the one I first thought it was. I particularly liked this later one, comparing how it’s handled in healthcare and aviation. Should Hospitals be more like Airplanes
I definitely think finding ways that we can get actual reliability - and acknowledging and dealing realistically with alert fatigue is a huge part of that - is a big part of what we need to change as programmers, to stop relying on this whole heavy-management thing for fake reliability.
Amen. System reliability comes from individual excellence. We obviously need both excellence and reliability. Humans are just really bad at the latter. Often, it requires human excellence to build systems with high technical reliability.
I think that the micromanagement culture comes from this idea that superficial industrial reliability is a good proxy measure for ethical reliability (which matters, and on which one can’t compromise). It’s not.
Story I was thinking of was a neurosurgeon talking about one of their learning surgeries. If I recall correctly, the teaching physician instructed the doc to do something rather risky for the hell of it (theoretically, to train them on something). Had it gone wrong, patient would’ve been partially paralyzed or dead, and the defense used would’ve been “I was told to do this.”
Malpractice is actually a whole set of misadventures: https://www.texasobserver.org/anatomy-tragedy/ .
I want to see software engineering professionalize as much as anyone else. I hate the infantilization of SV, the way tools and processes are evaluated based on tribal or religious considerations rather than technical merit, and everything else that makes software so sub-optimal for those who write it and those who use it.
The thing is, law, medicine, actuarial sciences, and civil engineering are professionalized because their professional credentials have legal force behind them. You can’t just teach yourself law or medicine in the United States and go around calling yourself a lawyer or doctor, and for good reason: to oversimplify, a bad doctor can kill or injure their patients, a bad lawyer can get their client sent to prison for something they didn’t do, etc. An incompetent actuary probably won’t kill anyone directly, but could single-handedly lose their company a lot of money.
What arguments can we marshal to professionalize software engineering in the same way? I don’t think there are any good ones, at least for the entirety of the industry in its current state. At some point in the future the Internet of Shit is going to burn a house down, and we’ve seen personal data lost again and again due to security breaches, many of which resulted to a large part because well-known best practices were not followed properly. (Not to mention any field which uses tools such as MISRA C, for which wild west style programming shenanigans are probably already seen as grossly counterproductive.)
The other extreme, though, are ‘idea guys’ who want some barely-competent programmer to throw together a MVC for their Snapchat-for-Vine-but-with-cat-emoji clone that they need done in time for their meeting with their VCs next week. Or those same idea guys building out their hot new startup, now that every teenager in the Western Hemisphere is using the damn thing. They care far more about filling rows of desks in their open-plan offices with anyone who can connect an IBOutlet from a UIButton to a view controller than about professional expertise, and people are rightly going to question why government-enforced professional credentials are getting in the way of their goals.
The only good solution I can think of is to deliberately bifurcate “software engineering” into ‘serious’ and ‘non-serious’ disciplines, and try to professionalize only the former. Even that, though, is going to be a complicated and horrendously controversial task. There is going to be an inevitable differential in terms of pay, prestige, and ease of entry between the two, which will breed resentment. A bigger hurdle might be convincing those developers whose job falls into the former bucket that giving up hacker/VC culture in favor of professional culture is something they should support. (I would love to be proven wrong, though!)
I agree with you that there’s a split between “serious” and “non-serious” software development, but I think your perspective is skewed from being in Silicon Valley.
That divide already exists. Not formally, but look for software development jobs in a market with a lot of defense contractors, automobile, aircraft, or heavy equipment manufacturing companies, and it’s pretty obvious.
Companies like Boeing, Lockheed, Northrop, etc. employ a lot of people writing software for aircraft, ships, trains, automobiles, satellites, space craft, etc., and their culture is as professional and as different from “hacker/VC culture” as you would expect.
I agree with you (hence the throwaway MISRA C reference). However, I’ve only ever seen those fields discussed in the context of embedded software development (“embedded” itself being a vaguely defined term), and it’s always seemed to me like embedded is, in practice, a completely separate field from the subset of “software engineering” that most people on this site belong to and that Michael is complaining about. At the very least there’s little interaction or movement between the two fields (or, if there is, it’s often in the form of embedded people deciding to make more money doing app/web style work).
The difference between the two cultures probably stems less from a conscious decision than from the circumstances behind their formation. Many of the big companies you listed employed professional, competent, properly-managed engineers long before Silicon Valley began its transition from hardware to software-based products, while many of the biggest ‘software’ companies today were built from startups with the express purpose of writing software for some business domain. We need to figure out: is the divide between these two cultures placed correctly? Or is there room for stuff that the latter culture is doing now to be forcibly professionalized? I would argue yes, although I don’t know how it would take place. Avionics firmware is part of a bigger, heavily regulated product that can fail due to a variety of causes, not all of which are software related, and as such there’s natural pressure to produce a professionalized culture that can write reliable software. The same isn’t true for a lot of other domains. How do we apply such pressure? Do we have to wait until something truly catastrophic occurs?
My bigger fear is SV muscling into these sorts of domains (automotive, aerospace, medical equipment, etc) and bringing along the attendant dysfunctional culture. Note that certain SV-esque companies in these fields are already lauded for being “run like startups”. Another example: I read recently that VCs are giving George Hotz funding to develop and commercialize his homebrew tested-on-public-streets self-driving car software. I like Hotz and I’m sure what he’s doing is perfectly legitimate, but at the same time I’m not comfortable with the precedent he’s setting.
All of these “obelisk-shaped” fields require expensive, highly stratified education, and involve some sort of “up or out” early career filter. There’s only a lot of room at the top when you ignore all the people who tried to get there, and failed. There are an enormous number of lawyers who are unemployed or doing doc review, even though they have a JD and passed the bar.
If we redefine “software engineer” to be everyone at some sort of Cravath-style consultancy, I’m sure we can create an obelisk, but that neither solves the larger problem nor supplies the volume of engineers needed to solve the existing set of software problems.
All of these “obelisk-shaped” fields require expensive, highly stratified education, and involve some sort of “up or out” early career filter.
This is true of the actuarial sciences as well, which I think is the field that provides the best model. People who struggle with the exams leave and do other things. I like that barrier better than parental capital.
There are an enormous number of lawyers who are unemployed or doing doc review, even though they have a JD and passed the bar.
Law has been poorly managed, it’s true. There are too many law schools and too many lawyers and that has created a legal underclass (doc review) as well as increased the importance of the elite law schools (“top 14”; I have no idea why it has to be 14 and not some other number).
The Cravath model is old and it actually worked for a long time. It relied somewhat on Cravath’s reputation, though: if you didn’t make partner, you’d be put on a partner track somewhere else. Boomer greed is what killed it: rich partners wanting to become even richer cut the number of partner positions and the likelihood of promotion to partnership plummeted (into the single-digit percentages, by some accounts). Imagine that, rich Boomers ruining something. Nothing lasts forever; if you create something good, some greedy generation will come along later and kill or squander it. However, a system that improves the situation of engineers for the next 100 years would almost certainly outlive me. ```
I’m sure we can create an obelisk, but that neither solves the larger problem nor supplies the volume of engineers needed to solve the existing set of software problems.
If we’re needed in volume, then we should be doing something with that demand. We should be earning more than the VPs and we should be able to work whereever we want, rather than being crammed into open-plan steerage. And we certainly should be able to kill the infantilizing “Agile” micromanagement fad.
The obelisk was not what I was expecting. I worked at a company that wanted to be a pyramid, but we were still kind of small, so they built a totem pole instead. The product management department was a VP with one report, the director, who had one report, the senior manager, who had one report, the PM, who was the engineering/sales/marketing liaison. This was because soon we would start growing and we needed to be ready to scape up. Of course, a four level hierarchy would support 1000 PMs which is kind of a lot. The engineering department was set up similarly, but at least we had a whole dozen workers at the bottom.
There was a lot of title equality baloney involved I think. Can’t have a minion directly report to a VP, because then the VP isn’t really a VP. Can’t have a director doing work because then they’re not really a director.
Only the sales department was organized in a somewhat rational manner, with management overlaid on the department instead of being a structure all its own. Junior associates would report to the regional manager, but the regional manager also had their own accounts.
I should have perhaps clarified that what I mean by obelisk is that I want people to be able to progress in compensation and standing (assuming there is commensurate skill growth) without positional scarcity.
Right now, the better you get at programming, the harder it is to find appropriate jobs. I’ll probably move into management over the next 10 years, not because I want to, but because I have to. There just isn’t a demand for Principal+ Engineers at most organizations… I mean, there “should” be, because it’s needed, but most companies construe it as a managerial role.
Trusting a single company (e.g. Google with its dual-ladder approach) to solve this problem is unreasonable. First, that’s too much of a burden to put on one organization. Second, we see empirically that this creates a difficulty disparity (i.e. it’s way harder to become a Director-equivalent engineer at Google than a Director) that becomes self-congratulatory for the managers. It’s going to require an inter-company effort and it’s probably going to trample the interests of the currently reigning tech barons.
It sounds like the proposed exam is leading to certification, which I agree could be useful. I think this needs to be done carefully because it’s possible to lead to something like Scrum certification, which not only reinforces the pyramid chart, but also uses something like a pyramid scheme.