All the best engineering advice I stole from non-technical people (2019)
bellmar.medium.com
bellmar.medium.com
I can’t read the article because of the signup wall. It is cheap and easy to set up a blog on your own custom domain.
True. But you can defeat all of Medium's annoying features by just disabling JavaScript.
"You can create a 10-minute email" you say. True, and a lot of people do while also a lot of people simply don't want the book that much.
I have trouble believing that they absolutely /need/ JavaScript to load answers to random questions on what seems like a relatively static page.
https://news.ycombinator.com/item?id=24314481
I see some of the famous company’s tech blogs on medium have posts behind paywall. Do you think they would put it behind paywall to make money from blog post.. For example - https://netflixtechblog.com/empowering-the-visual-effects-co...
There's a few of these. Can anyone confirm that https://addons.mozilla.org/en-US/firefox/addon/bypass-paywal... is the "real" one and is safe?
I don't understand why it's the top comment.
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.
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.
But, yeah, the scope is basically limited to each employee's direct manager. No one else can reasonably maintain all the context and perspective required to judge accurately.
The fundamental requirement is a high level of competence in the manager. It usually requires significant self-confidence, technical skill, and experience solving similar problems.
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.
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
Incredibly great advice. Especially when trying to resolve an already broken situation.
This phrase is intended for people that once discover they are in an always deepening hole panic and do nothing (or worse) because they see no way to completely fix the situation.
Don't go on a hunt when your house is on fire
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.
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).
If no one is available, stepping away from ones own work and reviewing it with a fresh mind can have a similar affect
But doing it right the first time would have been better. That comes from establishing habit.
"We are what we repeatedly do. Excellence, then, is not an act, but a habit." -Some guy that habitually wore a bedsheet.I have never really cared who said it. It's a great quote.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. ConwayYes, and if different parts of an organization don't communicate, then the systems they develop / procure will often be stovepiped.
I have seen this in a UK civil service acquisition organisation, that even lacked consistent shared engineering guidance for the different teams. They did at least approximately follow the same acquisition guidance so there were commonalities with how they approached industry and managed the bidding process.
I feel it's a similar reason books like Peopleware can still be so relevant - we've massively upgraded our computers, but the wetware is still the same as it was in the late 80s.
I wouldn't say it's the same.
In the 80s users knew less, while nowadays they're more clueless.
There's a big difference, like the difference between not knowing math (but having the openness to learn), and deciding that math is alien and you should shun it on principle.
so true
Ran into a lot of situations like this:
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.
That usually either gives the implementor enough information to wholeheartedly agree with the proposed solution, or to suggest something more appropriate.
If the project is a smaller one, then the developer is supposed to be acting in an analyst-developer type role. In my fairly limited experience the analyst part tends to take a back seat in these smaller projects.
I believe, though people are free to disagree, that it’s on the people developing the solution to ensure it satisfies the users needs. If the user is jumping to a solution, then it’s up to the team to take a step back and ensure the problem has been satisfactorily defined.
Note: I work on internal business apps used in a large corporation, and I have never worked on consumer facing apps.
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.
The interesting parts start to pop up when you need to make difficult choices. Good managers with a technical background are scarce and therefore not usually available. Sometimes you need to make a choice between a bad manager with a technical background, a good manager without a technical background and no manager at all. Whichever choice is made, it will never satisfy everyone.
Both the people part _AND_ the technical parts are the hard parts of technical management.
Of course some domain knowledge is needed.
My anecdotal experience with manager is either : they are useless and will rubber stamps things. Or they are actually involved, then, you want someone that has a vague idea of the process of doing the work. I vastly prefer someone who has produced code at some point. It’s fine if it was 10 years ago the last time it happen.
It's easy to say that something that seems simple when explained in simple terms is easy or quick to implement, but the people 'at the coal face' are often all too aware of the implicit complications of the task.
They need to build and facilitate a team to be run by itself and arbitrate on difficult decisions, sell team, etc, etc.
Also, you’re going to be manipulated and hoodwinked by the managers around you who are technical.
Lastly, the engineers you’re managing are going to laugh at you behind your back.
I’ve seen all of this happen before.
I do think when the team is more technical than the manager, he has to coach the team to communicate the useful information to him. It’s his job to be able to synthesize information and to ask questions that make the team think outside the scope of their work, try to find or tease out any gotchas. Lastly a manager should be aware of the impacts their teams work will have on others and intervene when he thinks something might go wrong.
It’s always positive when the manager has a very technical background or deep knowledge of the tech stack, but they should be aware of micro managing.
I read this as “leave it to the experts and please realise that sometime it’s not you” which is something that is sometimes quite hard for micromanaging delivery leads or business stakeholders when it comes to implementation details. Worst is when there are endless progress update meetings about some some irrelevant detail that then holds up the whole project.
Similarly it is quite difficult for developers to realise that leaving design decisions to user researchers and ux designers is a good thing!
"There's no such thing as a stupid question." "Design things for the person who's going to maintain it. It may be you."
Pretty much falls in line neatly with the All Of My Hard Work linkedin posts