Solid GOLD

I passed the Gold Exam! Once I get the official badge from Crestron, I’ll post it all over my online presence.

In accordance with testing protocols, I can’t share anything particular about this exam, but I thought this would be a good chance to reflect on my experience taking the test.

Compared to the Silver Exam

I passed the Silver Exam 3 years ago. That seemed to have a harder scope of work than the Gold, but I did end up having to write a lot more SIMPL# this time around. I heard stories about one of the years in-between that had an even more complicated design, but thankfully, I didn’t have to attempt that one.

I think this shows a trend that Crestron is scaling back on the workload for these exams. At least I hope that’s the case! They seemed to get things right on this one: it had a reasonable project scale, provided you a touchpanel layout that was mostly ready, and didn’t ask you to create something outside the realm of what Crestron would be used for in the real world.

There are some common elements I’ve started to pick up on, so I think for the next level I’ll have a better plan of attack.

Time Management

Once again, the hardest part about taking this exam was time management. Per usual, I had 90 days to work on the exam then submit. Knowing this, I wanted to find a slow period in my schedule where I could squeeze it in. So I didn’t start the exam right away, I waited a month. I hoped December would show signs of slowing, but I was still constantly double and triple booked on project work and support. Unfortunately, curiosity got the better of me, and I started the exam mid-December thinking I could use the Christmas week to make a good push.

Another thing I resolved to do this time around was track my time. I always wondered where all the time went, so going forward I would keep a record. 70 hours. That’s all I could spare in those 90 days because my workload never slacked. Looking at my time card, I put in at most 4 hours a day, but the days were sporadic. I tried to note what I worked on for each session, too.

My original goal was to divide my time into thirds. The first 30 days I would spend writing a program that worked and probably learn where I made mistakes along the way. Hopefully, I would have a good idea how I would rewrite parts if I had to do it again. The next 30 days I would rewrite from scratch, using what I learned during that first attempt. The last 30 days I would spend on bug fixing and polish.

But that’s not how reality works.

It felt like I was constantly behind schedule, so when I missed my first goal, I decided to just continue fixing and polishing my first version. This led to some pretty hairy bugs that had to be squashed in the final hour, but I had no other choice. I submitted a couple days before the deadline, but I felt sure there were things I’d missed that would probably cause it to get kicked back.

Second Attempt

And I got a list of a couple things that needed to be fixed. You are given 30 days for this part. I fixed the easy one first and saved what I thought would be most-difficult for last. The most-difficult lived up to its name because it did require I go back and rewrite some core parts of my SIMPL# library, then that exposed new bugs, but once those bugs were fixed the whole thing worked much better and I was happy.

Oh and my work schedule was still packed this whole time, so I was still stressing out that I wasn’t giving the Gold Exam enough attention, and the deadline was quickly approaching. I let my program run in a lab setup for days, checking every morning and evening if any errors popped up in the error log. After a week of this, I was again out of time and had to submit.

And this time, I passed.

Lessons

I’ve always come away from these exams with a slightly different approach to programming. I have an urge to take some of what I learned, clean it up, then start using it in the day-to-day work. That’s when you really start to see if it saves you time or what headaches it brings.

I am not a great programmer, and these exams are always a reminder that I’m lacking a lot of formal education. Imposter Syndrome really starts to set in when I’m chasing down a hard-to-find bug. How did I get this far being so bad at this?!

But if you can push those thoughts away, sketch out your problem, look at how it can be broken down into manageable chunks, I think that’s how you get through those moments that cause you to stretch a little. There’s a difference between elegance and trying to be clever. I’ve stumbled into old programs (usually my own) where clever has created a maintenance nightmare.

But every now and then, I see one of those old programs where I think, This programmer knew what they were doing, this is so clean! And (sometimes) that programmer is me.