5 ms·

I worked as a contractor with some companies and peer coded with their engineers. What I found was that its not just procrastination. Many folks are just afrai

I worked as a contractor with some companies and peer coded with their engineers. What I found was that its not just procrastination. Many folks are just afraid to commit code, like literally scared and I could never get a real reason for that. At one point I added some code based on the direction what requirements were taking. But I could not convince him to commit it. So we finally agreed to let it be there commented out, only a week later to find we need it now.

reificator 6y ago
Have I been working in a bubble? I'll give a coworker a hard time for making large infrequent commits, but I've never seen someone afraid to commit code. This sounds like the value proposition for version control hasn't really clicked for them. Are they comfortable branching?
- chrisandchris 6y ago
  I think it‘s less about version control and more about that the change is then associated with the employees name and if something ever goes wrong, it would be possible (easy?) to blame him therefore he‘s being scared about doing something because it could cause trouble for him somewhen in the future. And, imho, that goes back to not enough testing nd no safety nets to check for code errors (like code review, static analysis, ...).
  - reificator 6y ago
    Clearly I am living in a bubble, because I cannot imagine working somewhere where I would rather be seen doing literally nothing than to do the exact thing I was hired for.
- sgtnoodle 6y ago
  By commit, I think the intended meaning is "put on a path that will ultimately affect production". For my current project, merging bad code typically means breaking a bunch of regression test suites for any coworkers that cut their branches at the wrong time. In more nefarious outcomes, it means a delayed software version release and, potentially, damaged UAV hardware at our test site. For my previous project, merging bad code could have resulted in someone losing control of a fully drive by wire car in a closed parking lot or test track. That's what big red buttons are for! For my project before that, some of my code was involved in handling literally every single sensor and actuator on a rocket and the space capsule on top of it. A subtle bug that slipped through to production could have been rather serious indeed.
  - reificator 6y ago
    If individuals are fearing the repercussions from doing their jobs on a safety critical system like that, then the process has already failed. Your process needs to be so bulletproof that everyone involved feels absolutely sure that a defect will be caught. If there's any doubt in their minds then that part of the chain needs to be addressed and corrected. I'm not saying that people shouldn't take it seriously or should get sloppy, but if you're worried that making a commit could end in disaster then you're moving too fast.
- NotAnAccountNO 6y ago
  What do you consider to be large and infrequent? I see so many micro-commits that I start to wonder if some competition is going on...
sgtnoodle 6y ago
Sounds about right! I think that's an indication of lack of sufficient regression test coverage, coupled with complacency/fatigue from working on the same code base for an extended period of time. Unfortunately, the most business critical pieces of code tend to be the least regression tested. It's the earliest stuff that was made before any test frameworks were matured, it's been hacked on countless times by half the team based on shifting requirements to the point that no one understands it fully, and any future changes are such a high priority that it's "faster" to test it manually or in production. I am of course guilty of that myself on some pieces of code. I try to prioritize cleaning up expensive tech debt, though. When folk are hesitant to modify a piece of code, it's a strong indication that the code is due for refactoring. It's always worth it as long as you implement regression testing in the process.
- waheoo 6y ago
  Pretty much this. I suffer huge anxiety about committing code where I work. The regression testing is flakey and the ci/cd procedure is rediculously complex and black box. Very little transparency about what is or is not covered. Failures are common a, cryptic and intermittent. The work where I know where the tests live I commit without hesitation. Other random shit I happen across. Avoid it like the plague. Doesnt help how big the sites are either.
watwut 6y ago
Cause reasons for fear are not something people would tell you. I was in similar state twice and neither time I would be eager explain that to someone external. I was "afraid" to commit in a team where code review evolved into huge micro-management with inconsistent requirements on what good code looks like. The reviewer iteratively forced you to change it again and again each time with "this is bad code cant go in" comments. But you could not learn what he considers good code, cause it was different every time. I left after. Second time I was "afraid" to commit to part of code when our main architect had completely disproportionate blow up over previous bug. I made easy to fix bug which was my mistake. But it turned into massive public blow up over work being shitty, us intentionally ignoring his needs, there being tons of bug unusable version (there was literally one bug). Then he wanted massive refactoring to avoid possibility of same bug ... and I made bug in refactoring which led to same blow out, again claiming it was done without care etc. After that, I really did not wanted to do any changes in that code. I cant guarantee complete lack of bugs in my code. Other people do bugs too for that matter, I dont think I make so much more of them. But, he was under pressure and stress that had nothing to do with me and I became rod for that.
- sgtnoodle 6y ago
  That sounds miserable. I think, as a reviewer, it's important to keep in mind that most problems have many solutions. You have to be flexible and work with the person that did the hard work of implementing it. Everyone messes up and lets a bug slip through every now and then. That's what multiple layers of thorough testing is for. On my current team, I'm considered to be the most thorough code reviewer. Folk usually thank me rather than scorn me, though. Some are afraid to send me their PRs not because they fear my feedback, but because they think reviewing their code will take up too much of my time. Reviewing code thoroughly doesn't take much time at all, though, if you make it a habit. If it's a bug, I explain my concern and suggest a fix. If it's a style nit, I link to the relevant style guide section. If it's a suggestion or personal preference, I explicitly say that, write out my rationale, then offer to chat more. If it's a weak suggestion, I tell them right off the bat that I'm fine either way. If it's a strong suggestion, I try to give them an "early out" by suggesting they simply add a // TODO comment. I'll let a coworker get away with murder as long as they leave a TODO comment. For new team members that send me a PR for the first time, I typically send a message at the start describing what they should expect. That helps a lot, because everyone's first few PRs are going to be rough until they've gotten up to speed on the existing team's expectations. I will say that there are some engineers that just don't take technical feedback well. When they join an existing team, they can be stubborn and refuse to adapt to the established culture. Instead, they either misinterpret criticism as personal attacks, or get frustrated and insist that the team conform to their preferences right off the bat. Team culture can and should evolve over time, but it requires respect and understanding of the status quo. It's possible for an open minded engineer to join a team, embrace its current culture, then radically change it all over the course of a few months. It's possible for a close minded engineer to not get more than a dozen PRs approved over the course of a year. Not to say that such engineers are good or bad one way or another, but rather folk should seek out projects that are compatible with their personality.
sys_64738 6y ago
Commented out code is a terrible idea. It is the reason you look at source code and see it filled with garbage. When you have a developer who has no confidence in their code then you ask the usual question about requirements, testing, code review, etc. If it's still not committed then there's clearly a developer issue to workout with management. When a developer fails to follow through on their tasks and takes extra time then this increases the budget of a project.
- codegladiator 6y ago
  I understand I have put that up almost without any context, so let me add some. It was(is) a (very) huge project which is still in development (my last interaction was more than 3 years ago) being built by a very big company in tech space, and various parts of it were outsourced to various vendors (including Indian software shops) and I was consultant to one such vendor. There were huge number of layers of management, while all the usual questions you mentioned would have the answer "yes". So yeah the devs were in general scared about the code and management both. They wouldn't ask questions, just say "yes" to everything.
- chokeartist 6y ago
  > Commented out code is a terrible idea. I have no idea what your context for such a statement is but I can tell you in my career as both an IC and now as pseudo-Management (Product Manager), commented out code has saved me many a times. Why? Very simple scenario. We hit issue X, dev Y has what they think is a fix... but they are not super familiar with the code base. They put the fix it, and keep the prior function/logic commented out. If dev Z needs to review this (assuming dev Y has left the org), the history is right there. The inverse is I have had to contact former employees to help me/us understand X. And anyone worth their salt isn't going to consult for free :).
cratermoon 6y ago
That's also a sign they aren't comfortable with the version control system. I used to be like that, and with cvs and svn it was somewhat justifiable. Now that we have git and it's everywhere I'm far less anxious. Not that git is perfect and things don't happen, but it's extremely good at not Screwing Up. It may not do exactly what you expected, but it doesn't break the repo. It also tries really hard to never forget anything unless you make an effort to force it. It might take a bit of digging around in the reflog to figure out how to get back to a sane state, but in every case I've had to deal with it was possible.

reificator 6y ago

Have I been working in a bubble? I'll give a coworker a hard time for making large infrequent commits, but I've never seen someone afraid to commit code. This sounds like the value proposition for version control hasn't really clicked for them. Are they comfortable branching?

chrisandchris 6y ago
I think it‘s less about version control and more about that the change is then associated with the employees name and if something ever goes wrong, it would be possible (easy?) to blame him therefore he‘s being scared about doing something because it could cause trouble for him somewhen in the future. And, imho, that goes back to not enough testing nd no safety nets to check for code errors (like code review, static analysis, ...).
- reificator 6y ago
  Clearly I am living in a bubble, because I cannot imagine working somewhere where I would rather be seen doing literally nothing than to do the exact thing I was hired for.
sgtnoodle 6y ago
By commit, I think the intended meaning is "put on a path that will ultimately affect production". For my current project, merging bad code typically means breaking a bunch of regression test suites for any coworkers that cut their branches at the wrong time. In more nefarious outcomes, it means a delayed software version release and, potentially, damaged UAV hardware at our test site. For my previous project, merging bad code could have resulted in someone losing control of a fully drive by wire car in a closed parking lot or test track. That's what big red buttons are for! For my project before that, some of my code was involved in handling literally every single sensor and actuator on a rocket and the space capsule on top of it. A subtle bug that slipped through to production could have been rather serious indeed.
- reificator 6y ago
  If individuals are fearing the repercussions from doing their jobs on a safety critical system like that, then the process has already failed. Your process needs to be so bulletproof that everyone involved feels absolutely sure that a defect will be caught. If there's any doubt in their minds then that part of the chain needs to be addressed and corrected. I'm not saying that people shouldn't take it seriously or should get sloppy, but if you're worried that making a commit could end in disaster then you're moving too fast.
NotAnAccountNO 6y ago
What do you consider to be large and infrequent? I see so many micro-commits that I start to wonder if some competition is going on...

sgtnoodle 6y ago

Sounds about right! I think that's an indication of lack of sufficient regression test coverage, coupled with complacency/fatigue from working on the same code base for an extended period of time. Unfortunately, the most business critical pieces of code tend to be the least regression tested. It's the earliest stuff that was made before any test frameworks were matured, it's been hacked on countless times by half the team based on shifting requirements to the point that no one understands it fully, and any future changes are such a high priority that it's "faster" to test it manually or in production. I am of course guilty of that myself on some pieces of code. I try to prioritize cleaning up expensive tech debt, though. When folk are hesitant to modify a piece of code, it's a strong indication that the code is due for refactoring. It's always worth it as long as you implement regression testing in the process.

waheoo 6y ago
Pretty much this. I suffer huge anxiety about committing code where I work. The regression testing is flakey and the ci/cd procedure is rediculously complex and black box. Very little transparency about what is or is not covered. Failures are common a, cryptic and intermittent. The work where I know where the tests live I commit without hesitation. Other random shit I happen across. Avoid it like the plague. Doesnt help how big the sites are either.

watwut 6y ago

Cause reasons for fear are not something people would tell you. I was in similar state twice and neither time I would be eager explain that to someone external. I was "afraid" to commit in a team where code review evolved into huge micro-management with inconsistent requirements on what good code looks like. The reviewer iteratively forced you to change it again and again each time with "this is bad code cant go in" comments. But you could not learn what he considers good code, cause it was different every time. I left after. Second time I was "afraid" to commit to part of code when our main architect had completely disproportionate blow up over previous bug. I made easy to fix bug which was my mistake. But it turned into massive public blow up over work being shitty, us intentionally ignoring his needs, there being tons of bug unusable version (there was literally one bug). Then he wanted massive refactoring to avoid possibility of same bug ... and I made bug in refactoring which led to same blow out, again claiming it was done without care etc. After that, I really did not wanted to do any changes in that code. I cant guarantee complete lack of bugs in my code. Other people do bugs too for that matter, I dont think I make so much more of them. But, he was under pressure and stress that had nothing to do with me and I became rod for that.

sgtnoodle 6y ago
That sounds miserable. I think, as a reviewer, it's important to keep in mind that most problems have many solutions. You have to be flexible and work with the person that did the hard work of implementing it. Everyone messes up and lets a bug slip through every now and then. That's what multiple layers of thorough testing is for. On my current team, I'm considered to be the most thorough code reviewer. Folk usually thank me rather than scorn me, though. Some are afraid to send me their PRs not because they fear my feedback, but because they think reviewing their code will take up too much of my time. Reviewing code thoroughly doesn't take much time at all, though, if you make it a habit. If it's a bug, I explain my concern and suggest a fix. If it's a style nit, I link to the relevant style guide section. If it's a suggestion or personal preference, I explicitly say that, write out my rationale, then offer to chat more. If it's a weak suggestion, I tell them right off the bat that I'm fine either way. If it's a strong suggestion, I try to give them an "early out" by suggesting they simply add a // TODO comment. I'll let a coworker get away with murder as long as they leave a TODO comment. For new team members that send me a PR for the first time, I typically send a message at the start describing what they should expect. That helps a lot, because everyone's first few PRs are going to be rough until they've gotten up to speed on the existing team's expectations. I will say that there are some engineers that just don't take technical feedback well. When they join an existing team, they can be stubborn and refuse to adapt to the established culture. Instead, they either misinterpret criticism as personal attacks, or get frustrated and insist that the team conform to their preferences right off the bat. Team culture can and should evolve over time, but it requires respect and understanding of the status quo. It's possible for an open minded engineer to join a team, embrace its current culture, then radically change it all over the course of a few months. It's possible for a close minded engineer to not get more than a dozen PRs approved over the course of a year. Not to say that such engineers are good or bad one way or another, but rather folk should seek out projects that are compatible with their personality.

sys_64738 6y ago

Commented out code is a terrible idea. It is the reason you look at source code and see it filled with garbage. When you have a developer who has no confidence in their code then you ask the usual question about requirements, testing, code review, etc. If it's still not committed then there's clearly a developer issue to workout with management. When a developer fails to follow through on their tasks and takes extra time then this increases the budget of a project.

codegladiator 6y ago
I understand I have put that up almost without any context, so let me add some. It was(is) a (very) huge project which is still in development (my last interaction was more than 3 years ago) being built by a very big company in tech space, and various parts of it were outsourced to various vendors (including Indian software shops) and I was consultant to one such vendor. There were huge number of layers of management, while all the usual questions you mentioned would have the answer "yes". So yeah the devs were in general scared about the code and management both. They wouldn't ask questions, just say "yes" to everything.
chokeartist 6y ago
> Commented out code is a terrible idea. I have no idea what your context for such a statement is but I can tell you in my career as both an IC and now as pseudo-Management (Product Manager), commented out code has saved me many a times. Why? Very simple scenario. We hit issue X, dev Y has what they think is a fix... but they are not super familiar with the code base. They put the fix it, and keep the prior function/logic commented out. If dev Z needs to review this (assuming dev Y has left the org), the history is right there. The inverse is I have had to contact former employees to help me/us understand X. And anyone worth their salt isn't going to consult for free :).

cratermoon 6y ago

That's also a sign they aren't comfortable with the version control system. I used to be like that, and with cvs and svn it was somewhat justifiable. Now that we have git and it's everywhere I'm far less anxious. Not that git is perfect and things don't happen, but it's extremely good at not Screwing Up. It may not do exactly what you expected, but it doesn't break the repo. It also tries really hard to never forget anything unless you make an effort to force it. It might take a bit of digging around in the reflog to figure out how to get back to a sane state, but in every case I've had to deal with it was possible.