Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We fired our top talent. Best decision we ever made

medium.freecodecamp.org

Post reply on HN
Print view View original

131–137 of 137 posts

Re: We fired our top talent. Best decision we ever made

#131

Post by scintill76 »

mattbgates wrote: post #6
wakeywakeywakey wrote: post #2

TBH, I read this as: we mismanaged the project for months (years?), reduced scope creep by negotiating with the client, and finally implemented what should have been the version 1.0 solution while shifting the blame entirely on the loner dev who worked himself into a corner trying to catch up to our sales department's untenable promises. Everyone created the problem, the dev was an easy target to eat the blame becaus…

I think I have to agree with you. The fact that Rick was allowed to be turned from a Dr. Jekyll to a Mr. Hyde is kind of the company's fault. No one stepped in to hold Rick accountable during meetings? While I no longer work there, my first job with some programming had me training to understand the code, what it was about, and even how to write it. To this day, I still use this method so I don't get lost or bored in…

Reminds me of this style:

  /**
   * Calculate the thing.
   *
   * @param $foo the foo value
   * @param $bar the bar value
   * @return the thing
   */
  function calculateThing($foo, $bar) {
      return $foo + $bar; // add foo and bar
  }
Such comments are worthless noise that obscures the important parts of the code and camouflages any actual useful comments that might be there. I would so much rather have better names than "thing", "foo", and "bar", and maybe a comment about why the values are summed, if it's not obvious. When you do those right, you won't even need many comments. Maybe a docblock, but don't bother with that if it's nothing more than a robotic "English version" of what is already obvious from the function definition. IMO most good developers will perceive your file header as a redundant annoyance for similar reasons, as other commentors have explained.

Re: We fired our top talent. Best decision we ever made

#132

Post by valuearb »

sgift wrote: post #129
valuearb wrote: post #86

Earlier quoted context omitted.

I have been coding for almost 40 years and always been big on documenting code, but the problem is that code changes and documentation doesn’t always keep up. Given modern tools I’ve come to the conclusion that documenting overall purpose and specific edge cases is more than enough. For example, the file header should describe its purpose, and anything in the actual code that’s not obvious should be commented. No mor…

> I have been coding for almost 40 years and always been big on documenting code, but the problem is that code changes and documentation doesn’t always keep up. This has always been a sign for me to tread very, very carefully. People who change code without changing the comments probably didn't read the comments, didn't read the code or didn't understand it - either way, if comment and code disagree both are probably…

I agree mismatched comments/code is a huge warning sign. But I think requiring standardized comments is a problem.

When I started out every function had to have a header comment, with name, inputs/outputs, description of purpose/etc. It was significant extra work to keep that up to date. I could update a function three times in a day, and have to rewrite the comments three times to check it in.

And in the end, I know the name of the function. I can see the inputs and outputs. The only part of those comments that were occasionally useful were purpose, details of which often changed with edits. And in reality, as long as the function isn't hundreds of lines long (another problem), I can read it and discern exactly what it's trying to do.

Comments that were most useful said stuff like "this looks weird or dumb, but we had to do it this way because of this thing we and you probably didn't expect in the data/system/etc"

Re: We fired our top talent. Best decision we ever made

#135

Post by RangerScience »

seanmcdirmid wrote: post #96
zzalpha wrote: post #89

Earlier quoted context omitted.

No developer is a solo developer. At a bare minimum, Present You is working with Future You. And Future You would appreciate it if Present You documented your work.

The biggest problem of being a solo developer is that there is no one else to drive documentation needs. Yes, documentation would be great for future you, but present you has no one (including future you) to chat with about the code to get an idea of what documentation would be useful. If you are forced to work just inside your head, then the result is going to be obvious and predictable. And no, talking to the rubbe…

I use "tired me". I think once or twice I've used "inebriated me".

In the beginning of my career I was much more diligent about this (but I also didn't write as readable code, so it was more necessary); the exercise was simple:

When I hit the stupid part of the day (the end of the day), I go back over code. When I don't understand something, I write down something about my confusion. In the morning, when I'm back to being smart, I convert all the confusion to comments and/or better code.

Re: We fired our top talent. Best decision we ever made

#136

Post by pc86 »

mattbgates wrote: post #34
sverhagen wrote: post #21

Earlier quoted context omitted.

"Old school"? I think it's in most cases irresponsible not to use version control. Sorry to say, but it's "amateur hour". No better than "Rick". I agree with one of the parents that "Purpose" is probably the most useful, but even there: at that level the code should be largely self-documenting.

I never said I didn't have version control. To assume "at the code level it should be largely self-documenting" is to be a Rick. Comments are there to help everyone, including non-programmers understand what is going on.

For what logical purpose would a non-programmer be reading your source code and only be able to accomplish whatever their task is if you adequately comment it?

Re: We fired our top talent. Best decision we ever made

#137

Post by pc86 »

scintill76 wrote: post #131
mattbgates wrote: post #6

Earlier quoted context omitted.

I think I have to agree with you. The fact that Rick was allowed to be turned from a Dr. Jekyll to a Mr. Hyde is kind of the company's fault. No one stepped in to hold Rick accountable during meetings? While I no longer work there, my first job with some programming had me training to understand the code, what it was about, and even how to write it. To this day, I still use this method so I don't get lost or bored in…

Reminds me of this style: /** * Calculate the thing. * * @param $foo the foo value * @param $bar the bar value * @return the thing */ function calculateThing($foo, $bar) { return $foo + $bar; // add foo and bar } Such comments are worthless noise that obscures the important parts of the code and camouflages any actual useful comments that might be there. I would so much rather have better names than "thing", "foo", a…

It's the "CS 050 Computer Science for Humanities Majors" type of commenting (I was a humanities major, no offense intended). A bunch of comments that are only there because you think you have to have comments, or because you're graded on whether or not comments exist.
Post reply on HN