I completely agree.

Extract the utility (eg. Facebook’s events and groups) without getting sucked into the cycle of shallow dopamine hits that is the news feed.

TBH I just love auto completion to reduce the amount of typing I need to do.

It's not satire, it's hypothetical.

It reeks of humble bragging and pretentiousness. The Dark Souls analogy just tops it off...

Reading it again, I can see that. However, I personally am a fan of rigorous - not ruthless - code review, the purpose and level of which has previously been explained to a new employee.

Obviously being an asshole is out of line, and if someone is being a dick in code review, that's a problem with the reviewer. But I think that being rigorous about maintaining consistency and quality is important.

Decent positions dont usually need disclaimers. Theres a difference between preaching, teaching, and coaching. Its not obvious that being an asshole is out of line. You make it sound like this mystery of pure "collaboration" is all about giving raw feedback. Raw feedback is inferior to polished feedback. Its just as important to communicate in positive ways instead of throwing this ruthless word around.

Honestly, your problem is that youve approached code discussion from a purely quantitative approach - ability to convince and ability to convey arguments in a persuasive yet unbiased way is huge. No one wants to do things by demand, decree, or just general hate.

Haha ok dude. I didn't write the article. And that wasn't a disclaimer; I was empathising with your point.

Oh, well carry on then, my bad ;-)

My first internship was like this. I loved it. It provided me with instant feedback on my code and as a result the quality of my code went from probably pretty low to as good as I could make it.

Having now worked at other places where code review is given low priority, I can say with confidence that I don't want to work anywhere that does not do serious code review.

Code review provides an important mentorship opportunity for junior programmers, and provides a simple way to keep code quality high and consistent. In addition, it provides a simple way to instruct new hires on internal style and conventions.

I currently use vim for everything as you once did, with plugins for everything, and a large .vimrc. I started using Intellij with vim bindings for school Java projects and I liked the utility it provided.

However, I feel like the thing holding me back from leaving vim is its customization. I like to work with multiple vim and tmux splits side by side, e.g. dev server output on one tmux split, with vim splits inside another tmux split looking at the server code.

Most IDEs I've tried more or less force a workspace layout on me, and might make it hard to achieve something like that. However, I can see that, depending on your preferences and area of work it can be a reasonable trade-off.

Does that make it right to persecute and torture them?

Only if you subscribe to the "evil deeds done against bigots are not really evil" doctrine.

Congratulations to the whole team! Thank you for all your hard work! Phoenix has so far been a joy to work with.

No. UBC is known, at least in British Columbia, for having an abnormally large percentage of Asians relative to other ethic groups.

Forgive me, but doesn't file.readline() provide the same functionality for reading a single line at a time from a file?

Yeah, but aren't we actually supposed to do this?

  for line in file:

Yes, and that is the idiomatic way to read files in Python. I guess me and the author are looking at different Python programs, because slurping the whole file is not "by far the most common way" I have seen files read in the wild.

Most of my code slurps the entire file at a time. I can't actually think of any code we have that streams the code.

Then again, most of my files are three dimensional matrices. There's nothing I can really do on a line by line basis.

Yes, this is essentially looping over successive calls to file.readline()

With at least one small (and usually irrelevant) difference: "for line in file" has its own internal buffering which cannot be turned off with python -u.

I learned this the hard way when debugging a Python script that read from tail -f output...

I thought a function that reads a line from a file would read the entire line and block until doing so. How would turning off line buffering change that? Do you expect 'for line in file' to yield as many bytes as is available if a full line can't be read yet?