From Newsgroup: sci.electronics.design

My colleagues have been bandying about various "quips" that
encase "good engineering wisdom" in playful quotes.

My favorites, to date:

"If you can't describe (in prose) what you're doing, then you're
doomed to wasting time trying to sort out what you REALLY want to
achieve -- and mistakenly claiming that all to be 'Engineering'"

"The sooner you start, the longer it will take"

Both leverage the notion of having some sort of specification
that defines your goal -- so you know where you are headed
and when you've attained it.

There are others, of course, but many are old saws ("if it
doesn't fit in one brain, it's too complex"; "it should fit
on one *page*"; etc.)

Beyond that, there are far too many that address "specifics"
instead of The Big Picture.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

"Don Y" <blockedofcourse@foo.invalid> wrote in message news:115t08f$dcr7$1@dont-email.me...

My colleagues have been bandying about various "quips" that
encase "good engineering wisdom" in playful quotes.

My favorites, to date:

"If you can't describe (in prose) what you're doing, then you're
doomed to wasting time trying to sort out what you REALLY want to
achieve -- and mistakenly claiming that all to be 'Engineering'"

You're reminding me of
https://www.youtube.com/watch?v=BKorP55Aqvg

"The sooner you start, the longer it will take"

Both leverage the notion of having some sort of specification
that defines your goal -- so you know where you are headed
and when you've attained it.

And this
https://www.google.com/search?q=tree+swing+cartoon

There are others, of course, but many are old saws ("if it
doesn't fit in one brain, it's too complex"; "it should fit
on one *page*"; etc.)

Beyond that, there are far too many that address "specifics"
instead of The Big Picture.

An this
https://www.google.com/search?q=in+the+beginning+was+the+plan


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 8/16/2026 12:03 PM, Edward Rawde wrote:

"Don Y" <blockedofcourse@foo.invalid> wrote in message news:115t08f$dcr7$1@dont-email.me...

My colleagues have been bandying about various "quips" that
encase "good engineering wisdom" in playful quotes.

My favorites, to date:

"If you can't describe (in prose) what you're doing, then you're
doomed to wasting time trying to sort out what you REALLY want to
achieve -- and mistakenly claiming that all to be 'Engineering'"

You're reminding me of
https://www.youtube.com/watch?v=BKorP55Aqvg

Corporate environments are full of people protecting turf -- their
own notion of relevance. For a project to succeed, it has to do so
IN SPITE OF these leeches.

"The sooner you start, the longer it will take"

Both leverage the notion of having some sort of specification
that defines your goal -- so you know where you are headed
and when you've attained it.

And this
https://www.google.com/search?q=tree+swing+cartoon

That's why you have domain experts instead of letting the
engineers/designers decide what they're going to build.

I listened to a (very competent!) engineer explain his
"revolutionary" solution to a particular design problem
(we have historically designed devices that are self
calibrating and validating). When he was done, I pointed
out that he had presented a circular argument -- that A
relied on B relied on C ... relied on A.

Of course, every individual step made perfect sense. But,
until you looked back at it objectively, you couldn't
see how your assumptions enabled your other assumptions
(and none was based on the reality on the ground).

I.e., calibrate this by relying on the fact that THAT is
calibrated (which, in fact, had been calibrated by relying
on the fact that THIS was calibrated!)

There are others, of course, but many are old saws ("if it
doesn't fit in one brain, it's too complex"; "it should fit
on one *page*"; etc.)

Beyond that, there are far too many that address "specifics"
instead of The Big Picture.

An this
https://www.google.com/search?q=in+the+beginning+was+the+plan

I see more project "wander" as they try to sort out what they are
trying to do -- simply because they "set off on foot" without
a map, compass or intended destination. Great if you are paid
by the hour but foolhardy, otherwise!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 16/08/2026 19:41, Don Y wrote:

My colleagues have been bandying about various "quips" that
encase "good engineering wisdom" in playful quotes.

My favourite is that you need to split every level down to 7 +/- 2 sub
levels to stand a chance of being able to implement it reliably.

Ironically my Cyclic Complexity Index tool does not pass this test!

My favorites, to date:

"If you can't describe (in prose) what you're doing, then you're
doomed to wasting time trying to sort out what you REALLY want to
achieve -- and mistakenly claiming that all to be 'Engineering'"

"The sooner you start, the longer it will take"

+1

Or put another way:

Until you actually know where you want to go setting off is premature.

The management suits side of it was distilled to a mantra in my project management course: WHISKY - Why Isn't Sammy Coding Yet ?

That said managing software engineers *is* like herding cats.

My other favourite applicable to all project management is:

When you are up to your arse in alligators it is hard
to remember that the objective is to drain the swamp.

Both leverage the notion of having some sort of specification
that defines your goal -- so you know where you are headed
and when you've attained it.

+1

The other important one is never underestimate the stupidity of users
to do really dumb things even when you *warn* them of the consequences.
e.g.

DO YOU *REALLY* WANT TO WIPE YOUR ENTIRE HARD DISK ?
- EVERYTHING WILL BE DESTROYED (Y/N)

A worrying proportion of people still press "Y" :(
--
Martin Brown

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

Martin Brown <'''newspam'''@Nonad.co.UK> wrote: |-----------------------------------------------------------------------|
|"[. . .] never underestimate the stupidity of users |
|to do really dumb things even when you *warn* them of the consequences.|
|[. . .]" | |-----------------------------------------------------------------------|

Truly.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 8/16/2026 1:10 PM, Martin Brown wrote:

On 16/08/2026 19:41, Don Y wrote:

My colleagues have been bandying about various "quips" that
encase "good engineering wisdom" in playful quotes.

My favourite is that you need to split every level down to 7 +/- 2 sub levels
to stand a chance of being able to implement it reliably.

Ironically my Cyclic Complexity Index tool does not pass this test!

I see that as a consequence/manifestation of the "fit in one brain"
mantra. Cut a task into chunks that you can COMPLETELY wrap your
head around -- and explicitly define any assumptions you make
(better yet, codify them with invariants, keyed connectors, etc.)

My favorites, to date:

"If you can't describe (in prose) what you're doing, then you're
doomed to wasting time trying to sort out what you REALLY want to
achieve -- and mistakenly claiming that all to be 'Engineering'"

"The sooner you start, the longer it will take"

+1

Or put another way:

Until you actually know where you want to go setting off is premature.

The management suits side of it was distilled to a mantra in my project management course: WHISKY - Why Isn't Sammy Coding Yet ?

IMnsHO, that's been reified in Agile: just start and THEN sort
out that you're headed in the wrong direction!

Said another way: "I don't know what I want -- but, if you spend
time building SOMETHING, I can tell you that it's NOT what I want!"

But, a lot of developers (HW & SW) seem to think picking up a pen
*soon* is a good way to get done quicker. I spend a shitload of time
just "cogitating" about the model I want to map onto the problem.
Then, poking holes in it to verify that it really *does* fit the
problem -- or, why it deviates.

So, when I actually pick up a pen, I know the boundaries of the
module that I will be implementing WITHOUT worrying about the other
modules (because they've already been conceived as independant
entities)

That said managing software engineers *is* like herding cats.

I think that is largely because the folks who manage software
projects aren't particularly "skilled in the art". And, those
that are, quickly lose their skillsets and intuition for the
process.

My other favourite applicable to all project management is:

When you are up to your arse in alligators it is hard
to remember that the objective is to drain the swamp.

"If you're in a hole, STOP DIGGING!"

Both leverage the notion of having some sort of specification
that defines your goal -- so you know where you are headed
and when you've attained it.

+1

The other important one is never underestimate the stupidity of users
to do really dumb things even when you *warn* them of the consequences.
e.g.

DO YOU *REALLY* WANT TO WIPE YOUR ENTIRE HARD DISK ?
- EVERYTHING WILL BE DESTROYED (Y/N)

A worrying proportion of people still press "Y" :(

The lip side of this is developers who don't make it clear *which*
disk is going to be affected. "sda" and "sdb" don't mean squat
to most users. Would it kill you to take whatever information
you have on the available choices and present it in a non-nerdy
manner? So even *nerds* can resolve any ambiguity?

E.g., *describe* the drive (make, model, capacity) AND ITS CURRENT
CONTENTS (unformatted, NTFS partitioned, etc.) so the user can
have a chance at making an INFORMED decision. For example, if
I select the formatted drive to be operated on, leaving the UNFORMATTED
one "as is", you might want to prompt me: "Why are you looking to
copy the contents of the unformatted drive onto the formatted drive
THAT ALREADY HAS CONTENT???"

But, people have simplistic models of the world. I worked PT for
a hand tool manufacturer. Some of the litigation that came
along was mind-numbing: "You don't mean someone was THAT stupid??"
(yes, and here are their medical bills to prove it!)

OTOH, in each case, you could see how a simpleton's view of the world
would lead someone to thinking that what they were doing made sense!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design


I've been telling people: Those comments you put in your code are for
your future self, and should answer the question "what the hell were you thinking?"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 8/16/2026 5:18 PM, DJ Delorie wrote:

I've been telling people: Those comments you put in your code are for
your future self, and should answer the question "what the hell were you thinking?"

Comments should add value -- not restate what the code is already
unambiguously stating.

Many developers never revisit their code so you can't rely on
The Next Guy to understand your design choices. The same is
true of hardware designs -- if you do something that looks
a bit out-of-the-ordinary, justify your design choice.

E.g., I used Boyer-Moore in an application that would likely
have confused anyone not familiar with it or its advantages,
especially in that specific implementation. So, I explained
my "why" and included a reference to the original paper,
assuming anyone interested (or, tempted to tinker with my
implementation) would track it down.

Where possible, comments about what is *happening* in the code
should take the form of invariants as this also verifies the
integrity of the code at those points.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 17/08/2026 01:45, Don Y wrote:

On 8/16/2026 5:18 PM, DJ Delorie wrote:

I've been telling people: Those comments you put in your code are for
your future self, and should answer the question "what the hell were you
thinking?"

Comments should add value -- not restate what the code is already unambiguously stating.

I recall a friend recounting how he had left an undocumented as to why
it was done booby-trap in some kernel code for a particularly obnoxious know-it-all to trip over after he had left the company.

He was spot on about what would happen. The OS slowed down considerably
as a result of the "obvious optimisation" that know-it-all found.

Many developers never revisit their code so you can't rely on
The Next Guy to understand your design choices.-a The same is
true of hardware designs -- if you do something that looks
a bit out-of-the-ordinary, justify your design choice.

It is particularly important when you are doing something that is intrinsically complicated like transposing big matrices in place in a multi-level cache aware routine. You only want to do those sorts of
tricky ice-pack-on-head calculations once and make it clear how all the
magic numbers have been derived for when things change in the future.

Today there are libraries like BLAS with highly optimised routines
derived from those early hand written academic codes.

Where possible, comments about what is *happening* in the code
should take the form of invariants as this also verifies the
integrity of the code at those points.

Sometimes you can get caught out by invariants. There are too many other orthogonal rotation transforms that are not quite FFTs for example.

You have to test that for a few simple cases the one way application of
the algorithm gives the expected result. I always liked using
spreadsheets to make test data because the odds of making the same error
in that environment as in in procedural language was almost nil.

For most of my work the generation of test data from correct answers was relatively easy, but the inverse problem was fiendishly difficult.
(and that was what we wanted to solve for real experimental data)
--
Martin Brown

--- Synchronet 3.22a-Linux NewsLink 1.2