I used to work as an attorney before getting into software engineering, and I clearly took for granted that other educated professionals (particular those in a field where precision is required) would write clearly, logically, and succinctly. My expectations have frequently not been met.
It's particularly humorous, as everyone who has hired me has acted like they were taking a big risk because of my non-technical background. Yet, each time, they quickly realize it was a good idea to hire someone with a strong command of the English language and a ruthless attention to detail.
Of course, the technical skills are required as well, but I don't think people appreciate how easy those are to pick up for someone who is capable of reading and distilling voluminous amounts of information in a short period of time.
They do have extra gifts in writing code which compensates somewhat. But it's a huge problem when half your team struggles to carry a conversation.
That's useful for day-to-day issues, but if you're getting a lot of ambiguity that these folks have to address, someone higher up needs to write more.
Ive seem more projects fail because requirements weren't understood, often by the customer themselves, than because of tech
just like most cars are not F1 racecars and revolutionary engineering - other concerns like costs and aesthetics dominate
And of course I would make a typo. That should say "particularly". :)
I share much the same experience: both encountering a distinct lack of effective communication based on what I had expected, and being written off (pun intended) during the hiring process.
My biggest daily struggle is with those who want to verbally discuss every single issue, or worse, chat over informal DMs. Typically those conversations are somehow both circular and meandering all at once.
For me personally, I feel my commitment to writing-competency-over-technical-prowess has been my biggest asset throughout this second act. I'd like to think it allows me to back in to the technical aspects and keeps me better organized overall.
I also have diagnosed ADHD and a form of dyslexia so perhaps I'm just too easily distracted.
p.s. Please don't judge my grammar or spelling on this reply -- I'm writing from the bath with a fever!
That's interesting - I tend to have mixed feeling about this. Sometimes I wish I had all communication done in writting.
But the reality is that as a dev and seminconsultant I work in 10 different domains at the same time and there is no way for me to have enough time to encode all my clients knowledge in structured writing - the only way for my situation to be bearable is to encode this into code and working applications. And the only way to quickly gather knowledge and and have feedback loop on it is to encode it as working applications. Because lets face it even if I was master communicator and writer most clients areny and never will be. And most areny paing for writing text but for providing solutions.
So I'm in this dissonance here where I would love to be better writer but the reality is that its not really that useful in my situation. Ok, and now I feel depressed, thank goodness I just this moment went into confectionery.
Where do we order?
That said, I don’t buy the idea that you reach the same clarity of thought by talking through an idea as compared to writing that same idea down with the intention of communicating it clearly to another person. The latter requires significantly more command over an idea.
I've worked with many engineers who couldn't write, and it always came across in the aspects of the work mentioned in the thread — less ability to parse error messages, to describe things to others over email/Slack/comments, and most critically, to understand things that others wrote. Fundamentally, a huge amount of engineering is reading and writing. And I find those skills are very often linked.
Long story short, you will become an even greater engineer by drawing and writing out your ideas.
I don't think that applies here. Writing and reading are very basic skills that will help you in all aspects of your job as an engineer, and everyone should be as good as they can be at them.
On a (somewhat) less pedantic note I would add that “asserting” is a bit strong of a word to describe the statement I made. Perhaps you should be a bit more precise with your words. Writing more could help :).
One very direct application of this skill in day to day engineering is just reading and correctly interpreting error logs and stacktraces.
It's pretty incredible how often that's just the cause of a bug being literally given verbatim, if one can only engage with the message on its terms and frame of reference, and parse out the info from it that's meaningful in the context of the software you're writing (and not, for instance, expecting the error message to somehow do that work for you, which is often impossible)
At my list gig there were a few folks who would regularly message me anytime there was a failure in their CI pipeline. No reading the message. Possibly not even opening the failed job at all.
Most of the time, the pipeline was doing what it was supposed to: failing a bad build. It didn't even occur to them that it was their code that was the problem. Just "the pipeline is red: send to @recfab".
I got them to demo the issue for me, and they /immediately/ closed out of the error dialog when it popped up. Maddening!
But that is in part also because many error messages are closer to "there was an error" than providing full context info. These few minutes more invested into proper error messages can save many many man hours down the line.
One of the best signal for that is... a college degree.
So, like an IQ test without naming it an IQ test?
Seriously, I think our judgement of 'smartness' is lacking. We call people of loelw emotional intelligence smart.
Each of these has a way to eliminate people I have no reason to hire, including timid/shy people with no backbone of their own, people who are terrible at communicating, people who are clearly out of their depth even in a low stakes environment on a toy problem that doesn't even need to be fully solved.