3 ms·

Years ago, freshly out of school, I ended up in a job at a french small shop that required me to learn a lot of things. They had a brillant sysadmin, that I bo

Years ago, freshly out of school, I ended up in a job at a french small shop that required me to learn a lot of things. They had a brillant sysadmin, that I bothered to explain them to me. Sometimes, he'll come to my desk, looking at my screen, typing the solution while explaining the problem to me with simple words. Standing up, typing with one hand, and working on what was supposed to be my specialty, he was doing a better job than I was, despite me interrupting his workflow. I left the job, and levelled up. One day, I read an article about docker, and the name of the dev caught my eyes: it was the friendly former sysadmin colleague, Jérôme Petazzoni, who went on becomming docker's biggest evangelist. Thank you Jérôme, for making sure I started my carrer by not being the smartest guy in the room. I kept it as a habit. Or I'm just dumb :)

klibertp 5y ago
> for making sure I started my carrer by not being the smartest guy in the room That's indeed invaluable. That should be the first advice to anyone starting out: if you find yourself being the smartest in a room, go find a new room. Right now.
- arch-ninja 5y ago
  I left the company I was part-timing at because after college I realized I was the smartest one in the room; my boss thought some of the code I wrote was "brilliant" and for this reason did not let me improve/fix any of it, which led to the company shipping a broken product to some very annoyed customers. If you are ever managing someone who is "your best employee" and they want to do something you think is useless, please ask them why and what the expected results will be. Also when you get that data, listen a little? If priorities clash do a balancing act: "If you can do X in Y time, do it. But if day D comes along, switch over to my priority".
- throwaway894345 5y ago
  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.

klibertp 5y ago

> for making sure I started my carrer by not being the smartest guy in the room That's indeed invaluable. That should be the first advice to anyone starting out: if you find yourself being the smartest in a room, go find a new room. Right now.

arch-ninja 5y ago
I left the company I was part-timing at because after college I realized I was the smartest one in the room; my boss thought some of the code I wrote was "brilliant" and for this reason did not let me improve/fix any of it, which led to the company shipping a broken product to some very annoyed customers. If you are ever managing someone who is "your best employee" and they want to do something you think is useless, please ask them why and what the expected results will be. Also when you get that data, listen a little? If priorities clash do a balancing act: "If you can do X in Y time, do it. But if day D comes along, switch over to my priority".
throwaway894345 5y ago
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.