I graduated college and started working at a local tractor manufacturer. In hindsight, this company had no idea how to make software. For instance, they requir

I graduated college and started working at a local tractor manufacturer. In hindsight, this company had no idea how to make software. For instance, they required that all "software engineers" were from an accredited engineering program--at the time, none of the universities in the area had an accredited software engineering program, so they would hire electrical engineering majors who had no desire to write software but were looking for a way to get their foot in the door. Most of the EE majors had a single semester of C and that was their entire software qualification; however, I double majored in EE and CS and my passion was software. That said, when I graduated I didn't understand any of this--I just figured there was this successful company and there was so much I didn't know about software, so I thought I would learn loads there--and I did learn loads, but it was mostly about what not to do. One of my first projects was to take over an embedded C++/Qt project that had been bid out to some contractors in the Ukraine. The software was super buggy and the code was immensely convoluted. Test coverage was part of the contract, so it had tests, but even still, no one could change anything without breaking everything. It took me weeks of plotting the code paths to figure out that there were many paths through the code that were only exercised by tests--literally they were just trying to boost their code coverage metrics by adding code that was unreachable at production. I guess it didn't occur to me that professional software engineers would be so bad at writing code, and that a large and well-known software company would hire them. Thankfully, after eventually gaining my entirely-nontechnical manager's trust, we were able to bring in a consultancy who helped me demonstrate that it would be no more than half the cost to rewrite the code rather than try to fix all of the existing bugs even if we never found other bugs or introduced a single bug of our own. We did the rewrite and it was successful, but I was beginning to realize that in some overly simplistic sense, I was the "smartest" one in the room as it pertained to software development anyway. Ten years later, when I talk to my peers who stayed, many of them have been writing embedded C programs and various MatLab models and they still don't understand pointers or dynamic memory or git or anything outside of their very local niche. Which would be fine if they were happy, but now many want to move to another company but they lack the skills and confidence to get anything more than an entry level job at many other software companies--so much of their compensation is derived from their knowledge of their employer's business and processes rather than their technical acumen, so they would likely have to take a significant pay cut to move to another employer. Anyway, this is already a very long post despite oversimplifying many things, but I hope this illustrates what it looks like to be the smartest person in the room and why it's not good.