Comment by shados | Hacker News Reader

Comment by shados | Hacker News Reader

Parent Full thread

I definitely felt this decades ago when I started in the industry.

It's 2019 now though. only 8 years later, but a lot of things changed.

The industry is growing fast, faster than knowledge can be shared even with all the power of the internet. It's very bottom up, with newer engineers severely outnumbering those that have been around. People are making fat salaries and companies are catering to their whims. They/we're more spoiled than they've ever been. People go to work hoping they'll be find a reason today to try the latest pattern they saw on Twitter or try the trendy new tech or library their friend just talked about.

If you don't have people saying no, it quickly (very quickly) get out of control. As organizations grow, you need to start saying no. A lot. Else within 0.2 seconds of the new intern joining or the new grad coming in, or the lateral hire who was the king of their 5 people startup will be pushing some stuff that isn't mature enough or doesn't follow established patterns. More often, they'll be reintroducing something problematic that you just finished getting rid of 6 months ago.

It sucks. Sure, there are some power hungry people who get off on power trip by being gate keepers. But overall, it's just people desperately trying to keep things in one piece and the company going, and that means making hard decisions and enforcing them. It just doesn't feel good to say no, arguing all day with people who have way more energy than you do, but it has to be done.

Tim Cook agrees - "The hardest decisions we make are all the things not to work on. There is lots of things we'd like to work on but we can't do everything great. Most companies do larger and larger portfolios because its so easy to add. It gets hard to stay focused. Yet we know, we can only do our best work if we stay focused"

There's a big difference between saying "no" to the right things (valuable) and a borderline oppositional personality disorder (not valuable). There's an art to saying no. Ideally you look for ways to say yes, and try and distill the nuggets of value and work them into your future plans while acknowledging that now may not be the right time to pursue them. Or nerd-sniping them with other ideas to leverage their enthusiasm and bright-eyed/bushy-tailed attitudes. Likely they're just looking for impact and don't know how to get it.

Otherwise you're kind of a dick, and nobody wants to work with that. Unless you're in charge and they can't get away, I guess.

That is why you write that in a standards document, along with the reasons why and have a consensus about it. That way it becomes impersonal.

Same thing with auto formatters and linters sidestepping a lot of pointless bickering and bike shedding.

That works for things you want to DO, but is hard for things you DON'T want to do.

As I mentioned in another post, as your org grows, there's going to be an infinite amount of things people push, and pushing back is hard. If you have to stop and write a consensus document for every single one, you'll be doing nothing else.

With things you don't want to do, you make it concise with a whitelist. Like 'we only use these 2 languages for our backend and here is why:'.

If you have the authority to tell people no in the first place to make it stick, you have the ability to write that in a wiki page. You can go full FAQ mode for the miscellaneous stuff as it comes up.

Documenting the why is really important, so you don't get zombie decisions self perpetuating in your org and allow for change.

How hard is it to say "these are the types of things we want to do. anything must look like these types of things in terms of (insert x y and z criteria: size, scale, opportunity, profitability, growth, etc)

spoiler alert: it isn't hard and this is what we do at my startup that is currently experiencing hyper growth and is on multiple "unicorn" lists

I can't even tell if it's satire. But if it's not: I haven't see it be done easily over several hundred engineers. If you have that kind of charisma, hat off to you!

Charisma is certainly something I have never been told I lack. Maybe we are lucky and have the right people as well.

Linters are probably the single biggest productivity boost an organization can engage if they don't yet have one.

It's still personal: it's "authors of the document" vs everyone else. Often the "everyone else" have not been hired yet.

> Often the "everyone else" have not been hired yet.

And they may never get hired and you still have to fight with them.

I'm, honestly, TERRIFIED of what "thought leaders" may post on hacker news/twitter/reddit tonight, tomorrow, next week. The moment I see one of them suggest something that just wouldn't work for us, I -know- I'm going to have to fight 50 people at work soon who drank the koolaid.

If something is written down before you were even hired and it says no, then you know that the people are saying 'no' not because they don't like you or some other petty interpersonal political reason, but because of the actual technical reasons or some overarching political reason unrelated to you, personally.

When something isn't personal, it diffuses a lot of emotional tension. Our monkey brains jump to taking things personally way too easily probably as some sort of early tribal instinct for survival.

I don't really understand what you mean by personal otherwise? I was implying 'personal' was specific person personal.

I've had the opposite experience. Working for a "no guy" who was hired fresh out of school, stayed at the same place for 8 years or whatever, and then blocked anything anyone learned from working somewhere else.

We started to wonder if his blocking of everything was just pathological because the tech stack wasn't all that great.

I have to say "no" a lot in my role. Thank you for this post.

> it quickly (very quickly) get out of control

javascript

JavaScript is indeed a very good example of this. Not just in the ecosystem, but even just the standard itself. People are pushing for more and more stuff. People on the committee can say "no", but there's an infinite amount of bullshit to push, and only a limited amount of time to push back. So sooner or later, bullshit makes it in.

What are examples of bs in the javascript standard?

Not in the standard yet, but good incoming examples are decorators and private fields. They are not bad in all languages, but the way they are getting pushed in JS is awful.

String (capital "S") class.

I think that it is good. These functions for primitives (String, Number, etc) are good, one thing sometimes to call it, and also because of the prototype. Also, there is such thing as String.prototype.constructor and Number.prototype.constructor and so on, which I have used for parsing command-line arguments (to replace the default values with the user values, converted to the correct type).

Why don't you like Strings? All prototypes (Number, Array etc) have a capital letter.

Automatic semicolon insertion

JavaScript

arrow functions

curried functions

Even before I became the manager, as a Lead I felt half my time was explaining to younger, less experienced engineers why "no, we should not" introduce something.

And it really was an explanation, not a condescending or dismissive refusal. That part is key.

I wish more places understood this. Change of leadership where I am is causing so many issues because there isn't any substantiated reasons why something is a 'no'. Its just 'no', and attempts to get clarifications and how to proceed in the future are met with little clarification (and sometimes ignored altogether)

All while you're the "no wizard" ;)

"Chesterton's fence".

The opposite. In this case people saying no are the ones understanding, and people complaining about them are the ones who don't have the full context. Of course the job of the people saying no becomes to document this, but at large enough scale its hard to get people to read the documentation...(and even when they do, its hard to internalize it).

Chesterton's fence is about taking away things we don't understand.

There's a big gap between that and fighting cargo culting.

CF is about, generally, changing a thing without understanding why it was set a given way in the first place.

Where it is necessary to change (or to make changes) without full understanding, at the very least, instrument and observe for some time.

https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence

Yes, about changing the status quo.

Aping someone else's fancy, new solution is not the status quo. You have no way of knowing how badly they have steamrolled Chesterton's Fence.

But you really don't know if it's cargo culting until you know why the fence is there.

Reply on news.ycombinator.com