GrumpyYoungMan

You describe impact based on the scope of your job role. Most of the things you do day to day could conceivably be phrased of "I am doing my job and I overcame unusual challenge X / did Y to prevent the problem from occurring next time / taught Z to my coworkers to improve the team." List out those things, take out "I did my job..." part (because doing your job is the bare minimum) and put out those extra things on your resume as your impact.

Contrary to what others say, don't make stuff up unless you're a particularly skilled liar. If you have to ask the questions you are asking, you aren't.

The author's other videos are also worth a look for those interested in physics, particularly the ones that visually show what occurs under various conditions at relativistic speeds. It is astonishing, not to mention trippy, to see the contortions of space-time differing depending on which direction relative to the axis of travel that one is looking.

No, they are managers; management and leadership are different things. Being a manager is a set of things that a person is authorized to do on behalf on their employer, "hire, command work and fire" as you said being examples. Leaders nurture their staff so that they work together effectively as a team to achieve goals. Very few managers are good leaders.

Having had to estimate peak user traffic patterns, bandwidth usage, etc. for continent-scale services, Fermi estimation questions (https://en.wikipedia.org/wiki/Fermi_problem) are excellent questions for people working at the largest scales. Even if the guessed inputs or formula for the estimate are imperfect, being able to bang out an approximate formula that can brought out for discussion with peers and refined into something that can be agreed upon as a target is extremely valuable. It's not a useful skill for everyone but for those aspiring to be more than a mere coder, it's worth knowing.

> "I assumed that people who enjoy software would be into intellectual stimulation but I've learned that this is wrong."

It was truer in the 1980s-1990s, when programming was not a prestigious or high paying job and computers were much cruder and required much more skill to get adequate performance from them. Generally, aspiring hackers were very well read people.

There were, of course, corporate programmers doing business programming back then too but they weren't considered hackers and wouldn't even have wanted themselves to be considered hackers.

We're already seeing it if most are incapable of recognizing it. The chip folks aren't doing ridiculously complicated things like https://spectrum.ieee.org/semiconductor-technology-roadmap in $30 billion+ fabs for the fun of it.

There's a very old paper by Cem Kaner about the meaninglessness of "100% coverage" where he included an appendix where he enumerates 101 different possible types of code coverage: https://www.researchgate.net/publication/243782285_Software_...

In what way? RF test equipment is costly and so is building a home electronics lab.

> "...stuck with hardware out of passion..."

At least you don't hate your job, I hope? The recent maturation of AI revealed how many people in software seemingly loathe their own profession.

> Fred Brooks "throw one away" philosophy

Everybody remembers that soundbite but nobody remembers that he changed his mind about it later and switched to advocating iterative refinement.

> "FPGAs reconfigured during program execution to speed up hot paths"

The IEEE conference on Field-Programmable Custom Computing Machines (https://www.fccm.org/) is in its 34th year, to give you an idea of how old that idea is. The answer to your question is both 1 and 2 and also 3. that FPGAs have rather poor efficiency, both in terms of cost and performance, so it's not worthwhile outside of a few niches.

Developer testing is checking whether the code does what the developer themself thinks it should. QA testing is checking whether the code does what the customers / users / rest of the world thinks it should.

My frequent "senior moments" are what make me senior. (ba-dum-tish)

Terry Pratchett's Going Postal seems particularly apropos these days as we have Reacher Gilts aplenty in tech news headlines.

Obscure and a bit dated but Bruce Betkhe's Head Crash is hilarious if you've been deeply immersed in the software industry.

The problem with that quote is that all of us reading this are telescope operators, not astronomers. The quantity and quality of our telescope photos is what we are paid for so we have no choice but to know our chosen brand of telescope inside and out.

The things you list illustrate @aplamers point that software "doesn't really kill people". If you asked the average person on the street, they might just barely remember the Boeing incidents and the rest they probably have never heard of. Even something as gruesome as the Therac-25 incident is probably unknown to most.

It's the rising tide of low-level everyday harm from software that is going to motivate the public to start coming after the software industry.

> "How many centuries did it take for civil engineering, for example, to become the codified, standardized, and respected calling it is now?"

But the software industry is not starting from centuries ago. We have the benefit of modern education and literacy rates, instantaneous global communication, centuries of experience and data in other life and safety critical fields to draw on to understand how to establish a reasonable level of safety in the face of uncertainty, vast libraries of knowledge and data that can be called upon online, and nearly a century of increasing regulation and professionalization in those fields. Sorry but that doesn't hold up to scrutiny.

Software "engineering" doesn't kill people instantly in a flashy way, sure, but it has become more like leaded gasoline, a widespread low-level harm whose effects are increasingly evident in hindsight. You pretty much can't go more than a couple of days without hearing about another massive consumer data compromise by hackers, CVE, major services outage, etc. At some point, there is going to be a software related incident that is bad enough that the public and government is going to demand accountability.

"Is the company consistently profitable or not?" and "Are revenue and profits growing over time, stable, or declining?" are very important questions to answer, particularly if stock grants are part of the compensation package.

For developers who work on products, getting a sense of whether the product of the team you'd be joining is a core part of the business versus speculative (i.e. stable vs likely to have layoffs) and how successful the product is in the marketplace (teams for products that are failing also are likely to be victims of layoffs) are also very important to understand.

Casual of research shows that the ACM's Code of Ethics can be traced back to its Guidelines for Professional Conduct in Information Processing dating back to 1966 (https://www.acm.org/code-of-ethics/1966-acm-code) and the IEEE's Code of Ethics can be traced back to a precursor organization's Code of Professional Conduct dating to 1912.

TDD is a development methodology, not a testing methodology. The main thing it does is check whether the developer implemented what they thought they should be implementing, which is not necessarily what the spec actually says to implement or what the end user expects.

Early in my career, the raise and put it entirely towards retirement savings. Later in my career, the free time.

Debuggers are great until you have to work in a context where you can't attach a debugger. Good old printf works in every context.

By all means, learn to use a debugger well but don't become overly dependent on them.

The *.home.arpa domain in RFC 8375 has been approved for local use since 2018, which is long enough ago that most hardware and software currently in use should be able to handle it.

The fabs propped up the corpse of Moore's Law by throwing mountains of cash at expanding transistors into the third dimension: finFET, GAA, CFET, etc. That has kept the party going a little while longer than it would have lasted but it's a one-time deal since are no more dimensions to expand into.

The issue with scrum and agile is that it became a managerial and reporting process to force teams to hit a management imposed deadline instead of what it was intended to be: a tool for engineers to self-manage and self-evaluate their progress to provide a realistic completion date.

Vastly? I dunno about that. I was rather fond of Tanenbaum's Structured Computer Organization.

Sure, okay, but we can add that variance to the simulated load if it turns out to be meaningful for the system under test.

That battle has been lost. Dell's Ultrasharp U30xx 30" monitors were the last large 16:10 monitors I was aware of and it looks like Dell doesn't even make them anymore when I just checked.

There is another Battlezone game which is a reimagined/updated version of the coin-op game: https://en.wikipedia.org/wiki/Battlezone_(2016_video_game). It was a decent bit of fun and notably had VR headset support.