ttz

Like all things... this too shall pass.

Savantism is a separate concept from autism, though popular culture has somehow associated the two.

I realize my initial analysis is kind of wrong - everyone picking blue would also ensure everyone survives.

So I think the color doesn't really matter if everyone is rational. So long as they are consistent.

Blue is more tasteful here then. With the added bonus that if enough people do pick it, it's a win.

What is interesting is if you believe most people are not rational and will pick red, but at least one person will pick blue.

Do you choose certain death?

For me, who has dependents, it would rest on what I think they would choose.

A very interesting problem....

if everyone were rational, and knew everyone else would act rationally, then obvious answer is to pick red, because everyone would pick red, and hence everyone would survive.

modulo 2

root cause is believing anecdotes of people on the internet

> Alternatively, where possible set the server timezone to UTC so that no daylight savings changes will happen at all

this is the way

NPEs are also present in a lot of languages with "stronger" type systems though. Is there a specific language you're comparing against?

out of curiosity (not meant snidely), do you have an example of a case where the weaker type system resulted in serious problems?

in tech? oft times you just look at your manager or skip level

Ah, I see what you're objecting to. Yes, it is build tag trickery, and wouldn't work without it

Yep - my point was that _test is not the only exception to the "rule"

You can also include

package main

files in a non-main package directory (usually sed when implementing go generate)

> contrasting craftsmanship and utility, since both are somewhat prized on HN

I'd say they're prized everywhere, though "craftsmanship" is really subjective. and the HN I usually [edit/add: see] seems to have more a meta of "criticize anything someone tries to build, and rave about IQ" tbh ;)

SQLite works and I don't have to think about it why it works (too much). That is IMO a true hallmark of solid engineering.

It hurts because it's true

The amount of staffs at my place who build pointlessly complex bullshit that doesn't actually do anything different is too damn high

Thank you for this relevant insight.

You can still design for evolution and follow best practices. That's actually IMO a hallmark of good software design.

The issue is when the evolution is random and rife with special cases and rules that cannot be generalized... the unknown unknowns of reality, as you say.

Then, you just gotta patch with if elses.

I was recently having a conversation with some coworkers about this.

IMO a lot of (software) engineering wisdom and best practices fails in the face of business requirements and logic. In hard engineering you can push back a lot harder because it's more permanent and lives are more often on the line, but with software, it's harder to do so.

I truly believe the constraints of fast moving business and inane, non sensical requests for short term gains (to keep your product going) make it nearly impossible to do proper software engineering, and actually require these if-else nests to work properly. So much so that I think we should distinguish between software engineering and product engineering.

every language has its problems; Go I think is pretty good despite them. not saying points raised in the article are invalid, you def have to be careful, and I hate the "nil interface is not necessarily nil" issue as much as anyone.

It's hard to find a language that will satisfy everyone's needs. Go I find better for smaller, focused applications/utilities... can definitely see how it would cause problems at an "enterprise" level codebase.

Not arguing against you in any way, but IMO, if you're at a place where politics will dictate your _actual continued employment_, it's probably not somewhere I'd particularly enjoy working.

Not following the relevance here. I acknowledge and am aware this is very common, and it's a shame. But seems like a separate discussion.

Why does it matter if you don't get promoted? What if you like doing good work, making all that impact by osmosis anyway, but do it for the sake of just liking your damn job?

As someone who wholeheartedly agrees with this statement, I do wonder why this mentality is so prevalent. Is it just a consequence of natural selection? Those who want to grow and compete will inevitably dominate those who do not, and so propagate more?

> They inherit a codebase that successfully made enough of the right quality-vs-speed tradeoffs

Or was lucky enough that all the choices they made did not blow up yet.

I totally understand the value of technical debt. But I have also seen in the wild cases where people thought the codebase was great simply because they hadn't run into cases where its rotten core would be exposed.

Yet.

Google Datastudio, if you're fine with something in the cloud hooking up to your DB (and whitelisting the IP).

Metabase or Apache Superset, as others have mentioned, can be deployed on-prem so it's a bit more isolated/secure.

Yeah pretty much this.

If a paradigm (whether functional, OOP, or whatever label makes you feel better) isn't working for you when it has worked for many others, maybe it's not because the paradigm sucks... it's because you might just suck at the paradigm?

Obviously there are cases where things were pigeonholed into the wrong paradigm for the job. Then it's a case of the person choosing the paradigm sucking at choosing the paradigm. Whatever happened to personal responsibility?

revised solution?

"

i am going to send a random posint next round, and will continue to do so until you also send a random posint.

When we both receive posints, if they are identical, resend.

Otherwise, if both are the same parity, then we should choose red on the following round. otherwise, blue.

If for some reason your message details a strategy similar to this but with a different color decision based on the parity, then we should use the larger posint sender as the one to dictate the color decision strategy. "

ah, yes, good point. thanks for the catch!

am i finding some of the comments here over analyzing?

you can assume neither of you will end on the first round with a color.

message on round 1 = "if you send me a color, let us choose the most alphabetically earliest of your color and my color, which I am sending as red. if you did not send a color, i will not say anything, and logically, you will not either"

repeat each round if they continue to not send colors.

i find python generally quite pleasing to code in; django by extension is quite nice as well. well designed mixins and class-based views can make a project very smooth.