I wasn't given the spec, but I was told to see if I could solve the problem that all our 16:9 adverts were stored as 1:1.

As it was broadcast, and we had a billion different versions of the same add (localisation) it was something that needed automating, as sending it through the blasted tape machines and back to get it into 16:9 was a faff, and the digital solution cost many thousands of pounds.

So I turned to my toolset, which at the time was googling to find the full spec and spending the next few days workout out how to flip the aspect ratio bit of the mpeg2 to flip it to 16:9/4:3 depending on the metadata. I did this using perl and binary regex. It worked great, better than the commercial tools. but still not 100% correct, because it turns out a good number of mpeg2 encoders kick out non-compliant data.

This was before the days of ffmpeg's `mpeg2_metadata=display_aspect_ratio=16/9`

>I was handed a hardcopy of the MPEG-2 transport stream spec and told to read it and come back with questions.

OK, but what did you have to do on the job with the spec after reading it? Did you also have to do a codec implementation in SW or what? Don't leave us hanging.

>That's how you onboard.

Yeah, 15-30 years ago, when professional experienced SW devs weren't dime a dozen. Valve would also hire people off the street who never wrote any SW to code on the original Half-Life. But those days are long gone now, after 10+ years of "just learn to code bro" and ZIRP creating an oversupply of coders who now need to know a dozen programing languages, frameworks and buzzwords just to get a AI written rejection. Those were the days, writing SW felt like a craft, a science and a hobby at the same time.

But alas, certain jobs in EE/embedded SW still work like this. You get to read and learn a lot of source code, requirements, specs, design documents and standards, before actually building things, plus a proper (graybeard) mentor to onboard you. At least those remaining jobs that haven't yet been offshored(defense, aerospace).