eriktate

While I agree that it's for managers and stakeholders, I wonder how much of it ends up being a net value-add. Where I work, we have a million and one different kinds of reports that pass through the chain of command (admittedly not all of these are derived from Jira, but they exist for the same reasons). We then end up with arbitrary, company-wide reporting requirements that for a lot of teams are like fitting a square peg in a round hole. Then, when you show up as non-compliant on the report that doesn't actually say anything valuable about your team or project, you have to drop everything and shoehorn some solution to make the report happy even though there's precisely zero value added (I would argue a net loss because time and effort is wasted while adding zero value). All because inconsistencies in the reporting aren't tolerated since upper management can't be bothered to understand even the smallest amount of nuance.

I know most of the people in these positions aren't _actually_ stupid, and would agree if you were able to explain to them why some specific thing is completely irrelevant, or even detrimental, to your team. At the end of the day, though, at big orgs no one cares. They'll waste as much time and effort as necessary in order to look good on metrics. Even if the metrics are worthless.

> And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using.

I tend to conflate higher expressiveness with being "clever" until you're really proficient in the language. I think Go's main value prop is that it performs well with very little ramp up time compared to languages with more powerful features.

If you have a team of people who are really strong with something like OCaml or Scala, they'll be amazingly productive. But if you have a rotating team of engineers with varying backgrounds, it's hard to beat Go when you're talking about time-to-productivity.

I welcome salary discussions with any coworker who wants to talk about it, but I almost _never_ initiate the conversation. It's still too much of a taboo with many people to be worth the risk.

Nothing big ever got built by a bunch of self-centered loud mouths either. And these are typically the types that find themselves in these roles.

I think you're making a big leap saying "let them deal with the frustrations of relationships". Nowhere in OP's post does he mention disliking people. In fact he seems proud of the fact that people come to him when they have questions. You need more than pure technical acumen for people to feel comfortable coming to you.

Situations like these are complicated, and I'm not sure there's enough information to make a judgement one way or the other. I do think taking the "high road" here is not always the best course of action. If you're more interested in the success of your team or your product, you will remain ripe for being used by those more interested in their personal success. It's a toxic circle that's hard to escape once you find yourself in it.

My advice would be to heed the red flag and look for work elsewhere. If you are being leaned on as heavily as you feel, then it will likely become apparent once you move on to greener pastures.

I think it depends on how you define fun. For me personally, does a workplace need to have alcohol, video games, bowling alleys, and ping pong tables? Probably not. It does need to be interesting though. And my co-workers/team need to be enjoyable to be around, both professionally and personally. If I'm not consistently having a good time at work, which could be construed as having "fun", there's very little reason for me to stick around. Especially in the tech scene, there's always a better place to work, so it's competitively advantageous for companies to have "fun" workplaces.

I'm surprised that you would lump Go in as a "super-tanker" language. I find it incredibly small and simplistic when compared to something like Rust. I think it actually has fewer keywords than C.

>"Stuff like lambdas weren’t born in some hipster language, they came from JavaScript"

Lambdas are actually so hipster that they were cool before we even had programming languages: https://en.wikipedia.org/wiki/Lambda_calculus

As far as I know, Lisp was the first language to actually implement the idea. I actually struggle to think of any language concepts that were introduced by Javascript.

I also tend to disagree with the overall sentiment that new languages aren't a good way to influence programming. Haskell, for example, is quite a departure from a language like C. I don't think we would've ended up with the great, proven options we have today if everything was just incremental changes on some base. Sometimes you need to rethink things from scratch. It's part of the reason we don't have one language that fits perfectly for all problem sets.