7 ms·

I have worked with people like the author. They suck. They destroy entire teams and often times the feedback is 99% pedantic personal preferences because why wo

by bogota 5y ago

I have worked with people like the author. They suck. They destroy entire teams and often times the feedback is 99% pedantic personal preferences because why would they do something useful like setup the linter and propose the silly things they always nit pick. These people don’t last long and I have gotten pretty good at screening out this personality in interviews after having it cause huge issues at two different places I worked.

morgancmartin 5y ago
I'm curious to know if you or anyone else reading this has run into the opposite problem. Or maybe I'm just "that guy" although I am reasonably certain that I am not. As a rule, so far throughout my 5 year career as a full stack web developer, my coworkers have neither understood or cared about what clean code entails. I don't berate, I don't criticize, I've taken to mentioning it once and then doing my utmost to never mention it again in an attempt to avoid labeling myself as the odd one out. Granted, I've turned down a handful of much higher paying (and presumably higher quality teams) for various reasons. At first, it was because I was a bootcamper and high paying jobs are difficult to pick up out of the gate without the appropriate piece of paper. Since then, I've worked for various organizations on a consulting basis, and most recently landed at an early stage YC startup. Pay isn't great, but I have aspirations to start my own startup, so I'm cool with the pay cut for now in return for the opportunity to learn the ropes, business wise. Founder knows what he's doing at least. But the devs, man. They just don't care. 500-1500 line React function components are the norm. No standardized way for retrieving data from the back-end. I dread assignments that require me to modify or otherwise integrate with previously written code, because the best way I can come up with to figure out what the fuck is going on is to rewrite it sanely. I'm being a little hyperbolic, I do my best to avoid rewriting wherever possible, but I'm not mis-characterizing things by much. It's honestly depressing, especially considering I've had multiple other teams offer triple what I'm making right now, but neither of them were pre-seed startup SAAS companies which this one is, so here I stay for the time being. Invariably, I garner a reputation as "that guy" on any team I work on, although granted this is only the second multi-dev team I've ever worked on. Still though, it feels terrible to get a bad reputation for writing good code. Founder likes my work ethic and output though, so I guess I've got that going for me. Apologies if this turned into a bit of a rant, it just started pouring out, ha!
- AQuantized 5y ago
  I know of a few startups with relatively 'senior' people who just don't care at all or are seemingly unaware about 'best practices', and will happily write tens of thousands of the most messy code, neglecting standardizing anything or refactoring their code to be more modular or easily understood. It does seem to be something the big co. interview gauntlet is designed to weed out, whether it's worth it or not. I'm sure it's still relatively common, but probably a lot rarer than at the median startup.
- slumpt_ 5y ago
  It’s possible there are things you are still learning, or context you are missing. You sound still early career enough that the years will likely mellow you out and teach you to better appreciate the ups and downs of building things fast. You know what’s worse than no abstractions? The wrong abstractions.
  - raman162 5y ago
    Not the OP but also a full stack at my five year career mark and your last point was an appreciated reminder. I dread cleaning up solutions that I designed earlier where with hindsight, I made a lot of wrong assumptions. I still make wrong assumptions today, they are just designed less brittle.
  - manquer 5y ago
    You are right on the value of building things fast. However one thing I have learnt is more coupled the code is with no or poor incomplete abstractions less likely anyone is going to change it. In the interest of shipping fast I would rather have some abstraction today rather than none, simply because nobody fixes spaghetti code which is already working. Building new things start slowing down more and mode and you end up taking weeks for what should have been an afternoon's effort . There are no right answers, however sometimes wrong abstractions can be marginally better than none.
  - morgancmartin 5y ago
    Oh c'mon graybeard, you can't honestly be defending 1500 line components right now can you? It's not even a matter of abstraction choice, it's a matter of simple hygiene. You know what's worse than the wrong abstractions? Copy and pasting your inline-styled div with a zIndex of 99,999 for the fifth modal in a row because you can't be assed to write a damned display component in anticipation of the next time you'll need to put a Modal together.
dec0dedab0de 5y ago
I am always careful to prioritize my comments during code review so I don't come off like that too often. I'll say things like, "I would have done that like this because of this reason, but as long as it works" or "This needs to change right now because it's a security hole" or "We should find a more efficient way to do this, because as the data fills up, the users will start to notice it" I am definitely harder on new people, and people who ask me for help when they should have been able to figure it out on their own.
alostpuppy 5y ago
Dude. 100%.
robohoe 5y ago
How do you typically screen for such personality characteristics? I'm curious since my current role involves interviewing a lot of engineers. I too have noticed similar traits in others in the past and I shamefully admit that I myself was pedantic about silly semantics and syntax in code reviews. Sometimes criticism of someone's code was warranted, and sometimes it wasn't and it was just me being picky (I like clean, readable code).
- manquer 5y ago
  Being picky is not the problem. Being picky and detail oriented is good quality to have as a developer. We aren't artists, engineering is exacting field, more details you notice and remember better you can be. The character trait you should look for how do they present that feedback, is it constructive , is it positive , the kind of language they use and how patient they are able to be. One interview technique/tool that works for me is asking them to review some sample code mine or a junior devs. It is easy to gauge how many kinds of issues, how many are actually important and how well they present feedback. The other technique that worked for me is when I review their code in a interview, people who are agressively bad almost take it poorly and can't take feedback positively . Interviewing is not 100% representative of on job behaviour, however this helps a lot in filtering out
_RPL5_ 5y ago
"These people don’t last long and I have gotten pretty good at screening out this personality in interviews after having it cause huge issues at two different places I worked." Well, now everyone is curious for more details on this. Do share :)
suzzer99 5y ago
I think I've had this author review my homework project for several job interviews.

by bogota 5y ago

morgancmartin 5y ago

I'm curious to know if you or anyone else reading this has run into the opposite problem. Or maybe I'm just "that guy" although I am reasonably certain that I am not. As a rule, so far throughout my 5 year career as a full stack web developer, my coworkers have neither understood or cared about what clean code entails. I don't berate, I don't criticize, I've taken to mentioning it once and then doing my utmost to never mention it again in an attempt to avoid labeling myself as the odd one out. Granted, I've turned down a handful of much higher paying (and presumably higher quality teams) for various reasons. At first, it was because I was a bootcamper and high paying jobs are difficult to pick up out of the gate without the appropriate piece of paper. Since then, I've worked for various organizations on a consulting basis, and most recently landed at an early stage YC startup. Pay isn't great, but I have aspirations to start my own startup, so I'm cool with the pay cut for now in return for the opportunity to learn the ropes, business wise. Founder knows what he's doing at least. But the devs, man. They just don't care. 500-1500 line React function components are the norm. No standardized way for retrieving data from the back-end. I dread assignments that require me to modify or otherwise integrate with previously written code, because the best way I can come up with to figure out what the fuck is going on is to rewrite it sanely. I'm being a little hyperbolic, I do my best to avoid rewriting wherever possible, but I'm not mis-characterizing things by much. It's honestly depressing, especially considering I've had multiple other teams offer triple what I'm making right now, but neither of them were pre-seed startup SAAS companies which this one is, so here I stay for the time being. Invariably, I garner a reputation as "that guy" on any team I work on, although granted this is only the second multi-dev team I've ever worked on. Still though, it feels terrible to get a bad reputation for writing good code. Founder likes my work ethic and output though, so I guess I've got that going for me. Apologies if this turned into a bit of a rant, it just started pouring out, ha!

AQuantized 5y ago
I know of a few startups with relatively 'senior' people who just don't care at all or are seemingly unaware about 'best practices', and will happily write tens of thousands of the most messy code, neglecting standardizing anything or refactoring their code to be more modular or easily understood. It does seem to be something the big co. interview gauntlet is designed to weed out, whether it's worth it or not. I'm sure it's still relatively common, but probably a lot rarer than at the median startup.
slumpt_ 5y ago
It’s possible there are things you are still learning, or context you are missing. You sound still early career enough that the years will likely mellow you out and teach you to better appreciate the ups and downs of building things fast. You know what’s worse than no abstractions? The wrong abstractions.
- raman162 5y ago
  Not the OP but also a full stack at my five year career mark and your last point was an appreciated reminder. I dread cleaning up solutions that I designed earlier where with hindsight, I made a lot of wrong assumptions. I still make wrong assumptions today, they are just designed less brittle.
- manquer 5y ago
  You are right on the value of building things fast. However one thing I have learnt is more coupled the code is with no or poor incomplete abstractions less likely anyone is going to change it. In the interest of shipping fast I would rather have some abstraction today rather than none, simply because nobody fixes spaghetti code which is already working. Building new things start slowing down more and mode and you end up taking weeks for what should have been an afternoon's effort . There are no right answers, however sometimes wrong abstractions can be marginally better than none.
- morgancmartin 5y ago
  Oh c'mon graybeard, you can't honestly be defending 1500 line components right now can you? It's not even a matter of abstraction choice, it's a matter of simple hygiene. You know what's worse than the wrong abstractions? Copy and pasting your inline-styled div with a zIndex of 99,999 for the fifth modal in a row because you can't be assed to write a damned display component in anticipation of the next time you'll need to put a Modal together.

dec0dedab0de 5y ago

I am always careful to prioritize my comments during code review so I don't come off like that too often. I'll say things like, "I would have done that like this because of this reason, but as long as it works" or "This needs to change right now because it's a security hole" or "We should find a more efficient way to do this, because as the data fills up, the users will start to notice it" I am definitely harder on new people, and people who ask me for help when they should have been able to figure it out on their own.

alostpuppy 5y ago

Dude. 100%.

robohoe 5y ago

How do you typically screen for such personality characteristics? I'm curious since my current role involves interviewing a lot of engineers. I too have noticed similar traits in others in the past and I shamefully admit that I myself was pedantic about silly semantics and syntax in code reviews. Sometimes criticism of someone's code was warranted, and sometimes it wasn't and it was just me being picky (I like clean, readable code).

manquer 5y ago
Being picky is not the problem. Being picky and detail oriented is good quality to have as a developer. We aren't artists, engineering is exacting field, more details you notice and remember better you can be. The character trait you should look for how do they present that feedback, is it constructive , is it positive , the kind of language they use and how patient they are able to be. One interview technique/tool that works for me is asking them to review some sample code mine or a junior devs. It is easy to gauge how many kinds of issues, how many are actually important and how well they present feedback. The other technique that worked for me is when I review their code in a interview, people who are agressively bad almost take it poorly and can't take feedback positively . Interviewing is not 100% representative of on job behaviour, however this helps a lot in filtering out

_RPL5_ 5y ago

"These people don’t last long and I have gotten pretty good at screening out this personality in interviews after having it cause huge issues at two different places I worked." Well, now everyone is curious for more details on this. Do share :)

suzzer99 5y ago

I think I've had this author review my homework project for several job interviews.