3 ms·

Some people need to comment on something in order toi justify their existance. Subjective issues are the easiest. I assume PR is not public relations? <story

Some people need to comment on something in order toi justify their existance. Subjective issues are the easiest. I assume PR is not public relations? <story> Long time ago I worked at this place where the CEO was known for needed to fel involved without actually being involved. My boss had me work on a demo that the CEO would use for potenial clients. In the middle of the demo it did some odd steps. Clearly a mistake, I had just failed to remove a part in the scripting. Well I showed this to my boss, with the odd part in, since I did not realize it was there. When it happened I commented that I obviously need to remove that part. He told me to leave it in, as it would give the CEO something to complain about, and feel like he had made a real contribution. When shown to the CEO he loved the presentation except for that one glitch. You could almost read his mind ("oh my what would these foolish developers do without me"). <story off> Sadly I have seen this repeated many times.

navalsaini 8y ago
This is a really interesting story. Glad you shared it. I suppose, being a CEO, one is entitled to such privileges. :) PR = pull request. Created so that your peers can review the code and catch any issues (architectural, logical or just styling). I think the value attributed to them should be 100x to 10x to 1x (or lesser than 1x). But its not a commonly held belief. Many software engineers take pride on producing beautiful code. Its not about the product but also about wanting to be the best (say taking it from 99% to 99.9%). But it has its bad side - product can take a back seat to the new cool aid drink language on the block.
- sloaken 8y ago
  So back in the dark ages ... 20 years ago, company I worked for had what they called 'SoftWare Intensive Inspections'. Code we were writting delt with Telecomm and if a system failed then the telephone company lost money and when it failed real bad, 911 would not work and people could get hurt. Part of the proces was that when you reviewed stuff, you could comment on: 1) does not work 2) not understandable 3) not maintainable 4) failed to meet standard - but these were usually related to #2 or #3 5) excessively slow or large - like could be written to be 10 times faster, just double the speed was a STFU During the inspection the author was the note taker. Another would read the code and explain it as best they could. If they could not explain the code, then it failed #2 & #3. One person, usually team lead would arbitrate if the problem was really an issue. This process seemed to work real well, and found a lot of bugs before the code was fielded. Of course someone would always argue the tabs verses spaces, and where do the curly braces go. This was usually met with STFU. The most common standard fail was the use of magic numbers. I had one jerk who actually did a #define TEN 10. Needless to say that failed. In all of this STYLE was never a valid complaint.

navalsaini 8y ago

This is a really interesting story. Glad you shared it. I suppose, being a CEO, one is entitled to such privileges. :) PR = pull request. Created so that your peers can review the code and catch any issues (architectural, logical or just styling). I think the value attributed to them should be 100x to 10x to 1x (or lesser than 1x). But its not a commonly held belief. Many software engineers take pride on producing beautiful code. Its not about the product but also about wanting to be the best (say taking it from 99% to 99.9%). But it has its bad side - product can take a back seat to the new cool aid drink language on the block.

sloaken 8y ago
So back in the dark ages ... 20 years ago, company I worked for had what they called 'SoftWare Intensive Inspections'. Code we were writting delt with Telecomm and if a system failed then the telephone company lost money and when it failed real bad, 911 would not work and people could get hurt. Part of the proces was that when you reviewed stuff, you could comment on: 1) does not work 2) not understandable 3) not maintainable 4) failed to meet standard - but these were usually related to #2 or #3 5) excessively slow or large - like could be written to be 10 times faster, just double the speed was a STFU During the inspection the author was the note taker. Another would read the code and explain it as best they could. If they could not explain the code, then it failed #2 & #3. One person, usually team lead would arbitrate if the problem was really an issue. This process seemed to work real well, and found a lot of bugs before the code was fielded. Of course someone would always argue the tabs verses spaces, and where do the curly braces go. This was usually met with STFU. The most common standard fail was the use of magic numbers. I had one jerk who actually did a #define TEN 10. Needless to say that failed. In all of this STYLE was never a valid complaint.