7 ms·

>that's a huge groan and turn off and you lose tons of strength (credibility) as a candidate. Toxic and off putting. You put too much weight on relatively mino

>that's a huge groan and turn off and you lose tons of strength (credibility) as a candidate. Toxic and off putting. You put too much weight on relatively minor things. It’s preventing you from fairly considering the rest of the candidate. You could be the one to teach them to do READMEs well.

beardedwizard 8y ago
Wow. This comment is deep. People who call themselves managers, read that last sentence 20x. This is what we need to do, can you?
- deleted 8y ago
  [deleted]
- chillacy 8y ago
  Most big companies no longer believe in training but selecting. This is popularized in “strengths based” training sold by a handful of consultants.
zepolen 8y ago
So choose between: 1. A developer who doesn't respect himself first and foremost to write a README/maintainable code so that his future self and others can have an easier time. 2. A developer who cares about communicating his work to himself/others and making the environment easier for everyone to work for the future. Right.
- chickenfries 8y ago
  I cannot stand this kind of developer armchair psychology.
- beardedwizard 8y ago
  Are developers only male? Your biases are really showing in these comments.
  - zepolen 8y ago
    Yes developers are only male, women belong in the kitchen. /s
- Novashi 8y ago
  False dichotomy, and if you actually witness this first hand and only have two options in your candidate pool, you might need to spread your net a bit further. Also the original post was about READMEs only, so if they have unmaintainable code, the README really doesn't matter that much, does it? Developers are at various stages in their expertise when they go looking for jobs. READMEs are nice but try not to let yourself get tied up with emphasis on a few signals that document the whole human. README quality is a pretty weak signal. If you bring up the README in an interview, and the dev cannot find any motivation or acknowledge that it could be better, then maybe you might have to pass on them. My problem with your methods is that you get to this point without even opening a discussion. READMEs are a relatively teach-able skill and in pretty quick fashion. Maintainable code, much less so obviously.
  - zepolen 8y ago
    > README quality is a pretty weak signal. It's a fantastic signal of what the quality of the code will be. Lack of a README indicates many things, including unmaintainable code either via lack of experience or rushed work. But hey talk is cheap and you seem to know a lot - so how about you link an open source project you've published ;)
    - Novashi 8y ago
      >But hey talk is cheap and you seem to know a lot - so how about you link an open source project you've published ;) I wrote tech docs explaining the jungle of IT systems that we were relying on at a hospital I worked at, and sometimes that included diving into old code. These were usually much longer than READMEs. Having a README wouldn't have saved this code from needing to be refactored. Nor would it have really changed my opinion of the code. It hasn't been a reliable signal. The hard part about documentation is keeping it up-to-date and accurate and not filling it with extraneous details and going off on tangents. A lot of the READMEs are written for quick bootstrapping and that isn't going to reflect much on your code quality. I care more about good documentation and that's harder to write than a README and a much better signal. I don't have time to work on open source but it's clear my experience has been vastly different than yours and I doubt either one of us are going to come up with a peer reviewed reason for either side. Turn this around and say "this repo has a README! surely it's really good and so is the code" and it makes no sense to give that much credit for something that really isn't impactful beyond the first few days of using something.
- amitport 8y ago
  You're choosing between a person who didn't write a readme and a person who did. Anything beyond that is unfounded bias IMHO. (I have a lot of personal projects and I've conducted interviews)
- bjourne 8y ago
  I don't agree with zepolen's comments at all. But can you guys who use "downvote to disagree" kindly please stop? You are just making Ask HN worse for all of us by turning it into an echo chamber. This isn't Reddit FFS.
  - yeahitslikethat 8y ago
    And fading out comments just because people here disagree with them is super annoying. If 4 ppl disagree with something No one else is even able read it?? We shall all only say that which no one will disagree with.
  - zepolen 8y ago
    In the long term any vote based community turns into an echo chamber. The popular opinions win. The users with unpopular opinions get downvoted/censored and are either banned/leave. Leaving one opinion behind. Moderators also a play a huge part in this - which is why it's only an illusion of democracy. I wonder if it would be possible to create truly neutral discussion platform that doesn't end up as an echo chamber.

beardedwizard 8y ago

Wow. This comment is deep. People who call themselves managers, read that last sentence 20x. This is what we need to do, can you?

deleted 8y ago
[deleted]
chillacy 8y ago
Most big companies no longer believe in training but selecting. This is popularized in “strengths based” training sold by a handful of consultants.

zepolen 8y ago

So choose between: 1. A developer who doesn't respect himself first and foremost to write a README/maintainable code so that his future self and others can have an easier time. 2. A developer who cares about communicating his work to himself/others and making the environment easier for everyone to work for the future. Right.

chickenfries 8y ago
I cannot stand this kind of developer armchair psychology.
beardedwizard 8y ago
Are developers only male? Your biases are really showing in these comments.
- zepolen 8y ago
  Yes developers are only male, women belong in the kitchen. /s
Novashi 8y ago
False dichotomy, and if you actually witness this first hand and only have two options in your candidate pool, you might need to spread your net a bit further. Also the original post was about READMEs only, so if they have unmaintainable code, the README really doesn't matter that much, does it? Developers are at various stages in their expertise when they go looking for jobs. READMEs are nice but try not to let yourself get tied up with emphasis on a few signals that document the whole human. README quality is a pretty weak signal. If you bring up the README in an interview, and the dev cannot find any motivation or acknowledge that it could be better, then maybe you might have to pass on them. My problem with your methods is that you get to this point without even opening a discussion. READMEs are a relatively teach-able skill and in pretty quick fashion. Maintainable code, much less so obviously.
- zepolen 8y ago
  > README quality is a pretty weak signal. It's a fantastic signal of what the quality of the code will be. Lack of a README indicates many things, including unmaintainable code either via lack of experience or rushed work. But hey talk is cheap and you seem to know a lot - so how about you link an open source project you've published ;)
  - Novashi 8y ago
    >But hey talk is cheap and you seem to know a lot - so how about you link an open source project you've published ;) I wrote tech docs explaining the jungle of IT systems that we were relying on at a hospital I worked at, and sometimes that included diving into old code. These were usually much longer than READMEs. Having a README wouldn't have saved this code from needing to be refactored. Nor would it have really changed my opinion of the code. It hasn't been a reliable signal. The hard part about documentation is keeping it up-to-date and accurate and not filling it with extraneous details and going off on tangents. A lot of the READMEs are written for quick bootstrapping and that isn't going to reflect much on your code quality. I care more about good documentation and that's harder to write than a README and a much better signal. I don't have time to work on open source but it's clear my experience has been vastly different than yours and I doubt either one of us are going to come up with a peer reviewed reason for either side. Turn this around and say "this repo has a README! surely it's really good and so is the code" and it makes no sense to give that much credit for something that really isn't impactful beyond the first few days of using something.
amitport 8y ago
You're choosing between a person who didn't write a readme and a person who did. Anything beyond that is unfounded bias IMHO. (I have a lot of personal projects and I've conducted interviews)
bjourne 8y ago
I don't agree with zepolen's comments at all. But can you guys who use "downvote to disagree" kindly please stop? You are just making Ask HN worse for all of us by turning it into an echo chamber. This isn't Reddit FFS.
- yeahitslikethat 8y ago
  And fading out comments just because people here disagree with them is super annoying. If 4 ppl disagree with something No one else is even able read it?? We shall all only say that which no one will disagree with.
- zepolen 8y ago
  In the long term any vote based community turns into an echo chamber. The popular opinions win. The users with unpopular opinions get downvoted/censored and are either banned/leave. Leaving one opinion behind. Moderators also a play a huge part in this - which is why it's only an illusion of democracy. I wonder if it would be possible to create truly neutral discussion platform that doesn't end up as an echo chamber.