throwaway823882

I have been one of the toxic persons in a workplace. I was young and immature and an ungrateful arrogant prick. Not saying I'm totally reformed now (I still have my moments!). But every so often I see a little former-me running around. After a certain point I stop them and ask them to please calm the fuck down, because they are acting fucking nuts. That can sometimes result in a 180-degree behavior change (especially after a manager has already talked to them) because they usually don't want to get fired. I can't "fix" them, but I can give them the benefit of the doubt that they may want to be better, and may just need a nudge now and then to re-adjust.

Move to the east coast! We waste water like it's water.

> Is it ok to have if clauses that will basically never be run?

Yep.

> But when I thought about it more: should it be improved?

Nope.

If you are an average programmer, you should write your code first to be legible and maintainable.

If you are a smart programmer, you should add performance tests to your test suite (since you need to do performance testing anyway for any production-critical code) and run your app on the appropriate-sized machine.

If you are a very smart programmer, you should rely on performance hacks when your application no longer meets performance requirements under heavy load.

If you are a freaking genius, you should think about optimizing your code.

I never thought I'd say this, but: Thank you, Microsoft, for making useful, user-friendly software.

Make a company that does not suck to work for.

A lot of companies talk big about wanting to make their company "a great place to work". They talk about benefits, about inclusion, about a lot of ancillary things other than the work.

But when you start working on work, you find out there's a hornet's nest of beaurocracy, of office politics, departments run by finance rather than commitment to executing business needs effectively, lack of training, lack of industry standards, a sprawl of independent redundant silos, and a lot of people who seem to have no idea what the hell is going on. And of course they'll put you on-call 24/7 and force you to work overtime to meet unrealistic deadlines, without extra pay.

Most companies I've worked for, all of the engineers have known how shitty things are, and they've known how to fix it all. They tell their line-managers, and the line managers tell the middle managers, and the middle managers don't tell the executives. Everything stays shitty because the engineers are the ones who have to deal with the shit and can't do anything about it.

A contractor only has to deal with that shit in small bursts and can produce good work that somebody else can deal with actually running. It's the best way to avoid the long-term nightmare of working in shitty permanent roles. And the pay is better. And you can take a vacation!

New Ideas aren't crazy. Crazy Ideas are crazy. That's why people say it won't work, because it sounds crazy. It sounds crazy because the person proposing it hasn't made a good enough case for it.

Getting people to agree with a new idea is about salesmanship. If people think your idea is crazy, you suck at sales. Coffee's for closers.

If you don't experience seeing an American contractor getting decapitated by ISIS, then you may never have the gut-punch visceral understanding of how certain parts of the world works. Aside from actually getting kidnapped by ISIS, you can't experience it and truly feel the emotions of that act. Until you see a grainy, badly-compressed mobile phone video of someone slicing through cartilage and bone and sinew, a body twitching, blood trickling out from under the knife, a bunch of guys screaming and hollering and celebrating the victory of a murder. The body, headless, lifeless, being picked up and tossed in a ditch.

Now, watching that video won't help you understand ISIS at all. It may even completely color your interpretation of why the events took place, or who was doing it, or why. Is it better to walk around ignorant to a visceral understanding of horrible things? Or to walk around with new biases, after having seen something horrible with no context? Even if the "truth" is lost somewhere in between, I would rather know a little than know nothing.

We live in a world of "Nightly News" and platforms full of rules and restrictions. "Truth" will always elude us there, as long as someone else is deciding for us what we are allowed to see. It's nice to have at least one place where you can remove the filter.

Why can't these people just create a blog post and link to it? It takes 5 minutes. Blogging is free. You can actually maintain the blog post over time. It doesn't include 50 idiots' snarky comments. (That's what HN is for)

You sound like somebody who got exposed for trying to pay people with exposure.

Well, Fuck Netflix.

Can we work on getting real intelligence into Congress first?

Playing Quake doesn't make you a hacker, it makes you rad as fuck. But if they play Rocket Arena, your child is a G.G. Allin-level lunatic.

Which bias, the bias to want to multi-task? It's not a bias, we're just stupid. We think we can do multiple things at once. And we can do multiple things at once, so our stupid brains have proof that we can multitask.

The problem is that humans can't objectively qualify their own results without analysis, and we don't do rigorous scientific analysis on ourselves regularly, so we have no idea when something we do is shit or not. The only facility we have for that is comparison and pattern recognition, which is not rigorous analysis. If you don't go out of your way to compare your results as a multi-tasker to the cumulative qualitative results of somebody else doing two different things, you will never see that multi-tasking is worse.

I agree with this post 200%.

> Irecently spent some time trying to write a set of general guidelines for what to monitor in a software system

Reframe as "Shit That Needs To Run To Make The Customer Happy" and you get closer to what you want. Which is to say, it's completely product-specific. A general list of technical things to monitor is about as useful as monitoring the cotton thread fiber integrity of a pair of shoelaces. Is it the cotton thread fiber integrity what you care about, or a general quality of the shoelaces? Are they shitty laces, or just decent, or great laces? Quantify that.

> Typically, the former kind of PRR will take a quarter or more, because invariably, new large services have a significant amount of tasks to do to get them production-ready. The SRE team onboarding the service will spend significant time finding gaps, understanding what happens when dependencies of the service fail, improving monitoring and runbooks and automation.

I deal with these a lot of the time, and I hate them because they are so stupid. We could make these reviews completely self-service and automated and they'd move a lot faster, and could even be on-going as the product is actually released to customers. But SRE and Architecture remain their own silos, and neither of them work closely enough with the product team or core engineering groups to find the streamlined, agile ways of doing these things. Basically, none of them grok the concept of finding quicker and better ways to get this shit done. Or they just don't care to.

> The second kind of PRR typically does not uncover much to be done, and devolves into a tick-box exercise where the developers attempt to demonstrate compliance with the organisation’s production standards.

Architecture and SRE don't explain to the product team WTF they are going on about, so of course they just tick boxes mindlessly. Nobody wants to stop and understand the whole picture, so you end up with empty formalism.

The way to "formalize" and "standardize" the operationalizing of a product is to make it clear what the fuck is going on at each stage of your product. Who the fuck are my customers? What the fuck are they doing with the product? How the fuck does the product work for them, and internally? What the fuck are the external dependencies and how do they work? You need simple, practical ways to express these things.

And you also need to train people as to why everyone needs to understand these things. Why you cannot just allow someone to sit in their little corner of a room and jerk off and collect a paycheck. I often hear it from developers ("I just want to write code") but literally everyone else in the organization does it too.

Maturity models are just theoretical constructs designed to tell you what you aren't doing right. They aren't a roadmap, so their utility is about as useful as an academic research paper. Don't target what your organization should do around a maturity model.