[HN Gopher] The greatest resume I've ever seen
       ___________________________________________________________________
        
       The greatest resume I've ever seen
        
       Author : SenHeng
       Score  : 80 points
       Date   : 2024-05-07 10:58 UTC (12 hours ago)
        
 (HTM) web link (newsletter.goodtechthings.com)
 (TXT) w3m dump (newsletter.goodtechthings.com)
        
       | andyferris wrote:
       | I always thought a smoke test related to "where there is smoke
       | there is fire". Like "where there is an API response, there must
       | be a functioning API server".
       | 
       | Is that wrong? I am of course aware you can use smoke to track an
       | air current, but is that the meaning of the phrase?
        
         | 6510 wrote:
         | 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.
        
         | hiatus wrote:
         | I thought it came from hardware, where an erroneous component
         | placement would lead to releasing the magic smoke.
        
         | linsomniac wrote:
         | 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)
        
           | philk10 wrote:
           | The expression probably was first used in plumbing in
           | referring to tests for the detection of cracks, leaks or
           | breaks in closed systems of pipes.[1] Pre-dating the term
           | itself, smoke tests were performed to detect leaks in wooden
           | sailing vessels at least as early as 1836. After making a
           | slow fire in the bottom of the hold, Richard Henry Dana
           | writes, "Wherever smoke was seen coming out we calked and
           | pasted and, so far as we could, make the ship smoke tight." -
           | https://en.wikipedia.org/wiki/Smoke_testing_(mechanical)
           | 
           | ( I used to moderate a s/w testing forum and one of the most
           | common questions was "what is the difference between smoke
           | and sanity testing" as this seemed to be used as an interview
           | question...)
        
         | prerok wrote:
         | > 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)
        
           | cbsks wrote:
           | As my EE professor used to say, the problem is that once the
           | magic smoke gets released, it's super difficult to put back
           | in.
        
             | prerok wrote:
             | Yeah, in EE there is a joke that the devices run on smoke.
             | Once it's released it won't run anymore :)
        
               | dmoy wrote:
               | I also always liked the joke about "every diode can be a
               | light emitting diode at least once"
        
               | AstralStorm wrote:
               | Or a space heater. That's when the smoke doesn't come out
               | but the device still does not work and is hot.
        
         | bane wrote:
         | 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.
        
           | 8organicbits wrote:
           | There are only certain classes of systems this works for. If
           | the system generates infrequent alerts, for example, the
           | stakeholder won't know there's an issue until they
           | independently discover that they missed an alert. That said,
           | I've resorted to this approach before, and it works.
        
             | AstralStorm wrote:
             | And then you suddenly torpedoed security notifications for
             | the whole company. Nobody noticed for a year that updates
             | were not applied. The rest of the story writes itself.
        
           | reidjs wrote:
           | At my company, we call this a scream test
        
           | AstralStorm wrote:
           | And then you accidentally crashed the whole business, for
           | months, also known as a career limiting move. The stuff The
           | Daily WTF published for failed companies.
           | 
           | Which is why only independent contractors can safely pull it
           | off, and even then not always.
           | 
           | The correct test is targeted error injection. Make the thing
           | a bit flaky see who complains or notices. Fan favorite is
           | explicitly laggy or busted routers in the path for networked
           | hardware. It's still not without risks, crappy old glue or
           | scripts tend to fail catastrophically. So as usual, backups
           | and spares. Documentation before messing with the thing...
           | 
           | Generally also found that it is safer to send excess garbage
           | downstream from the putative server than induce outages. Spam
           | gets quick results. Assumes of course you know what it is
           | supposed to send... Or that garbage sent from there will get
           | noticed.
           | 
           | The last thing is an actual smoke test.
        
         | dekelpilli wrote:
         | 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.
        
         | drewcoo wrote:
         | 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.
        
         | snakeyjake wrote:
         | 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.
        
       | nolongerthere wrote:
       | Its a good primer on getting into DevOps, but in today's market
       | you need a lot more experience than this book can give you,
       | especially following all the layoffs.
        
         | JohnMakin wrote:
         | 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.
        
           | nolongerthere wrote:
           | Yup, the path usually looks something like:
           | 
           | Service desk job > L2 > L3 > company pays for a bunch of
           | cloud training so they don't have to pay for another
           | consultant > DevOps
           | 
           | or
           | 
           | CE/CS intern > tasked with implementing stuff in clouds >
           | hired as Jr SWE, but still tasked with doing those devopsy
           | things that the real devops team doesn't wanna do > jump a
           | few times, each time still taking on devopsy stuff > Sr
           | DevOps Admin
        
             | JohnMakin wrote:
             | > CE/CS intern > tasked with implementing stuff in clouds >
             | hired as Jr SWE, but still tasked with doing those devopsy
             | things that the real devops team doesn't wanna do > jump a
             | few times, each time still taking on devopsy stuff > Sr
             | DevOps Admin
             | 
             | Yea this is mostly the path I took. I had a hybrid lead/swe
             | role that ended up me picking up sysadm stuff due to a weak
             | DevOps team, then my next role was DevOps. Anecdotally, I
             | find there's a large difference in quality of the engineer
             | depending on which of those particular paths they took
             | that's not usually well represented by salary ranges
             | (although if you possess a CS degree jobs are MUCH easier
             | to get IME).
        
       | sebastianconcpt wrote:
       | A good infrastructure guy can translate problem solving and
       | troubleshooting techniques from one domain to the other.
       | 
       | We're natural general intelligence, remember that part?
        
         | Vitaly_C wrote:
         | Plumbers, engineers.. we're also all just dealing with $#%^ all
         | day right?
        
       | david_allison wrote:
       | (2021), site is now offline: https://dsresume.com/
       | 
       | Snapshot (Sept 30, 2021):
       | https://web.archive.org/web/20210930190513/https://dsresume....
        
       | l0c0b0x wrote:
       | I TOTALLY thought this was going to be an article about Major
       | Hayden's resume:
       | 
       | Resume as a man page: https://majorhayden.com/
        
       | bryanlarsen wrote:
       | 2021, so not obvious then, but I wonder when he'll switch back
       | because pay for plumbers is higher than that in IT.
       | 
       | Plumbing will likely eventually mostly get replaced by robots,
       | but almost certainly they will hold on longer than most IT
       | professionals.
        
       | mmh0000 wrote:
       | This is the greatest resume I've ever seen[1]! I'd hire this guy
       | in an instant.
       | 
       | [1] https://townsquare.media/site/393/files/2013/09/Redmon-
       | Resum...
        
         | onemoresoop wrote:
         | Definitely a candidate I'd remember after interviewing....
        
       ___________________________________________________________________
       (page generated 2024-05-07 23:02 UTC)