I just spent a very long time debugging a problem that, had I been looking at someone else's code I would have spotted straight away.

By way of confession...

I have a really nice new board from LILYGO and it has an ESP32-WROVER and 4 relays on it.

Because of an odd way they do the USB programming (a proprietary USB dongle which is included if you buy the "relay set" option) my usual MacOS platform was not working. There is some incompatibility with the chipset that doesn't have a definitive solution yet. So I moved over to the ThinkPad I use when I must use Windows to try it there.

Because the Arduino installation on that machine isn't as fully populated with libraries and my own programs. To simplify¹ things, I decided to upload the blink sketch to check that I could put a binary on the board. The first attempt to upload it resulted in an error. The LED_BUILTIN constant was not defined in the ESP32 DEV core. So, I put in a define, guessing at the pin that seemed to be the LED on the board.

It worked! But, it was not the board's LED flashing but the first relay and its associated LED. That gave me the idea to adapt the script to test all four relays. So I looked up the pins for the 3 others, and added them. But, it just didn't work. The first relay worked but the rest did nothing. I went through all sorts of contortions to try to get it to work, even traced the pins on the hardware and trying those numbers.

Then I changed the LED_BUILTIN define to the pin of the second relay. It worked! I was getting pretty annoyed. That's when it struck me. I had totally forgotten to add in pinMode() statements for the additional pins, so of course it didn't work!

So, I felt like a bonehead. This seemed an appropriate assessment but it got me thinking. If someone else had done the same thing, and said that of themselves, I would have objected knowing very well how blind we can be to things right in front of us when we are focused on something else.

Lately, I have been doing a lot of thinking about practicing self kindness. That is, not beating myself up because I have limitations, or make mistakes of the sort everyone makes. I am not better than other people in a way that I should judge myself more harshly that I would them. If I had been negligent there might be a reason for some self criticism, but I was just being normal.

It is exacerbated in my case because I suffer from ADHD. It has been a lifelong problem and the effects it has on attention and related functions can be very profound. If I have a "bad day", I need to just avoid trying to do anything important because there is a real danger I will make a mistake that I don't spot at all. Fortunately, treatment is very effective and though I waited far too long to do something about it I now have medicine that works very well.

I am willing to bet that a number of people reading this are fellow sufferers²—diagnosed or not—and you will understand what I am talking about. But you don't have to have ADHD to get so focused on a particular aspect of a problem that you don't see what someone uninvolved could spot in seconds.

All of us should practice self kindness because "do to others what you would want done to you", or whichever version of the Golden Rule you prefer, isn't very nice for others if you don't want kindness for yourself. You and I are not boneheads, we are jus people.

1. As I well knew, and didn't pay attention to, a shortcut is rarely a simplification. It's just a way to spend as much—or more—time but feel like you got a head start.

2. Engineering and computer science, and less formal versions of both, are very attractive to people with ADHD because of many of the characteristics of the activities and so we are over-represented in these fields.

 

As a senior in high school, I sat down for my first class in Chemistry and was presented with a sealed cigar box. Our task for that period was to determine what if anything was inside the box. This was a creative way of seeing if we had the facility to understand without being able to see. This lesson was essential for my embarkation on a career in software development given the crude debugging tools of that era. Even though our tools were crude the process of stepwise elimination of possibilities reduced the remining causes to a manageable set. I never beat myself up for not seeing the problem quickly.

 

I think that we have all missed simple things like that. If you do a lot of almost anything, a mistake is likely to sneak in somewhere sometimes. The key is not to ship the problem to a client.

 

Faults will always seek out a certain type of client.

 

What is the most bonehead thing I have done that I can recall?

I was doing PM on a DEC PDP-15 minicomputer. It consisted of three 19-inch racks the size of three fridges bolted together. There are about a dozen muffin fans in this beast. I knew that occasionally a fan will stop working and needed to be replaced.

Most of the fans I could see. There was one set of three I could not see. Without thinking I reached in with my hand to feel if it was spinning. I stuck a finger into the fan blades. Confirmation, yes it is spinning. No, it’s no longer spinning because I just broke the fan blades.
Fortunately for me, my fingers came out without a scratch.

 

I’d wear out my keyboard typing, changing, retyping, changing, etc. trying to get my biggest boneheaded move out. Not a ton of repeats though, so that’s good.

I like the idea of going easy on myself and others. Purposefully.

 

In all honesty, I try to go easy on other people when they make mistakes (except if they repeat those mistakes frequently, or when it's a matter of safety) and it's not hard for me to forgive others ... but I do tend to be a little hard on myself... here's an example showing a snippet of my code along with my own comments and observations:

​

Truth being told, I've always found it a bit hard to forgive myself whenever I screw up. There are mistakes I've made in the past that most people I care about have easily forgiven or forgotten. But dang it, in my case many of those events cling to my emotional memory and and won't let go.

 

It happens to the best of us. I don’t mind mistakes, it always seems to lead to some sort of understanding beyond the current understanding.

 

In all honesty, I try to go easy on other people when they make mistakes (except if they repeat those mistakes frequently, or when it's a matter of safety) and it's not hard for me to forgive others ... but I do tend to be a little hard on myself... here's an example showing a snippet of my code along with my own comments and observations:

View attachment 273926​

Truth being told, I've always found it a bit hard to forgive myself whenever I screw up. There are mistakes I've made in the past that most people I care about have easily forgiven or forgotten. But dang it, in my case many of those events cling to my emotional memory and and won't let go.

TL;DR: This is an apparently discursive jaunt into ethics, mysticism, and engineering but I promise that it contains some of the most important things I've learned in my life about these things. To sum up: "tough love is a good start but there's a lot more to it". Read on if you enjoy my sort of screed...

Yes, this is just the thing. As a person you who habitually practices the Golden Rule, don't forget how upset you would be with yourself if you were to see how you treat you without the blinders on. Kindness starts with ourselves. It is very much like a person who can't stand to see people suffering with money bankrupting themselves by giving everything they have away.

Now they can no longer help, and they become dependent. I find, though I will quickly and freely admit I am far from perfect at it, that when I am feeling most tolerant of myself I can be more tolerant of others who might otherwise provoke responses I regret.

↓*As an aside, your point about safety is important. If a person is a danger it is not kindness to anyone to ignore that danger. It doesn't help that person who will hurt others—something one hopes they will grow to regret—and it certainly twists the kindly concern from victim to perpetrator if you don't deal with the harm being done.

We can account for the factors that lead to bad actors, real things that they had done to them without fault of theirs, without ignoring the bad actions. Both must be addressed. In the Jewish mystical tradition, there is an abstract model for the world which, somewhat jarringly, is repeated with little difference in the OSI Network Model. (An observation, and a topic for some other time if ever).

In that model there are layers that interact. In an oversimplified but cogent subset, I will just take three of them. (As an aside, this condensation of the idea has served me very well applied to all manner of engineering problems and systems design).

The entire thing is called the Sephirotic Tree. Or simply, the ספירות (sephirot¹ ). For our purposes just three of the seven layers are important. Living near the top of the tree are גבורה ,חסד, and תפארת.

• חסד (ches-ed, where the "ch" is like more the German as in "Bach" and nothing like the English as in "cheese".)

Chesed means loving kindness in Hebrew, it is an important idea and even included among the 13 attributes of God. Chesed is an expansive principle. It is about opening and giving. It sits on top of the three, as a sort or source, and passes through גבורה like a filter leaving us תפארת.​

​

• גבורה (gev-oo-`rah [modern] or ge-voo-rah [Ashkenazic])

Gevurah means strength but also can be translated as awe among other related things. This is the principe of constraint, of contraction. It stands in distinction to chesed, but is never on its own in practice. Chesed and gevurah are always paired together in practice producing the third layer: תפארת​

• תפארת (tee-fer-'et [modern] or 'ti-fer-es [Ashkenazic])

Tiferet means beauty but also things like splendor and glory. This is the principal of the optimum. It is the output of the gevruah "filter" with the chesed input. It is the balanced result—the practical best, the elegant, the optimal.​

This three layer model implies a process which I have applied to every engineering project I have worked on.

First,

create a set of specifications without regard to immediate constraints and free of any implementation details. "blue sky thinking". This permits a freedom of thought that sometimes provides insights into structural choices that will best support expansion of scope without needing to tear things down and begin again.​

​

By trying to give everything you will always find some things you can give that you'd have assumed not possible given presumptuous constraints. Our brains ignore the impossible without even examining it, but on examination sometimes the impossible is the practical if we make changes well within the real constraints. That is why it is very important the the chesed phase must be about principle, not addressing things rightly seen as constrained by practice as it will often change practice.​

Second,

Pass the output of chesed through the filter of gevurah. Gevurah is all about implementation, about resources, methods, and limits. The principles of the chesed phase must find a way to be passed by the practices of the gevurah filter. This may mean modifying things, even discarding them but always in the light of the principles that are the reason for doing the thing in the first place, which came from the chesed analysis.​

​

This is optimization but with a clear understanding of what is being modified. Not a list of requirements that are part design ("a way to store bicycles") and part implementation ("it must be blue"). If done right, the result is a robust, sustainable, and scalable project, within budgetary limits (time. money, resources) and not infrequently with features that originally seemed impractical but now flow naturally from the structure.​

Third,

The result of this process is the practical manifestation of some idea—tiferet. It is what an idea properly treated becomes when it is made to exist in the world. It represents beauty in the same way that you can look at an engineering solution of a tough problem and say, "that's beautiful". We say this because we see the physical realization of some idea in the face of constraints that might otherwise seem to make it impractical if not impossible.​

​

This, when it works as it should and we'd hoped is the sort of thing we look ack fondly on as a real success. One that even seems to be more clever than we, the creators, were in the creation of it. It solves problems that arise but where never explicitly contemplated. It accumulates very little if any cruft. It allows for growth in both scale and scope with minimal pain if the resources become available to support that.​

I use this methodology, not in some formal way but heuristically, at every level of a project. Literally from choosing variable names (something never to be taken lightly) to creating the permission structure for ACLs (Access Control Lists), to designing the architecture for a LAN, and everything in between. It works brilliantly. You might even already be using a form of it without having examined what you do.

→*Now this was a very long way around to the point I make above, but I hope you will excuse an old man who can help but talk about the beauty of the principles he's learned in the world.

The idea is this. When we treat the oppressor with chesed (and we always should) but in the absence of gevurah (which would make the result completely upside down) we do damage to the world, that is, as defined by the people in it, rather than improving anything.

So kindness to the scoundrel means, sometimes, stopping them with force from continuing to destroy the innocent. Sometimes it means forgiving but not forgetting. Sometimes it means overlooking personal hurt for a greater collective result. There is no formula, only a set of principles agains with each case must be tested.

(In my opinion) we must always be kind, even to the worst of people we encounter. But what it means to be kind cannot be determined without both chesed and gevurah. Sometimes it is the act that looks for all the world like gevurah that is the kindest possible, and even the reverse can be true—gevurah practiced via chesed.

So, there you have another long explanation that you can read or ignore. When it comes to providing information my gevurah is often overwhelmed by my chesed. Demonstrating that sometimes giving can be a punishment.

——
1. ספירות is pronounced sef-ee-'ro︤t in Modern Hebrew and sef-eeros in traditional Ashkenazic Hebrew. In the former case the emphasis is in the last syllable, the latter has about equal emphasis. The "ת" is the last letter, Hebrew running right to left.

In Modern and Sephardic Hebrew is it pronounced like the English "t" but in Ashkenasic Hebrew there is a distinction between two forms: ּתּ (tav, like t) and ת (sav, like s). The "ot" or "os" ending indicates a feminie plural.

In our case, the singular would be ספירה wihch is pronounced the same but the ending is "ah" not "ōt/ōs".

Either pronunciation is acceptable but as you can imagine the debate among Hebrew speakers mirrors the debate about how to pronounce the file extension "gif".

[EDITED: unjumbled some wordy bits to make more sense]

 

Making a large 7 digit display for a truck weigh scale today. It receives values over Ethernet (Telnet protocol) from a computer running a Python script which gets data from a load cell amplifier over RS485, and displays the weight on these big 7-segments.

This is how it looked Friday:




Here's how it looked today:



It was a comedy of errors. The inverse of "too good to be true" - that is - "too terrible to be coincidence." The universe pointed out that I am in fact an idiot, and drove the point home repeatedly.

I now have 3 arduinos in various states of unrecoverable stupor and 3 dead 7-segments. How I killed them, in order:
1. Connected reverse polarity 24VDC to everything
2. Realized the polarity reversal, replaced arduino, Connected correct polarity 24VDC to everything.
3. Realized I connected 24V instead of 12V, replaced arduino, Connected 12VDC to everything.
4. Realized I connected 12V to the 5V output of arduino instead of the 12V input. Replaced arduino, Connected 12VDC to everything.

I think the 3 bad 7-segments are still good, just the SIPO shift registers on them suffered negligent homicide. I have more on order (along with replacement arduinos).

It was 100% a problem of complacency. I got too comfortable, thought I was past such noobish mistakes. I knew I should have taken it one step at a time, Arduino to a single digit on the workbench, then add another digit, and so on. Assembling the final product should have been the last step. But I told myself "this is child's play, and there are deadlines. Just build the damn thing." So I fully assembled it and then powered it on. After each failure I said "that was so stupid, there's no way I screwed up anything else like that." Except I did. It would have been a lot easier to spot the mistakes if it wasn't assembled inside the enclosure like that.

I ended up doing the one-step-at-a-time exercise on workbench anyway, but with the added time of assembly, disassembly, reassembly, and troubleshooting and testing things that otherwise could have been assumed good.

Burned up $120 worth of stuff. Feel super smart. Go me!

 

Making a large 7 digit display for a truck weigh scale today. It receives values over Ethernet (Telnet protocol) from a computer running a Python script which gets data from a load cell amplifier over RS485, and displays the weight on these big 7-segments.

This is how it looked Friday:

View attachment 275198


Here's how it looked today:

View attachment 275199
View attachment 275205View attachment 275198View attachment 275199View attachment 275204View attachment 275205
It was a comedy of errors. The inverse of "too good to be true" - that is - "too terrible to be coincidence." The universe pointed out that I am in fact an idiot, and drove the point home repeatedly.

I now have 3 arduinos in various states of unrecoverable stupor and 3 dead 7-segments. How I killed them, in order:
1. Connected reverse polarity 24VDC to everything
2. Realized the polarity reversal, replaced arduino, Connected correct polarity 24VDC to everything.
3. Realized I connected 24V instead of 12V, replaced arduino, Connected 12VDC to everything.
4. Realized I connected 12V to the 5V output of arduino instead of the 12V input. Replaced arduino, Connected 12VDC to everything.

I think the 3 bad 7-segments are still good, just the SIPO shift registers on them suffered negligent homicide. I have more on order (along with replacement arduinos).

It was 100% a problem of complacency. I got too comfortable, thought I was past such noobish mistakes. I knew I should have taken it one step at a time, Arduino to a single digit on the workbench, then add another digit, and so on. Assembling the final product should have been the last step. But I told myself "this is child's play, and there are deadlines. Just build the damn thing." So I fully assembled it and then powered it on. After each failure I said "that was so stupid, there's no way I screwed up anything else like that." Except I did. It would have been a lot easier to spot the mistakes if it wasn't assembled inside the enclosure like that.

I ended up doing the one-step-at-a-time exercise on workbench anyway, but with the added time of assembly, disassembly, reassembly, and troubleshooting and testing things that otherwise could have been assumed good.

Burned up $120 worth of stuff. Feel super smart. Go me!

This is the sort of knowledge one wishes we could pass on to our kids through our genes ... but no, stupidity is a very personal thing and fortunately (as far as I know) it is not inherited.

If I were to narrate every story that I have that is similar to the one that you've just told, I'd need to hire a professional editor so as to keep it within a normal person's attention span.

Sufficie it to say that one of the most important pearls of wisdom that I've ever been gifted had its source in an angry client that, after a bunch of inexcusable delays in a project exhausted his patience, said to me:

"You know what Ed?, you suffer from the freaking genius syndrome... you're a pretty smart guy, but exactly because of that you tend to think that every step in a complex project will go easy and smooth ...well, newsflash! ... it never freaking is like that!"

After that experience, my rule of thumb has been to pay as much attention to the easy stuff as to the harder parts ... and although I still slip every once in a while, it no longer happens as often as in yonder days.

PS: my gringo friends call me Ed, cause that's my middle name and they’re more comfortable with it.

 

Sufficie it to say that one of the most important pearls of wisdom that I've ever been gifted had its source in an angry client that, after a bunch of inexcusable delays in a project exhausted his patience, said to me:

"You know what Ed?, you suffer from the freaking genius syndrome... you're a pretty smart guy, but exactly because of that you tend to think that every step in a complex project will go easy and smooth ...well, newsflash! ... it never freaking is like that!"

After that experience, my rule of thumb has been to pay as much attention to the easy stuff as to the harder parts

When bidding a job I typically double the number of hours I think it will take and still, more often than I like to admit (to myself), it isn't enough.

I will take the pearl you have offered. I can't promise it will be thoroughly digested as I've already earned it myself a few times, but maybe it will last a year or so.

 

When bidding a job I typically double the number of hours I think it will take and still, more often than I like to admit (to myself), it isn't enough.

I will take the pearl you have offered. I can't promise it will be thoroughly digested as I've already earned it myself a few times, but maybe it will last a year or so.

Dude ... a pearl, by definition, is a product of indigestion... good luck...

 

Making a large 7 digit display for a truck weigh scale today. It receives values over Ethernet (Telnet protocol) from a computer running a Python script which gets data from a load cell amplifier over RS485, and displays the weight on these big 7-segments.

[...]

I ended up doing the one-step-at-a-time exercise on workbench anyway, but with the added time of assembly, disassembly, reassembly, and troubleshooting and testing things that otherwise could have been assumed good.

Burned up $120 worth of stuff. Feel super smart. Go me!

That project looks very cool. The construction looks excellent. Nice work.

There are days when the superpositions of distraction, fatigue, and lock of the bad kind crate a peak on the error rate that our actual ability doesn't account for. It sometimes help to realize we get the gift of the opposite, too, when things align to make us look utterly brilliant.

 

Dang it! ... I've literally spent hours debugging an assembly program I've been working on, only to find that the hideous, ugly bug was hidden in a macro:

   btfsc FLAGS1, LEAP_DAY_FLAG    ;it is not until AFTER february has passed that we 
    Fcall Inc_GPT02               ;add a leap day if there's need

The thing is, that the Fcall macro generates code according to this template:

;Select appropriate program memory page before and after calling a rouinte
Fcall macro Routine
         pagesel Routine            ;select Routine's program memory page before calling
         call Routine               ;execute the routine
         pagesel $                  ;restore the current program memory page
       endm

So what was happening, is that the function was no skipping the entire Inc_GPT02 instruction, but only the "pagesel Routine" part ... and then it would call the routine within the same page and a mess was created and all hell would break loose ...

stupid stupid stupid ...

 

I've only skimmed the thread and haven't read all the posts, but I see a common theme that I think everyone, most definitely myself included, is afflicted by.

Humans are very, very good at pattern recognition and extrapolation. We see part of something and we fill in the gaps with what we don't see but that we know needs to be there. We see the tip of the tail and we know that there is the rest of the lion attached. I think this carries forward to our writing and programming. We know what we meant to write, and so when we read it we tend to not see what's actually there, but rather what we know is supposed to be there. I can't even begin to count the number of times I have written something, from a post here to a paper I'm submitting for publication, that I have proofread over and over only to find several typos as soon as I print it out. Or the number of times I've been trying to point out a silly mistake that a student has made in a program, such as a misspelled variable name, and even after focusing their attention right to the specific word they still don't see the problem because their brain is taking what it sees and replacing it with what it knows it is supposed to be.

The good news is that there are some simple things we can do to greatly help (but never eliminate) this. I've noticed, and confirmed in conversations with countless others, that even minor changes in context make a huge impact. That's why printing out a paper, or previewing a post, allows me to immediately see errors that I've overlooked repeatedly in the editor. On several occasions when I've gone back to the editor to fix something I found in the preview, I couldn't find it again because it was now back in the context where my brain was tricking me. But as soon as I went back to the preview I found it immediately. Another technique, particularly good with programming situations, is to consciously tell myself tell myself to read what I wrote, not what I wanted to write, or to read what's there and not what I want to be there. Essentially I am forcing myself into the role of a reviewer looking at someone else's work and that often moves me far enough away from the mindset that established the familiar context that is masking the problem for me to spot it. If that doesn't help, I start explaining my work, in detail, to my dog (even if she's not around). That forces me to think about the problem and my solution differently, because now I am explaining it instead of solving it and implementing it, which again serves to create a new context in which I notice things I've overlooked. Numerous head-slap moments have resulted -- plus I should, by all rights, have a very well-educated dog by now.

 

Now, if you had used Rust, none of that would have happened.

 

It is common to test a variety of different development platforms. Lack of good documentation often why such projects remain unfinished.

If you use project management like Evernote you could be adding and modifying details, pictures, documents code, links.
Save your info early and often of all changes as they develop. From the desktop click on the icon and your notes and everything are in one place.
Best Note Taking App - Organize Your Notes with Evernote
This worth a try it will improve your organization and structure to reach goals in electronic projects, some might be just a concept that you wrote down. Keep track of every worthwhile idea. Possibly 1 out of 50 might have something that makes it better than the previous.
One drawback of Evernote is that browsers are used to collect information and sell it to cybermarkets, making intellectual property vulnerable.
You can makeshift your own encrypted project management using the same idea to get organized and prioritize what you consider important.

Self-understanding and less talk about boneheads, how others advance themselves with the other person's work and why this tactic happens.
Because only one standard of discipline or management style is adopted in early education ADHD react to stereotyping, competitive aggression ect.
The emotional reaction continues and is deeply rooted into defense mechanism.

Video interview explains one opinion about ADHD early development. ADHD actually unique and very sensitive are prone to wrong perception, unnecessary guilt and worries throughout their lives. Brain development is affected by their environment also the sensitive issue.

 

Yesterday morning I had five little ADS1115 modules. I programmed one for use with an ESP8266 module for two differential channels. Then I decided to go from a 3.3 volt supply which would have been just fine had I not reversed polarity to it. Now it's a one channel module. Now I have four remaining. Considering about $3.00 USD each it was an inexpensive reminder that polarity really does matter.

Ron

 

Considering about $3.00 USD each it was an inexpensive reminder that polarity really does matter.

How dare you try and tell polarity what it should be ... I say let polarity decide what it wants to be!