Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing for Engineers

heinrichhartmann.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Writing for Engineers

#31

Post by danielrpa »

zmgsabst wrote: post #17
pm90 wrote: post #11

I agree with this perspective of the world (that senior+ software engineers need to be able to express themselves more fluently to be able to be impactful) but… just as a thought experiment, I wish it didn’t have to be that way. Writing is hard and not much fun (to me). Building systems that do something is hard but its a lot of fun. I just want to spend most of my time doing the latter. I just don’t give a fuck abou…

> I just want to spend most of my time doing the latter. I just don’t give a fuck about impact or convincing others to work on my idea. SDE 2 is a career position at Amazon — and it sounds like that’s what you want: to stay at that level, but working as the “point man” on increasingly important technical systems. I would say that SDE 3 (senior) and SDE 4 (principal) are fundamentally political — you’re responsible fo…

Big tech has some specialized, high level/pay roles where someone can be successful just by being an excellent engineer, even with average communication skills. I've seen these in areas such as Compilers and Operating Systems Kernels, for instance. These jobs are, however, highly specialized and require extraordinary and domain-specific technical skills.

Re: Writing for Engineers

#32

Post by mateusfreira »

I agree with the author's perspective. Writing is the one skill I am working hard to improve. Since I hit senior positions, it has been a superpower, mainly in a remote culture. Sharing findings and experiments internally with concise texts will give you excellent visibility in the company you work for.

Re: Writing for Engineers

#33

Post by teddyh »

thundergolfer wrote: post #28
teddyh wrote: post #25

I vastly prefer Larry McEnerney’s lecture The Craft of Writing Effectively : https://www.youtube.com/watch?v=vtIzMaLkCaM In particular, he disagrees with this article about outlines.

In which bit of the lecture does he talk about outlines?

Outlines are mentioned about six minutes into the talk, but it is, IMHO, heavy with context, so I strongly suggest you simply watch it from the beginning.

Re: Writing for Engineers

#34

Post by closeparen »

zmgsabst wrote: post #17
pm90 wrote: post #11

I agree with this perspective of the world (that senior+ software engineers need to be able to express themselves more fluently to be able to be impactful) but… just as a thought experiment, I wish it didn’t have to be that way. Writing is hard and not much fun (to me). Building systems that do something is hard but its a lot of fun. I just want to spend most of my time doing the latter. I just don’t give a fuck abou…

> I just want to spend most of my time doing the latter. I just don’t give a fuck about impact or convincing others to work on my idea. SDE 2 is a career position at Amazon — and it sounds like that’s what you want: to stay at that level, but working as the “point man” on increasingly important technical systems. I would say that SDE 3 (senior) and SDE 4 (principal) are fundamentally political — you’re responsible fo…

If you are unusually good at being an SDE 2, there's not really a way to leverage that into pay or recognition or harder projects. Until you get the promo you will just be doing the same borderline-menial work any SDE 2 can do, a fungible story points resource. Although it's great that the engineering IC ladder provides an alternative path to people management, there is no alternative path to being a professional meeting-talker. We do not allow unusually capable individuals to write code that the median engineer couldn't write (because then the median engineer definitely couldn't maintain it). Instead we ask them to supervise and direct the work of the median engineers.

I actually think the best way to leverage mostly-solo intellectual work into business results and recognition might be data science. Models and analyses are allowed to be arbitrarily sophisticated and as long as the rest of the org understands the inputs/outputs/performance characteristics, they're content to treat the internals as black box. So data scientists can really go all out intellectually on their technical artifacts in a way that engineers can't.

Re: Writing for Engineers

#35

Post by going_ham »

I have a curious question. How to get started? When I am working, I cannot take notes. If I take notes, I won't be working and I will be derailed from my work.

When I am out of work, I forget the details of what I did because I lose the flow of it.

So it's a very confounding situation. I am in a ever growing battle between write or work. Can you advice on how to express what we learnt?

I will be very appreciative of it. Thank you so much!

Re: Writing for Engineers

#36

Post by nobody_nothing »

teddyh wrote: post #25

I vastly prefer Larry McEnerney’s lecture The Craft of Writing Effectively : https://www.youtube.com/watch?v=vtIzMaLkCaM In particular, he disagrees with this article about outlines.

This is one of the best – maybe the best – videos I've seen on effective writing. I rewatch it every couple months.

Re: Writing for Engineers

#37

Post by alimov »

macintux wrote: post #19
alimov wrote: post #6

> Know your audience This point is something that I notice in a lot of meetings. Some of the engineers I work with are long winded and tend to over-explain concepts/issues to non-engineering folks. I try to send a direct message during the meeting (now and then) to try and reel them in a little by explaining that the non-engineering folks don’t need those details and that a what they are really asking for is a summar…

That, and even if it is the right audience, know when to save your topic for another context. I used to work with someone who, as a team meeting was wrapping up, was prone to interrupting everyone’s departure with a question that could easily have been asked on Slack.

> “and even if it is the right audience, know when to save your topic for another context.”

Yeah I agree with this as well

Re: Writing for Engineers

#38

Post by alimov »

urthor wrote: post #30
alimov wrote: post #6

> Know your audience This point is something that I notice in a lot of meetings. Some of the engineers I work with are long winded and tend to over-explain concepts/issues to non-engineering folks. I try to send a direct message during the meeting (now and then) to try and reel them in a little by explaining that the non-engineering folks don’t need those details and that a what they are really asking for is a summar…

Empathy is its own little rabbit hole. Suggest reading a negotiation book like Never Split the Difference or 3D Negotiation. These books spend hundreds of pages describing techniques to jog your ability to put yourself in the other person's shoes. Endlessly bring up the major point, talking about how human beings see the world through rose tinted spectacles. Negotiation is about gathering information to make an offer…

Never Split the Difference is a good read. I haven’t heard of 3D Negotiation.

> Thinking about the point of view of the other person is difficult, mentally intensive work.

That’s true

Re: Writing for Engineers

#39

Post by alimov »

fibonachos wrote: post #23
alimov wrote: post #6

> Know your audience This point is something that I notice in a lot of meetings. Some of the engineers I work with are long winded and tend to over-explain concepts/issues to non-engineering folks. I try to send a direct message during the meeting (now and then) to try and reel them in a little by explaining that the non-engineering folks don’t need those details and that a what they are really asking for is a summar…

I’m definitely guilty of this one, and have been working on improving it due to feedback from a teammate. In my case it was very much appreciated :)

I’m sure we’ve all been guilty of this now and again. Glad to hear that it’s possible for people to take this kind of feedback and put it to use.
Post reply on HN