6 ms·

> I worked in an all-senior team once. Nobody admitted not understanding something. Everyone wrote overly-complex code just to 1-up each other Sorry to hear ab

by eosrei 9y ago

> I worked in an all-senior team once. Nobody admitted not understanding something. Everyone wrote overly-complex code just to 1-up each other Sorry to hear about that experience. Those aren't senior developers. There's no room for learning when you think you know everything. Senior developers mentor, simplify, document, and admit when they don't know the answers.

spaceseaman 9y ago
> Senior developers mentor, simplify, document, and admit when they don't know the answers. Sadly this is far from my experience as well. It's likely a few toxic work environments. Not to hijack your comment but I would like to offer a specific example I've seen of toxic behavior from senior developers. Many don't actually read the questions you ask of them or trust your knowledge. It's very similar to attitudes I see on Reddit, HackerNews, or StackOverflow: "Hey I'm having a bit of trouble getting this to compile / run / there's this weird error I'm encountering. I read the documentation and based on that tried X, Y, and Z, but none of those solved my problem / my problem appears somewhat different." (Where each of X, Y, and Z are somewhat long explanations of what was tried). "Did you try X?" "Uh yes I did" (then to be polite I repeat my explanation of doing X) "What about Y?" You see what I mean. Especially in text, I find that some senior developers can't be bothered to actually read what someone else said. So if you're worried that you're a poor senior developer, I recommend you actually try and read what your younger colleagues say and ask of you. And especially trust that they are being honest with you. Don't assume that someone is lying or that they're wrong on the first pass - it's condescending, frustrating, and usually a waste of time. If you hired someone in the first place, you should be allowed to assume a bare minimum of competency and if for some reason that fails, you can always question them after the fact. I think it's a result of our engineering mindset to assume absolute idiocy in every case and then work our way up, but I think it's more productive (and especially better leadership) to assume that your subordinates know what they are doing. In the context of an online forum like this, I think it's best to do the opposite: assume idiocy and work your way to competency - simply because we are all anonymous and don't know each other. The actual workplace should be treated differently though. People always perform better when you put your trust in them.
- tcbawo 9y ago
  That's not an age or experience thing. People can be jerks at any age or level. Good engineers do not equate illiteracy of the codebase (unfamiliarity) with ineptitude. Good engineers educate without contempt. On the flip side, many people come into an organization questioning why or how things are done. Often, the current product is a ball of inperfection and compromises. Spend 2x more time reading the code than asking questions. Understand why a fence was put there before you tear it down.
  - spaceseaman 9y ago
    > People can be jerks at any age or level. Good point, I was simply saying that in my experience it's the people with "senior" in their job title who do this most often. > many people come into an organization questioning why or how things are done. I think Chesterton's fence is a very important concept for new engineers to learn. But sometimes it's still valuable to understand for yourself why that fence is there in the first place rather than just take someone's word for it. The best scenario is an opportunity for a senior to guide a junior in the exact why.
  - matwood 9y ago
    > Understand why a fence was put there before you tear it down. I'm using this line from now on. As a senior dev with a lot of experience I find myself often being the only one questioning the tear it down mentality. Everyone wants to write greenfield code, and instead of taking the time to understand why current code looks like it is a mess people just want to start over. IMO, no one sets out to make a mess. A mess occurs are compromises are made to add new functionality and catch corner cases. I'm also fine tearing down a fence only after someone can tell my why it was put there and why it can down be torn down (and also how it can be rebuilt in some improved manner).
    - deleted 9y ago
      [deleted]
- eosrei 9y ago
  That is not a senior developer, developer or even technology specific issue. You can experience immature egotistical indifference in any job. "Senior" developers who act like that are "senior" in title only.
yahna 9y ago
They also lose all ego and eventually become beings of pure energy. People are competitive and do foolish things because of it.
icelancer 9y ago
> Those aren't senior developers While I agree with you in spirit, in practice - in my experience at $BIGCORPs and $STARTUPs - this is very much standard operating procedure.
deleted 9y ago
[deleted]

by eosrei 9y ago

spaceseaman 9y ago

> Senior developers mentor, simplify, document, and admit when they don't know the answers. Sadly this is far from my experience as well. It's likely a few toxic work environments. Not to hijack your comment but I would like to offer a specific example I've seen of toxic behavior from senior developers. Many don't actually read the questions you ask of them or trust your knowledge. It's very similar to attitudes I see on Reddit, HackerNews, or StackOverflow: "Hey I'm having a bit of trouble getting this to compile / run / there's this weird error I'm encountering. I read the documentation and based on that tried X, Y, and Z, but none of those solved my problem / my problem appears somewhat different." (Where each of X, Y, and Z are somewhat long explanations of what was tried). "Did you try X?" "Uh yes I did" (then to be polite I repeat my explanation of doing X) "What about Y?" You see what I mean. Especially in text, I find that some senior developers can't be bothered to actually read what someone else said. So if you're worried that you're a poor senior developer, I recommend you actually try and read what your younger colleagues say and ask of you. And especially trust that they are being honest with you. Don't assume that someone is lying or that they're wrong on the first pass - it's condescending, frustrating, and usually a waste of time. If you hired someone in the first place, you should be allowed to assume a bare minimum of competency and if for some reason that fails, you can always question them after the fact. I think it's a result of our engineering mindset to assume absolute idiocy in every case and then work our way up, but I think it's more productive (and especially better leadership) to assume that your subordinates know what they are doing. In the context of an online forum like this, I think it's best to do the opposite: assume idiocy and work your way to competency - simply because we are all anonymous and don't know each other. The actual workplace should be treated differently though. People always perform better when you put your trust in them.

tcbawo 9y ago
That's not an age or experience thing. People can be jerks at any age or level. Good engineers do not equate illiteracy of the codebase (unfamiliarity) with ineptitude. Good engineers educate without contempt. On the flip side, many people come into an organization questioning why or how things are done. Often, the current product is a ball of inperfection and compromises. Spend 2x more time reading the code than asking questions. Understand why a fence was put there before you tear it down.
- spaceseaman 9y ago
  > People can be jerks at any age or level. Good point, I was simply saying that in my experience it's the people with "senior" in their job title who do this most often. > many people come into an organization questioning why or how things are done. I think Chesterton's fence is a very important concept for new engineers to learn. But sometimes it's still valuable to understand for yourself why that fence is there in the first place rather than just take someone's word for it. The best scenario is an opportunity for a senior to guide a junior in the exact why.
- matwood 9y ago
  > Understand why a fence was put there before you tear it down. I'm using this line from now on. As a senior dev with a lot of experience I find myself often being the only one questioning the tear it down mentality. Everyone wants to write greenfield code, and instead of taking the time to understand why current code looks like it is a mess people just want to start over. IMO, no one sets out to make a mess. A mess occurs are compromises are made to add new functionality and catch corner cases. I'm also fine tearing down a fence only after someone can tell my why it was put there and why it can down be torn down (and also how it can be rebuilt in some improved manner).
  - deleted 9y ago
    [deleted]
eosrei 9y ago
That is not a senior developer, developer or even technology specific issue. You can experience immature egotistical indifference in any job. "Senior" developers who act like that are "senior" in title only.

yahna 9y ago

They also lose all ego and eventually become beings of pure energy. People are competitive and do foolish things because of it.

icelancer 9y ago

> Those aren't senior developers While I agree with you in spirit, in practice - in my experience at $BIGCORPs and $STARTUPs - this is very much standard operating procedure.

deleted 9y ago

[deleted]