It was 1995, and a bitter-cold winter in Romania. An automotive factory line worker stamped the UPC code from his pack of cigarettes into a car’s VIN number, and my software engineering career was born. Here’s how it all began.
I was several years into my tech career as a QA engineer. I’d gone to Romania to help set up a new system built by my then employer, an industrial control company, for a Rodae Automobile factory (later renamed Daewoo Automobile Romania). I was there to install a server that would replace the company’s old scheduling system with new, just-in-time scheduling. The Rodae factory previously had been a Citroen car factory producing Oltcit cars, but had recently began producing cars under the Rodae line.
At the factory, things started going haywire from a QA perspective. Inexplicably, cars were coming out of the assembly line with VIN numbers that were invalid. When this happens, the companycan’t simply go back and change the VIN number–they actually need to scrap the car body. We quickly got to the bottom of it: one of the guys on the line running the VIN stamping machine, instead of scanning the code our interface sent, had been scanning cigarette packs as a prank.
Our software didn’t have a control requiring it to check that the inputs were valid, so the stamping machine kicked in from the cigarette box UPC code. The engineer who’d written the program didn’t make sure the number was right length or confirm that it was valid. Those two risks meant that whatever got scanned got sent–a costly error.
Always check your inputs.
The engineers who had written the program were in San Jose, not Romania, and there were no other engineers on site. I was the only person on site who could write code, so I offered to fix it. It was my very first programming job. I added a small bit of code to validate the check digit for the VIN number. The check took the value of each of the 16 characters, added them up, and summed up on one byte. If the digits didn’t add up to that one number, it was invalid. I changed the software, which was a C-based driver, written for custom hardware based on the Motorola 68000 CPU that took input from a barcode scanner and sent it to the VIN stamping machine. The moral of the story: always check your inputs.
The fun didn’t stop with rewriting the program for the stamping machine. There had been another engineer who was there to complete the software for the factory’s just-in-time scheduling. The software, which was supposed to be written in Silicon Valley, was behind schedule, so the plan was to finish it on site. As luck would have it, Romania was experiencing a miserably, brutally cold and icy winter. To enter the factory, we actually had a rope attached to a wall so you could traverse the significant ice build-up outside the factory gates. Our working and living conditions were suboptimal. This admittedly challenging situation ended up being way too harsh for the engineer I was working with, and he went home mid-project. I ended up taking over and significantly re-engineering the software to deliver a working final product.
My previous experience writing software had been personal projects that were released into the public domain. This was my first real engineering job, for a real customer, that really had to be delivered. I was probably way too slow at it then. But I loved everything about it.
My takeaway: Don’t be afraid to try your hand at something new. Especially if you find yourself in an under-resourced former Eastern Bloc country during the coldest winter in 30 years. It might just light the spark you need to stay warm.
Also, don’t leave your laptop sitting on the factory floor, lest someone set a welding tank on top of it. But that’s a story for a different day.