timhrothgar

This is an interesting find. Thanks for sharing. Here are my notes on the video:

What is (geotechnical) engineering judgement?

* Having a sense of proportion

* Solving the right problem

* Deciding reasonable criteria

Where does engineering judgement come from?

* Know the precedent: What has worked in the past? What has not worked in the past?

* Know the theory: Precedent will always be tested. How do you know if you're going to far?

How do you cultivate this engineering judgement?

* Choose a variety of work to apply your efforts: You might need a variety of jobs

* Keep a notebook: Keep a record of what you see. The power of observation is greatly improved by attempting to reconstruct what you saw

PS. This is the first time that I've noticed that HN formatting is atrocious.

Looking Glass Factory | Light field display company | Full-time | Remote (US) / NYC | https://lookingglassfactory.com/

We have our own 3D light field display technology and a custom graphics and media software platform. We also manage lots of tooling and plugins for popular 3D rendering engines. Our customers are primarily content creators, artists, and scientific application developers.

Why you should consider joining:

- Very interesting technical challenges in computer vision, real-time graphics, and embedded systems

- Growth opportunity (2x revenues and headcount over last 12 months)

- Very collaborative and inclusive culture

- Still lots of room for high impact for a motivated engineer

- Effective engineering management process

Our tech stack:

- Software: C, C++, C#, OpenGL, GLSL, Python, and Javascript

- Platforms: MacOS, Windows, Linux

- Hardware: Nvidia Jetson NX, RaspberryPi 4

We're looking for:

- Experience in our stack or similar technologies

- 3+ years experience working on production systems

- Pragmatic engineers who demonstrate strong ownership

- Bonus points for the following experience: Vulkan, DirectX, OpenGL, Unity, Unreal, AWS EC2/S3/RDS/Route53

Take a look at our postings: https://lookingglassfactory.com/careers

Completely agreed. The credible threat of termination drives employees to perform even if they also misbehave in other ways (e.g. CYA and office politics). Consider the Lesson of the Concubines by Sun Tzu:

"Sun Tzu then set the women a simple drill and made sure they understood what to do. However, when he started ordering them to perform the drill, the women burst out in laughter. He tried again with the same result. Sun Tzu claimed that this failure of the troops to obey was the fault of the commanders. So, despite the warlord’s pleas, he ordered the two concubines beheaded as an example for the rest of the company. Thereafter, the women did not utter a single sound and performed the drill exactly as commanded."

This is a depiction of Amazon. However, a "simple drill" is not high speed software engineering.

Interesting take! I think this would apply to me personally. Though, I'm uncertain if it impacts old and large codebases. They could've theoretically been maintained by intelligent, experienced, and disciplined engineers for a decade even if their standards changed.

I think that open source software (like Linux distros) may be the best examples because they tend to avoid the traditional "business problems" that I initially referenced in my question. But could these same contribution and management methods work for private enterprise? Maybe not...

This also matches my perspective. I was too cavaliere to make reference to software quality when in fact, I'm more curious about code quality. I think the implicit nature of the problem is a central component - because conceptual integrity can only be achieved (or maintained) through a greater appreciation for what is implicit vs explicit.

As such, perhaps its an unworthy goal to maintain high code quality over the long-term.

Care to expound?

That's a very interesting insight. Thanks!

I had this specific example in mind. How has Linux done it? Was it ultimately due to the benevolent dictator for life (BDFL) management practice?

I tend to agree when considering _new_ projects. A new project begins with a larger ecosystem of knowledgeable and experienced software professionals. This would include people tangent to software development (project managers, designers, executives, etc). I suppose the intent for asking the question was really something like, "how could or should one institutionalize quality improvement?" Maybe that starts with 1) ensuring that the business actually grows, 2) ensuring that the software actually works, and 3) ensuring that some flexibility is baked into management of software as an asset... or something along those lines.

It would seem that this factor is important for understanding how we got here. If the hail-mary fails, nobody will notice. But sometimes it succeeds and when it does the engineers at said startup typically build upon a rotten core.

These are all good points. But most of them also seem like cultural factors too.

Perhaps I should update the question. I'm not referring to ALL software quality. I'm referring to the quality of codebases that are 1) old, 2) large, and 3) supported by many people.

You make a good point though. Perhaps I just miss the good ol' days of working on small teams with small codebases that were pretty easily maintained.

If anyone is interested in creating holographic technology with us, we're hiring! https://lookingglassfactory.com/careers