3 ms·

My rule of thumb is that I always try to be the dumbest person in the room. If I'm the smartest person in the room, I'm not learning. I want to surround myself

My rule of thumb is that I always try to be the dumbest person in the room. If I'm the smartest person in the room, I'm not learning. I want to surround myself with people that know more than I do about things I know little about. My advice: 1) Shut up and listen 2) Ask them respectfully and professionally for advice when you need it 3) Shut up and listen some more If you're an engineer, I also recommend the following: 1) Read everyone's commits, especially just before a feature launches. You'll learn their code styles and neat tricks that you never considered. If you have a question about why they did something, ask them respectfully. (e.g., "I've never seen that before. Why'd you decide to do it that way?") 2) Volunteer to be the bug fixer. When a support ticket comes in, be the first to grab it. Going in and fixing other people's bugs gives you more experience in reading new code and grokking it quickly, understanding how all the pieces of your app fit together, and everyone else will appreciate your initiative. 3) Ask your peers for code reviews every once in awhile. They will love that you respect their opinion, and they will be able to point out mistakes. Above all, keep an open mind -- don't take any criticisms personally. They probably think you're a great person and your code sucks -- that's great! That means they can help you improve. If they think you're a shitty person, then you're in trouble... :) Stay humble. Stay focused. Keep your eyes and ears open and learn as much as you can. When you feel like you're not learning any more or when you feel like you're actually the smartest person in the room, that's a good sign that it's time to go somewhere else. Good luck.

MollyR 12y ago
I second this. It's basically what I did, when I was the dumbest person in the room. I was also the dumbest person in the room for 4 years. I spent a ton of that time studying,asking questions,and playing catchup. It eventually paid off though. Persistence!
cJ0th 12y ago
> 1) Shut up and listen I like that but many people get irritated and feel you're not proactive enough if you just occasionally ask questions.
- akoncius 12y ago
  still it's better to listen and try to understand everything instead of suggesting stupid solutions without deep understanding of problem. I've seen many cases when new dev joins company and instantly suggests some solutions to some problems without any knowledge of domain. Unless you are expert at that domain, you should do that "shut up and listen" in the beginning. OR raise respectful questions to get that knowledge of domain/programming skills.
lawry 12y ago
> You'll learn their code styles and neat tricks that you never considered. I agree, it's a good thing to be the dumbest person in the room, BUT a good engineer or developer does not only shine in the work he/she produces, but also in making sure it's clear for his/hers coworkers. Clear and documented code beats smart code and hacks, and often you can bundle it in a library making it optional to truly understand the workings of the library to use it. (Unless performance is that important or you are doing HFT-alike things)
AOsborn 12y ago
>> If I'm the smartest person in the room, I'm not learning. Absolutely. This is something that I cannot stress enough to junior developers that I work with. This also applies to social and inter-personal skills as well as technical - just as you aim to continually improve your domain knowledge, there are always opportunities to identify and improve complementary skills. If OP can determine strategies, survive and thrive in the environment described, this will be invaluable for progressing in a more accommodating workplace.

MollyR 12y ago

I second this. It's basically what I did, when I was the dumbest person in the room. I was also the dumbest person in the room for 4 years. I spent a ton of that time studying,asking questions,and playing catchup. It eventually paid off though. Persistence!

cJ0th 12y ago

> 1) Shut up and listen I like that but many people get irritated and feel you're not proactive enough if you just occasionally ask questions.

akoncius 12y ago
still it's better to listen and try to understand everything instead of suggesting stupid solutions without deep understanding of problem. I've seen many cases when new dev joins company and instantly suggests some solutions to some problems without any knowledge of domain. Unless you are expert at that domain, you should do that "shut up and listen" in the beginning. OR raise respectful questions to get that knowledge of domain/programming skills.

lawry 12y ago

> You'll learn their code styles and neat tricks that you never considered. I agree, it's a good thing to be the dumbest person in the room, BUT a good engineer or developer does not only shine in the work he/she produces, but also in making sure it's clear for his/hers coworkers. Clear and documented code beats smart code and hacks, and often you can bundle it in a library making it optional to truly understand the workings of the library to use it. (Unless performance is that important or you are doing HFT-alike things)

AOsborn 12y ago

>> If I'm the smartest person in the room, I'm not learning. Absolutely. This is something that I cannot stress enough to junior developers that I work with. This also applies to social and inter-personal skills as well as technical - just as you aim to continually improve your domain knowledge, there are always opportunities to identify and improve complementary skills. If OP can determine strategies, survive and thrive in the environment described, this will be invaluable for progressing in a more accommodating workplace.