Live data from Hacker News

Writing for Engineers

heinrichhartmann.com

21–30 of 39 posts

Re: Writing for Engineers

#21
post #18

Earlier quoted context omitted.

I think this is mostly an organizational constraint. Having a lot of people going off doing whatever they want and not communicating about it sounds like a nightmare in a large organization. Smaller companies probably have less of this organizational overhead. > I just don’t give a fuck about impact or convincing others to work on my idea I'm curious what you think a Senior+ role should entail in your ideal world. I'…

> I'm curious what you think a Senior+ role should entail in your ideal world. I'm not sure how you can get away from impact, since otherwise I'd perceive that as authority without responsibility. The technical expertise Ive gained over the years makes me pretty confident of executing on building complex systems that a younger me probably couldn’t have done. So it feels like a waste to me that Im not leveraging that…

What I did was just build a lot of prototypes and then show those prototypes. It is very hard for people to say that something wont work when you have can show it working right there in the presentation.

You can put that prototyping work under "making presentations and documents in preparation for design discussions", because that is exactly why you prototype. Discussions gets much easier when you are well prepared, so when someone asks about performance you can show them benchmarks, if someone asks about alternatives you can show the difference in benchmarks and code complexity etc. A few hours coding can save weeks of meetings discussing these things.

Re: Writing for Engineers

#22
post #20

Earlier quoted context omitted.

I think this is mostly an organizational constraint. Having a lot of people going off doing whatever they want and not communicating about it sounds like a nightmare in a large organization. Smaller companies probably have less of this organizational overhead. > I just don’t give a fuck about impact or convincing others to work on my idea I'm curious what you think a Senior+ role should entail in your ideal world. I'…

> Having a lot of people going off doing whatever they want and not communicating about it sounds like a nightmare in a large organization. Why? As long as what they do doesn't interfere with others work why does it matter if they don't communicate everything immediately, rather than at a meeting at a later date? If they don't deliver anything useful you put them on a PIP and ultimately fire them, just like everybody…

Disclaimer: this is from the perspective of someone who is NOT a Senior engineer.

My experience so far has been that there is very little work in a large organization that doesn't affect multiple teams at some point.

So if you're a Senior+ engineer building a complex system, it's highly likely to impact a lot of other people in the company. Building something like that without getting impacted teams onboard with the idea seems like a recipe for organizational strife.

Another thing that comes to mind is organizational goals. If the company has high level goals they want to achieve, having people (Esp very Senior people) working on multiple things unrelated to those goals doesn't seem conducive to success.

Also, the more senior you are the more visible you tend to be. So what you work on is probably going to be noticed more. I know that I would find it weird if I found out a Staff or Senior Staff engineer was off working on random things instead of leading an important project.

I definitely think Senior+ people should have some freedom, but absolute freedom doesn't seem like a good idea for anyone. When you're at a certain level what you do affects way more people than just yourself. Titles have a lot of weight to other people.

Re: Writing for Engineers

#23
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 :)

Re: Writing for Engineers

#24
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 tend to under explain using lots of phrases like "it gets pretty mathy" as an excuse for hand waving details away. Most of the time I think I am doing the audience a favour but for the most part it seems like they actually want an explanation that they won't understand. I think lack of understanding gives them confidence that the implementation is as technical as they imagine it to be, and that I am actually engineering and not just talking bullshit.

Going forward I think I'll prefer to be more technical for the self advancement.

Re: Writing for Engineers

#26
post #20

Earlier quoted context omitted.

> Having a lot of people going off doing whatever they want and not communicating about it sounds like a nightmare in a large organization. Why? As long as what they do doesn't interfere with others work why does it matter if they don't communicate everything immediately, rather than at a meeting at a later date? If they don't deliver anything useful you put them on a PIP and ultimately fire them, just like everybody…

Disclaimer: this is from the perspective of someone who is NOT a Senior engineer. My experience so far has been that there is very little work in a large organization that doesn't affect multiple teams at some point. So if you're a Senior+ engineer building a complex system, it's highly likely to impact a lot of other people in the company. Building something like that without getting impacted teams onboard with the…

Tight collaboration doesn't scale all that well though. From what I've seen, once a team has built a product/service they now start to put up red tape around it and make changes harder and harder the longer it exists. In other words, teams starts accumulating bureaucratic debt, it is very similar to technical debt. It is great to have that for the sake of stability, but the agility/creativity from more individual work is also great.

There is no reason you can just have one or the other, if you already have a lot of tight collaboration then you probably miss out on many potential changes that are too disruptive to be politically feasible. But you are right that you can't have only individual work, organizations needs tightly collaborating teams to be an organization.

Re: Writing for Engineers

#27
post #26

Earlier quoted context omitted.

Disclaimer: this is from the perspective of someone who is NOT a Senior engineer. My experience so far has been that there is very little work in a large organization that doesn't affect multiple teams at some point. So if you're a Senior+ engineer building a complex system, it's highly likely to impact a lot of other people in the company. Building something like that without getting impacted teams onboard with the…

Tight collaboration doesn't scale all that well though. From what I've seen, once a team has built a product/service they now start to put up red tape around it and make changes harder and harder the longer it exists. In other words, teams starts accumulating bureaucratic debt, it is very similar to technical debt. It is great to have that for the sake of stability, but the agility/creativity from more individual wor…

I completely agree with everything you said :).

Re: Writing for Engineers

#29
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 enjoyed learning your perspective. This could only have happened because you wrote about it in your comment.

Re: Writing for Engineers

#30
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 the other person will accept.

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

Most folk I need can do it. Many have just... fallen out of the habit.

Post reply on HN