Doc Avid Mornington

Github != Git

That’s how you talk?

If your SQL model has nulls, and you don’t have some clear way to conserve them throughout the data chain, including to the json schema in your API contract, you have a bug. That way to preserve them doesn’t have to be keeping nulls distinct from missing values in the json schema, but it’s certainly the most straightforward way.

The world has more than three languages, and the way Java and Python do things is not universally correct. I’m not up to date on either of them, but I’m also guessing that they both have multiple libraries for (de) serialization and for API contract validation, so I am not really convinced your claims are universal even within those languages.

I am not the other person you were talking to, I’ve only made one comment on this, so not really “hellbent”, friend.

Yes, I am pretty sure I read the comments, although you’re making me wonder if I’m missing one. What specific comment, what “case specified above” are you referring to? As far as I can see, you are the one trying to say that if a distinction between null and a non-existent attribute is not specified, it should universally be assumed to be meaningless and fine to drop null values. I don’t see any context that changes that. If you can point it out, specifically, I’ll be glad to reassess.

Thanks for sharing this, it’s quite interesting. I found a Wikipedia article on it: https://en.m.wikipedia.org/wiki/Unary_numeral_system

Apparently, as you did suggest, “base 1” is a name that is used, but is somewhat a misnomer.

The article mentions that Church encoding is a kind of unary notation, which I would not have thought of, but I guess it is.

Enjoyable little rabbit-hole to zap my productivity for the day.

You seem to have missed the important phrase “in source code”, as well as the entire second part of my comment discussing that runtime functions that parse user input are different.

At the (SQL) database level, if you are using null in any sane way, it means “this value exists but is unknown”. Conflating that with “this value does not exist” is very dangerous. JavaScript, the closest thing there is to a reference implementation for json serialization, drops attributes set to undefined, but preserves null. You seem to be insisting that null only means “explicit omission”, but that isn’t the case. Null means a variety of subtly different things in different contexts. It’s perfectly fine to explicitly define null and missing as equivalent in any given protocol, but assuming it is not.

Closer to tally marks without clustering

Who calls it that? Who even uses that enough to have given it a name? Seems completely pointless…

It’s been a long time, but I’m pretty sure C treats a leading zero as octal in source code. PHP and Node definitely do. Yes, it’s a bad convention. It’s much worse if that’s being done by a runtime function that parses user input, though. I’m pretty sure I’ve seen that somewhere in the past, but no idea where. Doesn’t seem likely to be common.

I am definitely not at my most productive at the start of the day.

It’s better to have useful comments. Long odds are that somebody who writes comments like this absolutely isn’t writing useful comments as well - in fact, I’m pretty sure I’ve never seen it happen. Comments like this increase cognitive overhead when reading code. Sure, I’d be happy to accept ten BS useless comments in exchange for also getting one good one, but that’s not the tradeoff in reality - it’s always six hundred garbage lines of comment in exchange for nothing at all. This kind of commenting usually isn’t the dev’s fault, though - somebody has told a junior dev that they need to comment thoroughly, without any real guidelines, and they’re just trying not to get fired or whatever.

Or gets promoted, and keeps moving on to new and bigger projects, leaving a trail of destruction, because all management sees is they close tickets faster than the people who are busy picking up the pieces behind them.

So, writing stateless functions, or working in declarative languages doesn’t count?

I get the feeling you feel like I was somehow calling you out. I want to clarify the the intent of my message was more in the spirit of “wow must be nice” than “you’re making that up”. But also I’m just interested in how different your experience is from mine.

Who said anything about only requiring 1 reviewer?

I must have misunderstood. You said “If no one has reviewed your change within 24 hours you are allowed to approve it yourself.” To me, that sounds like, after 24 hours of no review, one self-approval is considered sufficient. That, in turn, seems to imply that before 24 hours, one non-self-approval is probably sufficient, no?

You should try working for a healthy team where everyone takes collective responsibility and where the teams progress is more important than any one person’s progress.

I’ve had team members in the past who are very self-focused, they tend to close a lot of tickets and look good, then get promoted out, leaving an unmaintainable mess behind. Allowing that is generally a failure of leadership. But right now, that’s not our problem, and what you describe is pretty much how we operate.

I’d love to work on a team where everybody took code review a lot more seriously, believe me, it’d be nice, but my team does generally get everything approved, with at least two non-self approvals, in under 24 hours. If something is getting ignored because people are busy and it’s a large change because we aren’t perfect, and there is some reason to get it in soon, it just takes a quick request on Slack to get the needed attention.

What I found surprising about your description was more that the potential of a self-approval coming up would, in itself, get people’s attention, rather than somebody reaching out personally and asking for a review.

Our big weakness is review quality, not quantity. It’s crazy the number of times I look at something and see the two or three approvals already, start going through it, and find issue after issue. I see that on other teams as well, where there’s usually only one or two devs who ever really make any comments on a review, it seems to be very common.

which usually leads to someone taking a look

Nevermind the idea that one reviewer is somehow sufficient, this sounds like pure fantasy. Did you forget a “/s”?

But an irreplaceable liability.