More Experience != Less Mistakes

A common view among people getting started with programming is that once they become more experienced they won’t make the obvious and frustrating mistakes that are currently slowing them down. Take it from me, nothing could be further from the truth. You’ll still make those mistakes, but what experience does give you is faster resolution, either because you’ve made that mistake many times before or because you know the tools/tricks that will allow you to quickly zero in on the problem.

A real world example

Earlier today I was refactoring a Lightning component which had logic in the component that I felt belonged in the helper, something like the following but more complicated (I’ve removed the complexity for the sake of understanding, as it wasn’t that which caused my mistakes) :

<aura:attribute name="optionA" type="Boolean" />
<aura:attribute name="optionB" type="Boolean" />
<aura:if isTrue=”{! (v.optionA && !v.optionB)}”>

I decided to change this to :

<aura:attribute name="optionA" type="Boolean" />
<aura:attribute name="optionB" type="Boolean" />
<aura:attribute name="showANotB" type="Boolean" />
<aura:if isTrue="{! v.showANotB }">

As this is a lot simpler to understand and it abstracts away the details of how we determine that we are showing A but not B, which future programmers shouldn’t have to figure out from first principles each time.

The plan was then to add code into my component initialisation event to setup ShowANotB. The first attempt was:

const optionA=cmp.get('v.optionA');
const optionB=cmp.get('v.optionA');
cmp.set('v.showANotB', optionA&&optionB);

Which didn’t work, as I’d assigned the contents of the v.optionA attribute to the constants optionA and optionB, which obviously still worked when optionB happened to have the same value as optionA. Didn’t take very long to find and fix, but wasn’t instant either.

I quickly updated the code to the following:

const optionA=cmp.get('v.optionA');
const optionB=cmp.get('v.optionbB');
cmp.set('v.showANotB', optionA&&optionB);

Which again didn’t work, as I’d somehow hit the b key twice, once without the shift key on, and changed the attribute name used to set the optionB constant to ‘v.optionbB’. Accessing a non-existent attribute gave me a falsy result, so this worked some of the time like the first attempt.

So even with 30+ years of development experience, I made a couple of really simple and once I saw they didn’t work, obvious mistakes. Probably not for the same reasons that new developers would, more likely because I was thinking ahead to the complex problems that I had to solve a little bit further down the line and thus didn’t give this simple problem my full attention.

I knew that these didn’t work pretty much immediately as I had created some tests that used my component with a variety of different values for optionA and optionB, and as I wasn’t changing the behaviour, just the implementation, I expected the tests to pass. When they didn’t, I went back to the code and spotted the issues.

The key takeaway here is that you will continue to make simple, and in my case at least, stupid mistakes forever, so you shouldn’t trust your code to work regardless of how long you’ve been programming or how simple the changes you are making are. That and a good set of tests will stop those stupid mistakes making it out of your development environment, where they can cause real problems.

I’m better known in the Salesforce community as Bob Buzzard — Umpteen Certifications, including Technical Architect, 6 x MVP and CTO of BrightGen, a Platinum Cloud Alliance Partner in the United Kingdom who are hiring.

You can find my (usually) more technical thoughts at the Bob Buzzard Blog