I’m kind of like that but in the other direction. I disable JavaScript on everything by default, and if I run into a website or a blog that won’t work without JavaScript, most of the time I just give up and leave the site instead of enabling JavaScript for that specific domain.
This. I've also noticed that websites that don't run without JS are either interactive apps (for which it is understandable) or sites that want to load JS from so many places that I simply can't be bothered figuring out which ones to whitelist.
Some websites like Quora would go so far as to just lock me completely out with a blank page that simply says "Please enable Javascript and refresh the page to continue"
I have trouble believing that they absolutely /need/ JavaScript to load answers to random questions on what seems like a relatively static page.
I think it’s a choice to monetize your writings. Medium doesn’t force you to put your stuff behind a paywall. We need to stop blaming Medium and realize the authors wanted to monetize.
I could be wrong but even if you choose not to join the system I think it might still count against views. But you can dig into the story settings and get a referrer link that does not eat page views.
> "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.
> 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.
A non-manager architect should have some sense. They should know all the open problems in their domain and recognize who is solving them and how well they're doing it.
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.
> 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.
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
Well, of course you can only stop digging after you realize you are on a hole.
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.
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.
> 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.
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).
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. Conway
> whose structure is a copy of the organization's communication structure
Yes, 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.
This feels more like engineering-manager advice, not advice for engineers. And, surprise surprise, people are the same even in non-technical fields.
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.
> 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.
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?
There’s only the minimal amount of knowledge needed. I think a manager is no different than a soccer manager. Their role is to train the player for the role they’re best fit for. A manager has to build a team with the right skill sets. And I don’t mean just technical skill sets. You coach the player during one on ones and give feedback, and then during game time, you maybe yell strategic advice but the ball is at their feet, they’re now autonomous unit that needs to work cohesively. A good manager gets out of the way and steps in only when necessary. The more coaching and autonomy is given the more your players develop. The more they develop the more they’re capable of doing, and the more time the manager can spend thinking about higher level ideas and goals. It’s a nice feedback cycle.
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.
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.
Where I work, for larger projects, we have business analysts or product managers who are supposed to help with converting the user request into some sort of specification.
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.
Yes, I've found that a useful way around this is to go back to the non-technical user and ask them why. Why do you want to do this? Why do you want to do this in this manner?
That usually either gives the implementor enough information to wholeheartedly agree with the proposed solution, or to suggest something more appropriate.
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.
If the manager simply does what the tech lead think is the best decision then the tech lead should be managing instead. If the manager makes technical decisions without knowing tech then he should be fired for incompetency.
I do think that, and (to paraphrase The Mythical Man-Month) I also think that it would be great to work on a small and focused team with a clear mandate and no legacy stakeholders to worry about. So do we all, but those circumstances are not usually available.
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.
If your manager has no power to decide what you work on, who gets promoted, what deadlines you should have, who is to blame when things go wrong, who to fire etc, then sure he doesn't need to be technical. Otherwise he will just promote and listen to the popular guys and fire the unpopular ones.
If that was truly the case, then why do so many engineers complain about having a non-technical manager? Thinking that a manager does not need even a little bit of domain knowledge is something managers tell themselves to feel good about themselves, but it is not actually true.
Both the people part _AND_ the technical parts are the hard parts of technical management.
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.
Tech lead vs manager.
A manager isn’t managing tech. It’s people and process.
Classic HN. I am not saying they shouldn’t have domain knowledge. That would be silly wouldn’t it. You know, context and all that.
They need to build and facilitate a team to be run by itself and arbitrate on difficult decisions, sell team, etc, etc.
That has been a divide I've experienced between senior devs and tech leads vs product owners and managers who were not technical. The former tend to be pessimistic and the latter optimistic.
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.
Do you think a military commander should know anything about the military/weapons/etc.? Do you think a ship building manager should know anything about ships? Yes of course! It is a myth that you can have a manager managing something that he/she doesn’t understand. Without actually delegating their job to people who do (and then take the credit).
The managers without tech background are making bad decisions. But the advantage of tech background is not that you are able to assess any situation. It is more that you are less stupid and make less unenforced clueless basic mistaskes.
> Know what people are asking you to be an expert in
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!
How is it that this is literally the cycle. The product is great while they’re still in the ramp up phase, and then a few years later it becomes utter garbage, filled with ads.
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.