After 5 years of working in tech, I've surmised that almost every company severely underestimates the importance of English writing skills

[-]

Rain-And-Coffee@reddit

As someone who writes 90% of our internal documentation I agree 100%.

I took a bunch of technical writing classes and I would highly recommend them.

[-]

beepboopnoise@reddit

https://developers.google.com/tech-writing/overview

is it this one??

[-]

PITCHPILOT@reddit

I had no idea this was freely available, thanks for sharing, definitely goes on my to do list. 👍

[-]

I recently semi-audited my work TODO list. For the portion I audited, it represented ~6 months of continuous full time effort. I imagine the rest of the unaudited portion is another 6 months, so my backlog is a year+ long.

[-]

tejasjadhav@reddit

This was really helpful. Thanks for sharing 🙏

[-]

Rain-And-Coffee@reddit

👍

[-]

reddit_man_6969@reddit

Thanks for mentioning, I’ll check it out.

I also love Google’s SRE manual. Hugely helpful even for non-SRE.

[-]

Proper-Ape@reddit

Google's SRE manual is very helpful indeed.

[-]

Old_Bug_6773@reddit

I've been meaning to reread it. Hopefully it is improved in the past eight years when it was required reading for work. I found the writing quite frustrating. Frequently triggering the voice of Inigo Montoya saying " You keep saying that word. I do not think it means what you think it means."

[-]

Proper-Ape@reddit

I'd be interested to hear why you say this. I didn't think the writing was stellar, but I don't remember it to be that terrible either. I read it about 3 years ago though, so maybe it was a different version.

[-]

Old_Bug_6773@reddit

I'm not seeing it with a quick scan. Hopefully I won't see it in a more careful reading. It was basically redefining a simple word to use incorrectly, but I am not seeing it.

So far, the most cringe worthy bit is the assertion that logs aren't meant to be read. Not with that attitude they aren't. Otherwise, it's reading smoother than I had remembered.

[-]

Proper-Ape@reddit

logs aren't meant to be read

I'd say logs should be as greppable as possible. I.e. information should be on one line if possible, especially correlated info.

Readability is never bad though. Even if you only read portions.

[-]

theDarkAngle@reddit

I agree but I'll add that part of the problem is that getting good requirements is a bunch of work in and of itself so often people find it easier to be vague or to use obfuscating language and make the developer do all that.

It is somewhat reinforced by the fact that often you'll have senior+ level devs who will write their own tickets for certain things like tech debt, and since they understand the issue, the ticket describes almost nothing, just a vague reference. So then vague or half-done tickets become normalized.

[-]

Regular_Zombie@reddit

A lot of the reason you are those tickets is a requirement that everything must be a ticket before work starts; typically for some vanity metric. It doesn't help when you inherit a project and there are piles of old tickets with no meaningful description.

[-]

SituationSoap@reddit

everything must be a ticket before work starts; typically for some vanity metric.

I pretty strongly disagree that the root desire here is generating some kind of vanity metric. The desire for all work to be in tickets is pretty simple: you need to know what everyone is working on. You need to know how far along they are in that work. You need to be able to track how long it's taking to deliver work, and ideally how long that work was estimated to take in the first place.

None of those things are vanity metrics. They're pretty basic large-scale project management.

[-]

ikeif@reddit

For the most part, in my experience - people who hated ticketing systems never had any established processes around them, or they were beaten over the head with "burndown charts" and "velocity."

I worked at a place where they were SO focused on metrics, but they would never change an estimate. If we said "we think this will be X-Y points" they'd just grab an average and round down. Then if it turned out it was complicated for whatever reason - "NOPE IT'S STILL LOWER POINTS WHY IS IT TAKING SO LONG?!"

I've worked with amazing POs/PMs/BAs in the past that absolutely spoiled me by having it down to a science of "here is the trail of tickets from start to finish, all the features, broken down so a developer knows when they can start something and what is blocking others work."

But the metrics measurement becomes a waste, because then some management focuses on that and not on the work itself.

OR people take a ticket, and it's just kanban - "I will do it, I am doing it, I did it." That's it. You see that status. Versus being able to look at the ticket and see "there is a PR open that hasn't been reviewed" or "ah, you added comments indicating it was being blocked/reviewed/on hold" in the ticket itself. So you can see the work and understand its current state.

But a lot of developers I've worked with don't want to communicate, they just want to do.

[-]

zuilli@reddit

But a lot of developers I've worked with don't want to communicate, they just want to do.

I think I'm one of those, I understand that communication about what's being done and what's taking longer than expected is desirable, specially by management, but I hate having my work tracked like that. It feels a lot like being micro-managed but a bit more lax.

I guess since I'm a devops and don't really work in big teams and systems with tons of changing parts I fail to see some of it's usefulness, it's mostly a metric creator about my work and less of an organizational tool.

[-]

ikeif@reddit

It's an aspect that depends on organization needs and team dynamics.

Like a lot of people will say "Scrum/kanban/tickets DO NOT WORK" when it's just how it's implemented - they just instantly shut down because they had a bad experience.

And I TOTALLY get that sometimes, the communication is longer than the effort to do the work.

The biggest aspect for me, that I've learned over the years - is "future you will thank past you for being detailed and leaving bread crumbs."

At one job, you can find what ticket is attached to a line of code, find the ticket, read the description, read the notes - and you have a better picture of who/what/why.

At another, I find - they changed ticketing systems. They didn't port anything over. The commit message is vague. So you have zero insight (unless the developer on the commit still works there, and remembers it from X years prior).

I try to over document and over comment so that there's no doubt about what's going on - especially if I am unavailable (and we are remote - so not everyone is online at the same time). So it's nice to know "I wanted to know how that was coming, he commented updates that he reached out to DevOps to resolve a pipeline issue, and they have a ticket on their board to handle it which will update this ticket when it's completed."

I think it's just… finding your flow. But I think as we move forward with LLM integration, we can get more things a little more automated so some of that heavy lifting/communicating can be delegated to "read over a generated paragraph - yup, that matches what I did, save that comment" and now you've communicated better!

But I think we need to build that tool first XD

[-]

janus_quadrifrons@reddit

As a career support person, this is the answer.

My current company worked fine without documentation for years. People understood the vague notes other people had left behind because they'd learned the actual tech from the person who wrote the notes and they knew the exceptions. If a routine job needed doing, someone just did it. There were some hiccups but overall it worked fine.

Then we got acquired, half the engineers were laid off, and in six months half of the ones who were left had quit because they were overworked and being micromanaged through RTO. We now have 3 engineers (of a team of 12 doing the work of a team of 18) who actually know what the fuck is going on. Hey, what does this setting on a 10+yo client account do? We don't know, probably nothing. Is it safe to turn it off? Sure, go ahead. Whoops, half our service has simply stopped working and it'll take two days to figure out why, never mind get it working again.

It's the bus factor times ten. Documentation is a waste of time until you don't have the documentation, at which point you find yourself setting money on fire to stay alive.

(We're retail-adjacent and coming up on our first Black Friday without some of our core team; pray for us.)

[-]

SituationSoap@reddit

But a lot of developers I've worked with don't want to communicate, they just want to do.

I'd reword this a little bit to say that a lot of developers don't want to put in the time to think about how to effectively manage projects. But I think you're generally right about this.

[-]

Proper-Ape@reddit

write their own tickets for certain things like tech debt, and since they understand the issue, the ticket describes almost nothing, just a vague

This is a pet peeve of mine. Especially since older tickets inevitably get cancelled because even the writer forgot what they were tangentially insinuating.

Be clear, be precise, summarize as much as you know about the issue as you can. If you need a sync meeting to explain the ticket to somebody on your team that's supposed to take it over: you've failed.

[-]

gopher_space@reddit

I'm not sure I've worked anywhere there was enough duplication of skill and knowledge to just start working on someone else's ticket without days and days of loading their state.

[-]

JustthenewsonCS@reddit

The problem reddit doesn't want to say or admit to is this is the cost of a large majority of the workforce being on VISA or offshored.

Shocking, if you hire people not born in a country that natively speaks English, the documentation and communication barriers might happen.

No, it isn't xenophobic or racist to say that either reddit. If anyone said this if it was happening in the opposite direction, you all would not have a problem with that.

[-]

Old_Bug_6773@reddit

It's hard to generalize. Although one might generalize doing so about people based on their ethnicity tends to generally be xenophobic.

I've often found it easier to understand an East Indian who grew up in the British based education system common in India where they are required to read English lit and know Shakespeare & co. than American products of the STEM program who've often never read a book.

But even such a generalization does adequately paint the picture of America let alone any culture. In California, I was shocked by the ridicule I received for having books. Although some were impressed I had a copy of K&R, the eye rolls I'd receive when quoting it were alarming. Whereas in the Midwest and East Coast, people caught references to Vonnuget and the Bars.

Reading and writing are fundamentally connected to the as ability to think clearly. If you can't do that, it shows in one's coding and life. The anti-literate bias in tech is a huge time suck.

You might find the difficulty is with your literacy, not theirs. Improving your English might help you bridge the gap and learn some interesting stuff from your coworkers around the globe.

Like Rambo said, change your language; change your life. It's on you.

I don't know how many foreign languages you speak, but learn a few and then get back to me on your findings.

[-]

NewRengarIsBad@reddit

Curious, what size is your company that you write 90% of the documentation?

Is your job title SWE?

[-]

Rain-And-Coffee@reddit

The company has hundreds of engineers.

I was referring to the docs for my direct team of ~20 devs

I’m Senior SWE, initially I wrote the docs for my own understanding, but they proved extremely helpful

[-]

isarockalso@reddit

What’s the difference with the op account and yours. You keep replying from another account?

[-]

WolfNo680@reddit

I think you're confused - the thread creator isn't the parent comment of this thread, u/Rain-and-Coffee is, and that's who everyone is responding to. The thread creator hasn't actually posted in this comment chain at all.

[-]

isarockalso@reddit

Ahhhh lol yes thank you!

[-]

Rain-And-Coffee@reddit

What other account? I’m confused

[-]

CalmLake999@reddit

Sad thing is Google writes some of the worst documentation...

[-]

calloutyourstupidity@reddit

Unfortunately for that class, chatgpt is here

[-]

Only-Friend-8483@reddit

Would the Google technical writing course be valuable and applicable for non-software related technical writing?

I run an R&D engineering team and end up doing most of the writing myself. I’d like to improve my engineers’ writing ability.

[-]

DeepHorse@reddit

Yes, I skimmed through both parts of the course and it would definitely be helpful for general technical writing. The diagrams are code related but they are mostly just placeholders to illustrate the concepts

[-]

pheonixblade9@reddit

I had to take two full years of technical writing classes for my degree and most of my classes had a significant writing component. But I studied compeng, so it was more traditional engineering.

[-]

cloaked_mode8@reddit

Would you mind providing a link to that class?

[-]

Rain-And-Coffee@reddit

https://developers.google.com/tech-writing/overview

[-]

rava-dosa@reddit

There is a deep-tech dev studio based out of India I worked with. (Origins AI)

They were pretty good with code and documentation. Had team members who were exceptionally fluent in English

[-]

coding_for_lyf@reddit (OP)

I’m sure there are exceptions that prove the rule

[-]

morbiiq@reddit

I’m much more worried about the fact that more and more people can’t even write decent code, let alone documentation.

[-]

WheresTheSoylent@reddit

Put me in, coach!

[-]

PureRepresentative9@reddit

Good writing skills and good programming skills are highly correlated I'm my experience.

I mean, it's called a programming LANGUAGE after all.

[-]

lift-and-yeet@reddit

I agree, which is why I find that most frequently the poor writing I have to deal with at work comes from other departments like sales and client services, not developers. The only consistently better writers I see are the technical writers.

[-]

MoreRopePlease@reddit

I wish we had actual technical writers at my company...

[-]

datacloudthings@reddit

Computers would be perfectly happy to communicate in binary. The only reason we have any higher-level programming languages is for humans' sake.

[-]

BipolarNeuron@reddit

Agree to that. I’m working at a company where they have over indexed so much on “writing” that engineers produce more meaningless documents than working software.

[-]

Putrid_Masterpiece76@reddit

God forbid having to explain how grafana metrics work.

[-]

seba_alonso@reddit

It's not about English per se, or even writing. It's about something more fundamental: Communication is hard, no matter the culture or language.

[-]

ezaquarii_com@reddit

It goes beyond tickets. A lack of language skills means that the code is undocumented and cannot be documented, as team members will revolt against writing documentation with excuses better than most seasoned politicians, hiding the fact that they are simply unable to do it. The code is also going to be a mess, full of nonsensical terminology.

[-]

chefhj@reddit

I have a dev on my team that is legit excellent in every other regard outside of the fact that we can barely communicate with him.

He comes up with brilliant solutions most of the time but god it is so much harder getting anything from him than every other middle of the road dev on our team.

[-]

BorderKeeper@reddit

This might be just me, but if "brilliant solutions" != "solutions which are bug free, and will easily remain bug free if other team members add functionality to it (or if nothing else are at least meeting product spec 200%)" I don't care

[-]

MaxMatti@reddit

The latter are not brillant, just convoluted.

[-]

BorderKeeper@reddit

Or very performant. I heard of "geniuses" from colleagues in last company which built some module that was pure maths and nobody ever touched it again. The praise I heard from others over lunch about this guy was one reason I was out of the company the next month.

[-]

Hammock2Wheels@reddit

Maybe he's hired someone else to do the actual coding or solutions.

[-]

chesserios@reddit

I think what's even more annoying day to day is people not being able to explain/discuss what's going on technically.

[-]

ezaquarii_com@reddit

Youp, but that's not necessarily linked to english as a 2nd, 3rd or nth language. Many devs hired during last decade hiring frenzy lack absolute basics and can't communicate outside their framework of choice.

[-]

ManfredKerber@reddit

This

[-]

pemungkah@reddit

I honestly think that my English minor in college made a huge difference in my overall success in my career. 90% of the time, you just need to have someone who can adequately explain stuff to whatever audience at the appropriate level. That could be proposals (got several bonuses for writing on winning proposals), documentation, bug reports (especially repro reports), presentations (an even rarer skill). The list goes on.

Which is why ChatGPT is so popular with so many people: they see it as a way to avoid the writing...when realistically it does about as well at concisely and accurately transmitting information as it does at writing code. It's sorta kinda maybe what you wanted if you squint, but it got done in 15 seconds.

[-]

Old_Bug_6773@reddit

Agreed. I have concerns in what happens when we consede our thinking to machines. Particularly considering how many people can no longer do basic navigation having long ago ceded their hippocampus to GPS.

[-]

cuntsalt@reddit

Going to make it USA centric because that is where I work and primarily who I work with (aside from a few Canadians). Literacy rates are pretty awful:

54% of Americans [read] below a sixth-grade level nationwide.
21% of U.S. adults ages 16 to 65 score at or below PIAAC literacy level 1, meaning they have difficulty "[completing] tasks that require comparing and contrasting information, paraphrasing, or making low-level inferences."

I frequently have difficulty getting people to read my communication in tickets, despite striving for short and sweet, self-editing for simplicity, and formatting things well with headers, bullets, and bolded text. It really seems like some people are incapable of digesting anything beyond Tiktok caption sized bites of text.

People struggle to read, so of course they struggle to write. They are connected skills. It's apparently a neglected core skill across the board.

[-]

No_Guarantee_185@reddit

one would hope that the situation would be better among highly-educated professionals, but I guess not

[-]

gopher_space@reddit

Reframe that as 'narrowly-educated' and it makes more sense. Most of the CS students I've mentored have been actively dismissive of other disciplines.

[-]

Old_Bug_6773@reddit

Narrowly educated or poorly educated, inarticulate is inarticulate. This failure in a person holding an advanced degree exposes a profound lack of curiosity and rigor.

If you can obtain a University education but still can't read at the sixth grade level, you really wasted an opportunity.

[-]

jalopagosisland@reddit

As I've gotten older the more I realized that just because someone has a degree or even multiple degrees doesn't mean they're educated. It just means they have passed curriculum. There are doctors, lawyers, engineers, etc who have skated through their education by doing the bare minimum to pass. They don't care about writing / communicating effectively.

[-]

drumstand@reddit

Not related to tech at all, but literacy in the US is a huge problem. I recently listened to https://features.apmreports.org/sold-a-story/ which is a fantastically well-researched podcast series diving into literacy education and its many issues. The initial episodes are from 2022 but there are multiple follow-up episodes with updates. This was very eye opening to me and I highly recommend it to anyone in the US.

[-]

cuntsalt@reddit

Thank you, much appreciated, it's on my to-listen list.

[-]

DaemonInside@reddit

The next revelation will be that the ability to summarize is almost as important. As you go up the ladder, the more you’d need to flex that “executive summary” muscle.

[-]

virtusdormitiva@reddit

I strongly agree and would add that writing good design docs is as important as writing clean code.

Unfortunately, with ai I fear that writing will soon be a lost art.

[-]

Jmc_da_boss@reddit

The industry does so much needful

[-]

nawap@reddit

Do you communicate with Indian government employees a lot? Because nobody who finished schooling in this millennium uses this construction in my experience.

Also quite tired of the casual stereotyping in these threads.

[-]

Appropriate-Dream388@reddit

It's funny because nobody mentioned "Indian". It's nonstandard English and is difficult to understand.

[-]

nawap@reddit

It's funny because it's making fun of Indians without spelling it out?

There is no such thing as a global standard of English. Perhaps you can point out comments making fun of other regional English variations? Wonder why it's only the Indian version that's made fun of and not the Aussie or Kiwi or other regional variations 🤔

[-]

Appropriate-Dream388@reddit

Needful is not in any recognized standard of English. It's just bad English.

If I speak another language and use bogus made-up words, do you think it would be productive to argue with native speakers that my foreign dialect is actually okay in my own tongue?

The funny part is how defensive you are of objectively bad English.

Needful is not anywhere close to an accepted regional dialectical difference in language whatsoever. "Perform the needful" is stupid, not "different"

[-]

nawap@reddit

I am sorry but I can't reason with you because your arguments relay that you don't have any understanding of linguistics. The Indian English wikipedia page is a good place to start for you.

If you are incapable or unwilling of that then at least google the word "needful". You'll realise that it's not any more "made up" than any other English word. In fact, it is an archaic term that has survived in India that your "native" speakers have forgotten about.

""Perform the needful" is stupid"" is both ignorant and stupid.

[-]

Appropriate-Dream388@reddit

I was a career linguist for 5 years before becoming a software engineer. The essence of communication is to understand your audience, and not to rely on your audience to "get you"; that is your job as the speaker or writer.

You blatantly admit it's an archaic term, so wouldn't it be better not to use archaic terms your audience doesn't understand? Good speakers/writers do NOT shift the burden of understanding to their audience, but instead tailor their message to the audience.

Do you think everyone should start saying "Perform the needful" since you think it's actually a good thing? Because it's essentially a meaningless phrase — a near-tautology. "Do what needs to be done" is the equivalent of commenting // This adds three to the number \n x += 3.

"The audience should simply adapt to my archaic use of their language" is a very bad take in communication.

[-]

nawap@reddit

If you have any training in linguistics then it's not coming across in your previous post.

You have moved the goalposts from "do the needful is not a valid English construction and is stupid" to "the writer should make content intelligible to the audience", so I think I must have convinced you that there is no scientific merit behind your initial arguments and that memeing on that phrase as "bad grammar" is ignorant at best.

I mostly agree with your new goalposts but that does not justify mocking one regional dialect over another. Archaic in the US/UK does not mean archaic everywhere. India has the second largest English speaking population in the world - they can make their own variations as required. I find it annoying that Americans can't pronounce the Rs in "mirror" too but that does not make their English invalid. In Québécois french the word for a beverage is "breuvage" but metropolitan french has moved to "boisson" instead - that does not make "breuvage" universally archaic because by definition it's still being used today.

Dialectical differences exist and we will never fully overcome that. British people call underwear "pants" and that will continue to be confusing to the rest of the English speaking world till that usage changes with age - as is happening with the aforementioned phrase in India as well. I am not sure anyone mocking Indian English is Indianising their writing when they are on the other side of the table.

It will help if people are not prescriptive with language because that helps nobody. The French do it with Quebec as well and it only reflects poorly on the French.

[-]

silsune@reddit

Yeah I was fully willing to listen to their perspective as a linguist until they implied that it is not difficult to understand Aussie English. I have never heard "do the needful" and confess I would have zero idea what it meant, but it would be miles easier to understand than most of what comes out of Australia.

[-]

Appropriate-Dream388@reddit

It gets worse than the needful.

[-]

Appropriate-Dream388@reddit

The reason you feel I am unreasonable is because you cannot comprehend that non-native English speakers speak bad English, on average, and using terminology archaic to an audience is a bad idea. This shouldn't be a controversial topic.

The main difference is that in discussions about software, topics including underwear, torches/flashlights, and common furniture items are not common topics. When it comes to discussing tasks (the needful, apparently), it's far easier to communicate with people who speak English fluently, not needfully.

The bottom line is that communications in English should adhere to standard English conventions. You can argue there is no "standard", but if you pick US, Canada, or Britain, the communication will not be difficult to understand. This is why nobody should "Indianise" their language. If I were working for an Indian company and had to speak and write Hindi, why the hell would I expect my colleagues to speak Americanized Hindi and expect them to interpret my archaic use of their language, and argue "No, it's actually you who is wrong!"

Also, while India is the second-largest English speaking population, this is maint an artifact of their population size as a whole, and according to this article, India is only the 60th best English speaking country int he world. It is far from "standard".

[-]

ItsOkILoveYouMYbb@reddit

Nearly our entire fucking offshored Hyderabad IT and Finance teams communicates like this

[-]

nawap@reddit

"like this" as in with perfectly valid English grammar using a localised turn of phrase that's become a literal meme? If you have trouble understanding them then it's not their fault at that point.

[-]

ItsOkILoveYouMYbb@reddit

You're delusional if you think they have flawless English and grammar and also regularly use "do the needful".

Management over there are the only people who are mostly easy to understand. Everyone I have to work with doesn't understand what they're being told, doesn't write clear English, doesn't understand requirements, and have to repeat themselves 2-3 times to our US based team unless they have management with them on the call to translate more clearly.

It's a massive waste of time and resources under the guise of cost cutting and "globalization" ie offshoring to suppress wages and further cut costs until the company eventually rots and dies from the inside.

They've already gone through 6 changes in C Suite, and the more they offshore the more North American market share they lose, which was by far their largest market. Now they're dying to competitors because of this obsession with only hiring more and more Indians.

But sure, talk out your ass all you want about how perfect everyone's English and communication skills are.

[-]

nawap@reddit

I'm talking specifically about the phrase "do the needful", when I'm talking about grammar, if you have forgotten the context of this thread.

And your management hired them, they didn't trojan horse their way into your company. They are not at fault for not being as proficient in their 3rd language as you are in your first. They shouldn't have hired them.

Sure there are loads of people in India in the software sector who are not as fluent in English as others - that's mainly because they didn't grow up learning English properly and because it's not a requirement for the industry in India. The same is true of developers from the slavic countries, especially Russia, and also from Brazil and China. I actually have colleagues who have a very have French Canadian accent in English but are brilliant otherwise. They are all trying to work in a language completely foreign to them and we make the extra effort to understand each other and work together just fine. Yet I only see jokes about the outsourced jobs in India.

I think this is because you have probably never met these offshore people and have very little empathy for them, and others are just regurgitating shit memes they see others make.

If you are tired of communication problems with them, there is a respectful way to bring it up instead of memeing on the stereotype which is frankly just casual racism at this point. I'm tired of the open season on Indians in this sub and elsewhere on the internet so I will call that shit out.

[-]

silsune@reddit

True lol, Indians are the Mexicans of the software world. It's somehow their fault for doing everything they can to make a living and you should hate them rather than your idiot boss who hired a team of people to do production level work in a language that they are learning on the fly in real time.

This somehow makes those indians "stupid" lol.

[-]

Jmc_da_boss@reddit

Idk what to tell you brother, i see it regularly

[-]

nawap@reddit

I'm sure you can handle valid English grammar brother.

[-]

gyroda@reddit

Also, "I will do the needful" might not be standard British/American English, but it's still pretty clear communication.

My biggest communication issues are rarely turns of phrase but a lack of communication.

[-]

nawap@reddit

Yes it's a grammatically valid turn of phrase in Indian English. If I started making fun of every time a "native" speaker said/wrote "could of" in a sentence at work, I wouldn't have time to do anything else.

[-]

ItsOkILoveYouMYbb@reddit

If I started making fun of every time a "native" speaker said/wrote "could of" in a sentence at work, I wouldn't have time to do anything else.

You would fit right in.

[-]

ccricers@reddit

My take- needful is a better way of saying necessary. Use of -ful to describe quality of, and fewer letters. It is efficient.

[-]

Jmc_da_boss@reddit

Ok, we will all provide the same

[-]

CalmTheMcFarm@reddit

... and revert to you after

[-]

Big__If_True@reddit

Kindly

[-]

CoffeeBaron@reddit

While a correct word in English, it's usage here is weird to native English speakers, because we'd use necessary over needful. Oddly 'useful' as a word is used more, but 'needful' while a word wouldn't be as clear to all English speakers. I would go with the clearest meaning over being concise over overall letter count.

[-]

teslas_love_pigeon@reddit

It's not a better way of communicating if your audience is the United States, no. People don't say or speak like that at all in the country.

[-]

new2bay@reddit

What are you getting at? If you have a point, just state it plainly.

[-]

mercival@reddit

Just casual racism, that's their point. The upvotes are interesting.

[-]

you-create-energy@reddit

How is it racist? Is that not actually a turn of phrase that Indian business people use?

[-]

mercival@reddit

Have you asked yourself, why an actual “turn of phrase that Indian business people use”, common enough that you and everyone know it, it used as a butt of a joke about miscommunication?

Sounds like everyone knows what they’re saying. So where’s the problem with communication here beyond dialect?

Unless it just “LOL casual racism” like I said. Which it is. It’s poor.

[-]

MoreRopePlease@reddit

common enough that you and everyone know it,

Even though I have worked with Indians for the last 10 years, I have never heard that phrase, and the word "needful" I've only ever seen in the Stephen King story called Needful Things. I thought it was an old fashioned word.

In the context here, even with the discussion in this thread, I still don't know what that sentence means. So it seems to me to be a good example.

[-]

you-create-energy@reddit

But miscommunication with offshore teams is a serious widespread problem in the industry. It's not about their race, it's about the role language plays in communication issues. Is it better to only make that point in a neutral sentence instead of with a dash of humor?

[-]

mercival@reddit

Is the humour casual racism?

[-]

cholantesh@reddit

Because it's entirely normalized on reddit and this sub is no different.

[-]

you-create-energy@reddit

I'm usually pretty dialed into these things but I'm not quite sure about this one... I could definitely see myself making a joke about better communication being "needful". I think tone and delivery would make a big difference between coming across as being light-hearted or contemptuous.

[-]

new2bay@reddit

Oh, I know that. I’m just making sure they know I know because I’ve already reported their comment.

[-]

mercival@reddit

Yeah all good, I was just calling it out too.

[-]

new2bay@reddit

I’ve got 281k karma. If you strike down, I shall become more powerful than you can possibly imagine. 😂

[-]

ings0c@reddit

Indian people often say “do the needful”. It’s considered proper business English in India, but it’s sounds like incorrect usage of the English language to a native speaker in most English speaking countries.

It’s so common that is has become a bit of a meme.

[-]

ether_reddit@reddit

idc ur wrong

^^/s

[-]

SheriffRoscoe@reddit

I mean, yeah, it's funny, but I've always assumed it's a Hindi or Urdu idiom. Kinda like "I could care less" meaning "I couldn't care less", etc.

[-]

Main-Drag-4975@reddit

At least 80% of programmers I have worked with don’t even try to shape their code into any sort of coherent story. I wouldn’t expect anything different from their emails or documentation.

As long as incoherent programs can still make money we’re going to have to live with this.

[-]

gyroda@reddit

At least 80% of programmers I have worked with don’t even try to shape their code into any sort of consistent narrative.

This is something I'm feeling more and more.

The code should be functional, but it's also a communication with the next developer who has to read it. You need to think about the intended audience and how they're going to perceive/understand the code.

Even something as simple as "please put the test cases/inputs for your tests next to the actual test method" is something I can't believe I have to tell people over and over. It'll all run the same, but if you just dump everything into a file willy-nilly it's a nightmare to read.

[-]

pheonixblade9@reddit

Oh man, the number of shared test objects for setup in some files I've seen... You change one thing, a bunch of tests break.

I've started forbidding shared test data except in very limited cases. Just set up the proto in the test itself.

[-]

gyroda@reddit

Also, shitty abstractions. Look, I'm all for convenience methods for setting up stubs and mocks, but for the love of god I mean things like StubGetUserListFromApi(User[] users) {} which does one well-labelled thing, not StubGoodRequest() which sets up a dozen things and there's no way to know what it's stubbing and with what values without diving into it.

[-]

dinosaursrarr@reddit

Tests should be DAMP not DRY

https://testing.googleblog.com/2019/12/testing-on-toilet-tests-too-dry-make.html

[-]

gyroda@reddit

I've been using the word "moist", much to my coworkers' chagrin

[-]

pheonixblade9@reddit

(maybe not such a) hot take - DRY does not apply for tests, generally. (Generic environment setup for integration tests etc. stuff aside)

[-]

ammuench@reddit

I've been pushing heavily with my teams to lean into using descriptive variables, even if not needed, to help readability.

Converting stuff like:

if (!isLoading && user.role !== "admin" && user.permissionsLevel === PERMISSIONS.WRITE)  {
// do the thing
}

into

const userIsAdmin = user.role === "admin";
const userCanWrite = user.permissionsLevel === PERMISSIONS.WRITE;

if (!isLoading && !userIsAdmin && userCanWrite) {
// do the thing
}

just makes it so much easier for folks who didn't write the code to instantly process what's going on.

I get not wanting to create extra variables in some mission-critical performance code, but when we're writing an enterprise react app, maintainability like this is far more important. Especially for code reviews, it lets reviewers understand what they're reading much more quickly

[-]

kndyone@reddit

Unless you think that making sure its well communicated is a bad idea because it makes you replaceable.

[-]

GirlFlowerPlougher@reddit

…yep.

I switched from readable to impenetrable code.

Another team screwed mine and management shrugged.

So I’m no longer the champion of best practices for the company.

I’m the champion of best paycheck for me, and I write my code with that in mind.

I hate it, but I learned my lesson and here we are.

[-]

Schmittfried@reddit

I don’t buy the job security narrative at all. Maybe a few graybeards or rockstars subconsciously undermine documentation to feel like a god in a small kingdom, but never ever is this a common motivation for average developers.

[-]

kndyone@reddit

you don't need to be that at all, all you need to do is be under someone who isnt actively reprimanding you or firing you if you don't do it right. Plenty of dead beat leads out there don't care how the job is getting done so long as their boss isn't mad at them.

Literally NO ONE is going to talk about this, its the sort of thing they do in part out of subconscious laziness and in part quietly, they will simply play dumb if confronted.

[-]

Wide-Pop6050@reddit

I was doing an open source project and you could really see this. It was something where someone else was definitely going to have to pick up your code and there was just so much variety in how readable peoples code was. Simple things like clear variable names and as you said test cases next to the method etc.

[-]

AFresh1984@reddit

Oh man. You should meet my dumbass boss from a few jobs ago.

It was all about making it elegant and concise above all else.

I could write something that worked fine, 90% efficiency, he'd spend a fucking week tweaking it to run at 91% efficiency just to critizise. fml glad I'm out

[-]

BanaTibor@reddit

I feel the same! If you can not put your thoughts into writing how do you put them in code? I believe that many bad code is a result of poorly organized and communicated thoughts of the programmer.

[-]

daguito81@reddit

I think now it’s going to take a hard turn to be even worse.

With layoffs every now and then a common practice and people feeling that job insecurity. I think people will start migrating towards making code more obfuscated and harder to read and less expressive as a means to increase their job security.

[-]

Gwolf4@reddit

That does not add anything, it just put you more into misery and the one replaces you.

[-]

Schmittfried@reddit

It doesn’t add job security at all and I doubt many people actually think it would (or would seriously consider doing this).

[-]

daguito81@reddit

I do know some people that have considered "non organic" ways to create more roots with stuff like this to increase their odds of surviving a layoff.

I mean, most of us know at least one or a few instances of "Oh, we can't get rid of X, because he's the only one that knows about A, B and C"

Is it a good thing? fuck no. But desperate people do desperate things.

[-]

XAWEvX@reddit

Do you have any examples of what would constitute coding with a consistent narrative?

[-]

Main-Drag-4975@reddit

Ever work with a really good library where a handful of core concepts are used throughout the system in a way that makes your work feel easier?

One where you find yourself correctly guessing how this piece will fit with that piece?

One where you think “I need a method to do _ to this type of data, if they have one I’ll bet its named __ since a similar method in this other module was named ____”?

Think of the work of a game designer or an office building’s architect. Things need to fit together in a clear, consistent way in order for the people living with them to be able to get comfortable working without having to stop and learn a unique, unconventional layout for each little piece of the system.

[-]

butchqueennerd@reddit

This is why I'm glad to have a history degree. Early in my career, it dawned on me that the first functional version of a deliverable (be it a utility script that's "just for now, until we can write a much better version" or adding a feature to a product) is just a first draft. It also helped me not take critical CR comments personally (meaning a judgment on my value, not an attack on me).

It's possible to take that mindset too far, which is where communication about expectations is vital. But I find the refinement process (including proper documentation) is a lot less frustrating when it's treated like any other writing process.

[-]

farazon@reddit

Good communication has a multiplicative effect across the company.

I work for an enterprise SaaS. We had a principal who was a master of clear communication. If he were put on a gnarly bug, he would not only resolve it, but lucidly describe why it occurred, what are the preconditions, steps to resolution, temporary mitigations, etc.

This wasn't limited to spoken word: he'd stitch written explanations together with succinct log snippets, telemetry screenshots, triage scripts, and so forth.

I call the impact 'multiplicative' is because it:

Brought clarity to the whole engineering org.
Empowered support and SEs directly dealing with the customer to explain the RCA and path forward more clearly and authoritatively.
Helped managers/directors talk about the impact and remediation to the executives up top.

[-]

bwainfweeze@reddit

If you can’t describe a problem you can’t really fix the problem. And if you can only describe it poorly, odds are great your solution will only be slightly better than that.

The crux of an issue can be a two line change in one place versus a lot of code in another, or a proliferation of hacks scattered in multiple places.

I scored high on verbal and it’s surprising how often I have to describe a problem in detail to people who should be closer to it, on behalf of people farther away. And some of my favorite coworkers have been people who can paint a more vivid picture of the bullshit than I can.

[-]

farazon@reddit

Agreed. I always felt that intuitively, but I didn't realise what a broad impact this skill could have beyond just yourself and your immediate team.

I was always fairly competent at written communication (would've happily majored in History if it paid), but it was inspirational to me to see that time invested into all the non-prose trappings isn't wasted either: I now go a lot further making sure that Grafana screenshot or that log snippet that I post is clear and succinct. And I'll write and post a script or a SQL query if it's reasonably within reach, too. The extra effort pays off, and of course, gets easier with practice too.

[-]

goodmammajamma@reddit

i had to leave a team because one of the other senior devs could not communicate anything in writing and basically refused to participate in any sort of requirements gathering or planning of any sort

[-]

silsune@reddit

Why didn't THEY have to leave the team?

[-]

goodmammajamma@reddit

I didn't have the energy to fight about it, leaving was easier

[-]

iamnogoodatthis@reddit

It feels like everybody higher up thinks they are too important to put any time into reading more than the first sentence of any given document or writing anything down clearly, and that nobody lower down has yet realised that it's important. Sigh.

[-]

gumol@reddit

English writing skills or just writing skills?

I've met native speakers who still can't write "clearly and succinctly".

[-]

detroitttiorted@reddit

I don’t understand how someone being a native speaker changes the meaning of “English writing skills”

[-]

BanaTibor@reddit

Many of us have learned english as a foreign language. I am hungarian but I speak english pretty well too, but I am not on the level of a native speaker. Even after 12 years in the industry it is still much easier for me to communicate my thoughts in hungarian than in english.

[-]

detroitttiorted@reddit

That makes sense but it doesn’t really relate to my last comment. “English writing skills” means an ability to write in English, whether it’s someone’s 1st or 10th language

[-]

gumol@reddit

That ain't me.

[-]

barravian@reddit

Writing skills in the English language.

I don't think it much matters that much if they are a native speaker, I've seen good and bad from both native and non-native speakers.

[-]

germansnowman@reddit

Writing skills are basically thinking skills.

[-]

darkapplepolisher@reddit

Yeah, too many people write paragraphs where outlines would be more appropriate.

Most technical communication can be conveyed through outlines.

[-]

PureRepresentative9@reddit

I would just like to get past the R/boneappletea problems tbh

[-]

Mister2112@reddit

I think this is true. I'm also finding an increasing tension between properly memorializing changes, requirements, and research, versus engineers who are really struggling with communicating in paragraphs.

Things take 3x longer because there's a tendency not to read for relevant detail, but if you're reducing it to bullet points for them then you're going back and forth answering the questions they would have had answers in-hand for if they had it long-form in the first place.

This isn't a CS thing, specifically. The phrase "functionally illiterate" is getting thrown around a lot in academia post-COVID as a surprising percentage of students are apparently just not familiar with written communication.

[-]

JustthenewsonCS@reddit

The problem reddit doesn't want to say or admit to is this is the cost of a large majority of the workforce being on VISA or offshored.

Shocking, if you hire people not born in a country that natively speaks English, the documentation and communication barriers might happen.

Also, some of it is cultural differences as well. What is expected to be communicated in one culture could be seen as unnecessary in another culture. This is the cost of all of this.

No, it isn't xenophobic or racist to say that either reddit. If anyone said this if it was happening in the opposite direction, you all would not have a problem with that.

[-]

charging_chinchilla@reddit

Communication and collaboration are just as important as technical skills. Building software is a team effort (unless it's a trivial project).

A lot of inexperienced SWEs expect the job to be a solo endeavor (e.g. "tell me the requirements and leave me alone"). That's a very naive and unrealistic view of the job. You will only advance so far if you focus on coding faster. Once you get to senior roles it's about scaling yourself and improving the velocity of the team, which requires communication more than technical chops.

[-]

Trineki@reddit

You can save countless hours by understanding the problem and the why than just mindlessly coding a list of requirements.

That being said. Having a list of requirements is also very nice and it kills me slowly inside when I receive tickets that have vague asks like make xyz button that does insert vague requirements using acronyms that can sometimes have multiple meanings

[-]

BanaTibor@reddit

Both are necessary for success!

[-]

savage_slurpie@reddit

Im so sick of dealing with ga who barely grasps the English language - we waste so much time just trying to figure out what they are trying to say I doubt we are saving any money than just having on shore qa who can actually speak the language.

[-]

rosenjcb@reddit

It's a very strong short term stock bump strategy but it results in information silos, tech debt, and market share erosion.

[-]

savage_slurpie@reddit

And extra burnout from your expensive on shore development resources.

Eventually I will be outsourced so that all of our teams have the same primary language

[-]

savage_slurpie@reddit

And extra burnout from your expensive on shore development resources.

Eventually I will be outsourced so that all of our teams have the same primary language

[-]

yep808@reddit

What's GA stood for?

[-]

savage_slurpie@reddit

Autocorrect from QA

[-]

Stoomba@reddit

I agree. We also ignore it when writing code too. We pay attention to technical aspects of it, but not to actually writing it so it reads more like instructions for a human than instructions for a computer.

[-]

ghostwail@reddit

What's surmised 😉

[-]

Born-Jello-6689@reddit

Surmise -

“suppose that something is true without having evidence to confirm it.”

[-]

ghostwail@reddit

Sure. My point is that every coder absolutely should write their comments and commit messages in correct english, but also keep it simple and use common words.

[-]

unpaid_official@reddit

it all gets back to the problem with tech interviews - everyones hiring people that are skilled at whiteboard coding, but whiteboard coding is literally never done in the day-to-day.

[-]

Habanero_Eyeball@reddit

At a company I worked for, ticket creation and ticket closings were the ONLY stats that were tracked and rewarded.

If they tracked a "ticket clarification" stat of some sort and dinged people for having to have their tickets clarified due to poor creation, it would likely end a lot of that crap....but then again, maybe not.

[-]

HalveMaen81@reddit

I interviewed for a job some months ago, and part of the "technical task" was a partially complete Jira ticket, which I was asked to refine. They wanted to see how I would deal with incomplete requirements, whether I could spot where dependencies might exist, would I know what good Acceptance Criteria looked like. Quite an interesting thing to include in the interview process, I thought.

[-]

crimsonpowder@reddit

Yes and this is why I have to spend all my days on stupid zoom meetings. People can't communicate to save their lives so a 30 second email turns into a 45 minute live call.

[-]

Fair-Anywhere4188@reddit

Yes. Was an English major. 30+ years in software and it is my secret weapon.

[-]

rosenjcb@reddit

That's because they're outsourcing tech from offshore and English comprehension is the hardest skill to master relatively speaking. It can take several years or decades to master a language. It takes months to get the "hang of programming" by comparison.

[-]

bwainfweeze@reddit

Articulation is an important part of both brainstorming and scope negotiation.

One of the reasons we lose to marketing on scope creep is that they can talk faster and prettier than the average dev and we or our bosses get dazzled by bullshit.

[-]

rosenjcb@reddit

I consider communication more important than technical skill because you can teach someone who can communicate well, but it's almost impossible to coach someone who you cannot talk with.

[-]

bwainfweeze@reddit

When in doubt about interviews, we hire the articulate one because they’ll tell us when they have a terrible idea instead of just implementing it.

[-]

Unlucky-Ice6810@reddit

I think people are bad at writing tickets/asking for help because they fundamentally don't understand what the problem at hand is.

I use it as a sanity check. If I can't explain the problem in a way that an 5 year old can understand, then I don't understand the problem well enough to articulate it to other engineers.

[-]

unrebigulator@reddit

Dude, shut up!

This is my secret weapon, and you're telling everyone about it?

[-]

coding_for_lyf@reddit (OP)

What do you mean?

[-]

unrebigulator@reddit

I can write well, and this is one of the things that differentiates me between other team members.

It's also what insulates me from being replaced by offshore teams, and/or AI.

[-]

CHR1SZ7@reddit

tbh writing well will not save you from AI, ‘cause one of the few things AI can do is actually write well

[-]

germansnowman@reddit

It is good at simulating good writing, but there is no actual understanding involved. It works in many cases, but you still have to verify the output. This is where we will still need good human writers. It may increase productivity, but it won’t work autonomously.

[-]

hippydipster@reddit

Words are words, and they never have actual understanding. The understanding (or not), happens within minds only.

So, if a "not actually understanding" process produces the words, and those words produce understanding in your mind, then there is no difference between "simulating" good writing and "being" good writing.

And so far I find that the process happening inside LLMs does produce words that function as needed, usually with greater reliability than words produced by humans.

[-]

kri5@reddit

so much this. People see a lot of output from an AI prompt and just think "oh wow, this is so good". Detail matters, and the details are often wrong (for now)...

[-]

bluesquare2543@reddit

keep telling yourself that. Sucks to say but that will not keep you safe because we are literally talking about how it is not valued.

[-]

CallNResponse@reddit

What part of “null pointer exception” do you not understand?

(I’m joking. I’ve been surprised more than once when I’ve read something written by a person that - up until then - I’d thought was extremely competent).

[-]

chipper33@reddit

It’s the short sightedness of everything. It starts at the shareholders and bleeds into day to day work. There’s no motivation to do things “the right way” or even a well thought out and communicative way when you’re under pressure to deliver something yesterday with no planning and super vague requirements…

“We have to use AI, just make sure we have AI in our products, our stakeholders keep asking about it.”

Enshitification comes for us all.

[-]

InfiniteMonorail@reddit

Everything you guys complain about is taught in universities.

[-]

hallcyon11@reddit

Just use gpt, this isn’t a problem anymore

[-]

upperdine@reddit

Being a good communicator will put you ahead of 80% of developers.

This is purely anecdotal but I find that career switchers from non-stem backgrounds progress in their careers so much faster than your average CS graduate.

[-]

StTheo@reddit

Lack of documentation for legacy code is where I'm most likey lean heavily into LLMs (when allowed):

"Please explain what the in the ever loving fuck this block of code is trying to do."

[-]

FetaMight@reddit

Yay. Another post where a newby declares they have seen the entire industry.

[-]

adept2051@reddit

Or just communication skills in general, Not just English. But actual communication and the value of it. How to ask questions, how to write specifics, docs, tickets, requests for comment, request for action etc

[-]

bsenftner@reddit

Oh, you're just starting to realize the gargantuan cluster fuck that is all science and technology: those we ask to create everything new are never given the education to explain themselves, not really. The lack of pretty much everyone in tech to effectively communicate is so bad, I'm surprised we've not created a black hole accidentally and destroyed the entire planet.

[-]

mrfredngo@reddit

Paul Graham has for years, maybe decades, written and talked about how important it is for technical folks to be able to write well.

[-]

bmy1978@reddit

I’ve always thought there should be more English / Literature / Journalism majors in SWE roles.

[-]

coding_for_lyf@reddit (OP)

🙋🏾‍♂️

[-]

mailed@reddit

Yes. I am convinced my level of success is completely linked to being able to put a sentence together, not any technical ability.

[-]

_predator_@reddit

It's so bad that even the bare minimum isn't followed. I recently found multiple typos across multiple tables IN A PRODUCTION DATABASE.

Like you can tell a senior dev or so described how a thing should be implemented, and that person had a funny dialect or something, and the devs implementing it just wrote it down without any understanding what things mean. I literally saw URL being spelled "yural" in a schema.

And then it went through PR, dev, uat, and prod approvals without anyone being bothered to flag typos. Drives me nuts.

[-]

franz_see@reddit

*(insert Awkward Look Monkey Puppet meme)[https://wompampsupport.azureedge.net/fetchimage?siteId=7575&v=2&jpgQuality=100&width=700&url=https%3A%2F%2Fi.kym-cdn.com%2Fentries%2Ficons%2Ffacebook%2F000%2F030%2F710%2Fdd0.jpg]*

HTTP Referer header

[-]

Regular_Zombie@reddit

Misspelling in database schemas doesn't bother me so much; partly I suppose because you so often find them. Lots of databases are quite old and we're often maintained by a single admin. It's not so easy to update the schema once it's in place if you can't be certain you know who all the clients are, not to mention disaster recovery from older backups. I just make sure we firewall those mistakes in the application code so users never know what's in the persistence sausage.

[-]

CherimoyaChump@reddit

Misspellings in code are a big pet peeve of mine, even when they seem innocuous. I've seen too many situations where an instance of "Recomendations" is spelled correctly as "recommendations" or vice versa. And further down the line it becomes tricky to tell which spelling you should be using, because you see both variations. Yes, the IDE can help, but why even add that extra layer? And sure it can be fixed later, but in some fragile codebases/workplaces, it can be hard to justify the risk of breaking something. Typos in DB schemas are my nightmare.

We have spellcheckers. That should really be fixed at the first PR, and I'd say it's a bad sign if it even makes it to PR.

[-]

cuntsalt@reddit

In the worst cases, the typos and misspellings can become codified and stick around for decades. I sincerely wonder how many hours have been burnt on that, I know I've contributed.

[-]

HowTheStoryEnds@reddit

let Yuralfiret = false;

I feel your pain. I live in a multilingual country, have to work in codebases with not even language consistency in it (usually mix of dutch, french and English) with ditto documentation when it exists and similar 'requirements'. Hell my business people can't even agree on the name of the domain models across the languages and some translation are very interchangeable.. add some non-native, bad to moderately speaking English devs in the mix and it makes for a great time.

[-]

Stubbby@reddit

I would write better ticket descriptions if I had hope that one day an archeologist will dig out a server rack from our era and marvel at my tickets. But given it is very unlikely, I dont think anybody will ever read them.

[-]

unrebigulator@reddit

Writing well is its own reward.

[-]

Stubbby@reddit

Working code > Well written ticket

[-]

Sunstorm84@reddit

Documented code > Working code

[-]

Stubbby@reddit

I know agile today has a bad rep BUT I agree with the principles when distilled to the main 4 points:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

[-]

MoreRopePlease@reddit

comprehensive documentation

"Comprehensive" is the key word there.

Any documentation at all is good.

[-]

Sunstorm84@reddit

Exactly this.

A few in-line comments and ideally some short descriptions on some of the more complex methods would be a HUGE improvement in many cases.

[-]

MoreRopePlease@reddit

As an ordinary dev, it's not uncommon for me to go digging into our ticket history to answer questions about things in the code. Usually a variant of "wtf did we implement it like this?"

[-]

danielt1263@reddit

The sort of organizational skills and analytic ability needed for programming come entirely from the Humanities. Logic, for example, was taught by the philosophy department when I was in school. the process used to design and write a computer program is almost identical to the process used to compose and write a book. The process of programming has no connection at all to the process used for solving mathematical equations.

-- Allen I Holub, "Enough Rope to Shoot Yourself in the Foot"

[-]

No_Guarantee_185@reddit

The process of programming has no connection at all to the process used for solving mathematical equations.

tbh this sounds like the opinion of someone who has no experience with mathematics beyond a basic level

[-]

danielt1263@reddit

To be sure, he's not talking about the more niche aspects of programming (cryptography, algorithm design, AI development, and the like).

But I expect even there, the process of programming (researching prior art, outlining, writing multiple drafts with peer review, applying final edits, and the like) is identical to what is taught in the Humanities and not at all what is taught in Mathematics.

[-]

dudebomb@reddit

While I like the idea of somehow testing for writing skills during interviews, I don't know how you'd do it in this age of ChatGPT. I totally agree that not being able to write effectively will eventually become a career-limiting problem.

[-]

germansnowman@reddit

Check if they used ChatGPT to outsource their thinking (which doesn’t work anyway) or as a productivity tool.

[-]

Appropriate-Dream388@reddit

You can't check that.

[-]

germansnowman@reddit

Simple: Ask them to explain what they’ve written.

[-]

Appropriate-Dream388@reddit

Not so foolproof. Good writers can be forgetful and bad writers can bullshit.

[-]

germansnowman@reddit

Fair enough. But it would be a start.

[-]

datacloudthings@reddit

This is absolutely the case. I wonder whether it is getting better at all with GPTs -- I assume BAs and POs are using LLMs to write their tickets (or they should be)

[-]

Main-Drag-4975@reddit

Why would you use an LLM to write a ticket?

[-]

datacloudthings@reddit

If your English wasn't great or your writing wasn't great, I would think LLMs could take some bullet points and turn them into a well-crafted ticket pretty well. They are great translators.

[-]

SheriffRoscoe@reddit

It's one of the things Amazon does really well. Writing is an acknowledged key skill there.

[-]

blondbrew@reddit

Nowhere have I seen it as bad as at Amazon. Lots of people who speak very little English and basically don't communicate. Everywhere else I worked, people made a much larger effort.

[-]

b1e@reddit

The number of ex amazonians we’ve interviewed with barely intelligible English says otherwise

[-]

winterblasty@reddit

That's why they are ex amazonians.

[-]

IndependentProject26@reddit

Every Amazonian is an ex-Amazonian in waiting.

[-]

b1e@reddit

I should add current amazonians too.

[-]

winterblasty@reddit

That's why they are soon to be ex amazonians.

[-]

SheriffRoscoe@reddit

That’s why they are soon to be ex amazonians.

Yes. Amazon, or at least AWS, is a "move up or move out" culture. If you can’t get promoted to a "terminal level" in the "right" number of years, you'll soon be an ex-. As an SWE, to get there, you have to be able to write documents that are acceptable and impactful to at least your L7, and probably to your L8.

[-]

I-AM-NOT-THAT-DUCK@reddit

Every current amazonian is a soon-to-be ex amazonian

[-]

ings0c@reddit

Can’t blame ‘em, not much English is spoken in that part of the world

[-]

space-to-bakersfield@reddit

Is this a river joke?

[-]

grain_delay@reddit

Just say you hate immigrants jeez. I know plenty of devs who may not have a perfect conversational English but can compose solid documentation and written communication. LLMs have been a big help for these people too

[-]

reddit_man_6969@reddit

I empathize, it’s not totally fair, but at the same time it’s true that language and writing skills are important for successful collaboration on complex tasks.

I’ve actually found most companies I’ve been at end up (maybe even unintentionally?) having homogenous teams even in a very diverse org. Like one team will be mostly Indian, another team mostly Spanish-speakers, a team of Ukrainians.

I oscillate between trying to encourage cross-cultural communication and being pragmatic/“facing facts”.

[-]

b1e@reddit

I’m an immigrant too :)

This has nothing to do with your place of birth. Plenty of Americans can’t communicate effectively either.

It’s about how to structure your thoughts and articulate them in a way that others understand them.

[-]

csanon212@reddit

That's really on the product side where it's valued. They have so much churn on the software engineering side that they can't be picky on the soft skills of developers who can pass Leetcode mediums.

[-]

SheriffRoscoe@reddit

The churn slows at the higher levels, and that's where writing becomes critical to career success. But yeah, at the Leetcoder level, you either prove your value quickly or you're gone.

[-]

Swoo413@reddit

Kind of ironic considering the constant posts about how poor aws’ documentation is in various tech boards

[-]

appogiatura@reddit

I mean that’s why it’s called AWS, Amazon Writing Services /s

[-]

DontKillTheMedic@reddit

Bro you are kidding me 😆

[-]

wenxuan27@reddit

I'd say not really. maybe that used to be a thing, but rn writing is just for the sake of promos.

[-]

softgripper@reddit

They did start as a book store after all.

[-]

Berbasecks@reddit

As someone whose 80% of the workload is reviewing the documentation written by developers, I cannot but agree.

[-]

Inside_Team9399@reddit

You are 100% correct.

We used to give writing tests to all of our technical hires. It was essentially just the candidate in an email conversation with another person that would pretend to be a coworker/customer/etc.

Occasionally, we'd have people write up documentation for some fictitious feature or whatever, but generally found that live email was enough to assess someone's writing ability.

The issue is that that ability to write well in an interview doesn't directly translate to a willingness to do so as an employee.

In reality it requires the same kind of performance management that writing good code does, but it's actually much harder to manage because there aren't always clear boundaries between a good email and a bad one. And, without better hiring practices, you're often left with people that are just incapable of communicating well.

Nonetheless, I still think testing for it is a good idea and I'd continue to do so today.

[-]

thekwoka@reddit

I spend quite a bit of time helping fledgling devs (and learned ones continuously learning) and how often people ask questions that give you almost no way to even help if you wanted to is staggering.

Like "this doesn't work" and show like just some small code.

No explanation of what doesn't work about it, or how they know it doesn't work ,or what the hell they are even trying to do...

[-]

No_Lingonberry1201@reddit

One time I broke down crying because I've seen a well-written ticket that used whole sentences and structured the ticket to be easily understood and contained all information. It was written by a former elementary school teacher who switched over to software development.

[-]

r0ck0@reddit

I think this is just humans in general. Not specific to IT/programming people.

I think we're above average actually.

Still infuriating how we see in our industry though, because we should all know better, given how much we're the receiving end of it from others.

But try dealing with some people in other industries for comparison. It actually gets pretty scary when you see some of the terrible communication in fields like medical and construction, where people actually die over this shit.

But yeah, agree with you overall. I rant about this topic pretty much daily, haha.

[-]

infiniterefactor@reddit

Oh I am so loaded on this.

Tech companies are terrible at communication. I don’t claim I am the best communicator around. I also don’t have a huge sample space to draw data from. But I’ve seen so much shit lately, sometimes I can’t believe what I see.

The way I see the state of communication at tech:

Tech companies are very proud with their capabilities to run everything via tech. Every little piece of thing you run with tech sends you emails to communicate with you. And suddenly mailboxes of all your employees are filled with thousands of emails per day, most of them are generated by applications, not from people.
Most tech workers do not bother to organize this huge influx of email. What happens is you start ignoring your email. And more importantly you know everybody ignores their emails.
All conversation shifts to chat. This eventually becomes the default way of communication. But people refuse to load chat communication. A lot of people do not read long chat messages and do not bother writing long chat messages. So when something needs to be talked in depth, there is one solution : “let’s jump onto a online meeting”
Welcome to modern communication! Everything is either fast food chat conversations or fine dining meetings. There is nothing in between. This affects every written stuff. Tickets, documents, meeting notes… Everything disappears unless there is a strong culture of certain types of documents in the company.
Tickets… The way tickets suffer in this trend is incredible. Suddenly even QA personel feel like they are too good to write a couple of sentences into tickets. I’ve seen tickets including only an exception where stack trace has no company code and not explaining in which context this exception was observed. I’ve seen tickets with a full email thread copy pasted into ticket body, with the latest message in the thread saying “Can you put this into a ticket?” (They did! Hurray!) I’ve seen tickets only having a photo taken with a shaking phone, without going into any details.
And people who communicate most poorly are the ones most adamant on this trend being the right thing. Everybody seems to just forget the most basic thing about the communication, that you need to make yourself understandable. In this style of communication, you are constantly forced into chat conversations and meetings. Still real exchange of information is so inefficient.
Company leadership is usually ok with this, because they spend their life in meetings and team leadership is usually ok with this, because they also spend their time at meetings, and they routinely ignore whole chat.
At the end, if this is bothering you for any reason, either you want clear communication in your routine, or if the way you are wired makes communicating like this very challenging, good luck with that. Everyday becomes a challenge and this affects all aspects of your job.

[-]

whateven1tw@reddit

100%. Single biggest issue: people use passive voice for everything. Avoids responsibility. Makes text a pain to read.

No clue how people learn this. But many seem to think that passive voice = professional, smart.

Just say who did what. Simple words.

[-]

thewritingwallah@reddit

After code, learning to write as an engineer is one of the best life decisions I’ve made in my career.

• Writing is an undervalued skill for engineers, especially as they grow in their careers

• While code skills is essential, but writing becomes imp as organizations scale and teams become distributed

• Writing becomes particularly important for:

- Creating documentation (guidelines, best practices, runbooks)

- Writing proposals, RCAs and postmortems

- To do effective code reviews

- Influencing people beyond immediate team

• Good writing helps:

- Grab readers' attention effectively across teams.

- Minimize misunderstandings

- Progress toward senior engineering roles (lead, principal, staff)

• Investment in writing skills can significantly boost an engineer's ability to influence and communicate effectively across organizations. These days, I code, write, and earn money as an independent consultant.

[-]

code-gazer@reddit

That seems off to me. I've only ever worked in one company where people with bad English made it into the tech interview stage (and a few got hired prior to me joining). Turned out that in this company the HR themselves spoke sub-par English, even though it was the working language.

Personally, as an interviewer, I'd never pass someone who has trouble communicating on deep technical topics in English for a role in a company where English is the working langauge, and I work exclusively in those.

[-]

Schmittfried@reddit

So, given a candidate is 10/10 with regards to technical skills and overall communication and soft skills, but they are a 3/10 in writing. Would you reject them? If no, that’s your answer why we‘re not focusing on it.

[-]

deathhead_68@reddit

Tbh there are a vast amount of shit developers around generally.

[-]

HurricaneRicky@reddit

Writing prof who's got a background in tech writing: can yall please forward this message to university deans and chancellors so they'll stop gutting our fucking departments?

[-]

leaf-bunny@reddit

My imposter syndrome is from writing and formatting my information so others can consume it.

[-]

maln0ir@reddit

Some people just prefer to be left alone and cultivate their oral traditions.

[-]

TiredLead@reddit

It's not just English writing skills. It's general cognitive skills that are lacking in many developers, managers, and people of every other role. They can't seem to reliably integrate and organize ideas in coherent and rational ways.

This means that synthesizing complex technical ideas (with all the rules and norms that entails) into correct and clear English (with a different set of rules and norms) is far beyond them. They struggle even at reading technical content, let alone writing it. How many times have you gotten a question or comment on a document that's already answered in the document? How many times have people proposed ideas that, far from being bad ideas, aren't even sensical ideas?

These people are a drag on the productivity of everyone around them. Everything they produce looks okay from the outside -- if they weren't good at that much they wouldn't have gotten the job -- but the moment you dig in the tiniest bit you start to realize the core is rotten.

[-]

ummaycoc@reddit

We need to work on "writing well" / "communicating well" not only in tickets but everywhere. It's part of coding, too.

[-]

ShenmeNamaeSollich@reddit

As a relatively new hire to a team/org full of people & apps that have been around for a decade of more, I’ve often run into tickets that just assume you must know wtf systems and people they’re referring to & where to find or put relevant code, and then they’re wrong.

“Vivian reported a bug in the Turbo Encabulator’s Flarmble job, requested fix” with a screenshot of a single log entry instead of a link …

Then after 3hrs of digging you discover the thing they were talking about was nowhere near the damn Flarmble job but was instead 3 connected projects/microservices away and caused by a single bad call one time to a 3rd party library 6mo ago and just nobody ever closed the damn ticket. And who the fuck is Vivian??

[-]

Echleon@reddit

This is the result of so many students not taking “gen eds” like English seriously.

[-]

ToeAggressive1034@reddit

I’ve always put a lot of effort into documentation. I’m sure the offshore team who took my job really appreciated it

[-]

colindean@reddit

"Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer." - Edsger Dijkstra

I am confident that I can teach how to program just about anyone with a decent memory and the ability to think forward. I don't want to teach them how to communicate clearly a set of steps to be taken or that have been taken, how to list the pros and cons, or how to clearly delineate the consequences of actions. I can forgive grammar, spelling, and punctuation mistakes as long as those mistakes do not alter the intended message and the writer is willing to accept constructive feedback just as I would when improving my skills in a (non-native) language.

[-]

Ok-Swan1152@reddit

I'm a PM not a dev but some of you (ok, a lot) are garbage communicators. And it's even worse with people who have English as 2nd or 3rd language. I'm tired of devs not even explaining why something is or isn't possible or rudely telling other teams that "it's not my business".

[-]

Ill-Simple1706@reddit

Once we get our ci/cd running, I'm adding spell check to our linter. Usually my ESL colleagues don't bother fixing spelling mistakes.

[-]

mercival@reddit

Not quite sure what this post is supposed to contribute, beyond a rant.

[-]

IndependentProject26@reddit

This thread is getting lots of upvotes because it’s an extremely common problem but people seldom talk about it.

[-]

tsznx@reddit

How the fuck can a sub be ruined by a discussion that, as you can tell, is relevant to a lot of people here and that has raised valid points about English and how the lack of it has caused issues in our daily jobs?

Some people are interested, if you're not, don't open it.

[-]

mercival@reddit

Because it's not a discussion. OP isn't asking any questions. They're just ranting. Read the OP's post, and the 'discussion'. It's 99% just rants and responses.

Nothing constructive, interesting, or 'experienced dev' about this. It's poor.

[-]

armrha@reddit

Well, everybody in programming has spent decades mocking and uniformly deriding anyone that has studied language, literature, humanities, generally espousing all soft skills as completely pointless and actually laughable and bad decisions to have made to study, so it's not too big a surprise that nobody can convey a thought with any precision

[-]

IndependentProject26@reddit

Everybody in programming? Extreme condolences if this is d who you have been surrounded by.

[-]

tikhonjelvis@reddit

I wouldn't conflate writing skills with English skills.

I've worked with folks who learned English late in life and had clearly limited English skills... but were sufficiently clear thinkers and writers that I wouldn't even notice the awkward syntax or grammatical errors.

On the other hand, I've worked with people who had no trouble with language and wrote perfectly reasonable prose, but seemed to almost intentionally obfuscate and overcomplicate everything they were saying. I'm pretty sure it wasn't intentional, but, if anything, that made it worse because I felt like I should put at least some effort into understanding them.

[-]

Sunstorm84@reddit

Autistic native English speaker here. As hard as I try to write clearly, I end up with either something being misunderstood, or called pedantic for making sure I’ve covered everything so it can’t be misunderstood.

I just wanted to comment to say thanks for putting the effort in to try and understand.

[-]

gomihako_@reddit

Not really your fault, communication is a skill. At higher levels (like in management) all communication starts with deep, empathetic listening. First, you have to understand your audience. Then, tailoring your message such that the intended audience can basically interpret your will (not just want you want to convey) is another skill.

[-]

Aggressive_Ad_5454@reddit

Yeah, I get called pedantic too. I guess it's because explaining stuff that should be obvious can irritate people for whom it IS obvious.

I deal with that by writing things like, "as I'm sure you know, floating-point arithmetic can be inexact" or whatever. Then, the readers who do know it don't get annoyed, and the readers who DON'T know it get annoyed with themselves, not the author. And they hopefully make sure they learn it.

[-]

zhadn@reddit

This is my career 👋

[-]

theavatare@reddit

Learning to code barely requires communication. Yet being on a team does.

People should be trained on the job on communication and given time to learn it and practice.

I honestly have gotten so much communication feedback over my career that im pretty sure i stopped listening for a bit.

[-]

bwainfweeze@reddit

I still say we need classes in comparative coding. Make people describe other people’s code, and why it’s fucking awesome or fucking awful. At best we have short answer on exams, which is not a lot of feedback cycles between high school and graduation.

[-]

theavatare@reddit

I would love that. Just not on my spare time.

[-]

coding_for_lyf@reddit (OP)

People should come in knowing how to write clearly and succinctly. That isn’t too much to ask

[-]

theavatare@reddit

You either make a professional license required for the profession that enforces those requirements.

Or it falls to hiring like we currently do and you can see how it’s going.

[-]

coding_for_lyf@reddit (OP)

You can assess writing skill in interview, just as you can coding skill.

[-]

Educational-Bird-880@reddit

As a QE, the best devs I've worked with were English majors in a previous life.

[-]

kndyone@reddit

I knew a guy who made an entire career off this, he just went around the country giving workshops on how to communicate and plan stuff out.

[-]

magicpants847@reddit

and doesn’t help many companies are hiring off shore devs

[-]

jjanderson3or9@reddit

Close out the tickets without actioning them. Onus is on the requestor to clearly define the request. If they can't do that, they need to fix themselves.

[-]

snapyotables@reddit

Shit attitude.

[-]

jjanderson3or9@reddit

Nope. Its corporate. Play or be played.

[-]

snapyotables@reddit

Lmao

[-]

sobrietyincorporated@reddit

That's why "stories" were created. They aren't just a jira ticket type.

"As a ${actor} i would Iike to ${function} so I can ${goal}"

For example:

"As a sysadmin, I'd like to move files to an s3 bucket to store for later use."

But not:

"As a developer, I'd like s3 permissions in prod account so can use it"

The concept of written stories as a request is to solve a few things.

Eliminate "programing by remote". In the bad example another dev is telling me exactly what to do. Not presenting the challenge. If a junior gets this ticket they will assume it's all been thought out and will spin their wheels for days trying to grant access through IAM instead of telling them there is already ab s3 bucket with lifecycle and permissions in place. That's why "programing by remote" is one of the biggest time sinks and breaks in communication.
It abstracts the problem into a more understandable ask that can lead to a more optimal solution from a domain expert.
It takes away any assumption that something is just a simple task.

[-]

midasgoldentouch@reddit

While I like this approach for descriptions, I’ve found in my experience that it can be awkward for more platform type work. Sometimes the actor is the system and it’s doesn’t have likes or dislikes - we just want to implement things a certain way. But perhaps there’s a particular approach to using this format for that type of work that I’m unfamiliar with.

[-]

CalmTheMcFarm@reddit

I utterly loathe the "As a ... I want ....". It's shitty language which requires you to start thinking that the only way you can write requirements is if you put yourself in somebody else's shoes.

Whoever you are in your org, a requirement exists, and it doesn't matter whether you're the CEO, an architect, a sysadmin or an intern.

So rather than "As a sysadmin, I'd like to move files to an s3 bucket to store for compliancy audits by 3rd party" I would write:

""" The business/organization requires compliance audits (for specific field) to be completed. To support this requirement (data producing team) needs to be able to write audit data to an S3 bucket with appropriate IAM roles and permissions.

The bucket name is s3://agreed-bucket-name. The AWS role ARN is arn://...

The data writing process must use (this role arn) which has (list of S3 permissions). """

[-]

sobrietyincorporated@reddit

This is where 99% of mistakes are made. If you're having to put in this much detail, you should break the story into subtasks. You might be overlooking something a junior dev is going to bash their head on because they think you thought of everything.

This is why "programming by remote" fails and turn over rates of shops go up. Even if the instructions are perfect, the junior will not absorb the unearned knowledge.

Knowledge transfer and swarming sessions.

[-]

maigpy@reddit

the main difference should be between PROBLEM SPACE and SOLUTION SPACE.

depending on the PERSON who writes the ticket, there could be more or less solution space language in the requirement.

but in general it is best not to venture into the solution space when writing requirements, unless you really know what is happening. and your expertise liea both in he PROBLEM and SOLUTION spaces.

[-]

anubus72@reddit

If I’m the domain expert and I’m writing tickets that will be implemented by someone with less experience in the domain then I’m definitely going to add detail about how I think it should be implemented. Otherwise my domain expertise is being wasted. I don’t want to get a PR later that’s not solving the problem in the right way because I wrote a ‘proper’ user story

[-]

sobrietyincorporated@reddit

I believe what you are missing are knowledge transfer and swarming sessions. Otherwise, this kind of ticketing is still "programming by remote."

[-]

Viscart@reddit

Just english skills in general basically do not seem to be considered

[-]

bwainfweeze@reddit

Opening a thesaurus is one of my secret weapons for brainstorming (and refactoring).

The word you’re thinking of implies a certain design that approximates the requirements. Finding another word that embodies them more precisely can also reveal more about the requirement. Corner cases you didn’t think of, or knock-on features that would make it more useful.

[-]

CalmTheMcFarm@reddit

This is precisely why I went through several rounds of education with my teams about how to write tickets clearly. I got sick and tired of a previous team lead and BA writing thought-bubble ticket synopses, never providing context in the description and then wasting time when we got to sprint planning asking "why was this ticket logged and what is it asking for?".

I took that aggravation and wrote two confluence docs ("Problem Descriptions: How to write tickets and save time", and "Writing User Stories: How to be Effective") about it all, where I laid out the approach that we would take, and demonstrated to that lead and BA how they could improve. The next sprint refinement and planning session we eliminated about half the backlog, and for the rest we were able to rewrite the stories so we had actionable items.

With the team I went to after that, I got the entire team on board with this approach from day 1. Having docs about how to write tickets meant that the developers on the team were able to write stories as well, and decreased the load on the BA, PO and lead.

Outside of writing tickets, I've made it a point to hammer the idea that expressing clarity of intent in documentation (READMEs, comments in code, confluence docs - everwhere!) not only makes us faster but also makes things easier for "future us" when we have to maintain the product/project.

[-]

MoreRopePlease@reddit

I would think all of this would be obvious. Are people really incapable of thinking about the future? "Future" = sprint planning, or 2 years in the future when things need maintenance. Or 5 years in the future when you need to search Jira to understand why something was done the way it was. It's all the same.

[-]

bwainfweeze@reddit

Selfish devs expect to remember what they’ve worked on before (wrong) and don’t think about their coworkers (worse).

[-]

Rinzeler@reddit

It's also worse when most of your team is outsourced to India/PK, because companies don't want to hire more "expensive" workers. I'm not saying folks in other countries can't have a grasp on the english language, but most of them clearly struggle if they don't have a template that they can force-feed to customers while sounding ultra robotic at the same time.

[-]

fakeuser515357@reddit

In my experience about half the problem is a lack of respect for other people's work, role or time; and of those about half again are deliberately difficult to work with.

[-]

axtran@reddit

Perhaps you do not do the needful is why they have to take the necessary action. Best time to address this is during the interview where you take few steps back to review.

[-]

powerkerb@reddit

All my tech writings are now proofread by chatgpt. Use the tools.

[-]

EternalStudent07@reddit

Agreed there is a tension/issue there, but in part people gravitate toward computers when their social skills feel lacking.

How do you accurately measure something like that? Can it be done continuously or do you need a quiz/test?

Seems like communication in general, and business communication specifically, would be a valuable thing to be able to monitor, rate, and improve. But it also sounds hard. It'll vary with every interaction, previous interactions can influence future interactions, and good versus bad can be an opinion.

I'll agree I've thought it could be useful to have people list out what they thought they said, separate from the main message. Or to have AI summarize things, and for people to confirm an unbiased tool understood.

[-]

MoreRopePlease@reddit

How do you accurately measure something like that?

Give someone a prompt and have them write a paragraph on the fly. Should take no more than 3 minutes.

[-]

twitchard@reddit

IMO "writing skills" are less important than "writing values". If you truly care about being understood but just can't find the right word or have to phrase things in an awkward way, this is at worst an annoyance for the reader.

The worse thing is people who really don't care if they are understood. As they see it, if they have had the idea in their heads and write something down that represents the idea adequately in their own minds, they have done their job. If you can't understand it, that's your problem and it falls to you to ask for clarification.

I worked with a very smart engineer who had a habit of writing things that were just not complete thoughts, and to unblock discussions I was constantly having to make guesses at what they meant, go back and forth and essentially do the (invisible) work of making their comments coherent. They would acknowledge this sometimes "oh, I'm the not the best writer" but like -- no, it's not a matter of being a "good" writer or not, it's a matter of actually caring enough to work so that what you write is comprehensible to somebody other than you.

[-]

MoreRopePlease@reddit

Exactly. Writing requires empathy for your reader.

[-]

DeterminedQuokka@reddit

Honestly I don’t think we underestimate it. I just think that a lot of people who go into engineering aren’t good at it and we don’t spend enough time helping them. Everywhere I’ve ever worked knows they are poor and knows it’s a huge problem.

[-]

MoreRopePlease@reddit

we don’t spend enough time helping them.

You get better at the things you do. Get people to write readnes and howtos. Get other people to follow those howtos and give feedback. Have people write design documents, then review as a group. Where the document isn't clear, edit and improve. Get people to write brief "this module does abc" comments in code, and part of the PR process is make sure it's accurate and intelligible.

Just like every other skill. Give people a reason to exercise it, give and get feedback, and it will improve.

[-]

mildOrWILD65@reddit

Every safety incident requires a written statement from the involved employee:

Without exception, it's illegible and illiterate. We've moved on to consensual video recordings because no one is literate.

[-]

nuclearpiltdown@reddit

A help desk technician should primarily have a background in communication with a specialization in technology. It is a blessing when one of the hoards of technical school goobers can string a sentence together.

[-]

gomihako_@reddit

But upwork, cheap. Good dev, expensive. Must smash rock, no money. Ooga Booga.

[-]

tidbitsmisfit@reddit

a report came out that said the biggest improvements AI has done is for documentation/writing

[-]

behusbwj@reddit

My team gave a positive hire decision to an intern who legitimately could not write English. My senior at the time covered for him because they were from the same country. So of course they could communicate, because they did it in a different language. But if I needed something from the guy, I would get what I can only describe as cipher over slack. Somewhat related words In a hope-it-works order

[-]

Jmc_da_boss@reddit

What country were they from?

[-]

behusbwj@reddit

Irrelevant

[-]

justUseAnSvm@reddit

Who has time to write ticket descriptions?

[-]

NullPointerJunkie@reddit

Once upon a time I was working on a project recruiting nuclear engineers. I remember the recruiters comment that English communication mattered a great deal in the nuclear industry. Reason given is that in the nuclear industry there is a big difference between lunch and launch.

[-]

salty_cluck@reddit

Most of the poor writing seems to come down to a few things in my experience:

Engineers writing documentation with half the context still stuck in their heads and not transferred to the medium of choice (seen in mostly junior and even senior engineers)
Off shore engineers who aren’t proficient in English but are asked to be responsible for documentation for English speaking engineers.
Stories that might as well say “make feature and have it work”

[-]

SheriffRoscoe@reddit

⁠Off shore engineers who aren’t proficient in English but are asked to be responsible for documentation for English speaking engineers.

I've had great written results in the past from offshore developers, but only when my company prioritized English communications skills when choosing the offshore company.

[-]

salty_cluck@reddit

Great point. Sadly I wasn’t involved in the hiring of these companies but I could definitely see that working out better. I’m guessing the price and speed of coding was what was important in my experiences.

[-]

lift-and-yeet@reddit

Yeah, but it's not limited to devs. In fact, I find that devs have better than average writing skills—it's more frequently the client services and product management divisions that write badly in tickets and requests.

[-]

ManfredKerber@reddit

Agreed.

This is one of my pet peeves when communicating via IM/email or reading documentation/ticket descriptions.

[-]

300w@reddit

Omg I was thinking this exact thing the other day. Reading comprehension is so low people can’t figure out how to put related files in the same folder let alone name a fucking variable after what the thing IS or DOES!

[-]

levelworm@reddit

TBH it's probably more of "people don't know what they want" or "people just don't care what they write" than "people tried their best and failed due to English skills".

[-]

CaffeinatedTech@reddit

The client hardly ever knows what they are talking about when it comes to computers. I let them spew forth their problems, and Intuit a couple of scenarios. What's the harm in asking further questions to narrow it down?

I do agree that people should try to be better at communicating effectively.

[-]

grouting@reddit

It's made for an interesting career as someone with a strong liberal arts and communication background. I was originally a women's stuidies and classical antiquities major, switched to CS as a junior, was mediocre at school for the first time in a life, but then once I started my career, I've had to bat away promotions with a stick, because I know how to have a god damn human conversation.

[-]

BigHashDragon@reddit

It genuinely boggles my mind that engineers that I know are smart are unwilling or incapable of writing a clear email, especially if the audience isn't other engineers. Writing well, communicating across zoom levels, having a personal touch, such simple things but so valuable in IT due to how rare they are.

[-]

Revision2000@reddit

Agreed, and we all suffer collectively whenever there’s yet another PowerPoint “presentation” with 10+ bullets on a sheet being read aloud by the presenter.

Even if the language on the sheet is correct, that too is a form of poor communication skills. Unfortunately it’s endemic.

Whenever I start at a new client I inevitably run into some archaic and poorly worded process for X. Could be about requesting access to my mailbox or Git. Anyway, instructions unclear, unable to proceed.

It seems we need critical peer reviews not only on code, but also on most other written forms of communication.

[-]

Green_Rooster9975@reddit

God, I was literally just griping about this three days ago to a coworker. Too real.

[-]

MrMichaelJames@reddit

What you don’t like getting bug reports in foreign language and having to use google translate to convert it to English?

[-]

Teh_Original@reddit

Agreed. It causes bad documentation, bad comments, unclear code.

[-]

Strus@reddit

This is why typing speed matters. One can cope, but people who write fast - write more. They write more detailed design documents, more detailed task descriptions, more detailed messages, more detailed docs. Everything.

Thinking that you are not bottlenecked by your typing speed as a software dev is purely wrong.

[-]

wenxuan27@reddit

I honestly think any place that does everything ticket based unless it's bug reporting just isn't at the highest level. Engineers should be owning products/projects/features entirely on their own without needing all that jira/scrum.

Quick Design doc and hop to work on it.

[-]

Evinceo@reddit

In my experience, tickets aren't a language issue so much as a context issue. Does the ticket writer know the system they're asking for a change to as well as the engineer who will pick up the ticket? Often not. Does the engineer know the business case as well as the ticket author? Just as often not.

[-]

sortaeTheDog@reddit

I have an indian PO and tech architect. I can relate

[-]

fired85@reddit

Hire Good Writers https://basecamp.com/gettingreal/08.6-wordsmiths