To find great remote employees, prioritize candidates with strong writing skills | Hacker News Reader

To find great remote employees, prioritize candidates with strong writing skills

youteam.io

655 pointsRiphyak320 comments

I've been working on remote teams for almost 20 years. The key to success is overcommunicating.

In other words--don't assume people have full context or share assumptions. Write emails that lay out assumptions explicitly and detail problems completely. As a manager I sometimes feel like a Habsburg bureaucrat buried in the Chancery offices sending painstaking messages to a far flung empire. Come to think of it, remote work is not that different.

The other thing working remote forces me to do is to actually think before I assign a task to someone or ask a question.

It's a lot easier to casually interrupt someone with half a thought than to write a poorly thought out email.

Wow, that’s pretty interesting. In real life, I might blurt out a comment or question, but when I find myself doing the same even with a long slack message — by the time I write two or three sentences, and maybe go back to reword something, I’ve already started thinking about how I can solve the problem myself, and I cancel the message.

That is also the main advantage of email over IM. Email kind of forces some effect of the remoteness you described even when everyone is in the same office.

On the other hand, in a colocated workspace it is infuriating when a high effort, carefully crafted email is met by recipients interrupting you at your desk with, "Hey, about that email, can you just quickly run through it with me now please?"

One of the rules I tried to enforce on a prior team was to minimize context conversation medium changes. Following a conversation as it freely moves from email to chat to in person is exhausting.

You're using IM wrong :)

You don't have to read the message when it arrives just because it instantly arrived.

Sometimes it’s my colleagues that are using IM wrong.

> Hey I have a question

People are too lazy to type the rest of their request until they see a response from me indicating I’m listening.

Ignore it until they ask the question. Eventually they'll learn.

This is my general take on "remote doesn't work for X": Did your existing process actually work, or did you use the ability to interrupt people as a crutch in order to make it not totally fail?

I strongly relate to your comment! I was recently brought into a project where my company was working with a vendor to use their platform to reduce tedious work. Only by repeatedly emailing the vendor specific questions was I able to discover that the internal team had made some significant incorrect assumptions about what the vendor's product does.

To prevent dozens of wasted work hours, we can't be afraid to ask specific questions, even if they might make us look dumb!

In marketing world a common way of ensuring good communication is the client will write a brief of what they want, then the agency will reply with a 'response to brief'. Here they basically write the same thing in their words back to you.

It helps on several levels to ensure understanding is aligned vs emailing back 'I got it' and off to work.

I've also worked remotely for 15+ years. I constantly ask dumb questions. It's amazing how much comes out of the woodwork doing that. Doesn't seem to have hurt career progression either.

With some of my clients, I go even further. Where possible, I figure out what the possible answers to my question might be and write them in a concise numbered list (with a “something else” option at the end”). Ideally, the response is a number with a little context. At the very least, it prompts a response that challenges my assumptions, which is useful too.

I started doing this because I received so many short and incomprehensible or long and incomprehensible responses that rarely included the information I asked for.

But, when it's that long, do people read it? It seems like a great CYB tactic, but maybe a poor communication tactic. I'm a voracious reader, but when it comes to most corporate communication I won't really read anything over a paragraph long. I might skim it if it is from my manager. Maybe.

Title. Abstract. Details.

Most people will skim the title. Some will read the abstract. Few will read a specific paragraph or two of details. Yet, the writer doesn't know who's going to read what. Could be the writer himself, 6 months down the line. Often times those details are pure gold.

If everyone in a corporation is unwilling to read more than a paragraph of a colleague's thoughts, it's amazing anything of any remote complexity is able to be produced by collaborative software organizations. Unless it's one guy in a corner, talking to nobody.

> it's amazing anything of any remote complexity is able to be produced by collaborative software organizations. Unless it's one guy in a corner, talking to nobody.

Honestly, I have seen this happen so many times that I rather suspect it is fairly common.

Agree. It's usually one or two people building all core features and then an army of so-so skilled maintainers.

This however happen exactly when communication is bad. When two people monopolize core, won't explain what they meant by what and effectively make it impossible to split work and effectively work for others. The army of maintainers suggests that original people just move on to new functionality having others fixed their bugs.

It works better when team has mechanism for knowledge sharing and core developers fix their own bugs.

It's hard to have more than 2 developers working on the core of something. Development is a very non-concurrent activity.

Speaking from experience, when there's multiple people trying to take over the same bit, they only create conflicting changes all over the place and deadlock the project. It's worse than if no work was not done. Now somebody needs to take the lead and remerge things manually and discard what cannot be merged.

Regarding maintenance, the later army of maintainers is typically a bunch of contractors mostly sitting idle billing for time. The size of the maintenance team has little correlation to the workload.

People read if it’s written well. Don’t make it long to be long, make it long because it needs to be long.

My favorite feedback is when someone replies to a 1000+ word newsletter with “Wow, short and to the point! Thanks”.

It's a lot harder to write something short and concise that efficiently communicates to team members than something long and wordy that requires a lot of reading.

"I didn’t have time to write a short letter, so I wrote a long one instead."

> People read if it’s written well.

This is bordering on the No True Scotsman fallacy.

I work on distributed teams that are spread across 10 to 12 time zones. We depend on people making local decisions that are approximately right, because confirming a decision may mean a 24 to 48 hour cycle of back and forth communications.

In these situations it's more important to share "what is the problem" than how to solve it.

As a manager, you can probably get away with this.

As an IC, people rarely read my emails if it doesn't fit in their screen (so 3 paragraphs is the max).

The only thing I've found that works is to send details, and then probe the recipient on each important item in there to make sure they understood what I wrote. If I'm too detailed, they will get lost. If I'm very concise (but still complete), they'll misinterpret.

Getting people to reflect back to you what they understood is encouraged in most communications books. You can write the perfect email, and it will still get misunderstood.

Edit:

It is amusing that people are responding giving me writing advice. Equally amusing is the implicit tone in some of the comments that I'm doing it wrong and implying I don't follow what they are suggesting - especially when I didn't even discuss how I write my emails!

As I said: You can write the perfect email, and there will always be someone who will misinterpret it. The problem is not merely in the content, but in the other (including their worldview, culture, social status, etc). The solution isn't to try to become a more perfect writer, but to understand the dynamics involved in communication (written or verbal).

To paraphrase one of the books: People will interpret what you say based on their worldview - something that you often do not have access to. It's their worldview that will often make them misinterpret something that is very clear and unambiguous in what you say. Accept that reality and work around it.

Have you tried putting each important sentence on it's own paragraph? Just the important ones.

That makes a difference in focus/readability.

Try it.

Take this too far and you end up writing broetry.

After enough years in a corporate setting I can guarantee that this has the opposite effect, because it makes it even less likely for your email to fit on a screen so it just gets skipped.

Many of the suggestions I'm seeing are the polar opposite of how this thread started.

When you're remote you miss a lot of context. Overcommunicating in writing helps address that. Eliminating information or not expecting people to fully read and engage with what they read is going in the wrong direction of the fundamental problem.

If an email is too long, then some will just ignore it. So overcommunicating can lead to people ignoring your essays for a simple point. Then there’s the time aspect. With everybody overcommunicating how will work get done with everybody overcommunicating to discuss a bug? Some of the most productive teams I’ve been around and on barely needed any communication outside of quick alignment meetings. Seems this is very opinionated, rather than fact.

Put your ask at the top, don't be afraid to use bullet points, keep things short and sweet. Most things can be effectively communicated in 2 or 3 paragraphs - if you need to communicate more than this, send it in a follow-up email after they respond. If you need to communicate more than this, you should really set up a quick call to communicate the thing and ensure they understand, then send the long email afterward.

Using checkboxes in GitHub issues is my secret weapon. There is no way to mark an issue as done or glaze over the details that way. Checklists in general are a great thing. I wish there was a startup that made community sourced checklists for common tasks like opening up a PR or writing an email asking for a raise.

Checklists also save lives!

> But a year after surgical teams at eight hospitals adopted a 19-item checklist, the average patient death rate fell more than 40 percent and the rate of complications fell by about a third, the researchers reported.

https://web.archive.org/web/20151103232100/http://www.nytime...

on the flip side of this, there’s those of us who hate the superfluous (opinion) processes that seem only to slow down, not speed up.

PRs don’t need checklists IMO. If they do maybe your team is too large.

I think a little checklist would help me remember things that are easy to forget, like updating documentation or making sure that a test exists to reproduce the issue. That said, at the end of the day tools exist to help us, not slow us down. If they is a small PR that fixes a typo then I want to be trusted to skip the checklist completely.

I've found it useful to distinguish between the times I'm asking for something, and the times I'm documenting something.

When asking a question, lead with the question, and put only the bits you need to clarify your question underneath. For these communications, the shorter you can make it, the better.

When writing documentation, you're writing for the future, and should aim for completeness rather than full comprehension immediately -- you want something people can look back at later when they're not clear on something, rather than something that your reader will read in one sitting and remember flawlessly. Your reader isn't going to be able to retain that much stuff.

If you absolutely need your reader to understand some points, I recommend keeping the points as short as possible, and also to your point, asking a question that requires them to have understood what you wrote (e.g. "people who signed up before this date will be grandfathered in, so may see different rates than new customers. Are you aware of any marketing material which might give conflicting information? " -- the answer is probably "no", but in the course of answering that question, they had to understand what you were saying, and as a bonus if the answer is "yes" you've avoided a problem before it happened).

> As an IC, people rarely read my emails if it doesn't fit in their screen (so 3 paragraphs is the max).

You need to learn how to restructure your writing. Most logical people naturally write in a way where it’s premise, premise, premise, conclusion. Instead, you need to write conclusion, premise, premise, premise.

One way I’ve found to help my team learn to write this way is to institute a rule that any writing longer than 3 paragraphs has to have a TL;DR at the top that is no more than 3 sentences. This gets people over the hump of putting the big ask up front and then after a few weeks, they start naturally writing that way.

This echoes OPs point about culture. One absolutely should not do what you've mentioned in my location. Here we lay out the arguments, and the conclusion at the end. The reverse is seen as jumping the gun, and not being well reasoned. It is looked down upon, and frequently discounted immediately.

Cultural bias is very much a thing.

How is that cultural? Even through elementary school we were taught to have an intro with what your point is, follow up with supporting arguments, then conclude by reiterating the point the you made.

How could you read anything without knowing the point in the beginning. Even research papers start off with an abstract.

The fact that you was taught that in elementary school and thus literally concluded that it is impossible to read something without knowing conclusion first is what makes it cultural. The fact that he and everyone around him sees conclusion up front as jumping the gun and likely was taught that structure in school, is what makes it cultural.

> How could you read anything without knowing the point in the beginning. Even research papers start off with an abstract.

It is pretty easy to read email or argument without knowing the conclusion up front. You just read on. Research papers are specific writing with specific rules. I dont really think they are in general example of good or persuasive writing.

It doesn't make sense as being cultural because there plenty of real examples of effective writing that starts with what you are writing about. The only exception might be in story telling, but that only works because there is some kind of context assumed or it works as a tool.

It makes no sense for this "culture" to think less of research or any writing that intends to persuade because it starts with a introduction or summary. Anyone who starts with a summary of what is going to follow will be a more effective communicator. They would be missing out on lots of writing that is done this way.

Your first paragraph or sentence will always be an introduction. If you choose to not take advantage of it to set the context of what follows the writing will be more confusing or require a second read through. Its like wandering through a forest vs following a trail map. At work, writing something that needs automatically needs a second read through is a problem.

I guess i have hard time believing this culture exists the way is presented, and isn't being misinterpreted.

> It is pretty easy to read email or argument without knowing the conclusion up front.

Its not, that was the point of the thread were commenting on

> Research papers are specific writing with specific rules. I dont really think they are in general example of good or persuasive writing.

This is one example, it has rules because those are effective at communicating. How can you just write it off like that? With no reason other then you think it doesn't count?

> It doesn't make sense as being cultural because there plenty of real examples of effective writing that starts with what you are writing about.

That argument does not make sense.

> It makes no sense for this "culture" to think less of research or any writing that intends to persuade because it starts with a introduction or summary.

And it does not make sense for you to look down at writing that puts conclusion to the end going with arguments first. It is just an habit and meaningless difference, that is all.

> This is one example, it has rules because those are effective at communicating. How can you just write it off like that? With no reason other then you think it doesn't count?

Researchers and their papers are not effective at communicating. That a thing that researches complain about periodically.

In any case, corporate mail is not research paper. Among other things, it is supposed to be significantly shorter. Just like it is not newspaper article.

Can you show me something written that doesn't have an introduction that includes a summary of what's to come

> It doesn't make sense as being cultural because there plenty of real examples of effective writing that starts with what you are writing about.

This is a non-argument. In the US, writing is considered effective if you put the bottom line up front. GP wrote that BLUFfing is considered offensive in their culture. Now you respond that lots of people like BLUFfing.

Now you say it's not culture-dependent but a universal truth that BLUF is better.

Well, other cultures disagree.

Bluf seems to be a specific thing, no one mentioned that in the thread I'm commenting on.

The post that I responded to suggested having an intro with a summary of what's to follow is offensive

You could still totally just read the ending first if it's that big of a deal for you.

This approach depends very much on culture. For example, US culture is very much, get to the point, start with the conclusion. German culture requires you to outline how you got to the conclusion.

Interesting book on this topic: The culture map, by Erin Meyer. (https://www.amazon.com/Culture-Map-INTL-ED-Decoding/dp/16103...)

It has a whole chapter on this topic: 3 - Why versus How, the art of persuasion in the multicultural world.

German culture requires no introduction in any writing? Am I talking about the same thing as everyone else commenting?

Anything you write will always have a first sentence or paragraph. Your saying it's offensive to use that to give an overview of what's to come and to set the tone of the writing?

Looks like i wasn't very clear.

The difference according to the book is that if you want to convice an audience of something, e.g, result of a study, americans are more interested in the results and how to apply it. Germans want to understand how you got to the results, what the process was behind it so they can understand that your results are correct.

> One absolutely should not do what you've mentioned in my location. Here we lay out the arguments, and the conclusion at the end. The reverse is seen as jumping the gun, and not being well reasoned. It is looked down upon, and frequently discounted immediately.

I would like to understand why the reverse is "jumping the gun". I am assuming the arguments have not changed, the reasoning remains the same. Why is a mere change of order "jumping the gun"?

Theory: If people read conclusion first, then people tend to evaluate whether they agree or not after reading conclusion. Emotional reaction toward conclusion will bias interpretation of arguments.

The remaining arguments are more likely to be accepted or rejected based on what you know conclusion is. So instead of asking "is this true", people will start either with "I am looking for nitpick cause I see this is going toward bad conclusion" or with "yeah sure, it shows what I think".

However, they will still feel like they evaluated arguments on merit. If the conclusion is last, people can and some will go back to arguments to bias them, but it is easier to see what they are doing.

While the solution may be valuable, there's more value in reading the work to get there. Rarely is the value a decision, inasmuch as the path to the decision. By first declaring a solution to a problem, you're priming the other individual. Depending on their personality you're priming them to be for, or against your decision.

By articulating the reasons, methods, and considerations that went into a decision, you're slowly and softly building an argument. Individuals are less likely to have an instinctive reaction to something this way. At the very least, it's proven (yes, as in measured) to be the case here.

I have experience at several companies with many different cultures, and I don't know of anyone who likes to slog through the details before getting to what the final problem or solution is. People just don't have time for that. Putting the important part first serves the dual purpose of quickly informing people who aren't interested in the details, and telling them up front why they might care about reading the details.

It's like having an abstract or a blurb to briefly summarize for management.

Similarly, if you need someone to take action based on the result, you don't put it at the end where nobody's going to read it. You put it at the beginning, first thing, and then build up the background.

That's a really interesting counter-example to what I've learned as the best way to write.

Can I ask what culture you're referring to?

We called this BLUF: Bottom line up front.

>people rarely read my emails if it doesn't fit in their screen

I think this is the case unless the problem is very relevant to what you are working on at the moment. Normally what I would do, if I were writing an email to explain a problem, is create that explanation in depth on a wiki or other knowledge repository somewhere. Write the email referencing the url of this wiki, and explain the main points in the email.

This is as a general rule if I am explaining something important for tech team to know, if I am explaining something that is important for product owner to know I write it in as verbose an email as is required to explain everything. That's up to the product owner to follow. Generally after receiving an email like this they will want a meeting where I can explain in person and draw stuff on the whiteboard.

> As I said: You can write the perfect email, and there will always be someone who will misinterpret it. The problem is not merely in the content, but in the other (including their worldview, culture, social status, etc). The solution isn't to try to become a more perfect writer, but to understand the dynamics involved in communication (written or verbal).

Wiio's laws are always relevant: https://en.wikipedia.org/wiki/Wiio%27s_laws

The main thesis being "Communication usually fails, except by accident".

It’s a bit like sending events to an unknown state machine.

You need add enough context for the event to be processed but you can’t know what will happen when it is...

The One Palm Rule. I know a few people that promote this :) If it's larger then your palm, when you streach a hand towards screen, you are not obliged to read it.

Suprisingly effective, especially if you are open about it. Of course it applies only for those with 1000 unread (after filters).

I can't fit your comment with my palm on my current monitor.

(But I read it anyway.)

I guess the effect of following this rule depends a lot on formatting, size of hands and monitor and how long your arms are and how far away you are standing.

You are holding your palm flat towards screen, right? :)

It's one of those things you apply only when it suits you, and ignore when it doesn't work to your benefit.

Jokes aside: I wrote this because it's both sad and interesting how people cope with huge amounts of communication that waits for their action.

I was working a pretty big screen at the time.

pick up the phone

You're totally right that you have to know your audience and cater to it. Technical writing still requires it.

What changed my perspective though is the book "Comedy Writing Secrets". It's a very different topic, but the general aspects of writing fun an engaging texts translate quite well.

One example I've seen it done brilliantly is the re-frame docs https://day8.github.io/re-frame/re-frame/ - I often point it to people as an example of technical writing so good, that its fun to read just for the sheer pleasure of it, regardless of whether one writes Clojure or not.

_why's (Poignant) Guide to Ruby is also a famous example of this.

> You can write the perfect email, and there will always be someone who will misinterpret it. The problem is not merely in the content, but in the other (including their worldview, culture, social status, etc).

Without a doubt the first sentence is true. Successful written communication requires properly encoding the information (writing) and properly decoding it (reading). A flawed reading of an email means communication breaks down independent of the quality of the writing.

The second is also true, but incomplete. In many cases, there is a failure to read (either because of laziness or "I already know what he's going to say") or a language issue - even for native English speakers. It's not at all uncommon for someone to miss a "not", think "and" rather than "or", interpret "weeks" as "days" and so on.

Edit: One story that comes to mind is related to a policy our department was implementing a number of years ago. I sent an email with what I thought was minor supporting information. I got an angry reply of six paragraphs, totally irate that I would suggest something so crazy, listing all the ways I was wrong. I responded to say "I think you read my first sentence wrong." The response: "Oops!"

One of the hidden assumptions in "hire people that write well" is that people who write well would also likely have high reading comprehension skills. Or, the inverse—I find that the ones who want to jump on a quick call vs. writing out their request are the same people who seemingly don't read the documents I produce.

Quickly reading and understanding almost everything I can find—code, plans, schedules, calendars, strategy, memos—is how I excel in remote environments. It's not a huge time commitment, 20 minutes a day, but I have the organization's "state" modeled in my head, which helps me identify dependencies and potential bottlenecks before they're surprises.

Different people have different communications styles, and resolving that is always tough. But there are definitely those who communicate poorly in any medium -- and I find that often they're the ones who like media where they don't leave a trail that can be pinned on them.

There are are advantages to the "quick call", and some people definitely work better that way. But I much prefer written communication: not only do I get to refer back to it, but it's more asynchronous, freeing me up considerably.

"Let's talk" often seems like a barbarous imposition on my time, that I have to hear it right now and make any decisions while you're staring at me. I try to keep in mind that they just have a different communications style, but that's not always easy.

You are right, of course, though this may seem to conflict with my original comment. One way to reduce email size is to put context information into reference documentation. (Or other substitutes, like Github issues, JIRA, design docs, requirements, operational run books, etc.)

One thing that may not work very well is depending on Slack channels or other chat systems for context. It's fine for an on-going issue but does not work for general information. Important topics are just too hard to find later.

Have you considered refactoring info into wiki webpages and hyperlinking between them? Then your email can link to that.

As an IC you probably have more time to fully read emails, esp. those from your management chain.

I like to lay out the decisions I'm going to make if I don't get feedback, if possible. That seems to prompt feedback when feedback is required -- it seems the human desire to fix mistakes is stronger then it is to answer open ended questions. It likely gives the reader some context as to why you need the information as well.

> As an IC you probably have more time to fully read emails, esp. those from your management chain.

I’m sorry, an IC having time?

Be mindful of how Outlook displays messages. Subject should be the topic, and the first line should be the ask. That way busy people see everything they need in the preview, without ever opening the email.

In a properly collaborative environment, work is performative. When the work is not face to face, this is doubly true.

Please write a collaborative doc instead of an email if you have that much detail. Having an effective discussion over email is actively painful and worse yet no one can refer back to your detailed documentation later.

Good on you for communicating. Personally I've found that details are great, but being able to distill that core message down to a quick code really helps. Call it an elevator pitch, sound bite or whatever but it is really transformative. So much communication seems to be just passing along a historically linear repeat of facts rather than helping reader by distilling down.

Email is the worst but a close contender are Slack messages and threads .... Confluence is somewhat better but comments are not handled well with respect to the source document. Add in Smart sheet and the rest as kludges and I have 10 different things to check for a single project with dependencies.. it's nuts. I am not sure if anyone has really figured the information based workflow out yet. There needs to be some auto association and project based aggregation (maybe tags?) .. that and a personal workspace of things you need to do in each system.. right now everything is asynchronously propagated by slack or email.

I am interested in trying out Asana and Facebook Workplace to see if they have solved this in a more natural way.

Exactly this. Assume nobody knows anything and explain everything 500 times.

Also quick 5 minute call on Slack can save 4 hours to 4 days of sending emails. So prioritize fast issue solving rather than "process".

Imho key things are:

* Communication. * Biz + Technical PoV from devs. * Ownership / ability to make decisions.

Full remote is not for control freaks. It is for people who wants to get shit done. If you can't trust anyone you can't do remote.

1. Communication is key

Ability to talk and exchange info in processable way is king. This means no 5000 esseys. But not 1 line 4 word summaries. Communication should assume 0 knowledge on the reader but start with easily digestable summary / TLDR so person reading it can skip explanations he already knows.

Your english doesn't have to be perfect, but when you speak you can't sound like a broken acordeon. If your english is on level of ability to laugh from a pun you are good. Always learn and never assume your english is perfect.

2. Biz + Technical PoV from devs

Developers should know entire domain, how the app works in a biz sense. What is important. IF you are selling voice services and birthday card generator services from which cards generate 3% of income. Dev should be aware where the focus must be. This might be simple example, but this knowledge lets developer asses damage in dire situation and help prioritize things.

I know it might be shocking but sometimes developers can generate a good biz idea that will propel more profits.

Technical pov from devs. This is trivial and i assume every dev has technical pov but it might not be 100% true always. Simply to put it. This means understanding code in platform and setup / deployment. Sometimes developer can spot some easy optimization in other areas that just code. For example in the deployment sense.

3. Ownership

Teams / Developers have to have decent level of ownership. Possibly 100%. The decision-feedback-loop should be fast and simple. It doesn't mean devs call all shots but if they need to do something or get info it shouldn't take 3 weeks to get response.

All questions not answered are waste, all meetings about follow up to this questions are waste, all emails without answer or with bad answer are waste.

Imagine this situation:

Your team has 3 devs in 3 different countries. Lets call them D1,D2 and Dave. There is a product owner in 4 time zones behind him. Dave asks a question "how do we want handle service deletion?" he has to wait 4 hours to get the response, if product owner don't have to ask higher up. If PO has to ask up the response might be after 2 days. The response might be "in a good way" which prompts another set of questions. etc...

ofc Dave can ask the question like this:

"How do we want to handle service deletion ? Option A: just remove everything. Option B: marked it as deleted and keep in archive"

This might prompt Product owner response

"Adding in Steve from finance and Karolina from GDPR department. What do you guys think ?" ^- this solo can freaking prompt a week of delay because Karolina will respond "we must delete it" and Steve "i'm on holidays until March" etc....

Short feedback loops are ideal even if solution isn't ideal. It will be ideal most of the time. but the key is that a lot of this comms was just useless waste of time. And when PO involves multiple people and they start to disagree it is full scale setting up money on fire.

ofc Karolina is correct about GDPR handling but Steve might say "no no, we never delete" xD classic Steve.

TL;DR ;)

One tip for communicating at work: keep your message brief and concise. Add too many details and your mail won't be read or just half of it.

>This means no 5000 esseys.

I generally tell people looking for my advice, engineering is a reading job. Until humanity figures out how to transfer ideas with something other than characters, you're going to have to read. A lot.

For example, one quick tip I give is just read the entirety of anything you encounter. The whole error message + stack trace. The whole document (page) about the package that contains the function you're after... the whole type and its functions.

It's also how I often mark people a "No" for interview -- when they obviously are not reading the error (with line number!) of their non-compiling code...

That is good if you are working in a team that is comfortable reading and writing a lot of English, and cares about what you're writing.

If those things aren't true, "overtransmitting" (because you are not in fact communicating) will just lead to unread email, incomprehension, sidelining and getting ignored. That goes double if what you're trying to do is already against the corporate culture (in the conventions and accepted quality level sense).

Some teams focus on communicating as much as possible and I as a developer am in favor of this, since it makes my job easier.

On the other hand some teams, usually startups that move too fast and can't communicate everything, stress the importance of independence.

Both are needed, when you can say as much as you can, I am totally for overcommunication. Sometimes unexpected things happen, or there is just not enough time for proper communications, so a proper judgement is needed.

I managed a team for 25 years at a Japanese corporation. We had team members in many different timezones, and scheduling videoconferences was always a fraught process.

I write a lot. In fact “prolix” is not a bad word to use for my writing.

The biggest complaints I received were always about the lengths of my missives.

This was a legitimate complaint. It took a long time for people to translate my messages, and to translate the responses.

I learned to write emails with every sentence as a separate line, a clear abstract, and a clear conclusion/question.

Bullets were important, as was careful wording. Fifty-cent words were OK, as long as they were accurate and relevant, but jargon was harmful.

A good maxim from safety critical industry: patronised is better than dead.

Nobody seems to read long emails.

The issue people fail to realize is that language is quite lossy in terms of information. The way you make up for that to clarify ambiguity is through verbosity.

If you can't read and write long emails (or voice/video chat), you're going to have miscommunication. Experience and knowledge can only be used so far to interpolate and extrapolate. No matter how skilled you are at this, clarification will be needed in some form or another.

In cases where whoever you're working with doesn't know exactly what they want and give you what is essentially artistic liberty to fill those voids, you can reduce communication some but be warned, you may create the wrong thing and have to double back or worse, you may find out much later when its not viable to fix something was off.

I'm a fan of long emails or conversations to be certain I understand what's needed.

One thing I often do is split an email into two parts, I'll even label them.

High Level Summary: 1-3 sentences that cover the main ideas, kind of an executive summary.

Details: the nitty gritty, full context, screenshots, etc.

People seem to really like this, each reader has the option to dive as deep as they need/want.

Good on you for thinking about the user experience of the person receiving the communication. It's a skill to know how to do this well. It requires practice and effort that many people don't bother with – because of a lack empathy, they're too busy, or they realize the recipient(s) won't recognize (or even read) the results.

Edit: In my experience, a lot of people can't even bother to think of an appropriate subject line that summarizes the content effectively. "URGENT: please read" is the worst offender.

Communication is a weak point in the entire software industry. It permeates everything from emails to variable names. I wonder if it's the same in other industries.

I've started using an equivalent pattern and my implementation has generally been a success, so I'll share:

My email body has everything the "optimal" reader (i.e., someone who is already familiar with the topic item) needs to |action_verb| regarding what I've written.

Then I "conclude" with my usual sign-off (e.g., Cheers, [CRLF] "/Aceyman").

BELOW that—but above my default signature/contact info block—I place all the deeper-dive / expository / rationalization narrative which provides that level of detail for anyone who needs more than my main body provides.

I've been using this pattern for about a year or so with good results.

/Acey

At the start of the supplementary section—and depending on the topic & audience—I'll sometimes use the 'section title' Extra-credit reading, because everyone loves a chance for some extra-credit, right? That's my little psych ploy to entice readers to take a look at the nominally 'optional' expository stuff.

I have started to question the value of sign-off text. It seems that is just wastes screen space. The only time it would be useful is when you are emailing someone who might not know who you are. What value do you see in it?

It's a signal that you're in the "in" group of the cultural norms, like shaking hands or the superfluous "Hi" in text chats. The value is social signaling and emotional, not informational.

Looks like a wiki would help

That is only working if you are the only one doing this. If everybody in the team starts repeating everything very detailed, this soon becomes completely unproductive and ignored. Think one information mail from one system might be a good idea, but when you start getting 1000 automated mails every day like I get right now you are actually not informed at all.

The key to success is focusing on a small number of messages that you really want to get to people and then overcommunicating them.

We need to explicitly communicate Requirements + Expectations

> Come to think of it, remote work is not that different.

I've spent the majority of my career at large companies with multiple offices. My experience is that non-remote work is no different unless everyone in the company is in the same building. Even then, if different functions or teams are sufficiently siloed it still requires that level of over-communication.

> The key to success is overcommunicating.

No, "overcommunicating", by definition, means giving more information than what is needed.

There are times and places where overcommunicating works, but email is almost never one of them. You simply can't get away with more than a few sentences in an email unless the recipients are specifically expecting that from you.

When "an essay" lands in someone's inbox unexpectedly, at best, you can expect recipients to skim it for whatever concerns them directly. If you have critical points or conditions embedded in a paragraph in the middle, those are probably going fly past the recipients' attention completely unnoticed.

As a corollary, if your org is dependent on email for communication, you likely have some inefficiency and room for improvement.

In all seriousness, please enlighten me. Email isn't the best, but the other options are equally or more shit:

Slack, which has nonfunctional search and is miserable to navigate?

Github readmes?

Atlassian's wiki, which has even more broken search, and follows management's whims?

Google docs, which vary widely in format, is not easily searchable, and has no index?

Team documentation, which follows managements whims, gets moved around, deprecated and eventually stowed in unused lavatories?

Internal stackoverflow, which is piloted and then slowly abandoned after an intial big push my managers, who get promoted and then leave the company?

Facebook workplace, which suffers a similar fate to stackoverflow?

The problem is there is no global index or search- think Sourcegraph, and management keeps changing products/documentation/comms strategy every 6 months.

Quote: "The problem is there is no global index or search- think Sourcegraph, and management keeps changing products/documentation/comms strategy every 6 months."

Are you saying that Sourcegraph's management keeps changing products/documentation/comms strategy every 6 months? (Just not sure how to parse this sentence.)

No, I'm saying that management keeps changing internal documentation/comms strategy, and that without a central index to search, it's impossible to know where things are, or what's even going on.

A tool like Sourcegraph but for finding documentation could be useful, but it doesn't show you the amount of "dead" documentation that's floating out there, or give you a way to browse everything.

The key to success doesn't have much to do with communicating. Recognizing people respond to different behavior in different ways will be much more productive. I for example, rarely spend more than a few seconds reading an email so if you have a point to make it better be in a succinct mini paragraph.

I believe that you should be fired for that.

While I agree that the key to success is _a lot_ of communication, there is much more to the management of remote teams than that: you should treat them like the on-site teams; communicate a lot but prefer video conferencing; try to give your remote teams the overall context; stick to as few means of communication as possible (if it's email, then stick to email).

I believe I am a good writer. On my first job as a developer I kept getting very positive feedback on my writing. I ended up even starting a newsletter with writing advice for software developers[0].

So 4 months ago I started looking for a remote job. I applied to 250+ positions. All very suited to my skills (e.g. I wouldn’t apply to any job asking for “senior” or “fullstack”). I got about only ~15 interviews, 1 offer.

The message is that I believe strong writing skills won’t help you get a job. It will help you a lot once you start the job, but I don’t believe it helps at all at being hired.

Things that I do believe help you get hired: a well-written CV, a CS degree, a top-branded college, a top-branded former employer, a good public sample of your code (open source, side-project, etc), interview skills (be calm, articulate, charming, clear explanations and thought process), practice at technical interviews of the specific type of the positions you are applying to.

My advice is to practice your writing skills after you get a job, not before.

[0] https://writingfordevelopers.substack.com

I think you missed one thing -- in my opinion the most crucial: cover letter.

I wrote about it on https://blog.gingerlime.com/2020/who-doesnt-want-to-be-hired...

I am on the fence on cover letters. I am pretty sure they are not the most crucial part though. I did write cover letters for most of my applications, a relevant part of them following all the good advice for cover letters, some just copy and paste.

I couldn’t see correlation in my application of well-thought cover letters and interviews. My copy-paste one was very well written and representative of my skills. Good enough for most companies I think.

In the end I got a job from a copy-paste one.

The most a good customized cover letter did to me were customized rejections praising my cover letter/email.

How do you deploy the cover letter? I always package it in with the resume to force it to be read rather than just in the dedicated cover letter spot.

I always use the cover letter spot, never occurred to me that trick. Might be a good idea. Still, the GP argument is that a hiring manager would read the cover letter first. This trick would help with other type of managers

I often write very unique cover letters, so I want to force them to at least be skimmed.

Do you have the cover letter be the first page or the second? I'm now thinking about doing this myself. Figured it would be more likely read when it's part of the resume itself.

I put it first. I want it read. Then they can be encouraged to read the resume in more detail.

my limited experience there is from reading hundreds of applications. The cover letter definitely made the biggest difference in our process (small remote company, no HR department, no headhunters or agents).

You mention things like “representative of my skills”, which I’m sure these were. I would however stress out the importance of representing the match to the employer. A good cover letter makes it obvious. And yes there’s an overlap between skills and match, but they are still different.

7 jobs; 2-3x offers over career, and I’ve never written a cover letter.

Involved in interviewing for 2/7, and a cover letter has never factored into a hiring decision.

> I applied to 250+ positions

That sounds wrong. It's common, but it still sounds wrong to me.

When I look for new jobs, I find a couple of companies (3-4) that match with what I'm looking for exactly, read up on the companies, tell them explicitly how I fit into what they need and write them personally. I have a 100% success rate when it comes to interviews, and most of the time I get a offer, but drop out when my counter-offer is too high.

On the other side of the fence (as someone who does hiring), if the application looks like something that can be easily copy-pasted and the applicant has no idea about the company itself or tried the product when I follow up, then the candidate very quickly goes to the bottom of the list.

Instead of focusing on useless parameters like "CS degree, top-branded college" and so on, try to focus on writing high quality applications for a few selected companies you know you can help. I'm sure your success rate will improve then.

”I’m sure your success rate will improve then”

I think you are wrong. I don’t have a CS degree, I don’t have top brand college or employer.

You also assume wrong that I didn’t dedicated myself to apply to specific jobs where I was a very good fit. I did that. And it didn’t got me offers.

If you tell me more about your profile, I am sure I can pinpoint why you get 100% success rate and I don’t. I am pretty sure it is not for the reasons you mentioned.

Your comments echo what many who are currently employed say. When the shoe is on the other foot though, and unemployed, you can almost guarantee they will have applied to 100+ roles!

Oh man, it's in the thousands every time I apply. I used to keep a spreadsheet of it, but that just got depressing. Job searches are quite painful.

(Note that I'm in biotech and real engineering, not SW)

>real engineering,

<fire emoji>. Some schools have tried to make Software Engineering actual engineering

eg: https://www.apega.ca/apply/membership/exams/technical/softwa...

I don't have any CS degree, nor studied at any college, nor worked at any famous employer neither. So probably irrelevant.

I sure knows that when I'm doing the hiring, I rarely if ever read what colleges or what previous companies the candidate worked on. All that matters is what their experience is, what they learned so far, what they tell me they wanna do in the future and how they are as a person.

> You also assume wrong that I didn’t dedicated myself to apply to specific jobs

Yeah, that's my fault, sorry about that. It's hard for me to imagine how you can have time to send out 250+ applications and still have a dedicated cover letter and well-researched application for each one of them.

While I don't know how the 250+ companies you've applied to are thinking, I can share how I think, when trying to hire someone for a position. And from your advice, only "good public sample of your code" and "clear explanations and thought process" would be something that I would care about. The rest of your advice are not only not relevant, but some are even outright harmful. Good writing absolutely helps someone (in my eyes) to be more fitting for any type of position.

My advice to job seekers would also be to look for advice regarding getting hired by either people who have been hired, consistently so, or by the people who are doing the hiring. While it could be helpful, chances are that people who haven't got a high success rate at getting hired, aren't able to give you good advice.

> I sure knows that when I'm doing the hiring, I rarely if ever read what colleges or what previous companies the candidate worked on. All that matters is what their experience is, what they learned so far, what they tell me they wanna do in the future and how they are as a person.

You are not the only hiring manager. I have seen decision makers openly read college name or even high school name and use that information to judge candidate. I am talking about people who did it very openly, I am pretty sure that there are also people who don't broadcast it and are still affected by that.

Most of it was "bonus" for someone with known school, but I have seen also negative judgement.

Soneca said that they dedicated themselves to applying to specific jobs not all jobs, so your comment saying it’s hard to imagine them applying to 250 jobs makes no sense.

And it’s also false that someone who gets hired a lot can accurately give advice on what got them hired unless they personally ask everyone who was involved in the hiring decision.

The employer, compensation, and social capital of the applicant may play a role as well. I think you may be too focused on proving OP wrong to ask about more factors that could be affecting their results because there are way too many things that come into play (from when an employer gets an application to the interview and offer) to generalize.

Not all 250 applications are in the same time frame. I would that the first 4 to 6 weeks I was applying just like you said. Selecting very specific companies and creating higher quality applications. Only when it seemed to be going nowhere I made it a numbers game. And that worked for me.

About your profile, I was not talking about credentials only. The fact that you are in position to hire someone tells me you are not a junior developer. The hiring market for junior vs senior is very different. If you are a senior/principal/staff/tech lead fullstack, you can choose where to work. If you happen to know something very specific, that helps too. I have 3 years of experience only with Javascript on the frontend. It is not the same market as you probably.

Hmm. I don't agree with you. My degree is chemistry from a good-not-great institution. Since getting into SE, I've progressed to technical leadership very rapidly.

I have dedicated myself to applying for jobs, but it's not that much work. It's about making sure you advertise matching strengths.

I make sure my CV only has the minimum information needed to sell this. Then only job of my CV is to get a callback. After that, it comes down to my interviewing.

I also have an extraordinarily high success rate. I've applied to 8 SE jobs in my career. 7 of those led to interviews, 4 to jobs. Of the three interviews, 2 of them I chose not to progress with (i.e. they didn't reject me, I rejected them).

Maybe my strength has been applying to realistic opportunities. My first jobs were low paying roles in non-tech companies.

Remember that your strongest selling point is your most recent experience. As a fresh graduate, your university matters the most. As soon as you have your first job, your experience here will dictate your next step.

Since my first job, I still get asked about how I transitioned from chemistry to SE, but the tone has changed. People don't expect me to justify the change, they want to hear about the similarities, differences, and strengths that have translated. It's become one of my favorite interview questions to answer now.

It seems you're on your first job in tech? You were lucky to get a position out of your first batch of applications.

>>> My first jobs were low paying roles in non-tech companies.

Strong hint that a major factor in you getting the job was that you were cheap and that the companies were struggling to fill the position. Expect the next jobs to be get exponentially harder to get as you try to find a job that pays more and companies have much higher expectations.

P.S. The poster was applying to remote jobs which are orders of magnitude more competitive to get. It's almost a miracle he even got an offer as a new graduate.

I am not a new graduate. I am 41, learned to code when I was 37. I still am in a junior position though, but not first job in tech, nor young.

The problem is you're "applying" for jobs. Those applications almost always get filtered out by terrible decision makers (AI, HR, etc). Instead of applying for jobs, you need to network for jobs.

Part of your research about the job is figuring out who in the company will be your manager and getting your resume directly to them. People are often willing to help each other make helpful introductions, so check linkedin to see who you know at that company or at least your closest contact and then contact that person and ask for help getting your resume to the right person.

This is what they're talking about when they say most people get jobs through people they know. It's more work than simply applying, and that's why you can only afford the time to do it with 4-5 jobs. Even still, it's far more effective than applying for hundreds of jobs.

Not sure why he is getting downvoted, but I agree. I did the same, without having a degree. Telling companies why you fit and why they should hire you has a huge effect, especially if you compete with people who come from a university with a degree in their pocket.

Explaining a company why you are a great fit and directly write the responsible person in HR shows, that you:

1. Did not blindly sent out hundreds of applications 2. Gathered information about what the company does and evaluate your fit in consideration of your skillset 3. Contact the right person

The 2. point is the most important one. Now, where I am in the position of hiring people, I would gladly take someone who tells me, thoughtful reasons of why we should hire him. But also don't underestimate the 3. point. Don't message the head of HR or similar persons. Instead write the people who will potentially be your lead.

But it also depends where you apply. A big corporation? A startup? Government? Something else?

The parent comment is correct regardless: Target-focus

He might be right, that a top brand college (and other stuff) will help getting past the HR filter. But I do not agree that this is the only thing.

I agree with you, that very specifically targeted and created applications will get a response rate better by at least a factor of ten.

I am often on the other side. Reading applications and deciding whom to invite to an interview. As Inteverviews take time for at least me and 3 other colleagues I filter very strongly. For one hour of interview the amount of time it takes (preparation, discussion afterwards, and so on) can take up to 1 - 1.5 person days.

As I am working for an agency this means 1.5 days me and my colleagues can't earn money for the company by working productively for our clients (even our managers work hands on on client projects at least part of their time).

So creating a well thought out application, one that is targeted and also shows the personality of the applicant helps me a lot in deciding whom to invite. Make it stand out without being obnoxious. Make it fitting for the company and the job.

An anecdote to exemplify my point:

I remember how my late father helped our neighbor's son with his application. He was a carpenter and had specialized in restoration. He wanted to apply for a job at a workshop that had been set up to do just that.

My father and he then designed (and he made) a special application folder made of wood. This had very fine intarsia work and showed very precisely what skills the neighbor's son had as a craftsman.

The cover letter and curriculum vitae were of course also well thought out and designed. No question.

An application - an interview - a job offer at one of the leading workshops for restoration work in Europe.

I agree with that 100%. I've had interviews with every company I've applied to when it's been for a specific job. I don't always get results when I speculatively apply or apply for something which I might not be the best candidate for. But if it's something I know, then it's as simple as touching up the CV, writing a personalised cover letter about my experience in industry, what I can bring to the company, what I'm interested in working on etc.

People underestimate cover letters so much. Nothing says you've done your research than 300-400 words about why you want the job. Shotgunning CVs to a billion companies is a brute force approach.

What is high quality applications supposed to mean? Most tech jobs are simply sending a resume and maybe filling a short form. There's no difference between applications.

> What is high quality applications supposed to mean? Most tech jobs are simply sending a resume and maybe filling a short form

A resume for the job. Sending the same resume every time skips an opportunity to sell yourself. It commoditises you.

Not that I've applied to all that many jobs since school (a long time ago), I'm not sure I agree unless you're applying for materially different roles. I certainly agree that a cover letter should usually be customized. However, the downside of customizing a resume for each application is that it introduces the possibility of mistakes or at least less polishing. At the least it's a tradeoff.

Is the job market so tough/picky in US (I assume it's US by default since we're on HN) or is it because the IT companies don't hire people without CS degree? I get 2-3 interview invites every day on my LikedIn account just for listed keywords (nothing special, really, generic devops stuff). And the account is explicitly marked as "not looking for a job". I leave in Eastern Europe with a lot of huge outsource outlets though, maybe that drives the demand up.

The job market is pretty unequal here. The software jobs that pay high professional salaries are indeed competitive, but there are quite a few lower-paid jobs available.

I don't know if this is the case in your country, but my impression of the European market is that the pay difference between a "mediocre" and "good" job is pretty small: say, €40k vs €50k / year for an entry-level job in one of the richer countries. In the US, a mediocre entry-level job might pay $50k / year while a top-tier one pays $150k or more.

The level of competition for the higher tier is extreme.

I've experienced both of these things: applying to many jobs and getting many rejections, as well as applying to a few focused companies and getting multiple offers. In my experience, without a prestigious education it's common for the first job search to involve lots of rejections. Your description of the process sounds similar to my second and third job searches, after I had some experience.

The first time, I didn't have a resume that clearly showed experience in the kind of work I was trying to get, so I rarely got past screening. After about a year working at a recognizable (but not especially prestigious) company, I was able to get interviews more consistently.

Second, I got a lot better at interviewing, through a relatively small amount of focused practicing. This got my interview pass rate close to 100%.

Finally, my work experience allowed me to tell credible stories about things I'd accomplished and challenges I'd faced. I also learned, through experience, more of the shibboleths that engineers (often subconsciously) use to identify members of their in-group.

It is likely that hiring practices are not updated for a remote job. With remote jobs increasing I think that writing skills will be taken into consideration.

> My advice is to practice your writing skills after you get a job, not before.

I so completely disagree. The same can be, and often is, said of actual programming skills. The result is a collection of people with insufficient skills and poor communications.

Writing influences your ability to organize thoughts into a cohesive flow which influences programming skills. It is really frustrating to work with developers who can’t do their job without some magic tool to do the job for them. These are people scared to death to write any original code or make any technical decision. It is so frustrating that the next time I go through hiring I am so tempted to use an essay requirement as a filter.

Sounds like a ton of work.

I go through recruiters both for contract and full-time positions.

Does a CS degree really matter? I suspect not. Where I work there are more programmers who did maths, physics, engineering, or something else (or nothing!) than there are programmers with CS degrees. Based on random people I've talked to it's probably like 1/4 of people have a CS degree.

I wonder if the notion of a cover letter is waning in tech recruitment. Did you write a cover letter for those 250+ positions, and if so, I wonder who read it?

When I applied for IC roles in the past I put a fair amount of thought into writing a good cover letter. Now, as a hiring manager I am normally just passed resumes by internal or external recruiters.

The article has me thinking that it might be worth requesting to read the letter, but I believe it's optional, so I worry it might narrow the funnel too much. Also I am conscious that much, if not the majority of the talent pool in my region have English as a second language, so I'm keen not to judge formal writing skills excessively, which could exclude otherwise good informal communicators and coders.

I agree. Writing abilities are valued after you have passed whatever arbitrary coding test the company requires you to take. Similar to leadership and people skills in technical roles. Companies say they want them but they are valued much lower than ability to pass their technical to a suitable degree.

> help you get hired ... a CS degree, a top-branded college, a top-branded former employer

Well, while it's true that people with all of that will have no problem finding jobs, you should remember that there aren't that many of them and employers eventually have to be flexible somewhere if they actually want to fill a position.

Subscribed! You are indeed a great writer.

How do you feel about acronyms? Do they improve or hurt communication?

From time to time, Musk will send out an e-mail to the entire company to enforce a new policy or let them know about something that's bothering him. One of the more famous e-mails arrived in May 2010 with the subject line: Acronyms Seriously Suck:

  There is a creeping tendency to use made up acronyms at SpaceX. Excessive use of made up acronyms is a significant impediment to communication and keeping communication good as we grow is incredibly important. Individually, a few acronyms here and there may not seem so bad, but if a thousand people are making these up, over time the result will be a huge glossary that we have to issue to new employees. No one can actually remember all these acronyms and people don't want to seem dumb in a meeting, so they just sit there in ignorance. This is particularly tough on new employees.

  That needs to stop immediately or I will take drastic action - I have given enough warning over the years. Unless an acronym is approved by me, it should not enter the SpaceX glossary. If there is an existing acronym that cannot reasonably be justified, it should be eliminated, as I have requested in the past.

  For example, there should be not "HTS" [horizontal test stand] or "VTS" [vertical test stand] designations for test stands. Those are particularly dumb, as they contain unnecessary words. A "stand" at our test site is obviously a test stand. VTS-3 is four syllables compared with "Tripod", which is two, so the bloody acronym version actually takes longer to say than the name!

  The key test for an acronym is to ask whether it helps or hurts communication. An acronym that most engineers outside of SpaceX already know, such as GUI, is fine to use. It is also ok to make up a few acronyms/contractions every now and again, assuming I have approved them, e.g. MVac and M9 instead of Merlin 1C-Vacuum or Merlin 1C-Sea Level, but those need to be kept to a minimum.

They are detrimental to understanding. I hate them with a passion. I see people using acronyms without explaining them in context, which makes it even more difficult to understand what's written.

Some terms are jargon and are probably ubiquitous in the field, but unless I'm reading a text written for the professionals working in that field, I'd much rather see it explained.

> unless I'm reading a text written for the professionals working in that field

Most internal communication is made for professionals working in that field.

Acronyms have a habit of mutating. Groups using industry-standard acronyms tend to, in my experience, create their own acronyms faster than groups using jargon. It’s too easy to add another letter.

Spelling out acronyms in written communication while dropping them when spoken is a good middle ground. If an acronym-compatible phrase is used more than twice, it can be defined at use and then compressed. Though I keep track of how many acronyms I’m forcing the reader to juggle at a time.

What got me, was explaining SMTP to engineers not familiar with the acronym, who used SNMP, and a guy walked in asking it if was SNTP.

Everyone started saying the above as initialisms, or long form, at that point.

So does he propose that people always spell out the full name of all components? To me it comes across as selfish, he only wants people to use acronyms that he personally knows, even when they're not talking to him.

For instance I work on aircraft. Basically every component has its acronym. Yes, it's hard when you're new to the area. But nobody is going to take the time to write or say "Integrated Drive Generator", "Power Control Unit", or "Over-Pressure Shut-Off Valve" every time. Everyone spends their day referring to components.

Most documents have a lexicon however, and there's a web interface to search them.

> So does he propose that people always spell out the full name of all components? To me it comes across as selfish, he only wants people to use acronyms that he personally knows, even when they're not talking to him.

I'm curious what makes you attribute that selfish motivation to him? I thought he was pretty clear in saying that it's particularly tough for new employees:

"Individually, a few acronyms here and there may not seem so bad, but if a thousand people are making these up, over time the result will be a huge glossary that we have to issue to new employees. No one can actually remember all these acronyms and people don't want to seem dumb in a meeting, so they just sit there in ignorance. This is particularly tough on new employees."

"No one can actually remember all these acronyms and people don't want to seem dumb in a meeting, so they just sit there in ignorance. This is particularly tough on [me]."

Selfishness is a bit too strong a word, but I'd bet he wrote this after a particularly acronym-heavy meeting where he was annoyed at feeling dumb for not following the conversation. So it's a good policy directive that's also self-serving.

Also this is a difficulty inherent in micromanaging large organizations, something Musk and Jobs are famous for. Leaders who trust their delegates don't need to understand jargon as much as manager-speak.

Not only are you ascribing ill motives without justification, you're doing it based on pure supposition. The whole story exists only in your head. Snap out of it.

It's not as if there aren't real reasons to think Musk is an ass. Wait for one of those to come up before you start the hate train.

You'll say or write "Over-Pressure Shut-Off Vale" once, and then context now makes it possible to say "valve" for instances after. Unless you're discussing several valves at one, why does one need to use whatever acronym (with more syllables than the word 'valve')?

I agree that it's unclear from the E-mail whether he actually means that these things should be fully spelled out or something else. And this is the problem I have with the E-mail: It's unclear. The details really matter when the edict comes from the CEO, and there will be senior people in the company that make and enforce huge, sweeping changes to the business that hang on the exact wording coming from the CEO.

I've worked at a company where the CEO (and sometimes SVP leadership too) was basically treated as a God-King figure. I mean that in a literal sense: People would walk behind him, writing down every word he said in the hallways and every meeting with him had multiple note takers. Kind of like those guys with the notebooks following Kim Jong Un around writing every word down. If a senior exec said something that wasn't clear or didn't make sense YOU DID IT ANYWAY because it came from [Person's Name]. In E-mail forwards, the words of top leadership would be quoted in a different color, and then scrutinized and interpreted until everyone thought they understood every little nuance of what was said.

I don't know if SpaceX and Tesla are like that but I have my suspicions :). When an E-mail like that comes from Elon, I'm positive there are dozens of people who make it their full-time job for the next few weeks to carry out to the letter exactly what he said. So if it's unclear or incomplete, there's a big problem.

Judging by that, Elon Musk is a seriously smart man. I've worked at places with that tendency, and he's described the issue well.

Used too generously, acronyms make it impossible to gauge the complexity of the thing they're describing. Say that my system compromises a CCP, a SBS, and a RCS. That could mean "an afternoon and $1000" to "we need to build an entire supply chain". How do I begin to budget that, financially or mentally, based on three letters? Cynically, is that difficulty the point?

If your budgeting process relies critically on the number of characters being a good proxy for the value of a service, I don’t think acronyms are the problem. :)

It isn't like he is the only person to identify this issue.

I think the fact that he wants to personally approve things is an indication that he might not be as smart, since it implies limited trust.

He does not trust the team on this issue, because they have acted contrary to his previous instructions.

If you think that email is impressive, wait until you hear about the other shit this guy’s accomplished

TLAs (Three letter acronyms) are indeed the worst and I try to avoid using any custom ones as well. I worked with a company where the code base was all organized into folders like "MCM" and "PCM" for every module... Of course this list of acronyms was nowhere to be found. It was just one example of many of how big a mess their organization was.

What's worse is multiple unrelated definitions for the same acronym. I worked for an international industrial manufacturer, and their lexicon of acronyms and abbreviations contained many entries with more than one definition.

i completely agree with that sentiment. even if the audience is familiar, acronyms and abbreviations put a cost on the listener/reader to "unzip" them. in code, in meetings, in communication generally, the priority should be on comprehensibility to the reader/listener, not the convenience of the writer/speaker. we read code at least 10x more than we write it. in a meeting, one person speaks and many people listen.

If it's not an industry standard acronym or initialism, don't use it. Internal-specific acronyms and initialisms are a litmus test for smart stupid people: smart enough to build the systems, too stupid to realize no one will understand what they're talking about. See also: enterprise-level companies.

It's not the hill I'm going to die on, but I've referred to this email a lot: I'd love for people to stop using acronyms.

A somewhat related pet peeve: generic "descriptive" names of projects, which often end up being acronymised eventually too. They're either too generic to be informative, or tend to become inaccurate as requirements change. Additionally, by some kind of regression to the mean they all start to look alike.

If there's not a logical short name that applies, then just think of some random name that you think sounds funny, or fits some category that you use for all your products (a coworker of mine suggested French cheeses). Still give as little information about what they are as the "generic" names, but at least they're easily distinguishable and easy to pronounce.

(This, too, is not a hill I'll die on, but I'd love to wave a magic wand that would convince everyone of this.)

Anyone know the article that was about how with acronyms it slows the reading comprehension for the whole team whereas it saves you a few seconds to type it out? I really liked it.

Eng manager at a team that was remote pre-pandemic and I will 100% confirm this is critical to getting things done.

I'll add on that it is tough to find someone who is a great writer and a great engineer early on in their careers. You just haven't had a lot of time to practice both. When you're looking for junior candidates, they will often fall into two camps: they'll write too much, or they'll write too little.

If you're the candidate: err on the side of writing too much.

If you're the manager: writing too much is considerably easier to fix than writing too little.

For a junior candidate, which do you think is easier to train? The engineering skills, or the writing skills? At first glance, I think writing... But as I think more I personally think the writing / communication skills are more challenging to teach, especially to engineers because it is more of an "art" than a fixed talent.

I find they can sort of be taught in similar ways, as there are a lot of things about good, clear coding that translate to/from clear writing. At the risk of self-promoting, I wrote a comparison here a long time ago: https://www.ericsuh.com/blog/posts/2016/01/writing-code.html

Also been a hiring manager but not OP. I would honestly say they are more related than you think. If you can't fit a narrative to your architecture or what you're doing, it will be hard to understand. It's important to know the "story" of what you are building: where is the data going? Who is the user?

If you come up with an architecture that is complicated, just keep working on it and editing, like writing, to make it make more sense. You need good editors / code reviewers on both sides, and they will make you a better reader and writer.

If you struggle with writing skills (not all people are good at some particular language) I find being able to make a good picture is even more essential.

I think one of the things to state is that it's not about writing something that sounds important. It's about writing something that people can understand. Don't get too stuck in the "art" part of it. At least for me, simplicity is beauty.

Another way to try this is to sit down with someone and say "explain what this does" and then see what they come up with. Some people are really good at talking, but not writing. But being able to explain is almost as good, and sometimes more necessary than writing.

I hired two folks locally, then moved to an island thousands of miles away, then hired an ML and data science team of 3 more folks. My team also has to work in a mixed group where a few folks were hired by another, very senior manager. He knows how to hire. The guy is a legend.

Those hires I made from far away were much more carefully thought out and turned out to be much stronger. Equivalent to the ones the senior guy was hiring, if not stronger. I think it's because I couldn't delude myself into thinking "They're fine, I don't need to waste time interviewing. I can just groom them, get them to where they need to be." I had to, absolutely, consider these people as full time remote workers, several time zones away. They had to be crack engineers and crack communicators. And I had to enforce those standards from the get go.

Watching everyone else go through the shift to remote work was fascinating. The pandemic caused us to change nothing.

GP's post is written with an implicit assumption that the junior candidate's engineering skills are "good enough", so that should absolutely be the focus. But I agree that writing is probably easier to train.

Considering the number of people who have good engineering skills vs good writing skills (I think very few people are good at writing), I think writing is more difficult.

Most people are not used to paring their writing down and getting rid of the fluff while also being articulate.

It depends. A person who doesn’t want to learn doesn’t pick up either, in my experience. On the other hand, having a style guide helps in coding, and it helps everyone express ideas using a uniform style and idiom, which enables a lot of implicit communication via the code itself. Training people would entail pointing to the style guide.

A big caveat is that you need a team or larger organization where this has already been set up, and that the hires need to be the kind of people who can take direction. It will fail miserably if even one of the above is untrue.

Engineering, no question. The number of people I've met that can code like the blazes but can neither clearly communicate their ideas nor persuade people with the written word is kind of astounding. Many of them can be persuasive in person by relying on their passion and high rate of speech to carry them through, a strategy which does not work at all for the written word.

Engineering has the clear benefit of things either working or not, with the reasons why it failed being entirely explainable even if it's not obvious at the time. Documentation is fundamentally a human to human operation, which means that all of the signals are messy and unclear. Writing is harder than speaking too, because you can't adjust course mid-stream if it's clear that your reader is confused or unmoved. Writing demands that you not only get your thoughts organized effectively, but that you reliably predict how people will read it and compensate appropriately. This is not a skill trivially learned.

They are both easy to train if you have trainers who are thinking about it as craft. That being said, if you are working in the technology field, you are more likely to work with individuals who actively learned engineering but passively learned writing.

Alternative example: early on in my career, I was a software developer for a PR agency and then a news organization after that. At these organizations, solid writing and editing is drilled just as much as good code review or test coverage is taught in engineering organizations. Their lunch-and-learn sessions aren't about new JavaScript frameworks; they analyze how a particular piece of text was created and find ways to improve it.

My single largest "level-up" in this domain was when I started reading more on character creation in fiction. It forced me to think about how I'm telling stories, which then meant I had to think about how I constructed paragraphs, which then... you get the idea. Some great books I read:

- Robert McKee's "Story," which analyzes how great screenwriting is constructed. You will view action movies in a totally different way after this.

- Corbett's "The Art of Character," which focuses on how characters are created

- Roman/Raphaelson's business writing book, which was recommended by PR legend David Ogilvy

- the U.S. Joint Chiefs of Staff manuals (https://www.jcs.mil/Library/CJCS-Manuals/). These are rigidly structured texts with strange language that forced me to consider writing for a different audience than I normally would (military officers versus tech engineers)

The longer I work in tech, the less silly it seems to have "English minor" on my resume.

These comments are making me feel a lot better about having "Philosophy major" on my resume.

No that was a waste ^_^

One of the things that was becoming a big thing when I left my last big company employer, was non-standard backgrounds. When you're looking for diversity a product manager or developer that has had a previous job as a lawyer (or whatever) can be a really useful asset.

They see things a little bit different from their team. Call out risks that wouldn't otherwise have been addressed.

The founder of Slack was a philosophy major, you're in good company.

I joined a new company recently (during pandemic; July). The onboarding was not so smooth. I was constantly following up here and there to get things done (e.g access to tools with IT), more importantly to get to the part with whom do I need to follow up and how to follow up; figuring this out was another follow up.

I created an onboarding guide last week (for my team) which was a very small thing for me (created a document on confluence in an hour). But the amount of response I got was overwhelming (IMO bit too much compared to how i expected to be yet-another-document).

I've been the "over the moon" guy when someone comes aboard who wants to improve stuff. Sometimes when you're in the trenches competent help arriving can be a godsend. Not saying this is your situation, but people may just be excited.

>Sometimes when you're in the trenches competent help arriving can be a godsend.

So much this.

Sadly this sort of thing rarely matters when performance review time comes. I have never received any significant benefit career wise or money wise from doing this, despite this kind of stuff making a huge difference for the new joinee.

That's okay, I think. Not like it's a harder job than you'd otherwise be spending your time on.

Sometimes its just about the mindshare. The HR person chatting with the VP: "You know that new girl, what's her name, yeah Julie, she setup a nice onboarding guide, yeah I liked it, very useful..."; casual stuff like that adds the layers of impressions that construct how everyone sees you. And I have observed those impressions to be more lasting and impactful than your last code review.

Meh... Ultimately it has to result in something meaningful; without that, it's just thankless work. Many places (particularly growing companies) have managers who simply do not know how to evaluate technical work (which should be the biggest determinant of monetary or career development rewards). SV has very good technical people (i.e., the foot soldiers are very motivated and above-average people), but the managers are very mediocre at best, way below average or actively malicious at worst (compared to many other industries). It's a curious dichotomy, and I often wonder why it's the case. One reason, that I have seen many times, is that during times of hypergrowth, whoever is just there gets slotted into managerial positions with scarcely any thought given to their managerial ability or skills. This happens less in larger companies, but there, there is a lot of infighting and politics that thwarts good management, not actual incompetence.

I generally agree with you and that kind of solidifies my point. Those mediocre managers won't be as impressed by the milliseconds you shaved off in your clever commit compared to the shiny CRUD front-end or nice checklist or anything else that they can actually understand and relate to. And they are the ones in charge of the comp.

Sounds like maybe you need to review your choice of employer.

Definitely. One thing I have realised over many years in this industry is that it rarely pays to stay longer than two years at a given place. That's usually enough time to figure out whether you'll be (a) making more money or (b) climbing the career ladder at the company. The answer is usually no, and for this reason, continually interviewing and jumping on the latest shiny toy is the best strategy long-term.

> To find great remote employees, prioritize candidates with strong writing skills

I strongly agree! Looks like many other commenters agree too.

how do I find companies that are hiring and agree with this statement?

I've had a hard time finding those companies. I've had a slew of interviews recently, and none of them asked about my extensive online writing. None of them seemed to have clicked through to my website.

Are any of you on teams that really celebrate good writing, and would weigh my blog [0] at least as much as a technical challenge?

[0] https://josh.works/blog

Amazon celebrates good writing.

Stripe

I interviewed with them, after very affirming conversations with a few different people in the organization.

My writing/async communication skills didn't come up. _They did not ask_, which means my writing skills are illegible to the organization.

I bombed the "live algorithmic coding challenge", which is a re-implementation of the Trier Social Stress Test, and indeed induced substantial anxiety on my behalf, _because I so wanted to work at Stripe_. [0]

I was so dispirited I've not done another technical interview since.

[0] https://en.m.wikipedia.org/wiki/Trier_social_stress_test

Off-topic:

I like the look of your blog. Is your theme a heavily customized instance of Jekyll?

Thanks ayewo!

It is indeed Jekyll. The Poole theme. I've written a little about how to set up something similar here: https://josh.works/build-a-personal-site-with-jekyll

It's not super customized, but I've done a lot of work over the years to just make it work well for me.

Jekyll is a super cool tool.

It's not really about 'writing skills', it's 'communication skills'.

'Writing' usually implies the ability to be creatively articulate, for example, like writing a long form news article. People can be great writers and poor communicators.

For coherent team communications you even don't need proper grammar - what you need the ability to be clear, succinct, appropriate, provide context, timely etc..

It's not about 'writing' so much as it is 'social' and 'structured' communicating.

People with strong sensibility for others in a social context will know what needs to be said and not.

For example, some people, when reading something ambiguous in an e-mail, will take it the wrong way. Some will not. Some will know when not to write something and when to.

Again, this is not a 'writing skill' per sey more like communication.

"you need the ability to be clear, succinct, appropriate, timely etc.."

These are the basics of technical writing.

But to be fair, technical writers are also called technical communicators.

That's true - but the article is not about technical writing, nor is technical writing the key to smooth communication for remote workers. (Obviously it might help though.)

Many great writers are far too verbose and indirect to be great examples of how to succinctly communicate.

Again, the term 'writing' is totally misapplied.

Most people have sufficient writing skills, the issue is content which is where most of us are lacking.

100% this. grammar, punctuation and all the like are nice to haves. (and can be good social signaling) but the real skill is the ability to communicate complex ideas completely in a way that is easy for others to understand.

I hate long form writing with a passion. I barely got my decree because I hated writing that trite crap they call a thesis so much.

On the other hand I consider myself a good communicator, I can type a succinct email with a clear structure, I can create a damn fine Wiki page with indexes and all and I also communicate pretty well over text-based chats (started with IRC in the 90's).

Still, I couldn't write a 10 page report to save my life (still have one due for a course, been putting it off for 6 months now...)

"I hate long form writing with a passion. I barely got my decree" - HN Classic.

Yes, I think there is such a thing as 'Engineering Speak' - organizing thoughts in structured and coherent way - it requires thinking a little bit differently though. I'm not impressed by most API documentation, it's just so terrible it makes me wonder about the people in tech.

This isn't my experience, I find that people who are quick to initiate communication do really well. Doesn't matter too much about the writing (maybe some people are much worse than us at writing) as we simply voice chat if things weren't clear

This is how it is at my company (100% remote).

Having Zoom on stand-by is key for us. Anytime things get complicated, we just hop on a Zoom call.

All of us can communicated well in writing, but I don't know of anyone on my team who prefers it. For me, in particular, I'm an incredibly slow writer, so it's just painful to write too much.

It’s big where I work, too - I’m very into the little slack (there might be a teams one?) plug-in, where you can just message people “/zoom” and it instantly makes a meeting with whoever’s in the chat.

It makes little 5-minute meetings for debugging or clarification super painless, which means we do more of them, which is huge for the team being on the same page.

I doubt there's an equivalent Teams plugin because the standard solution for that problem in Teams is to click the little telephone icon inside the chat and you're on a call. Add or subtract video and screen sharing as desired. Continue to paste things (documents, links, whatever) inside the call's chat and it's recorded along with the chat/call.

I have a lot of complaints about Teams, but there's something to be said for an integrated solution.

Oh, interesting, that sounds pretty cool. I haven’t used Teams, but it does seem like the big sell is how insanely tied into everything else Microsoft it is.

This doesn’t scale well, every time someone needs to understand, or onboards, or wants to audit a process then they have to go through that. It’s really hard to improve on something not documented.

I’m with a team that has scaled great with this approach and is now over 1,000 employees. Do you have any concrete research or even an anecdote about your statement?

I don't see how it doesn't. Our approach is literally no different than most in person companies.

Instead of walking over to somebody's desk, we get on a video call. Sure, there are still things that require written communication - but day-to-day quick talk is no different.

We still Slack, we still write PR feedback, we still document processes and policies, etc.

Voice chats don't leave a record if they're not followed up by writing up the content of the call (which rarely happens). Writing first protects against poor discipline and record keeping. I encourage people to write everything up. Nothing happens without a ticket on the kanban even if the solution has been discussed on a call. I can't count the number of times this has saved hours or even days of work further down the road.

This breaks down quickly if you are across timezones like many remote teams. Async communication becomes the most common way of distilling info. It can't completely replace zoom/slack but it is critical for transparency and team cohesion.

Note, this is also true for great non-remote employees.

Highly developed writing skills are a superpower everywhere.

Yes, and it's arguably why we're all here. HN and YC developed out of pg's writing.

There are other examples too. StackOverflow comes to mind.

And I think it supports Dijkstra's argument [1]: "Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer."

https://twitter.com/CodeWisdom/status/1318597850411008006

Not sure why it's "one's native tongue" and not "same language as the people you work with", as many of us hardly use our native language once we move away from the country we were born in, especially when talking about programming.

It's especially surprising given Dijkstra wasn't a native English speaker.

Because mastering the native tongue shows the programmer was able to learn a lot of important basics at a very young age. Whereas the inability to master the native tongue shows a lack of education.

> able to learn a lot of important basics at a very young age

Ok, and why is that important? Could be a ton of reasons why people are lagging behind when they are younger but be able to catch up when they are adults. Judging people based on how you think they might have been when they were younger feels... Not fair. Judge them based on their current knowledge and person instead.

> inability to master the native tongue shows a lack of education

I think you're reading too much into it. Education has nothing to do with native tongue. People forget language.

I myself speak my native tongue a lot worse now when I lived outside the country I was born in a couple of years. Does this mean I lack education? No! I do lack any education, but that's not the reason my native tongue is getting worse every passing year.

One can master owns native language being an adult, why not?

I am Russian and I enjoy translating wonderfully sounding English concepts to Russian. As you can understand, it takes a little bit of mastery in both languages. The upside I get is that these wonderfully sounding language concepts often lose all their charm when translated into Russian. They turn into a pumpkin. This way I can better focus on what is essential.

As I am here on the matter of focusing on essential things, please look at "Being Popular" essay by Paul Graham: http://www.paulgraham.com/popular.html

Let me quote: "They're perfectly justified: the majority of hot new whatevers do turn out to be a waste of time, and eventually go away. By delaying learning VRML, I avoided having to learn it at all."

Another upside of translating things is that you often cannot apply same questions to English and Russian terms. There are questions applicable only to English term and there are questions for Russian term which are not applicable to English one. You have to do analysis anew, finding new sides of the problem, which either show you the problem's true underwater size or help you solve it.

Because learning a formal language is akin to learning a programming language.

You misunderstood education as formal education. Just by exploring as a child, and living, you learn your native language. Before a child goes to school, they already learn by playing. That, too, is education, and sadly some children are deprived from that or their lack of intelligence already shows. Our oldest (not even 3), for example, is well ahead language-wise, whereas motor skills she's a tad behind.

If you don't practice something, the skill tend to get lost, yes. However, something you learned at a very young age defines you, and is (for good or bad) difficult to unlearn. Only at an old age or due to memory/brain related disease does it get lost.

When I went on vacation to USA for 3 months, twice, I had to speak English. I didn't speak Dutch at all. When I got back, I had to adapt to Dutch way of living and Dutch language, but it went rather quick. I have no problem 'thinking' in English because I learned this at a very young age; whereas French just never clicked with me.

These people who end up with expat parents and the like are an exception. Exceptions like these prove the rule.

This might be splitting hairs a little bit, but I wonder if he didn't mean native tongue so literally. Perhaps native tongue simply means "the language you are most comfortable with" -- along the same lines of "use whatever tool you like, as long as you can use it /well/"

Considering that Dijkstra didn't consistently work in his native tongue (this is quoted from EWD498 which was written in English), this seems to be very much intentional.

I guess he meant: If you know how to formulate some concept efficiently in your native tongue, you can work out how to translate it into another [programming or human] language.

> If you know how to formulate some concept efficiently in your native tongue, you can work out how to translate it into another [programming or human] language

Even with that it seems strange, as I don't think I'm alone with having a easier time formulating some concepts (especially programming) in my now main language, while sometimes I can barely make myself understood when speaking my mother tongue.

The view yowlingcat offers in another sibling comment makes more sense to me, to not parse Dijkstras comment as literally as I did.

It's also possible that Dijkstra was wrong/didn't consider this case.

At this point in his career, he was still teaching in Dutch at a Dutch University, so likely had a different experience of being bilingual than you do.

Agree, but this does skew in favor of people who's first language is English, which shouldn't really be an indicator of engineering quality.

I don’t think it skews towards English speakers in particular: it actually skews towards strong communicators in the preferred communication language of the team. A great engineer who can’t communicate effectively with the team due to a language barrier isn’t a very useful team member. It’s tempting to think that technical ability should be the sole measure of someone’s worth as a engineer but that simply not true outside of working in a vacuum.

But English skill is a major component of being a strong communicator in English.

Native English speakers who practice speaking English every minute of their lives would be at a huge advantage.

Not necessarily. English as a second language speakers who may have a accent or take longer to formulate their responses are at a disadvantage in person. I've met many who have expansive vocabularies and impeccable grammar, and I am one myself, but it's hard for us to get over the first impression of the accent and to formulate our responses with natural timing.

For us writing sets a level playing field.

> A great engineer who can’t communicate effectively with the team due to a language barrier isn’t a very useful team member.

This is a much lesser bar than "strong English writing skills" that the article say you should require. "strong English writing skills" will force you to overlook most immigrants, but most of the great engineers in USA are immigrants so you'd handicap yourself by doing that.

You'd handicap yourself much worse by hiring people that you can't effectively communicate with.

You're not necessarily hiring people you're working with, even if you're hiring for your local office.

Say your company has an office in Germany, well you're going to communicate with colleagues whose native language is German. Or say your company decides to select a supplier from Japan, you have to communicate with them. You can't say they shouldn't have been hired in the first place.

That’s a completely different topic from hiring immigrants with insufficient English skills.

If they can't even communicate in person because they aren't familiar with English, they shouldn't even be considering a remote job where they have to write and overcommunicate in English all the time.

If anything I would think this is the opposite. Written communication above verbal/face-to-face gives the non-native speaker greater time to formulate their correspondence, look things up if necessary, and use translation tools for help. On the flip side they may get less from language-agnostic channels such as body language, but I think that is a small loss compared to the gains.

An engineer that can't communicate properly is a poor engineer, regardless of their coding ability. I've worked with too many great coders who were terrible at communicating. This includes engineers who were fluent at English. Communication is an extremely important skill.

This is a reality of life. If I moved to Nigeria and could barely speak the language, should I expect people to accommodate my poor communication skills? Or would I get passed over for a local who is possibly sub par in terms of coding quality but is more effective in all parts of their job?

> If I moved to Nigeria and could barely speak the language

English?

lol I randomly picked the worst example in the world. But you know what I meant, some country that didn't have English as an popular language. You know, like India! (just kidding!)

I just learned right now that Nigeria's official language is English!

Not writing well doesn't mean that you don't communicate well. Plenty of engineers can communicate just fine in English, just sloppily without perfect grammar.

You never work with people working in different countries? In the same company, or just some partners (suppliers, customers…).

Not really, unless you assume that a great writer is someone with perfect grammar, as opposed to someone who is good at communicating their ideas in text (and image) form.

In fact you should probably deliberately include some grammatical errors and omissions so that you can flush out the people whom are unable to understand which things matter and which don't.

First language is Danish btw.

IDK for me as a non-native english speaker, it's harder to discern non-native english from native english speakers when inspecting written communication as it is when listening to spoken communication. I assume it's the same for native english speakers, but please say if you disagree.

Also, I think it's easier for non-native folks to both comprehend others and communicate as they can look up stuff or use google translate.

I'm a native English speaker who works with mostly non-native English speakers. And in my experience written English is much closer in similarity(and basically indistinguishable) to a native speaker's written communication than spoken english is to a native speaker's.

I think the reason is as someone else in the thread said, it gives you more time to formulate your thoughts and there is tooling to support cleaning up your thoughts (spellcheck, more time to look up words, translation tools, etc.)

I think this is also true for the language I'm trying to learn right now, Ukrainian. When I try to speak it the problem is that I don't have enough time to think about what words I'm looking for. I don't have time to think about my grammar/declensions(very hard for me as an English speaker). But when I interact with Ukrainian speakers online in a written format I can actually formulate sentences that don't sound like I'm 5 years old. Instead I get to sound like I'm maybe 8 years old :)

> this does skew in favor of people who's first language is English

You mean the people who don't know the difference between your and you're ?

“If you’re a strong writer and you can consume information in written formats really well, you’ll probably have an easier time transitioning to a remote team than someone who prefers face-to-face communication.”

Inspiring young employees to read and become more articulate is something the best managers and organizations do. Few people enter the workforce being ultra-literate. Who writes love letters, anymore? Who bothers to inspire, or to be inspired? A scarce currency is only more precious.

Programming ability is related more to language ability than to math:

https://www.nature.com/articles/s41598-020-60661-8

This study used a 10 session beginner Python course, and was graded almost entirely with multiple choice quizzes rather than actual problem solving. Seems like they ended up testing participants' ability to quickly memorise syntax and language constructs rather than more general programming skills.

I have seen blog posts by middle/high school comp sci teachers saying that language skills are a greater predictor of success in their classes than maths, but it seems like this type of student is less likely to pursue a career in programming.

It's complicated, right? Effective writing and reading comprehension are necessary to produce and parse code of any sort. Math is necessary to construct and analyze the algorithms that are implemented or described in the code.

You can be a good coder (writing) but not a great engineer (math). Likewise the converse is also true.

I find that it isn't just the act of communication or writing that's important -- it's the person's ability to step outside their own bubble of code, jargon, details, and synthesize (whether up or down) to give someone else the essence of what they need to know about an issue or problem in that communication or writing. To be able to offer some decision, plan some work, take some conclusion from what has been done so far.

I encounter too many developers who simply start talking about the detailed issue at hand as if I've been working on it sitting aside them for the last week. Well, if that were the case, I would not need to talk to you about it.

When talking to someone not directly involved in your work, the point is that some level of abstraction is needed, and probably some decision is the reason for talking. People need synthesis and summary of the issues at hand, and not recitation at the details level.

This takes extra work and preparation, or at least mental organization -- to summarize for someone else what they need to take away from your details. It takes active effort to think about what your work or result or roadblock means for others, present options on what they should do, and you can tell easily when someone has thought through that next step, rather than just regurgitating what they've been working on all week.

That is a highly valuable skill and you know it when you encounter it.

I recommend hiring at least one person who actually knows how to get the job done.

I also recommend making sure you don't interrupt them with senseless meetings, spam them with a doom scrolling e-mail stream, or force them to be in useless chat rooms that keep interrupting their train of thought.

> I recommend hiring at least one person who actually knows how to get the job done.

I totally agree.

Having "strong writing skills" is a plus -- but it is way less important than being qualified to the job.

Strong writing skills are part of being qualified for any remote job.

My two cents:

1. English is not my first language, and Grammarly helps a lot. Small things like correct punctuation and articles make the text much easier to read for native speakers.

2. I try to make communication "modular". There is tension between over-communicating (giving full context) and under-communicating (leaving out details). The first sentence of each paragraph summarizes the point. If you know that stuff already, you can skip. If you are re-reading, you can quickly get up to speed by skimming first sentences. If you are surprised by the first sentence, read the paragraph.

3. I often use numbers so that my recipient can answer or discuss just one point from my text. That usually starts with "Ad2". You can then "split" the discussion by numbering annotations "Ad2.1". If the conversation gets too long and convoluted, we need to add a summary of what we've written. Both Slack and email have flat conversation structure (Slack threads can go one level deep). That flat structure is usually a good thing for someone following the discussion.

It is very natural, and most people reply in the same way instinctively.

1. Writing is FOR THE READER and your effort reflects this point.

2. This style is very effective across non-native languages and helps facilitate future communications by organizing back-and-forth discussions with topic numbers

3. Focused topics provide transition space in the reader's mind for internal language translation and context framing for improved comprehension. Each topic sits in its own compartment of the Bento Box for consumption and consideration

I emailed Ian Tien to ask him, given the emphasis on written communication, if his company does anything to support dyslexic employees.

Any response yet?

Sadly not. I will post a comment below if I get one.

I’m appreciative that at least one other commenter had this thought in mind.

I find this trope quite boring; you know who is good, people who can code, people with high IQs and people with the right experience. Being able to write is probably about the same as people who can design as well as code. Sure it’ll be useful but hiring experts in these areas should be your ultimate goal. No startup was killed ever by a bad prose style.

So after reading the article (ha imagine) it is are NOT about writing ability, they talk about the company prioritising documentation and communication. Documentation, sure, but communication is another truism I don’t have much time for; we’ve all worked with extremely productive clever programmers who don’t communicate well, if you’re a founder getting the best from each persons character might be better than just hiring only extroverts.

> No startup was killed ever by a bad prose style.

With the uptick in startups trying to be passive-aggressive, witty, and provocative in their social media posts, I would disagree. Your product doesn't have to be edgy. If it is, it tells me that your product probably has no merit in and of itself.

I'm afraid that hiring for writing skills will reduce your pool of hires by 99%.

I expect it would be more fruitful to create a workflow around a combination of video calls and writing that would take the strong sides of each to buttress the weaknesses of the other.

As far as writing is concerned my moment of enlightenment came when I read "Nobody wants to read your sh*t". The book is not about any particular "effective writing" skills, etc. it is about writing in such a way that someone will actually read what was written.

The author applied that to copy-writing (he was working in the ads business), but this applies so well to everyday emails exchange or writing documentation.

Making someone to read and comprahend something is not an easy task since a lot of people are getting used to (or maybe already got used to) communication using 200 chars tweets or a memes.

> To find great remote employees, prioritize candidates with strong writing skills

This makes some sense.

"Strong writing skills" is not a skill IT people are good at.

Pre C19 I argued to stop putting this in job ads since no one could come up with examples where it mattered. For our best workers they didn't have it, we were just cargo culting the job ads.

Is this post-coronavirus remote working excitement just the dopamine hit of thinking what skipping a commute is like or a well thought out plan around long term job prospects and long term mental health?

Conversely, I think employers should actively promote writing and communications training programs to send staff to.

One of the people I previously had the pleasure of working next to was absolutely brilliant in his field (malware reversing, broadly), but watching his presentations was an awkward experience. He just could not communicate his work effectively, either in a written or spoken medium and was someone who would have benefited immensely from a writing and presentation workshop.

Given how many of my fellow students in college studying math/science were convinced that the required english lit/composition course was a waste of time, and disdained the liberal arts generally, this is a problem that arises early in education somehow.

How did we end up here? https://www.youtube.com/watch?v=oxjT7veKi9c

Honestly, I feel like the maths and science lecturers are the source for reinforcing the paradigm that their job is simply to teach maths and science, not effective communications of the topics. Many of them likely feel the same way as their students.

At the bare minimum, they should explicitly and repeatedly mention in their courses the importance of taking writing classes, if not have an entire part of their own curricula devoted to these topics.

The number of educators with terrible communications skills is a real problem, and I'm not talking about language/cultural differences, either. In higher education, with the focus on research and publish-or-perish over teaching, there are many disincentives to effective communication and writing is constrained to the academic style.

I'd say effective communication is more important than strong writing skills.

I used to work with someone that could write 300 pages to communicate something that could have been communicated with a single sentence.

I used to work with someone who wold span the team channel for hours to communicate something that he could take them time to properly craft a complete message.

Prolixity and noise can happen on both written and spoken forms. Getting people who can balance all the ins and outs of communication is the key.

Is strong writing not also effective by definition?

So Basecamp wrote it years ago and now every company will make its own pice of PR-come-to-work-with-us crap out of this? You don’t have any personal thought on top of that?

My thoughts exactly.

It's not an issue for me, but how does this gel with discrimination laws? If the reason a candidate is a worse communicator is a protected characteristic, you can't (legally) reject them on that basis.

(Not that I necessarily think that's net good, but it is the case.)

I'm not so clear on where you stand if you just see poor communication and really honestly have no idea of the reason for it, they don't say and it doesn't give itself away.

Literacy skill is not a protected class.

You can reject candidates for performance-related reasons. You cannot reject a candidate for status within a protected class. Structured patterns suggesting protected-class discrimination may raise issues, though typically require convincing evidence. Offsetting considerations (say, recruiting or mentoring programmes) might be considered mitigating.

Literacy skill is not a protected class.

Literacy skill itself is not, but be VERY careful with that. Learning disabilities are still disabilities, and those 100% are protected.

https://www.understood.org/en/community-events/blogs/in-the-...

Interesting casse. Not precedent-setting as I read it.

The EEOC does not establish precedent, it is a federal agency, not a court, so correct-it is not "prcedent" setting. But it is still relevant and worth caution, care and consideration when assessing potential hires based on 'literacy'. Non-Compliance is costly.

And with that, I conclude my alliterative TED Talk on best practices and compliance in hiring.

In a remote setting, over communicating is key.

Some signs that the candidate is good in communicating:

1. They number each point. This helps person replying to address each point separately.

2. When hiring, a candidate is asking a lot of questions. An email with a proactive communication is a win over another candidate that fails to communicate, is silent, or inability to communicate over writing.

This should allow for the responder, manager, whoever, to respond back and also synthesize whether follow up call is required. Writing is one channel for communication and can be efficient if done right.

I also found that non-english native speakers tend to write quite well. Superfluous words are omitted and usually the "essence" of the idea is straight to the point which makes it easy to clarify any ambiguity, if any. Whereas you might expect to literally take on face value what was written by a native speaker without hesitation.

> Some signs that the candidate is good in communicating:

> 1. They number each point. This helps person replying to address each point separately.

I disagree.

For me the most important sign is that:

* They use bullets instead of numbers.

Other than that, I fully agree.

It's not just writing, good communication skills in general, and this applies to non-remote, too. This is just common sense. Don't hire someone that can't or won't communicate well with you and your team. Writing is a good start, but I think a lot of people are using audio and video calls for work.

I'm an IC who has worked remote for 18 of the last 20 years. Effective communication is critical.

I tell my teenage son that my most important class in high school was actually English. Being able to write accurately, concisely, and persuasively is critically important, even when you're in a technical role.

I'd note that "strong writing skills" here means being able to communicate information fluently, not having perfect grammar and spelling.

Those skills are not always in alignment - I've worked happily with great written communicators who couldn't spell for shift.

First of all, writing skills != good communication.

As someone else said, hire the person who actually knows how to get the job done -- even if they are not great writers.

(I don't think J. K. Rowling would be the best candidate for many jobs -- except, perhaps, writing.)

Also, hire telepaths to know when the job is done.

Since we’re at the topic of eloquence, might I add that horribly-written codebases are unbearable to work with during this time, or perhaps even during regular times for as long as the set up is remote. I get it that codebases inevitably rot over time, but the amount of rot can be mitigated by good dev practices such as unit testing, code reviews, best-effort (not perfect!) documentation, and standardizing dev practices. Dev teams that simply don’t care about code maintenance practices because the code “works” won’t be able to move fast enough during regular times, much less during a pandemic remote-setup scenario.

Yes, but things change over time, and there is rarely a chance to go back and refactor. Every time you introduce something new, or make some tech decision, it should be able to exist without needing to be re-written for a long time. If you are lucky enough to have some budget available for refactoring, it will probably be incremental, so choose choose things that can be adopted incrementally.

> there is rarely a chance to go back and refactor

I wouldn’t say that this has been true in my experience. I’ve worked on multiple products that evolve over time and it often happens that a new feature touches on previously built features that can’t support all the behaviors of the new one, so then a refactor of the old code (at least some of it) is necessary. You can argue that doing so would require regression tests, but that’s why you automate those with a unit testing framework. This mindset of never modifying previously written code within reasonable and pragmatic boundaries is so rigid and anti-growth, I don’t even know how it came to be so popular within an industry that identifies so closely with innovation. That’s how you end up with putting band-aid solutions on top of each other and slowing down the agility of your teams over time.

I agree, and I'd go so far as to say that it's important for most office workers, even if you're not planning to be remote.

Writing is a great proxy for thinking, and a lot of people have great thoughts, but aren't good at organizing those thoughts into a coherent story.

(Note that there are a lot of people who think they're "good at writing" because they know a lot of words and can commit them to the screen quickly, and a lot of people who think they are bad at writing because they get a mental block trying to commit words to the screen.)

Might look like self-promotion but a tool* I've developed is meant to help (read: force) people into writing in a better way:

You write your full idea, then you create a new 'layer', and have to cut down on words. Basically distilling what you're trying to say. In the end you'll end up with the 'shortest' layer of the message.

I built it partly with the aim of helping remote workers 'learn' how to write better

* https://bychgroup.com/layered-ink

> If you’re a strong writer and you can consume information in written formats really well

Most comments here are focused on the "write well" part, which is important, no doubt.

But let's not forget the "read well" part. When people cannot read more than a paragraph without losing focus, or are confused by the used of precise technical terms (like stacks and queues, lists and sets...), the idea that you want to communicate will at best not pass, at worst been reshaped to something else.

I don't agree with everything DHH does or says, but the Basecamp Guide to Internal Communication is amazing: https://basecamp.com/guides/how-we-communicate

This is especially important now that people are working remotely and can't just quickly chat about things.

A few quotes:

#2 Real-time sometimes, asynchronous most of the time.

#3 Internal communication based on long-form writing, rather than a verbal tradition of meetings, speaking, and chatting, leads to a welcomed reduction in meetings, video conferences, calls, or other real-time opportunities to interrupt and be interrupted.

#16 "Now" is often the wrong time to say what just popped into your head. It's better to let it filter it through the sieve of time. What's left is the part worth saying.

Weak writing skills = lower information throughput = worse at remote work. Obvious or not?

Sorry nevermind, this was a misleading title. The article is actually about writing more documentation to decrease onboarding time. I think this is also true for non-remote onboarding. Better title would be "Writing great documentation decreases onboarding time for remote employees". Not really sure why this has > 300 votes. I guess people read the title and agreed.

I'm really interested in finding resources to help my team members develop their writings skills. Tech skills are comparatively easy to find materials for, I think. At this point I think writing skills are so important it's the biggest priority for further their careers, given the level of technology experience they have.

> Tech skills are comparatively easy to find materials for, I think.

Sorta, but most of the tech skills that are easy to find information on are closer to grammar and punctuation than to writing.

Just like software development, the way you train people to write is have people write and, importantly, have people review and edit it.

While I agree that while application is a great way to learn most of the time when you go to school they don't just tell you "just keep doing a thing over and over" without any other kind of guidance or material.

Quote: "To learn more about what it’s like to work at Mattermost and to see our current open roles, check out our Careers page."

So I went to check that, see what they have. And puff, Firefox informed me it has stopped a tracker on that page.

To paraphrase: "Nice tracker you have there Mattermost, would be a shame is somebody would point it out"

Also: hire people with strong reading skills. No matter how good your writing or your automation (requiring less writing), sometimes the business processes need long explanations. You don't want people asking around without reading the basics first. Overcommunicate, yes. But also, read what others actually wrote.

Absolutely agree.

The emphasis on writing skills is a repeating theme here, too.

A few months ago I wrote a similar thing that got >800 votes here on HN: https://snir.dev/blog/remote-async-communication

How do you interview for developers with strong writing skills? Do you give a writing assignment, etc

I’ve submitted job applications that asked me to include a writing sample, and have also asked job applicants to edit a page of bad writing riddled with errors, for positions where writing or editing skills were important.

but we are talking about developers here. is it socially acceptable to give writing interviews here ?

Has anyone released a GTP-3 annealing program that will take what you wrote and make it perfectly clear to someone with less reading comprehension by some fixed amount?

That would be amazing..

On this note, can someone suggest good practical resources to learn how to improve writing skills?

William Zinsser's "On Writing Well" is a good starting point.

I've had good experience with Steven Pinker's book The Sense of Style.

Also journaling every day helps immensely.

Any guidance for developing these skills, especially in the context of tech companies?

As with all things - practice and find someone who can give you honest, constructive feedback.

To find great remote employees, prioritize candidates with strong thinking skills.

Good writing is a business and career advantage. Try to be clear, concise, and get to the point real quick.

Here are some of my learnings and anecdotal incidents I have experienced so far. Still learning and recalibrating as I go on.

Try following BLUF[1], a military communications acronym — “Bottom Line Up Front” — designed to enforce speed and clarity in reports and emails.

We, especially in the eastern culture, tend to weave stories and try to form a connection before hitting the point. When it comes to team communication, either in emails and other forms of communication, it is better to reverse it -- start with the important points and then, if needed, weave the stories to make it clearer and empathetic.

However, just knowing the tips/tricks isn't enough, communication (more aptly writing) is a habit that becomes better with more practice.

One common suggestion I advise my team is, "I cannot read your mind, you have to tell me. The same goes with the client/customer -- ask them, talk to them unless you can read their mind."

If you work for a Startup or any Company for that matter, how do you think the founder or the C-Suites know what you did. Make it a habit to write weekly, bi-weekly, or monthly reports and email them. I guarantee you that it will come to pay you with compound interest in the future.

Here is a scenario. You just joined a new company. You report to a few at the top and work with a few under you. You have to gain the trust of those below you and prove to the ones above. If you are someone who wants to "prove it", do beyond your call, and wants to go the extra mile, what would be an ideal step besides the usual work you have to do.

Try this (I think I read this on Seth Godin's Blog[2]). Write a regular report of the accomplishment of your team, and highlight the people under you -- include their names and what they did that help you, and the team. The tops know what's happening and can take decisions without having to read your mind or setting up "meetings" and "catch-ups" which most will forget as soon as they are over. When in writing, they will likely mark it and act on it appropriately.

For those Individual Contributors (IC), I would still suggest doing something similar. Others, including your managers, friends, colleagues cannot read your mind. You might be one of the best programmers and you can prove it with code but imagine supplementing that with some form of communication on your gotchas, tips, tricks -- people love to hear those.

I was once in a team, big enough, and we had just one DevOps. He was rather silent, talks to very few people, the corner guy. But I was intrigued by the short and clear emails he sent when things are going to go down, backup, etc. while maintaining everyone's DevOps needs without much sweat (or is it). I began talking to him often and he was friendly, eager to tell me interesting things. He was also a regular documenter and writes some of the best documentation of what he did, why he did and was pretty much future proof. Almost none knew about that but he continues the routine. That documentation soon became a way to onboard new recruits when a new account was started for DevOps for enterprise customers earning $100Ks in the first few months of operation. By the time he left or close to it, that department was pulling in close to millions.

If you are in the lower rung and believe no one listens to you, despite you being smart -- think again. You have writing as your weapon. One of my career advice is, “Imagine yourself already advanced in your careers a year or more, then start acting and doing the roles you would do by then.“ If you are asked why you do something better because that is above your pay grade, you are in the wrong company.

1. https://en.wikipedia.org/wiki/BLUF_(communication)

2. https://www.sethgodin.com

Pro tip: you should have been doing this pre-covid instead of asking irrelevant algorithm questions.

Also non-remote employees

Documentation is all well and good, but also having people who can solve domain problems rather than just describe them ought to be a priority among many to have a mix in the organization. Less capable people can document what someone more skilled solved if they're not great communicators (I knew several people exactly like this). Having all documenters doesn't necessarily allow tackling hard problems but could risk reducing the bar to who can communicate in-lieu of doing hard things. There is a finite supply of hard problem solvers and even fewer far who can communicate well. It may or may not be cheaper to hire one who can't communicate and a technical writer or junior staffer rather than an all-in-one unicorn who can do everything.

To be honest, this fetishization of writing is very Anglo-centric. I don't think that people say this for example in Germany.

This is a strange comment.

>this fetishization

What part of Mr Tien's post implies that he fetishizes writing? I read it twice, the logic behind prioritizing writing skills in a remote-first world is reasonable. Why is it suddenly a fetish?

>I don't think that people say this for example in Germany.

What experience are you drawing this statement from? Are you saying people in Germany don't prioritize good writing skills wrt remote candidates?

The part where he says that writing matters for remote work. Like these types of articles tend to pop up in different contexts but it's always vague.

I'm drawing on the experience that people in Germany don't talk about the importance of writing as much.

Can you speak German? I mean seriously, talk to any German boomer and he will tell you about correct orthography. Its his favorite topic.

Yeah I can. Orthography is different from writing.

Es ist Teil davon. Dein Kommentar ist einfach Unfug.

That’s interesting. Have you had similar professional experience in both English and German-speaking workplaces? I would have expected a greater emphasis on good writing in European countries with more multilingualism.

I have comparable experience consuming media's interacting with people and such. Or maybe there could be less emphasis on writing since you can't reach as many people.

Yeah. And I'm having a ton of problems with co-workers who have shitty writing skills; where, pre-covid, they weren't that bad. I could always walk over and get a clarification when I needed. But jeez, come on guys, the same people who get their panties in a bunch over an extra space in my yaml, or "too many comments" - don't bother to slack complete sentences.

Reply on news.ycombinator.com