Live data from Hacker News

All the best engineering advice I stole from non-technical people (2019)

bellmar.medium.com

21–30 of 91 posts

Re: All the best engineering advice I stole from non-technical people (2019)

#21
> "The turning point in my life was the day I realized to run great engineering teams I didn’t need to be the best engineer in the world, I needed to get good at advertising my people and their stories up the chain of command. I needed to improve their observability so that we can keep bureaucracy at bay by maintaining a high level of trust."

Poof. Another Big Tech middle manager got their wings.

This cynical surrendering is not keeping bureaucracy at bay, at all. It's joining the bureaucracy and increasing its size. It is the bureaucracy.

At companies that have competent managers up and down the hierarchy, it doesn't have to be like this. Good work can be judged by good managers, and rewarded, without anyone having to play bureaucratic games. There are companies, mostly smaller, that work like this.

It seems to reliably fail as companies scale, but for each company it might fail at a different point. The longer competent management can be maintained, the better chance of the company succeeding in a big way.

But all it takes is one good manager hiring a bad manager and the whole thing can start to fall apart. Once the company culture starts to reward people for playing bureaucratic games more than doing good work, it becomes broken and dysfunctional. Diseased.

Everyone quickly realizes that the dynamic has shifted. That good work isn't rewarded any better than bad work that is well marketed internally.

And so the best people, who have the most confidence and ability, go to smaller/better companies that know how to reward the people that do the best work. The other people stay and settle in for long-term escalating bureaucratic warfare.

And these broken companies are left to fail or ride out the momentum generated before they were broken. All the while being miserable places to work.

Re: All the best engineering advice I stole from non-technical people (2019)

#22
post #21

> "The turning point in my life was the day I realized to run great engineering teams I didn’t need to be the best engineer in the world, I needed to get good at advertising my people and their stories up the chain of command. I needed to improve their observability so that we can keep bureaucracy at bay by maintaining a high level of trust. " Poof. Another Big Tech middle manager got their wings. This cynical surren…

> Good work can be judged by good managers, and rewarded, without anyone having to play bureaucratic games.

I lost hope this is possible. Even as a non-manager architect, I struggle to see good work if it's not made visible.

Fortunately, making good work visible takes little effort from the doer: take "before" and "after" screenshots; update the docs; if you improved performance, leave some plots behind; talk about your work and the benefits it brings.

All in all, if you are a software engineer, stop treating yourself as a code monkey and start treating yourself as a problem solver. You don't hear plumpers showing their hammer, they show the pipe stopped leaking. Same with software, stop showing code and start showing their effects.

Re: All the best engineering advice I stole from non-technical people (2019)

#23
post #21

> "The turning point in my life was the day I realized to run great engineering teams I didn’t need to be the best engineer in the world, I needed to get good at advertising my people and their stories up the chain of command. I needed to improve their observability so that we can keep bureaucracy at bay by maintaining a high level of trust. " Poof. Another Big Tech middle manager got their wings. This cynical surren…

> This cynical surrendering is not keeping bureaucracy at bay, at all. It's joining the bureaucracy and increasing its size. It is the bureaucracy.

It is keeping it at bay in the context of a team. My company is a company with seemingly more paperwork than the government (and I used to work in government).

Until a few weeks ago, I saw none of it as an individual developer (then we got individual specific paperwork and I looked at the required paperwork in the Google drive). A little digging turned up exactly why he doesn't have time to write code anymore. I would have called my company extremely low in bureaucracy before that.

How does that work? He is constantly in meetings with senior people. So my manager keeps the bureaucracy at bay from the perspective of me by joining it.

Re: All the best engineering advice I stole from non-technical people (2019)

#24
post #21

> "The turning point in my life was the day I realized to run great engineering teams I didn’t need to be the best engineer in the world, I needed to get good at advertising my people and their stories up the chain of command. I needed to improve their observability so that we can keep bureaucracy at bay by maintaining a high level of trust. " Poof. Another Big Tech middle manager got their wings. This cynical surren…

This exactly.

If it works it makes companies fly.

Sadly when said companies grow, the managerial part needs to grow, but with that all too often true understanding of the technical core is diluted and diluted and diluted

Re: All the best engineering advice I stole from non-technical people (2019)

#25
> Security and reliability are more likely to go wrong in the seams between components. That means literal integrations, but it also means organization seams.

Elon said the best part is no part. Parts between systems, interfaces/valves/pumps/APIs/whatever, are often modelled not after what makes the most sense for the final system or product but often follows the organisational structure of the people making the system. So it makes sense that these interface parts are often what creates problems.

Re: All the best engineering advice I stole from non-technical people (2019)

#26
Do you guys think that managers should have some tech background so they could assess any situation and get better decisions. I've been involved in a few projects were the lead senior developer was having difficult times with the manager. Any thoughts?

Re: All the best engineering advice I stole from non-technical people (2019)

#27

Do you guys think that managers should have some tech background so they could assess any situation and get better decisions. I've been involved in a few projects were the lead senior developer was having difficult times with the manager. Any thoughts?

I was on a team where the lead had issues like that

Ran into a lot of situations like this:

https://xkcd.com/1425/

The other common issue was that the non-technicals didn't grasp the need for absolutes and specificity. One common issue revolved around dates.

So we would get a ticket that "such and such permission should expire at a reasonable time on the date specified." Reasonable time was not defined and it turned out to be whenever the particular thing closed.

They would also forgot to list exceptions to that expiration policy, which the people doing it manually would have seen on the post-its this system replaced.

Re: All the best engineering advice I stole from non-technical people (2019)

#28

Do you guys think that managers should have some tech background so they could assess any situation and get better decisions. I've been involved in a few projects were the lead senior developer was having difficult times with the manager. Any thoughts?

Good managers should focus on taking the best decisions they can with the available information. Sure if they have a tech background, some of that information is easier to process if technical, but good decisions rely on much more than just what is good in the opinion of the tech lead.

If a manager starts analyzing the technical information in front of them without the background to do so, they are missing the point. They should rely on the opinion of their more technical counterparts when the information is technical.

Yet, the opposite is also true, if a technical background person becomes manager and doesn't trust their accounting, finance, marketing counter part, then they wouldn't be a very good manager either.

The above assumes that the manager has a more general role and that decisions on technical topics isn't their only job. If yes, of course a technical background should be required.

Re: All the best engineering advice I stole from non-technical people (2019)

#29
post #2

“Before you can make things better, you have to stop making them worse” Incredibly great advice. Especially when trying to resolve an already broken situation.

Notable failures both personally experienced and famous usually involve great amplifications of the issue resulting from attempts to fix, often with increasingly urgent and hasty actions.

Re: All the best engineering advice I stole from non-technical people (2019)

#30
post #25

> Security and reliability are more likely to go wrong in the seams between components. That means literal integrations, but it also means organization seams. Elon said the best part is no part. Parts between systems, interfaces/valves/pumps/APIs/whatever, are often modelled not after what makes the most sense for the final system or product but often follows the organisational structure of the people making the syst…

I have always worked with the concept of what I call “trouble nodes.”

These are basically graph vertexes; places where two (or more) things interface.

Every “node” is a potential quality hit. A lot of my refactoring involves removing these, using techniques like deriving base classes, protocol defaults, or recursion/reuse.

As an example, a couple of days ago, I refactored an SDK I’m refining. It has an auth capability that uses an API key (bearer token), in a Basic Auth scheme. It does this via a common method that generates a URL request, and adds a header.

But servers that run fastCGI don’t like auth headers, so I was forced to add the option for query arguments to deliver the tokens.

So I basically “kludged” it, and added the arguments to the URI in all the places the requests were being built. An ugly, clumsy, lash-up (I was in a hurry).

This was months ago. I forgot I did that.

As I was reviewing my code a few days ago, I saw this, and was quite embarrassed.

Not only was it sloppy, but it was dangerous. This was auth stuff. The worst kind of place to have rotten quality code.

The refactoring was a pretty intense effort, and removed dozens of “trouble nodes.” It was fundamental stuff, and required a lot of testing. If I had taken the time to do it right, the first time, it would not have been necessary. I’m glad I found it before it became a problem.

And I slept like a baby, that night (waking up frequently, cying).

Post reply on HN