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.

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.

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.

Flatly untrue. They are people capable of mistakes. Viruses are often more complex than every day business software and that isn't perfect yet either.

Assuming this means you won't actually check their usage of it, meaning you won't catch any errors they make.

It hasn't for me. Rent has gone in the opposite direction as I've downsized.

We haven't optimized low-cost, small, quality homes despite all of technological progress and I'm pretty sure it's intentional.

Well that just tells you everything you'd want to know about FB culture, regardless of his actions in those situations

(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.

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.

Travel would be nice but I'd prefer to stick to civilization and not do stuff like long-term scientific expeditions to an Antarctic glacier or something remote like that.

Company size really doesn't matter but I've found it's easier to break into industries by joining a larger company.

Salary isn't a huge deal as long as it's over $80k (with median cost-of-living).

Thanks for taking the time!

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.

I'd avoid getting into that mindset. Fight tooth and nail for what's owed without damaging your quality of life. Ideas and opportunity like this don't come around often in life.

It's dangerous because it will dilute electrolyte concentrations in your body. Drink tap/bottled water. Distilled water is completely unnatural to the body and should only be consumed in emergencies when you literally have nothing else. Even then it's still probably not a good idea.

There's literally no benefit to choosing distilled water over tap/bottled water.

Most of my experience is desktop and web apps, but I'm looking to learn new tech. Some of the job posts I've seen have been scientific computing (python/C++/linux) so not really my area of experience but I have a pretty long runway.

Ultimately I'm looking for a field to learn and combine with my skills instead of just being a developer but I want deeper knowledge than what you'd get just by being thrown on a project that happens to involve oceanography.

There's pet projects with data crunching like with this stuff (https://podaac.jpl.nasa.gov/ and https://stackoverflow.com/search?q=oceanography) but I'm wondering more about problems and needs from scientists and people doing fieldwork.

Comments URL: https://news.ycombinator.com/item?id=19263294

Points: 9

# Comments: 4

It is removing something whereas most of the other diets simply want to replace something.

Many times developers get held to standards that they didn’t know existed. This still triggers developers to feel bad about their work (or themselves). It’s usually after someone has left that they find out some ‘standard’ only exists for that particular company.

It’s hard to make global standards, but company standards are easily do-able without having to endlessly specify every coding situation. What the standard doesn’t cover should be addressed in code review or before.

Sometimes languages come with standards (C# coding standards are better than JavaScript standards, for example) and those can be a good proxy or starting point.