Live data from Hacker News

Reflecting on the Soul of a New Machine

dtrace.org

41–50 of 50 posts

Re: Reflecting on the Soul of a New Machine

#41

Earlier quoted context omitted.

I wish I knew the answer to this, but I don’t. The closest I’ve come to succeeding at this is to have a reputation as a “breaker”. This really started in undergrad algorithms; I wasn’t great at finding solutions, but I had a knack for finding edge cases to break solutions others had come up with. Sometimes it just needed a tweak to work, sometimes it was “throw it all away and start over”. For the few times I’ve done…

Yes! Finally, a word — "breaker" — for my greatest talent, which I still haven't found a way to monetize in my 70 years and 8 months on the planet. I can unerringly and quickly find the FAIL point in most devices/methods/ideas/setups/systems/websites etc. in a savant-like fashion. Perhaps in the future I'll find someone who will pay me for my quirky skill.

Software QA. Not particularly prestigious but the pay is passable, more so if you can code well enough to automate tests or dig into the codebase to isolate the bug.

Re: Reflecting on the Soul of a New Machine

#42

Earlier quoted context omitted.

I'm having trouble finding the essay - can you give me some pointers?

The essay I remember is this one, which isn't nearly so harsh as what the patent comment suggests (but is a lovely read, with good advice): https://medium.com/message/deathhacks-b767903b7c15

That is worth posting separately.

Re: Reflecting on the Soul of a New Machine

#43
post #14

I took a valuable lesson from the book that has served me well over the years. At one point the CEO injects a critical piece of wisdom by telling the engineers they are not allowed to use a mode switch to preserve backwards compatibility. In any system, the presence of mode switches often points to where things will go wrong. If a system has two modes, then inevitably, one of them will be more unloved, untested, unde…

OTOH, in the context of a distributed system that has to be upgraded live and the deployment of new code has to be carefully staged across hours or days (e.g. a storage cluster with thousands of machines), such mode switches can be absolutely essential. The process can look something like this. * Roll out the code with support for a new feature * Flip the mode switch on a few nodes to use the new feature * Wait a whi…

A feature switch is not a mode switch. A feature switch in the 'on' position just gives. A mode switch gives and takes away in the 'on' position.

Re: Reflecting on the Soul of a New Machine

#44
post #39

Earlier quoted context omitted.

Yeah, these days what you are describing is simply utopy, at least according to my experience spanning a single decade across two startups and two large companies. Engineers, once they are hired and passed the interview, are mostly seen as a commodity, in the sense that, in the eyes of management, every non-junior engineer should exactly be able to come up with the correct idea (modulo a short phase of code review, j…

Effective agile teams practice swarming by minimizing the work in progress "inventory" and focusing all team members on a very small number of stories at a time. You can sell it to management in terms of adopting agile best practices and reducing the cost of delay. https://www.agilealliance.org/resources/experience-reports/s...

These bots are getting out of hand.

Re: Reflecting on the Soul of a New Machine

#45

Earlier quoted context omitted.

Yes! Finally, a word — "breaker" — for my greatest talent, which I still haven't found a way to monetize in my 70 years and 8 months on the planet. I can unerringly and quickly find the FAIL point in most devices/methods/ideas/setups/systems/websites etc. in a savant-like fashion. Perhaps in the future I'll find someone who will pay me for my quirky skill.

Software QA. Not particularly prestigious but the pay is passable, more so if you can code well enough to automate tests or dig into the codebase to isolate the bug.

Alas, I cannot code at all.

Re: Reflecting on the Soul of a New Machine

#46

I struggled with this a few times: “When a person signed up to do a job for him, he would in turn trust that person to accomplish it; he wouldn’t break it down into little pieces and make the task small, easy and dull.” I’m not particularly talented, far from it actually, but many times I’ve worked in teams with non-junior people who were tasked to do some portion of a project, and simply delivered garbage: a terribl…

When the coder is a peer and you’re not their mentor, manager, or lead, I normally keep code review comments to suggestions or questions - “What happens here in X scenario? Maybe we should refactor this part out into a stateless microservice?” That avoids the resentment and makes you look less like a control freak, but still shows your competency/foresight. If they choose not to take your advice, too bad for them, bu…

Other useful phrases: "Here, I was expecting to see...", "This code made me look at this other code and they cannot both be correct...", and "It took me a while to see why this is correct. We could save the next reader time by..."

Excellent code reviews take time and attention, which is why you need auto code formatting and $lang proverbs to take the uncontroversial stuff off the table early. Then you still have brain power left to give value from the review.

Also: work hard to earn a reputation as a fair but tough reviewer. Then when you need to be a prick, people will know it's important and let their ego down.

Re: Reflecting on the Soul of a New Machine

#47

Earlier quoted context omitted.

I wish I knew the answer to this, but I don’t. The closest I’ve come to succeeding at this is to have a reputation as a “breaker”. This really started in undergrad algorithms; I wasn’t great at finding solutions, but I had a knack for finding edge cases to break solutions others had come up with. Sometimes it just needed a tweak to work, sometimes it was “throw it all away and start over”. For the few times I’ve done…

Yes! Finally, a word — "breaker" — for my greatest talent, which I still haven't found a way to monetize in my 70 years and 8 months on the planet. I can unerringly and quickly find the FAIL point in most devices/methods/ideas/setups/systems/websites etc. in a savant-like fashion. Perhaps in the future I'll find someone who will pay me for my quirky skill.

security related positions, such as application penetration testing, physical pen testing, etc. all require the "security mindset" which is essentially the skill of thinking adversarily and breaking things.

Re: Reflecting on the Soul of a New Machine

#49
I read bits from the book in The Atlantic (I think) before I ever saw an MV. Some years later, my wife read the book for a class in her MBA program, and I read the whole thing.

A couple of points struck me then that may be of interest to the HN readership.

First, the instruction set originally proposed by the architect was very VAX-like. It would probably have been great for those writing in assembler. But the end was approaching VAX-like instruction sets.

Second, retaining the old Nova/Eclipse instruction set meant that one kept three general-purpose registers (well, sort of general-purpose: by convention, I think the stack pointer was in AC3). One also had no register-relative byte addressing.

I liked the Novas and Eclipses, and learned a lot working on them. But the RISC-based UNIX machines took over from the minicomputers pretty quickly.

[Edit: I don't think I've used an MV since about 1995--take any remarks with a grain of salt.]

Re: Reflecting on the Soul of a New Machine

#50
post #47

Earlier quoted context omitted.

Yes! Finally, a word — "breaker" — for my greatest talent, which I still haven't found a way to monetize in my 70 years and 8 months on the planet. I can unerringly and quickly find the FAIL point in most devices/methods/ideas/setups/systems/websites etc. in a savant-like fashion. Perhaps in the future I'll find someone who will pay me for my quirky skill.

security related positions, such as application penetration testing, physical pen testing, etc. all require the "security mindset" which is essentially the skill of thinking adversarily and breaking things.

I'm thinking no decent company is gonna hire a geezer like me for any job like this.
Post reply on HN