The greatest resume I've ever seen

Definitely a candidate I'd remember after interviewing....

Everyone use to smoke, it was something you didn't need equipment for.

If you have no idea behind which wall a pipe terminates or don't know which of 30 pipes runs to [say] the back room you blow some smoke into it (or a lot) One would mostly use it because it is really fast. Non smoking solutions take considerably longer. One might put a pull string in the tube, if you need to wire it anyway that wouldn't take much extra time but ideally you start pushing the spring into the tube on the side closest to the sharp corners. If there are many pipes on that side you would start pushing on the other and might get stuck. If the curves are really smooth the spring could drop out of the tube. You could need an extra set of hands (more expensive). With the smoke test you could push the spring in from the other end.

If there are wires in the tubes you can tie them together and use an ohm meter to find the right tube. You might have to walk up the stairs 10 times.

Non of it is much like software development.

I thought it came from hardware, where an erroneous component placement would lead to releasing the magic smoke.

From Wikipedia:

In Lessons Learned in Software Testing, Cem Kaner, James Bach, and Brett Pettichord provided the origin of the term: "The phrase smoke test comes from electronic hardware testing. You plug in a new board and turn on the power. If you see smoke coming from the board, turn off the power. You don't have to do any more testing."

https://en.wikipedia.org/wiki/Smoke_testing_(software)

> In Lessons Learned in Software Testing, Cem Kaner, James Bach, and Brett Pettichord provided the origin of the term: "The phrase smoke test comes from electronic hardware testing. You plug in a new board and turn on the power. If you see smoke coming from the board, turn off the power. You don't have to do any more testing."

Source: https://en.m.wikipedia.org/wiki/Smoke_testing_(software)

The way I've heard it used is thus:

In a complex system you are attempting to simplify (or deprecate components of), and where you cannot find an owner or stakeholder over some component system -- unplug the component and wait for errors or user complaints. Thus you will find out who is affected by the component and who likely stakeholders should be.

For example, old graybeards like myself will almost all have a story of finding some lost Sun or Irix server sitting under a pile of gear in an old closet, happily turned on with nobody current employed who knows anything about it.

What does it do? What's the user/password? How did it get there? all lost to the sands of time.

Turning it off will let you know if you can retire it or if somebody emerges with a problem then they can own it.

Tangential: at my first company out of uni we worked on software that ran in cars. I had never heard the term "smoke test" during my studies, and for quite a while I thought we were running tests (diagnostics) to check if the car was smoking.

I got so sick of having to explain what smoke tests were that I just don't use the term anymore.

In software, they tend to happen at deploy time, whether to an internal environment or production. I just call them "deploy tests" now.

Smoke test is an ancient engineering phrase to describe the first time you turn something on after building/fixing it.

If it starts smoking, something is wrong.

It's been in the Jargon File since the late 80s and was popular in military/defense contracting prior to that.

You actually got me curious about this because it's a term I've been using for 40 years, and the earliest reference I've been able to find is in an internal memo about the development of a computer system, circa 1952:

> What all this adds up to is, that if Mike Stobin and Willis Ware who have been dealing with the ventilation engineers can come through with the ventilating equipment in time, it is very likely that we can have a smoke test of the arithmetic unit on the JOHNNIAC main frame in October [of 1952].

>The goal of the test will be to connect the A [accumulator register] and MQ for end-around shifting (7.5 order)15 and let the machine shift a set of digits all day while we hammer on the frame and wiggle wires. Applications for wire wigglers are now open.

https://www.rand.org/content/dam/rand/pubs/corporate_pubs/20...

Well shit I haven't used/heard the term "wire wiggler" in decades time to up my rizz with some outdated slang.

It is almost certainly a WWII slang term that spread to universities post-war.

Definitely. At the same time, there's a weird dynamic in the market - because of the boom of AI (driven mostly by cloud spending) architecture, the demand for cloud engineers and even general devops has surged, but mostly in the more senior 5+ years experience market. I am getting asked a lot of questions by people messaging me about how to enter after college, and I don't really have a good answer for them. The honest truth is that it's always been a little tricky and you've gotta be a little odd to get into it in the first place, and what I usually tell people is I don't believe many senior people doing it now ever "chose" it, it usually just happens to people.

Plus the fact that these AI coding assistants can almost do a passable job of a junior, to the point where most of their job is probably going to be just dumping crap into copilot or some gpt. I feel very very bad for anyone entering the market right now.

Plumbers, engineers.. we’re also all just dealing with $#%^ all day right?

Id bet on disposable housing before I would bet on robotic plumbers.