Comment by klibertp | Hacker News Reader

Comment by klibertp | Hacker News Reader

Parent Full thread

> "We fired people who could not write English right alongside"

The rest of the "features" of the GP workplace aside, this one is something I wish I've seen more often.

Would you read a novel riddled with language errors? Where no sentence connects seamlessly to the next? Where there's an order of magnitude more implicit content to track than what is actually written? Where all the usual rules of orthography and punctuation are casually ignored, for no apparent reason? Where there's no structure to follow and things happen in a pretty much random order?

I wouldn't. Yet I have to read hundreds upon hundreds of pages of code written in such a fashion. It's not just about aesthetics - code like that is harder to work with and, I think, in most cases is a net loss in productivity, ie. it would be better if that code was never written. I understand not all the code can be written with sufficiently well-worded comments and docs, but there should be a limit to how bad things can get!

In other words, if you don't want to be treated like a child, please start writing like a grown-up instead of like a 5 years old who's convinced he's the best writer in the world.

I think we may be in danger violently agreeing, and perhaps I should have added a bit more nuance to my previous comment:

- I've worked with plenty of people over the years whose first language is not English, so I don't necessarily expect the most wonderfully written prose in comments and documentation (or anywhere else).

- I'd much rather somebody used expressive variable, method, type, or function names than wrote a ton of comments. Nowadays, with reliable auto-complete, and masses of storage there's really no need for terse naming. That being said, the odd comment to convey intent can be great. Reams of comments tends to be a smell because, even with the best intentioned teams, when the pressure's on they tend to rust, which in itself can obviously become a problem. Some might argue that incorrect documentation can be worse than none at all.

- I do like people to write descriptive commit and PR comments: "fixed a bug" or similar is obviously not acceptable.

But a lot of the above is about professionalism and taking pride in what you do, rather than being something that needs "enforcing". In other words it's something you want to deal with by hiring and promoting the right people, who are going to provide an example for others to follow.

In my experience people who work in tech are not on average known for their love of being told what to do (although to be fair that applies many people) so it's more about creating a culture that leads to the outcomes you need than trying to enforce behaviours.

We indeed are in general agreement, but the devil is in the details - and there are many details to discuss.

Are you a native English speaker? I'm not, and I could easily claim that your first point is condescending to the point of discrimination. I know it's not what you're trying to say, but treating non-native English speakers like dimwits who can't even properly learn the de facto language of their profession may be actually offensive to quite a lot of people. It's entirely possible to learn a language well enough to be able to write clearly and correctly (mostly! mistakes happen) in terms of grammar, vocabulary, and punctuation and, personally, I believe it's a programmers' duty to do so, natives and non-natives alike.

> I'd much rather somebody used expressive variable, method, type, or function names than wrote a ton of comments.

But of course! However, the sad truth is that people who can't write good (meaning understandable and mostly correct) prose also cannot write readable code. Searching for a good name for a variable, method, type, etc. is the same process as searching for a good word to put in a sentence, to structure the sentence correctly or to make sentences flow naturally in a paragraph. If someone cannot write readable English, then how is he going to write readable code, which is actually even harder, because the rules of the language are much stricter? Some people use comments as an escape hatch which allows them not to think about the readability of their code and they should probably be fired, because both their code and comments suck. I believe the brilliant coder who can't write clearly in a natural language is a myth: it may not be "wonderful", but writing at least clear and succinct prose is doable for most competent programmers.

I think the difference of opinion between you and me here is that I see readability of source code as a single whole, encompassing things from naming temporary variables, to naming methods, classes and modules, to writing comments, docstrings, tests and examples, to writing docs, readmes and issue descriptions, while you seem to consider these things separately.

To summarize: programming is, from lowest level of programming language syntax to highest level of cooperating with teammates and clients, about communication, with a heavy emphasis on written communication. People who can't write prose are worse programmers than those who can. Whether you want or can work with such programmers is of course up to you.

You'd be surprised how many people have no idea about English and they are pursuing development career. Successfully even. There are companies where you can consider yourself lucky if half of your team speaks English.

English is one thing - knowing it enables access to a vast body of knowledge which is not translated to your native language, but you can - in principle - be a competent developer without ever learning English. It will be harder because you'll have a lot fewer books, articles, talks, blog posts and so on to read and listen to, but it's possible.

Writing is another thing. In my opinion, you cannot be a competent programmer if you are unable to communicate well in writing.

A private company is NOT A STATE. DC is a right to work state. We fire people for any reasons. I had a pro PWC recruiter as employee #11. We were exemplary in practice. But nobody "gets jobs." That is unskillful thinking. People "make things." I need not argue. Go read "The McKinsey Way." That is a famous company where smart people like to work. They run an attrition hierarchy. They have a famous hierarchy of priorities: Customers 1st, McKinsey 2nd, Employees 3rd. Language deficits are never customer problems. Is this a support group for Matrix Neo Masters of Swift rewrite future? Too bad. Heroes write paychecks. They make the rule their customers need. Machines rust. Flesh rots. How philosophical do we have to make this?

Reply on news.ycombinator.com