Engineers Need to Write
developing.dev
developing.dev
So true! Redrafting and self-editing involves so much more than just getting the commas in the right places. This is how we see new linkages that weren't obvious at first. It's how we become more discerning, so we can define the limits and strengths of our concepts more precisely. And it's one of the best ways of opening up new avenues of thought. (If A is valid, then B, C and D become possible.)
Just challenged the hacker news crew to draw a bike. See my reply to the OP.
I understand how this condition might make the writing process more challenging, but I don’t think that contradicts GPs point at all.
It's harsh, but it isn't wrong, right? The reason that these states of being are considered 'disorders' is because they interfere with daily life and with tasks that other people consider to be easy.
I need to take a lot of time to edit my writing and to re-evaluate the content that I write because it is easy for me to slip into a multi-paragraph tangent. Fundamentally that happens because my thinking is not sharp/focused.
On the other hand, when I am done writing I get a feeling of great accomplishment. Like I was able to swim through the deep waters of my mind and harpoon all the good ideas. Being smart isn't worth much if you can't communicate your ideas!
i do take offense of people implying my "mind is weak" based soley on my writing skills. Yes, I know writing skills are important at communicating, but humans have seriously many skills to offer than just writing or even communicating for that matter. yet people seem to be condensing their opinion of other people into a very highlevel simplistic rule. Are we going back in time here? whats next? basing if peoples minds are weak on DNA/ race?
>I need to take a lot of time to edit my writing and to re-evaluate the content that I write because it is easy for me to slip into a multi-paragraph tangent. Fundamentally that happens because my thinking is not sharp/focused.
same here on the first part, but not because I can't focus, its because I have to juggle many train of thoughts whilst writing slowing into one stream of communication. to the point I give up on many things that i really want to say
Are you defining people as weak because you think writing is important and ignoring all other aspects of their personality?
Irrespective of creativity and intelligence you need some amount of conscientiousness to be goal oriented. That is just yourself. To direct others to do the same you need that plus excellent communication skills. There are no shortcuts or alternatives here.
Originally the quote was about sloppy thinking, not "weak" minds. You're right that weak isn't a great word to use here.
Maybe you'd also disagree that your thinking is sloppy.
"Writing is nature's way of letting you know how sloppy your thinking is."
As a father to three kids on rhe ASD spectrum, yes I guess you are right. And yeah they need extra time in exams - but honestly no-one writes the final draft the first time. All exams are is how quickly can you regurgitate an essay you wrote (yourself) earlier.
Write, rewrite and repeat. It's the only way. No matter how it bounces around in your brain at some point you mail the slippery thought down and can examine it.
I write everything down because of this. Bullet points, paragraphs etc.
When writing a StackExchange post asking for help, I want to include all relevant information and include a list of things I've tried, along with explanations for why they're dead ends.
Writing it all down sometimes helps me realise that one of the ends is in fact not dead.
Rubber ducking can be a highly productive measure when your mentally clouded and can take many forms.
Then I'll have this odd memory of - "I discussed this with you, I told you all abo- oh wait, I didn't send it."
I felt I was wasting too much time. But I've realized that for me the time spent writing something in details has always helped me fill in the gaps and also discover the unknowns.
I'm using Obsidian right now for this, although you can just use plain code editor it's nice to have WYSIWYG.
Writing for a child forces me to keep the words and concepts very, very simple, and to write in a style that builds up usage of the program from first principles. Writing for the grumpy old-timer is a practice in minimizing questions from them, forcing me to do a sort of final pass on the overall design of what I'm writing about, to defend design choices, and to add future improvements to the backlog. Drafting the documentation for semi-finished features that are still in progress has sometimes led me to change the design in order to make writing the docs targeting these two people simpler.
-- (don't know who said this quote)
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.
Your brain takes shortcuts, you can think you understand what is going on, it's only when you need to communicate it you realize how many shortcuts in hallucinations of understanding there are in your head.
So for those with imgur accounts... I have a challenge for you.
Most people will know how to ride a bike, will know a bike when they see it.
But can you communicate what a bike looks like (in a diagram)? 90% of you won't be able to.
Grab a piece of paper, and draw a bike. Post it to imgur, and post a link to it below (please don't be a troll).
Then take a look at https://www.gianlucagimini.it/portfolio-item/velocipedia/
Until you try to communicate a concept or idea in words or diagrams, the chances are you are hallucinating your understanding.
When I write something down, it changes my viewpoint. Not sure why, but it does.
I tend to "just do things a certain way," without really planning, structuring, or thinking about it.
I have found that I surprise myself, if I then go back, with a goal of explaining what I do, to others.
Here are some examples of what I mean:
[0] https://littlegreenviper.com/miscellany/thats-not-what-ships...
[1] https://littlegreenviper.com/various/the-road-most-traveled-...
[2] https://littlegreenviper.com/various/evolutionary-design-spe...
etc.
As soon as I switched to passive tense, or my brain started to hand wave over something, I knew I'd hit a weak point.
And perhaps unsurprisingly, when I'd check with the engineers, as often as not I'd get the same response: "Huh, I'm not sure either."
I've never found an equivalent tool for identifying my weaknesses. In a conversation I can bluff my way through something and rationalize it to myself or others as "I don't have all the details at hand but I'm sure I understand it"; when writing, I don't have that same luxury.
A lot of the times, in projects, you're writing to yourself, or more precisely to your future self, so that you can figure out in the future what it was you were trying to do in the present. If you've ever come across one of your past projects, and have no idea what it was supposed to do, or where you stopped working on it - that's where a document addressed to yourself would have been invaluable.
If you're writing for some other audience, then it's most important - assuming you want them to read your writing - to try to see the world through their eyes. Technical writing should generally be gradually incremental, starting from minimal assumptions of the audience's knowledge and working upwards. Then, they can read along for awhile at least before having to jump off the train. I recently came across an excellent example of this approach:
https://www.scottaaronson.com/papers/pnp.pdf
As far as non-technical writing, anything goes, be creative, you could be the next James Joyce, which AI is unlikely to ever replicate, or at least probably not.
As for communication, it depends. One problem with writing is that it generates something to read, and people don't want to read.
I think a better way to think about it is if you have a team, there’s probably someone on it that gets more done by writing it down and another person who does better by drawing it and another by coding it and another by talking it through. So, talk it through and explain the plan to stakeholders, write it down for everyone to have a definite written explanation of what was talked about, draw the diagrams to explain in pictures what’s complex in words, and code a POC to make it real - and do it together as a team. don’t tell everyone else to be like you, enjoy that they are them and they’re on your team filling the gaps. A sports team isn’t composed of uniform cogs, they take roles that exploit their natural abilities.
Chill mate, it's just some person sharing their own experience and beliefs, they are not assuming anything. I don't know why you feel so opposed and attacked to an otherwise benign topic. The workplace interaction is dominantly biased towards speaking and face-to-face interaction. Even job interviews selects for the extroverts who can talk smoothly and has an outward pleasing personality. A dissenting opinion that argues for the unpopular or minority point of view seems perfectly healthy and natural.
In fact, I find your comment strange. Given the current dominant mode of communication, I would have expected that you would support the idea of writing more. Why? Because you clearly advocate for a balanced team that covers all modality (whatever that means), yet I don't see you pointing out the fact that people dominantly prefers and selects for verbal communication, subtly discriminating people who are more effective in writing or other alternative modes of communication. Instead, you get defensive and even argues against the minority view, clearly contradicting what you seem to be advocating for. What do you say about that?
My flow looks like:
1. Write the impact of the problem as currently observed. This answers most Product and Executive questions and know I'm actively working on solving this problem.
2. List down ideas of what I think it could be.
3. Start exploring those ideas by priority.
4. Bring in Datadog metrics, log items, commands/queries
5. Have a conclusion for each of those ideas
This has multiplicative effects:
1. Others don't feel the need to have me in a Zoom call because they can follow my progress and comment on the doc if they feel strongly about something. I have full focus on the task at hand.
2. The doc becomes handy in outage review meetings and retrospectives later on
3. Useful commands/queries sometimes end up being formed here and I can go back and reuse them
*I rarely actually handwrite things. I depend on Markdown-formatted collaborative notes tools that get out of the way (i.e. not Google Docs).
I've learned not to worry about anything that isn't content during the process. It can be copied, pasted, formatted, fixed, proof read, and put somewhere more permanent later, just not while I am hard at it.
(and before someone says it, GitHub/GitLab really isn't a good substitute because they're designed around a different use case. I actually use GitLab for one type of task I'm involved with. Given the final form will be an adoc, it's OK but not really ideal for writing.)
For personal notes that aren't handwritten, mostly anything that will produce a txt file.
The tools are going to write more and more of the code for us. We're going to be spending more time writing about the code and less time writing code.
(I posted this as a comment on the article, but there's more active conversation here so I pasted it here as well. I'm curious if anyone else has thoughts along these lines.)
It struck me, as a programmer with a creative writing background, that he was basically writing microfiction with a character (himself) that needed help, and a character (ChatGPT) to help him out.
1. he's been using it for 9 days
2. he has subscribed for gpt4
3. it took 3 rounds of refining to get it running
4. it did what he wanted
5. it took about 15 minutes to do something that would have taken him "3 months"
I believe the first 3 but am skeptical of the last 2. He was, in any case, effusive about its capabilities.
For context, I should note:
- he was obviously inebriated, high, and the sort of person who trusted a stranger (me) with his unlocked phone while he went to the bathroom. (I think this actually has a little to say about how quickly he's picking up good prompting?)
- This was at a dive bar in Houston's east end--not really a tech hub.
Edit: he was persuasive enough that I intend to try to shift more of my habitual queries from Google to chat gpt until I at least have a deeper grok of effective prompting than I have picked up so far.
I try to mitigate theft/loss/disaster anxiety by keeping a backup/recovery hygiene that enables me to be productive in <2 hours of obtaining a replacement (but I'll sheepishly admit a tool update has the backup script failing atm and I haven't found time to debug).
IME I'm more likely to spill beer on one at home than out and about. Something subtle about space or psychology? (Spaces at home are more likely to be cluttered enough to nudge me towards a risky drink placement? Not habituated to expecting spillables near the computer at home? Idk.)
I did have some jackass having a whiny argument with someone else spill my beer on my laptop this past summer. Close call, but luckily it was almost empty. This was, to some degree, my mistake for going against my gut and humoring his curiosity about what I was doing long enough for him to decide he was welcome to sit across from me.
I do agree that writing badly is a reliably correlated with being a bad developer. Not writing well denotes lack of clarity, inattention to detail and self-indulgence, all damning attributes for a serious professional.
I think we will see a similar transition happening with writing, and perhaps knowledge work in general. The machines do a lot of writing for us, and we will have to do less of it. Writing becomes more of a pastime activity that people do for pleasure, and also to sharpen their thinking and stay sane.
I think we will see an increase in offers for writing retreats, journal clubs, calligraphy classes, etc.
On the other hand, I really struggle with writing up objectives, performance reviews, intern projects, my own resume, product roadmaps, etc. I tend to put this stuff off to the last minute, and spend way too much time making minor tweaks and edits, but probably not improving the overall impact. I'm never sure how much detail is useful vs just going for vague but impressive sounding bullet points.
I guess these things are basically marketing / advertising / BS, and the audience is senior management, hiring managers, clients, etc. that more or less live in their own different world, or at least at a different level of abstraction from me. It also doesn't help that it's sporadic stuff that happens once or a few times / year, so I feel I never get good at it or have any kind of feedback loop, and it feels like a distraction from my "actual" coding/day-to-day job, but obviously this stuff actually really important in the long run.
I am really tempted to try to hire some kind of communications consultant to basically sit down with me and do this together, or for me, on an hourly basis or something... much like I do for my taxes. Although maybe I should just learn to do it myself, read a few books / youtube on it, etc... in practice, I don't, and if I found someone who was great at it and it got done, maybe I'd have a better job, better projects, etc.
Really curious to hear of thoughts on this, whether anyone has ever done something like this, whether it worked out... or if the work to find the right person and explain things exceeded the benefits.
It's hard to know if this kind of activity, for me, is a "cost center" that is best outsourced, or a "profit center" that it's a mistake to outsource.
You seem like a smart person. If you don't understand who is reading it and why, then of course it'll seem like meaningless busy work, and you'll have trouble writing it well.
I'd consider telling your manager how you feel, and ask them for help writing these well. Kind of a pair programming session. I bet you'd get a ton out of it.
Sometimes people help and provide feedback which is great... but sometimes they don't, because I guess my boss is busy with his own stuff / reports / etc, or if I am writing my own objectives / appraisal for him, then he is in fact the person that needs to be persuaded, or has his own competing interests, etc.
One of the candidate 20% projects that tempts me is something to keep track of number of words I write in jira. Or slacking with coworkers.
I have great code stats at current job, top tier, but I don't think people have the evidence to really see what I really do. I write. I make our plans. I review the shit out of our work. I help coworkers all the time. (And I write reams of code.)
Absolutely, collaboration is much smoother if we write well
Kudos for doing that! I hate when people treat writing messages like a second hand skill that doesn't deserve any effort, especially when explaining technical stuff.
A few months back, I was job hunting due to tech layoffs and ended up with two offers from different startups. One was a 2-year-old YC company with a larger team, while the other was a brand-new startup where I'd be the first engineer, building the tech stack from the ground up.
Deciding between the two was tough, so I tried a creative exercise. I wrote draft emails to both hiring managers, explaining why I chose not to join their startup. After about 90 minutes, my preferences became clear.
The only reasons I had for joining the more established startup were job security and better work-life balance. Meanwhile, my passion for the new startup was evident in the email I wrote. This exercise helped me uncover my true feelings.
---
It was a very useful exercise; might be able to help someone else faced with this issue.
It's also a great help to closing a topic. Once everything is put down and said, I can checkpoint in trust that I'll be able to restore later. Closing all the open loops. For some time at least.
And sometimes, most of the times, I end up sharing with interested parties. Either because someone needs to write up a conclusion or synthesis, and (very humbly) better me than someone else, especially if I'm the one doing or driving most of the work.
If you share widely, sometimes it's also a way to find other kindred souls, or to have a place to come back 'see, someone tried this and it worked'. And to challenge oneself against a larger public and see whether you need to improve in some ways.
Just don't look too much at HN or Twitter downers (use the mute and block features heavily), try and focus on positive and constructive, additive comments. Push back, shut down, leave alone anything harmful. It may come with the need for additional therapy sessions (it did for me the first times), so please beware.
It doesn't need to be a fight. I hope whenever/if you feel like writing something and share it, that I'll be able to read it and maybe enjoy the thoughtful ideas or conversation or inspiration, the challenge.
(By contrast, I'll usually have a temporary digital file with notes in flux while I'm learning something. But the notebooks are where I write things "on-the-record.")
But I share you sentiment, I don’t write, too many fights to win. There is a significant portion of the workforce who do not do anything except to try an take up the air in a conversation.
I don’t post on HN, often write out the comment, refresh the tab and move on because of what I see that will unfold. Sometimes things need to be said, but often it’s the things that are not said that paint the picture.
I know the author here is talking about non-code writing but it still sounds weird to hear it given that is our job. To write. I call myself a writer when people ask what I do as it represents it much better than any of the dumb technical names people have come up with. No I don't build houses nor do I design physical artifacts. I write.
I mostly write for myself— that's where ideas get figured out. Most of this happens in an Apple Note or in Notion.
I'm apprehensive about all the time I'd be spending polishing something up to put on a blog somewhere, mostly because of the time it takes to explain stuff. We all know that if you take shortcuts and don't speak to a predefined audience, at some point it'll get picked up on HN and torn to shreds...
It was the first things I ever read of his because I don’t like scary stuff. I was so impressed that I have started to read some of his works… and they are amazing. He is such an amazing story teller.
Highly recommend picking up ‘On Writing’ and letting it guide you towards a future of improved writing skills via practice and helpful concepts.
Here's the Amazon link if anyone else is thinking about reading it - https://www.amazon.com/Writing-10th-Anniversary-Memoir-Craft...
I do believe however that fewer and fewer engineers will actually take time to develop that skill and will rely on ChatGPT and co in the future to generate most of the written content based on draft notes.
The classic English teacher advice is also very much worth following, such as reading aloud and creating an outline.
And of course, reading is a fantastic way to improve your writing. There are examples of great writing in any genre or format, but I would say that fiction and long-form journalism are usually quite good, while non-fiction books and blog posts tend to be more hit or miss. Sometimes you need to read a little James Baldwin to remember that writing can be an art form and not just a perfunctory means towards an end.
Tools like The Brain is ok but I would rather have source files which I can commit to a repo. Dendron is ok as well but is not universally inteoperable...as I use Jetbrains tooling. I can't deny how important the somatic & muscle memory elements are to the task of writing & VSCodium is just not on the same level as Jetbrains tools.
What would be great is to have a Universal ID & a graph api where all of my writings can be queried & updated or amended.
For now, software is more satisfying to write than prose. I hope experience of writing in a digital format can become more like writing graph data structures in the near future.
A word processor, you, and time are all it takes.
Prose, iconography, pictures, spoken word, voice inflection, body language, etc were the only games in town before the advent of computers. Now we have algorithms, graph data structures, set logic, as tools to work with information. Prose can be analyzed using NLP, but it is verbose, full of throwaway words, & the expression of scoped intent of meaning can be improved.
One major weakness of prose is the difficulty of gauging breadth & completeness of expression. When writing software, it is easier to perceive if a program is incomplete. Compilers, type systems, automated tests, & runtime errors guard against bugs or issues with syntax or logic.
It is more difficult to parse the prose to understand if all of the essential pieces of information (i.e. logical premises followed to their conclusion) is present in the document. If a conversation is started about a document pointing out missing logic or a fallacy, it is difficult to counter a chain of reason other than quoting phrases & responding to those phrases, possibly taking the phrases out of context. There is also a trend toward rivalrous attention dynamics in online conversations. If you look at Hacker News, many of the threads repeat each other & the disagreements quickly turn into bickering. Such patterns of conversation could even be identified with simple algorithms with can be open.
A graph data structure allows the context to be transmitted so if a phrase in a graph is quoted, the context comes along with it. If the phrase is separated from the contextual graph, the meaning changes. An assertion or counter assertion could be tested using Set logic. Phrases are less likely to be taken out of context, diminishing strawmen. The full breadth of unique points can also be aggregated. I think tooling with expressions being in a graph would also disincentivize bickering & rivalrous attention dynamics.
The cool thing about writing software is that one participates in the trend of evolved tooling of expression. Whether it's writing a library, creating a program or app, writing a language, an experiment of expression is conducted.
The ultimate goal is communication, not experiments.
Given how online discourse has devolved in the recent decade, it seems that the modality of prose is lacking certain elements which brings shared understanding & context.
Prose is also inefficient to read. We train our vision to fixate on certain words & glyphs to derive the meaning of a sentence. If the format were more friendly to scanning to understand context & meaning, we could also more efficiently understand content & find links to other related content.
An eye opening insight I had while I was learning to write properly was that I was doing a lot of things systematically wrong. So, the job became learning to do it right in a systematic way. This didn't happen overnight but I learned from my mistakes one by one and started criticizing my own writings based on that and slowly improved what I was doing. One by one, I was eliminating whole categories of mistakes and learning why they were mistakes.
Another thing that I learned was that putting a lot of effort in writing creates a sunk cost fallacy. You start becoming defensive of all the text you have write. Learning to rewrite your text and stepping over your reluctance to delete stuff you have written is a key skill. Iterating makes things better. It's literally faster to rewrite than to correct text. If it looks or feels wrong, just delete it and write it again.
Another insight is that writing things down forces you to make your fuzzy ideas concrete. You get progressive insight from rewriting things that you've already written. This works better if you wait a bit for your short term memory to purge itself of any notions you might have. You can use time to your advantage here. Simply take a break and rewrite or revise what you have written later. Weekends and sleeping are great for this. You come back fresh and you instantly spot all the mistakes you made earlier.
People think of writing as an art form. Which of course it is. But in many ways, writing is like programming. It is governed by simple rules (grammar and stylistic ones). All you need to do is learn those rules and apply them. There's a certain logic to how a good text flows. How sentences and paragraphs connect, etc. The whole job of learning to write is figuring out how that works.
Tools actually exist that can check your writing automatically these days. Use those and don't argue with them and instead fix the issues that these tools will point out to you and learn about why those are issues that need fixing. Once you stop producing text that has loads of such issues, you'll have become a better writer. It's not that hard. But you do need to make an effort. And of course know to use and install such tools.
And since programmers indeed depend on written communication, this is a good skill to have.
That being said – it's really hard.
I try regardless, but it's very hard to avoid accidentally irking coworkers.
Humor sounds like a great tool to keep people reading
Clearly written technical specs make implementation easy but also easy to reason about.
But it didn't do anything to explain how to write as an engineer. Like the author I didn't enjoy writing in school, so how does writing as an Engineer differ, and how does one improve ones Engineering writing.
While I never considered myself an engineer, but a computer scientist, I've always loved writing.
My favorite course in high school beside programming was literature and language.
I never stopped writing in a form or another. I love Shakespeare as much as I love any other old or new good author.
Considering Shakespeare old and hard to understand doesn't tell us as much about Shakespeare as about you.
Was genuinely searching for the the stuff and asked a clerk, they said that stuff's gone so pricey people don't buy any more... It's honestly a little worrying
It seems as if most of my writing is ent sent straight to dev/null
Also I'm eager to receive feedback on it. That's why I'm so grateful for the Hacker News community's comments!