6 ms·

A lot of things, my experience is based on working in startups: 1. Suggesting silly changes in CR - instead of A you could have used B. So what? I used A, let's

A lot of things, my experience is based on working in startups: 1. Suggesting silly changes in CR - instead of A you could have used B. So what? I used A, let's keep it that way, time is money. 2. Long discussions in CR 3. Too much thinking like a programmer. I'm not coding, because I love it(although I like it), I'm coding, because business needs it... 4. Asking for estimates, when we both know that estimates in this situation are impossible to predict. 5. Shitty written tickets. I don't know the app well enough yet, so one sentence tickets won't help me much. 6. Too much obsession over some technology. Everything has some good and bad sides, so stop selling it, especially when no one is paying you to do that. 7. Also, I dislike when you can't get a simple answer to your question, but you get funny looks that you don't know the answer yet.

nullandvoid 8y ago
Whilst I agree with a lot of the points you made I'm not sure on #3 - I don't see that as a negative when compared with the opposite ( devs who don't care or 'think like a programmer' as much as they should ). Similarly on point 7 I get very excited about new tech ( or similarly with cool old stuff i've only just discovered ). Who needs to be paid to be passionate about what benefits new tools may bring for me or the team :)
- wrestlerman 8y ago
  I don't think it's wrong to get excited about new tech. But from what I have observed it's mostly that one dev that pushes for new stuff and after they get sick/leave someone else has to take care of it and many times it means a rewrite of that functionality. Also many times with new tech, you can't really tell its bad sides, because it takes some time to know if it's solid or not.
nqr 8y ago
Thanks for #3. Writing code is my profession. I don't love it, in the same way that a plumber doesn't love unclogging your toilet. He has to do it because he needs to buy food.
JoeAltmaier 8y ago
Oh yes, so often the CR process becomes a hassle. Somebody positions themselves at the door as some sort of guard, and harasses everybody going through. So often just to feel like they're the boss or something. My son just quit a startup because that had become epidemic. Couldn't get emergency code committed; couldn't meet (artificial) deadlines for demos and shows; every choice yammered over for esoteric reasons. I suggest to everyone: when you make a comment in CR, also approve the commit. Trust the engineer on the other end to do what is necessary and responsible. If that become a problem, address it then. It seems like the minimum in professional respect.
- longerthoughts 8y ago
  >Somebody positions themselves at the door as some sort of guard, and harasses everybody going through. So often just to feel like they're the boss or something. I've noticed this outside of the CR process as well. When people are tasked with providing a critique, it's as if they feel obligated to say something because they're treating the task as "find something wrong with X" not "determine if anything is wrong with X". Sometimes it seems like people trying to exert their power, but often it's more like people are just trying to prove that they're adding value.
  - hluska 8y ago
    > Sometimes it seems like people trying to exert their power, but often it's more like people are just trying to prove that they're adding value. If you work with people like this a lot, try introducing a shit sandwich to your company. Before you call your caterer, let me explain what that is...:) My Dad taught me that when you have to criticize/correct something, do so in a shit sandwich. Start off with positives, then express your criticism and then end with positives. Thinking about positives tends to ground people and get them to evaluate the situation, not merely come out with negativity to prove their worth...
    - drbojingle 8y ago
      This is common enough that everyone would know what you're doing and think you only said the nice things so you could say the negative :P
drbojingle 8y ago
Agree with most of your points. For 1 and 2 it depends on what constitutes silly and the situation. I've seen some terrible code go through CR in the name of speed. For loops in for loops in if statements in for loops with breaks and continues abound. It worked, but be damned if I wanted to see it again.
closeparen 8y ago
A "why aren't you doing it this other way?" comment is appropriate when: - You understand both options. - You understand the tradeoffs between them. - You have a reasoned argument for favoring one approach. - You suspect that the other person is missing some of this information. I love getting comments that teach me about a language, API, design patterns, or potential bug, and make my code better. Even if I'm going to stay the course in this particular case, I'm happy to have received the comment, and always try to let the commenter know that. An okay code review gets my code landed fast, a good code review is one I learn from. But I can't fucking stand defending and explaining perfectly normal and reasonable choices to engineers who just don't know and are curious, or have weird taste, or are otherwise putting me through the exhausting exercise of fighting for every little choice without providing value in return.
- tomlagier 8y ago
  > But I can't fucking stand defending and explaining perfectly normal and reasonable choices to engineers who just don't know and are curious, Often times when I'm reviewing code, I'm learning as well. If I ask a question because I don't know and am curious, I'd think that's a good opportunity for knowledge transfer. Why can't you fucking stand it? edit: it occurs to me that this comment is extremely meta, hah.
  - deleted 8y ago
    [deleted]
  - closeparen 8y ago
    Code quality is an aesthetic sense. It's easy to look at some code and render an opinion. With a certain level of maturity, you can intuitively come up with code that feels right. But offering a rational explanation for each minor decision between mostly-equivalent alternatives is disproportionately hard. Usually there isn't one. Trying to get more experienced engineers to knowledge-transfer the decision trees they're following is a seductive but wrong model for getting better at software engineering. If such trees even exist they are subconscious. Observe, reflect, try stuff out, solicit feedback. Run that cycle with the highest quality and quantity inputs you can find. It's absolutely your senior colleagues' duty to help you develop the aesthetic sense, but the higher quality and more cost effective way to do that is by giving feedback on your work.
arandr0x 8y ago
This list kind of makes me want to work with you! And I didn't even work in startups... I guess that experience can be very widespread...
amirouche 8y ago
What is CR?

nullandvoid 8y ago

Whilst I agree with a lot of the points you made I'm not sure on #3 - I don't see that as a negative when compared with the opposite ( devs who don't care or 'think like a programmer' as much as they should ). Similarly on point 7 I get very excited about new tech ( or similarly with cool old stuff i've only just discovered ). Who needs to be paid to be passionate about what benefits new tools may bring for me or the team :)

wrestlerman 8y ago
I don't think it's wrong to get excited about new tech. But from what I have observed it's mostly that one dev that pushes for new stuff and after they get sick/leave someone else has to take care of it and many times it means a rewrite of that functionality. Also many times with new tech, you can't really tell its bad sides, because it takes some time to know if it's solid or not.

nqr 8y ago

Thanks for #3. Writing code is my profession. I don't love it, in the same way that a plumber doesn't love unclogging your toilet. He has to do it because he needs to buy food.

JoeAltmaier 8y ago

Oh yes, so often the CR process becomes a hassle. Somebody positions themselves at the door as some sort of guard, and harasses everybody going through. So often just to feel like they're the boss or something. My son just quit a startup because that had become epidemic. Couldn't get emergency code committed; couldn't meet (artificial) deadlines for demos and shows; every choice yammered over for esoteric reasons. I suggest to everyone: when you make a comment in CR, also approve the commit. Trust the engineer on the other end to do what is necessary and responsible. If that become a problem, address it then. It seems like the minimum in professional respect.

longerthoughts 8y ago
>Somebody positions themselves at the door as some sort of guard, and harasses everybody going through. So often just to feel like they're the boss or something. I've noticed this outside of the CR process as well. When people are tasked with providing a critique, it's as if they feel obligated to say something because they're treating the task as "find something wrong with X" not "determine if anything is wrong with X". Sometimes it seems like people trying to exert their power, but often it's more like people are just trying to prove that they're adding value.
- hluska 8y ago
  > Sometimes it seems like people trying to exert their power, but often it's more like people are just trying to prove that they're adding value. If you work with people like this a lot, try introducing a shit sandwich to your company. Before you call your caterer, let me explain what that is...:) My Dad taught me that when you have to criticize/correct something, do so in a shit sandwich. Start off with positives, then express your criticism and then end with positives. Thinking about positives tends to ground people and get them to evaluate the situation, not merely come out with negativity to prove their worth...
  - drbojingle 8y ago
    This is common enough that everyone would know what you're doing and think you only said the nice things so you could say the negative :P

drbojingle 8y ago

Agree with most of your points. For 1 and 2 it depends on what constitutes silly and the situation. I've seen some terrible code go through CR in the name of speed. For loops in for loops in if statements in for loops with breaks and continues abound. It worked, but be damned if I wanted to see it again.

closeparen 8y ago

A "why aren't you doing it this other way?" comment is appropriate when: - You understand both options. - You understand the tradeoffs between them. - You have a reasoned argument for favoring one approach. - You suspect that the other person is missing some of this information. I love getting comments that teach me about a language, API, design patterns, or potential bug, and make my code better. Even if I'm going to stay the course in this particular case, I'm happy to have received the comment, and always try to let the commenter know that. An okay code review gets my code landed fast, a good code review is one I learn from. But I can't fucking stand defending and explaining perfectly normal and reasonable choices to engineers who just don't know and are curious, or have weird taste, or are otherwise putting me through the exhausting exercise of fighting for every little choice without providing value in return.

tomlagier 8y ago
> But I can't fucking stand defending and explaining perfectly normal and reasonable choices to engineers who just don't know and are curious, Often times when I'm reviewing code, I'm learning as well. If I ask a question because I don't know and am curious, I'd think that's a good opportunity for knowledge transfer. Why can't you fucking stand it? edit: it occurs to me that this comment is extremely meta, hah.
- deleted 8y ago
  [deleted]
- closeparen 8y ago
  Code quality is an aesthetic sense. It's easy to look at some code and render an opinion. With a certain level of maturity, you can intuitively come up with code that feels right. But offering a rational explanation for each minor decision between mostly-equivalent alternatives is disproportionately hard. Usually there isn't one. Trying to get more experienced engineers to knowledge-transfer the decision trees they're following is a seductive but wrong model for getting better at software engineering. If such trees even exist they are subconscious. Observe, reflect, try stuff out, solicit feedback. Run that cycle with the highest quality and quantity inputs you can find. It's absolutely your senior colleagues' duty to help you develop the aesthetic sense, but the higher quality and more cost effective way to do that is by giving feedback on your work.

arandr0x 8y ago

This list kind of makes me want to work with you! And I didn't even work in startups... I guess that experience can be very widespread...

amirouche 8y ago

What is CR?