throwaway6532

>And every country does it differently

Seems like the real world is just choc-full of Liskov Substitution Principle violations :P

The US tax system is the legislative equivalent of spaghetti code / big ball of mud.

>And in a world where we're unable to continue exploiting fossil fuels, whether due to the environmental impacts of their waste, or the lack of future supplies, the present mode of operation will end. What that means in terms of the set of factors affecting human impacts on the planet --- per-capita wealth and total population --- one or both factors must move.

Thanks for the book recommendation. Over time digging through history books and trying to wrap my head around how supply chains and agriculture work I've come to more or less the same conclusion. I feel so alone a lot of the time in understanding this stuff and it's refreshing to know that I'm not the only one who takes a look at things and goes... wait a minute...

This has been my line of thinking too.

You just actually quit if they refuse your hard 'no'. I was asked to be a team lead and turned it down as I know it's not right for me. I left my last company after they asked me to do a project in a similar way to an already disastrous one I was on previously. I said no, and left when it was clear that was the way they wanted the project done.

Well I just do it by putting the laptop on my chest and using an external keyboard that also contains one of those touchpad mice like laptops have. Works like a charm and costs way less time / effort. The chest gets a little sore if you use it for too long or too many days in a row, so lately I've been thinking maybe I need to elevate the laptop off my chest a little with a C-shaped table of sorts that the laptop can sit on can sit it on. I get into flow so easily working in such a setup, and wish I could do it more often. I'm considering investing more in my work from bed setup.

Comments like this are why I find reading HN to be both depressing and cathartic at the same time. That's quite an achievement.

Sounds exactly like my current job.

Perfectly describes my last job.

>In my mind, it happens when autonomous systems optimizing reward functions to "stay alive" (by ordering fuel, making payments, investments etc) fail because of problems described above in (a) -- the inability to have deterministic rules baked into them to avoid global fail states in order to achieve local success states. (Eg, autonomous power plant increases output to solve for energy needs -> autonomous dam messes up something structural -> cascade effect into large swathes of arable land and homes destroyed).

And for this to develop in machines, machines would have to be subject to many mistakes along the way leading to all kinds of outcomes that we hold humans accountable for by fining them, sending them to jail, some of them dying etc. I think that would be so wholly unpalatable to man kind they'd cut that experiment short before it ever reached any sort of scale.

I agree with your conclusion that enough of the rules can't be encoded by us as we don't even know them and for machines to acquire them the traditional way is, I believe, fundamentally disagreeable to humans.

>Oh, we do it better. We just replace step 2 and 3 with "Executive management says the same set of empty slogans they've been saying for years whenever these problems are raised, thus all but admitting that nothing is actually going to change."

This. I've learned to completely ignore what companies state their values are and/or these slogans they trot out. Culture isn't a poster you put on the wall.

>Not that I’m bitter or anything.

Hahahahah. Me neither man, me neither.

>I'm increasingly convinced that a large portion of our problems as a society is our absolute refusal to hold anyone in power accountable for anything.

Well the problem is you try and then you disappear either because you self-select out of that environment or you get managed out because that's an easier problem for the manager to solve because it doesn't involve admitting they're the problem.

It's sad but true.

Turns out I'm covered in lint and basically a walking fire hazard.

>I asked a psychiatrist friend of mine what they do when someone shows up depressed for reasons that are totally reasonable. She said they try to use drugs and therapy to generate some minor delusions that would help the person feel better in their environment.

I've literally just been through this, and I can 100% say it actually helped. I'm still on the drugs but I've got just enough tools to create just enough minor delusions to ride out the current funk and get to a better place where I can come off the drugs. I'm pretty glad I caught it in time as I can totally see what that level of stress/anxiety/depression does to people and I'm particularly vulnerable to it.

>Simply switching from a monolith to microservices makes them more thoughtful about the consequences of design.

Well, in my experience it makes _some_ people more thoughtful about those things.

Welcome to software development. Expect it to be like this forever and continue to get worse. Tech seems to have 5 year cycles in which a problem has gotten enough peoples nerves over the previous 5 years that a new abstraction comes out to solve it which people then adopt and develop a love/hate relationship with over the next 5 years and wind up either inventing or adopting the next abstraction to deal with the current frustrations.

It's not all bad. In my 8 years in the industry there has been an incredible shift in what a single person and/or small teams are capable of versus the status quo at the time. It comes at what I can only describe as a Schrodinger Cost - i.e a cost that is sometimes worth it and sometimes not.

There is no 'science of future events' only probabilistic outcomes based on models underpinned by chains of inference. The longer those chains of inference the lower the conditional probability the entire chain is correct becomes. Those models don't account for black swans Russia invading Ukraine and that suddenly massively changing a large portion of the worlds calculus on what sources of energy to leverage in the short-term. We have decades of data to draw a pretty good gut feel from looking at Kyoto Protocol and Paris Accord and COP26 and it's always the same story - "hey we're going to hit an iceberg!", "OK, well then we'll steer away from it :)" rinse repeat. I keep up with technological improvements that can help us avert disaster, but I also look around me and see human behavior changing not nearly fast enough. I dunno man... this is less of a 'science' thing for me and more of a human behavior thing.

My take on "Don't Look Up" was that it's actually a documentary, but it had to be made ahead of time because we won't be around to make it or see it after the fact. Don't forget to like and subscribe.

>I see this often when climate change is discussed. People seem to casually throw science under the bus when it suits them.

I think it's because people see humanity casually throwing the planet under the bus when it suits them despite what the science says. Eventually you just kind of see the writing on the wall (or _feel_ like you do).

Thanks for your response. I definitely agree that bikeshedding can be a problem in code reviews and bikeshedding itself is best avoided for sure. Automating that stuff away with linting tools is a good tool in the toolbox for that, and so to is having some conventions and/or understanding and accepting preferences of different team members and not actively engaging in bikeshedding over things that are a difference, but not a difference that makes a difference.

In my experience the value of code reviews doesn't come from nitpicking those types of things. That's by far the worst part of code reviews and is definitely annoying but mostly becomes not a problem if you employ the abovementioned tools/practices. Rather the value comes from others picking up mistakes in the quality of your implementation that arises from some gap in knowledge that the reviewer is able to pick up on and fill in. And to that end they're absolutely essential. They're not simply a box ticking exercise either - the amount of code reviews I've both done and received that picked up on actually important issues is in the high double digit percentages. I would take no code reviews to be a major red flag.

>There is a continuous stream of bad ideas being implemented. And when a bad idea gets implemented, it is really hard to undo it and it tends to just create more chaos.

This describes all aspects of software development.

>We are in an era of mythologizing that old white men are at the root of all problems, so thinkpieces like this have to mention old white men as a matter of course.

That we've gotten to this point must also be old white men's fault.

Precisely.

You could replace the entire thing with "shorter feedback loops" and it would be significantly more meaningful.

>Agile as per the Agile Manifesto isn't bad. At all.

If you actually read it it really is just a bunch of words that doesn't specify much of anything at all. To me it reads as something incredibly vague and hand-wavy and how on earth modern Agile has been inferred out of the text of the agile manifesto is somewhat beyond me.

This is an amazing list, though I'm curious given how accurate the rest of this list is how you drew the conclusion that code reviews are a waste of time?

>We need to talk about a "software archaeologist" specialty where one tries to plow through a mound of garbage left by the predecessors and seeks to figure out what prescriptions their therapists had written for them

Reminds me of one of my favorite quotes about software/computer systems - "we build our computer systems like we build our cities - over time, without a plan, on top of ruins."

The reality is sometimes the market decides to do terrible things.

If it were always paid then one could just game the system taking such take home tests as a second job. Since they're relatively small in scope you'd quickly (if you haven't already) build up a code library containing a cache off pre-solved problems allowing you to punch them out relatively quickly. Heck, you could even do it as a full-time job.

>It's the reality of how large organizations keep their teams stable with employee turnover and also slightly grow them. Yes, teams will work to fill their roles directly too but often the team will show up for work on a Monday morning to find that they have a new member of their team who they've never met but is an 'extra bonus' or the headcount has been filled anyway.

Can confirm. Just had this exact Monday morning.