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.
> 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.
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)
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.
> 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.
Mergers & Acquisitions are a foundational part of building any major conglomerate or corporation. Every industry does it. Energy, Media, Technology, Healthcare, Finance, Food, Clothing, whatever. Big Anything can be measured by this, but the sheer number of them does not mean as much as how much of the market they suck up through each one.
The unstated end goal of every capitalist organization is to become a monopoly. Do people just not want to acknowledge this? Because that's kind of what every decision of competing corporations is always leading towards. You can't gain infinite capital unless you are always absorbing or eliminating more of the competition. The whole point of competition is not co-existence, it's domination.
1) Switch your bank account, 2) there are apps out there that replace the entire UI with a blank screen with 7 or 8 pre-selected apps (for Android anyway) and silence notifications. Helped me a ton, my phone doesn't grab my attention or show me anything unless I make it. I think the premium versions may allow you to completely block apps (like the App Store). Otherwise look into "Parental Controls" to lock down the phone to essentials.
If you feel you're about to start doing something on your phone that you don't want to, force yourself to get up and do 10 pushups, and then go accomplish some task that you have already set for yourself (chores, make a phone call, plan your day/week). If you can stick to it, the worst case is you'll be getting stuff done in addition to wasting time. Best case, you lose the interest in the scrolly thing because your attention gets focused on something else.
Nit-pick: I don't like the language of wins [versus losses]. I get that people like short words that are associated with happiness and success, but the underlying messaging are that if we're not winning, we're losing, or that we "have to win".
In reality, failure should be normal, expected, and even desired, because if you're not failing, you're not trying new things or taking risks. You should lose sometimes. But success is preferred to failure, so I would prefer to get Tiny Successes through Tiny Improvements.
> Are non tech companies really that foolish to think they can salvage a brand that was relevant 10 years ago and revive it?
Sure you can, though branding isn't the only way to make a successful business. Kleenex knock-offs thrive even though nobody ever says "please hand me the Generic Tissue Paper". Assuming there are professionals involved (not just rich techbros that have held on since founding) tech companies should be operated the same as non-tech companies. Build a good product, keep costs down, drive sales, put away cash, grow your market.
Once AOL and Yahoo were acquired, it should have been possible to convert them into factories for generic content and services, and service many small brands. But you need an experienced executive and management class that can do this efficiently. It's much easier to turn an acquisition into an poorly-run independent cash cow, or plunder its IP and eliminate it.
I've seen acquisitions go many ways. In some, the parent company may end up more like the acquisition because its business or product was more robust. Other times the point was to obtain some tech and absorb it into the parent company's products. Other times they just wanted a steady cash flow and a foothold into a new market. Sometimes they keep the acquisition fairly independent, because it already has a strong brand and products and they seem to be fucking up less than other acquisitions. Sometimes the companies' execs were literally just golf buddies and one just decided to help the other out of a bind. Sometimes they have no idea why the fuck they bought it or what to do with it, some moron at the top just thought "we need an X, we'll figure out what to do with it later". Sometimes
In general, for a very large old project that has no major problems with SVN, it's easiest to just leave it. Lots of open source projects are still on SVN (some even on CVS...)