Hacker News Reader

Comment by josephmosby | Hacker News Reader

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.

View on HN

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.

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)

Reply on news.ycombinator.com