4 ms·

You should try code review, it’s a great tool.

moron4hire 4y ago
I can't see how. If I were to be in an environment where there are multiple developers who can understand even the basic mathematics of geometry and linear algebra too do what I do (that's a tall order. It hasn't happened once in 20 years that I've worked in a company that has had even one other developer that knew anything beyond basic algebra), why would they spend their time telling me how to do my job, rather than just doing their job? If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it? It's kind how my children argue over basic things like bedtime. They insist it's only "fair" if one of them turns off the light and the other closes the door. And if the light is already off when they enter the room, then the door closer is going to get pissy and turn the light on to make his brother get up out of bed and turn it off. It's a meaningless exercise developed to give the illusion of control.
- chasd00 4y ago
  > If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it? well.. fair point. Code review guarantees nothing, if there is an issue found there's going to be delay to fix it as it rolls back through the process. I hate "process" as much as anyone else but I learned during COVID its importance. I implemented a vaccine system for a state government with a team starting at 3 and growing to over 100 in about 8 weeks. It was the hardest thing i ever did and "process" saved my ass and kept CNN off my front lawn a few times. It also was a real thorn in my side when i needed to get things done. Process vs getting-shit-done is a balance and it's rarely perfect.
- snovv_crash 4y ago
  I struggle to believe that your coworkers don't understand the basics of LinAlg and geometry. It seems much more likely that you write code which is hard to parse, can't be explained, and your concept of maintenance is rewriting it from scratch because you don't understand it a year later either. Writing code that other people understand is an independent skill from solving the particular problem at hand. If your colleagues don't understand your code, either you need different colleagues, or you can't write understandable code.
  - bambax 4y ago
    > Writing code that other people understand is an independent skill It's also the main skill of a developer. Code is for people.
    - chasd00 4y ago
      >> Writing code that other people understand is an independent skill > It's also the main skill of a developer. Code is for people. If there are any people reading this starting out in their career, i can't stress how important this is. Being able to write beautiful code and being able to explain it to your peers and see them take off with it and do amazing things is the single most important skill as a software engineer IMO. I would put it above any algorithm riddle, esoteric language feature, tool expertise, or anything else.
- vbezhenar 4y ago
  Why would you expect for code review to catch all errors? That's a false dichotomy. Code review is expected to catch some errors. Why code reviewer wouldn't fix errors himself? Well, that's an interesting question for sure. One reason, I guess, is that it current way encourages people to avoid doing mistakes over and over again. If code reviewer would have to fix error himself, that would not encourage person writing the code to avoid issues in the future and that would discourage person doing code review to find any issues. But, I guess, in a very trusted environment that definitely could work.

I can't see how. If I were to be in an environment where there are multiple developers who can understand even the basic mathematics of geometry and linear algebra too do what I do (that's a tall order. It hasn't happened once in 20 years that I've worked in a company that has had even one other developer that knew anything beyond basic algebra), why would they spend their time telling me how to do my job, rather than just doing their job? If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it? It's kind how my children argue over basic things like bedtime. They insist it's only "fair" if one of them turns off the light and the other closes the door. And if the light is already off when they enter the room, then the door closer is going to get pissy and turn the light on to make his brother get up out of bed and turn it off. It's a meaningless exercise developed to give the illusion of control.

chasd00 4y ago
> If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it? well.. fair point. Code review guarantees nothing, if there is an issue found there's going to be delay to fix it as it rolls back through the process. I hate "process" as much as anyone else but I learned during COVID its importance. I implemented a vaccine system for a state government with a team starting at 3 and growing to over 100 in about 8 weeks. It was the hardest thing i ever did and "process" saved my ass and kept CNN off my front lawn a few times. It also was a real thorn in my side when i needed to get things done. Process vs getting-shit-done is a balance and it's rarely perfect.
snovv_crash 4y ago
I struggle to believe that your coworkers don't understand the basics of LinAlg and geometry. It seems much more likely that you write code which is hard to parse, can't be explained, and your concept of maintenance is rewriting it from scratch because you don't understand it a year later either. Writing code that other people understand is an independent skill from solving the particular problem at hand. If your colleagues don't understand your code, either you need different colleagues, or you can't write understandable code.
- bambax 4y ago
  > Writing code that other people understand is an independent skill It's also the main skill of a developer. Code is for people.
  - chasd00 4y ago
    >> Writing code that other people understand is an independent skill > It's also the main skill of a developer. Code is for people. If there are any people reading this starting out in their career, i can't stress how important this is. Being able to write beautiful code and being able to explain it to your peers and see them take off with it and do amazing things is the single most important skill as a software engineer IMO. I would put it above any algorithm riddle, esoteric language feature, tool expertise, or anything else.
vbezhenar 4y ago
Why would you expect for code review to catch all errors? That's a false dichotomy. Code review is expected to catch some errors. Why code reviewer wouldn't fix errors himself? Well, that's an interesting question for sure. One reason, I guess, is that it current way encourages people to avoid doing mistakes over and over again. If code reviewer would have to fix error himself, that would not encourage person writing the code to avoid issues in the future and that would discourage person doing code review to find any issues. But, I guess, in a very trusted environment that definitely could work.