>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.
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.
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.
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 ;)
>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.
A programmer who by default adds a good concise readme to his projects is an indicator that the same will apply to the codebase, in that he will plan for the future.
I've seen it too many times, exceptions are rare.
A good readme is concise, it offers key 'bring me up to speed as fast as possible' information, nothing more. It's not documentation.
A good readme should include a quick bootstrapping info, but it's not enough, it should have a concise summary overview and list any important gotchas. As well as provide the procedures for builds/releases if apply. Links to relevant docs if exist are fine if the information becomes too large for the readme.
> 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.
See I read that and figure that it was actually a perfect signal - since that "bad unmaintainable code" lacked a good readme.
It's like the Van Halen requiring Brown M&Ms at their concerts https://www.snopes.com/fact-check/brown-out/ - I've found the README is one of the best indicators of the level of detail a person applies to their work.
> it makes no sense to give that much credit for something that really isn't impactful beyond the first few days of using something.
This is the attitude that I wouldn't be looking for when recruiting - a README has a ton of use, for helping bootstrapping new people to the code base - to even helping yourself if you do some maintenance on an old project and don't want to spend more than the minimum time necessary.
It's this forethought I'd like to see in a candidate, and that 99.9% of the time shows in the quality of the readme.
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.
It isn't just the older generation (and actions done 20-30 years ago) doing dumb things and getting shamed for it. The newer generation grows up without learning the implications of mass surveillance, mass long-term storage, mass searching and indexing, and encountering driven people looking to shame others just for fun.
(example: one of the kids of the parents accused in the college admission scandal tweeted about "studying is hard" or something to that effect and it came into my twitter feed and everyone was having a laugh)
If you decide that people NOW shouldn't be shamed for behavior 20-30 years ago, why even bother shaming? I know I'll be different in 20-30 years in the future, so maybe don't shame me (as much) in the present, as long as the actions aren't too heinous. Maybe I don't end up changing, in which case, more shaming would seem 'normal', but the advantage there is that someone has to remember to come check on me. I could gamble that there's a bigger outrage and the internet mob moves onto something else.
The upside of this is that the internet is learning how many people are really bad people. Part of the outrage culture comes from that. Most of these details were hidden in an information-deprived world, and importantly, lack of searching and indexing to actually find all of it.
Maybe it will get so bad that new identities become a much bigger industry and that becomes a social norm. A new identity and probably a new home country is probably the best short-term solution today for this if anyone feels unjustly shamed by society.
You have observed something that points at a much deeper problem. The problem lies in our use of language. Language is the key.
> I know I'll be different in 20-30 years in the future,
Psychologist Wendell Johnson, pointed out that we create many problems for ourselves by using Static Language to express or
capture a reality that is ever changing -
“Our language is an imperfect instrument created by ancient and ignorant men. It is an animistic language that invites us to talk about stability and constants, good and bad, right and wrong, about similarities and normals and kinds,
about simple problems, and final solutions.
Yet the world we try to symbolize with this language is a world of process, change, differences, dimensions, functions, relationships, growths, interactions, developing, learning, coping, complexity. And the mismatch of our ever-changing world and our relatively
static language forms is part of our problem.”
"really bad people" is an example of that static constraint on language. People are not static but ever changing (which all our marketers are very conscious off which is why we get an iphone 4,5,6,7 etc not just an iphone).
To get people to accept that reality is dynamic, social media and news media have to reflect on their signaling. Signals like clicks/views/likes/retweets/upvotes all reinforce static world views.
Honestly what should your salary be if you have domain expertise and are good with data science tools (and tools surrounding them like git, CI/CD, etc.)?
>Feels like it's a very high false positive rate and one that pushes all the time costs onto the applicant (multiply ~2hr by say 5 companies that want you to do a coding challenge).
It is, I wouldn't entertain companies that do this unless you really need a position.
This is the trifecta of bad interviewing tests:
- No compensation
- Stupidly restrictive time limit
- High chance of not getting feedback
Personally I would turn them down and then explain these three things. There are plenty of companies with less annoying hoops.
This one kills the chance of my applying by itself. Turns what could be a interesting coding challenge into an exam, ruining the fun of it. I could see junior devs going through this to get some experience but why would anyone past that point in their career bother when there are so many options?
Because the companies that do the coding exams pay well, have high prestige, use tech that he likes, etc. It's not always so simple to just refuse to go through an annoying interview process, even if it sucks.
Not the same thing but I’ve read that Square pays people for coming to their on site interview because it’s a full day. Unsure if that is still the case.
This is a good technical approach but if you get this far, your salary won't match the value delivered by your actual skillset.
Companies know this. There's not appropriate compensation for people who can get comfortable with this breadth of stuff. Fullstack is currently "exploited" because of this IMO.
That is true. Your salary will most likely not reflect your actual value, but will be way below what you should actually earn.
But - if you do it right (and with a bit of luck), you can work yourself into a position in which you've got a lot of freedom to choose what you want to work on, and that freedom is worth a lot in itself. Because you're the one guy that can "get everything to work smoothly together" and that is able to deliver entire working solutions, while practically all the others may be able to get a single part into good condition, but they stumble when it comes to getting to something working in a greater context. Their solutions will inevitably be less polished than yours.
People are not indifferent to this. It takes a while, but they notice it. And you will be in high demand because your solutions have this really nice tendency to "just work". And nobody will really understand why it is that way. Which means you'll be able to largely direct what you're going to work on next, because since nobody has a real clue why your stuff "just works" all the time, they are doomed to rely on your opinion when it comes to where your specific skill set is most valuably used next.
This is the direction that my career is taking. Definitely the benefit is you eventually get to work on the good projects that you want to because people trust you to deliver a level of work they don't seem to get very often.
I've always felt relatively underpaid compared to what I wind up bringing to the table, but I would say there have been subtle but noticable perks in other ways and it's definitely translated to comp over time too.
It clicked for me a while back that the vast majority of devs just working on line of business applications have never and will never put together an entire enterprise grade system end to end by themselves in their career. So all you really have to do is (a) have a relatively good head on your shoulders and (b) just hack away at building out a fully fledged system end to end in your own time. A sort of reference architecture of your own. Then when you need to implement stuff at work, you've already solved the problem once before so instead of taking a day to wrap your head around how a particular part of it works, you just whizz through it relatively quickly. It looks like magic from the outside, but it's nothing more than being prepared ahead of time.
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.