Mantras for developers

Aug 16, 2026 Last reply: 26 minutes ago 5 Replies

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.


You're reminding me of

formatting link

And this

formatting link

An this

formatting link

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.

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!)

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!

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!

+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.

+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 <'''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.

formatting link
fuer Kontaktdaten!)

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.)

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)

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.

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

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!

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required