I sometimes wish I did not post under my real name. But man, it's a decision I made for a reason.

Is this kind of jumping from one gig to another something you used to do before you started programming?

Did something happen?

I would occasionally like to vent or express things that happen at work, but I won't, because people who work there might find it.

I use my real name because I'm kind of an *******, and being anonymous in the past has only accentuated that. Using my real name keeps me remembering... your mom or your boss or your friends could read this. Don't say things you wouldn't want your mom or your boss or your friends to see.

It has occasionally caused problems for me at poker games.

Well I will say it's incredibly impressive both in terms of self awareness and constraint.

I post hoping for anonymity but knowing it's trivial to break so similarly I try to avoid things people close to me may see and not appreciate.

The differences between anonymous and named communication on the internet is something that has always fascinated me.

that's funny. fwiw, i would have never guessed this, so your self-policing must have worked.

It's amazing how many people don't understand this simple rule and just go nutzo on the internets.

Our IT/engineering dept is ~>50% remote and we all met up last week for dept wide meetings. Overall we trend older and I would say most people have kids.

I had the worst cold I've had in years (probably the flu tbh) and I think I can directly trace it to these meetings.

Is this a common problem for remote teams?

I get sick more often when traveling and I definitely get sick from the kid.

I haven't really noticed it as a "remote team" problem, but wouldn't be surprised.

Almost every time I start a new job I get a cold within a month.

I worked at home for almost 4 years, barely got sick at all. Now I'm in an office with 100 ppl and get a cold/mild flu 2-3 times a year (basically every flu season).

Yeah it's surely just people.

In flu related news, just spent 10 mins debugging an issue caused by forgetting to all caps an action type in one instance.

I hate those. I spent a few hours looking for what turned out to be an arrow pointing the wrong way in an R function definition...

My favorite thing is when you take something like this in python

and decide to refactor it a little via cut/paste

(in python, accidentally appending a comma makes saved_val into a tuple)

Sounds to me like a type checker in a statically typed language would've caught all of those :P

I know this is a joke, but it depends.

Consider

And consider further that we are checking "x is supposed to be a tuple"

This would pass that check, and still, the value would be "wrong". It would fail a check like "x is supposed to be a tuple of ints" and some statically typed languages would catch that, but plenty of languages are just like "you can put whatever kind of object you want into containers" (I think Java is like this, or it was when I learned it, uh, a long ****ing time ago)

Languages that don't allow the "this is a container of random types of objects" can be really hard to work with btw. You end up with mazes of subclasses made specifically to store simple data.

I was a carpenter for a few years, but being that I was non-union, it wasn't beneath my standing to bust out a wall or throw concrete. In any case, I was doing another totally unexpected income at night during those years.

Almost my entire working career is day / night dual-incomes, so bike messenger / banquet server, construction / radio, phone customer service / fire eater, promotional products / ebay seller, etc etc etc.

I've never had much luck working a single job. I've tried, but it went bad every time. Not sure why people put that kind of faith into their employer, so always have a second something, IMO (or get married like normal people, I guess).

That "Not sure why people put that kind of faith into their employer" is straight crazy talk.

There's no way in hell you can convince me that at my worst sales job with 60 day hard quotas or termination I was anywhere near as risky weighted as working phone customer service and eating fire.

Having 2 low paying jobs isn't a hedge against having 1 decent one.

Question for Wolfram or any other Go experts. Here's a code snippet that caused a problem for me today:

These variables are of the type net.Addr, which is an interface. I assumed this would perform struct-level equality, and I was wrong; it did pointer comparison, and even though the addresses held identical data, it executed the code in the if.

So, uh, what's the right way to do this? This kinda led me down a rabbit hole of how interfaces, despite being the same type on the surface, can hold either a struct (if they did in this case, my code above would have worked as I expected) OR a pointer, and behave differently as a result. In C++ you at least know what type of object you're dealing with (if you have pointers, you can dereference them to compare data equality), and I'm not sure how to deal with this uncertainty in Go.

It's extremely unlikely and probably impossible in most statically typed languages because even languages that lack generics still have built-ins that are generic (C, Java and Go all lack generalized generics but typed arrays) and containers that aren't built-in tend to require you to specify the type during initialization and type inference, where applicable, usually has to be unambiguous for programs to pass type checks.

What language do you have in mind? I can't think of any mainstream langauge where this is true. Allowing typed collections is not the same thing as disallowing untyped collections.

The only languages that came to mind that didn't directly allow this are functional programming languages where you could trivially declare an algebraic data type to suppor this case and you wouldn't need to create subclasses.

I've written some scala code that suffers from this, although case classes make it a bit less annoying. Mostly converting between class objects and json in the play framework is painful for this reason. Generally though I still find the benefits of static typing to outweigh the negatives most of the time, especially when you start making changes to larger code bases. And yet it always feel so easy to slap out some javascript. Except now we're moving to typescript here...

if addr.String() != sock.addr.String() {

The point of interfaces as I understand it is to abstract away what's under the hood - you only interact with its methods.

One thought I had is that you may have spent too much time in low-trust environments. We've been doing some home renovation and been hiring a bunch of contractors, handy-men and what not for all kinds of stuff and it was interesting to see how people behave in a low-trust environment - most business in that world seems to be one-off without that much in the way of previous relationships - how many times are you going to install central AC or renovate your kitchen - so everyone's somewhat defensive and paranoid, at least compared to the corporate world. It seems to me that spending too much time in that kind of environment will damage your ability to work in a high-trust environment because you come across as excessively cynical and paranoid, not to mention spending a lot of energy guarding yourself against phantom threats is suboptimal in a competitive environment.

Does this make sense at all? It seems to me that a lot of people with no concrete skills (not even great social skills) often get paid 6-figures mostly for their ability to act normally in and thereby sustain a high-trust environment. You seem like the opposite case.

Ugh, yes. It honestly feels silly at this point to use a static language for a JSON api. Currently writing one in node and one in scala and its unreal how much more painful it is in scala