_5yoy

There were two deaths, one of which was a black man being murdered by Proud Boys, and the other does not have evidence suggesting it was related to the Seattle AZ (other than they were near the perimeter).

> A lot of them expect you to tell them how, but they will refuse to ask for help until too late.

Software is an industry in which people are criticized frequently for doing things differently than how others would've done them. This results in devs (that are less confident with that type of confrontation) over-asking how a company wants something done, and then feeling anxiety around getting it wrong and needing to ask for help. It might not necessarily be the responsibility of the direct manager to define _how_ things are done from a technical perspective on that team, but it's certainly someone's. "I expect you to know how to write software in our codebase" kind of falls apart, given the infinite options for how problems are approached within a given problemspace.

If you're seeing this type of behavior, your org might have trouble with A.) responding to aggressively with developers building something differently than expected, B.) valuable criticism. Pull requests are exhausting, in my experience, because they oftentimes turn into theoretical debates about the validity of different approaches.

Pull requests are the correct time to offer actionable criticism on submitted work. Pull requests are not a place to complain about an implementation strategy, or to suggest the developer should've done something totally differently. If the submitted solution is so far away from correct that that type of criticism comes up, your workflow has already fallen apart (as a developer was able to build and submit a solution without realizing their work wouldn't pass review).

> When I was on the other side, the opposite was true too, I has bosses that expected me to do things their way, even if I could demonstrate that there were better.

I think ultimately either is "fine" - things just need to be defined appropriately. If a developer is given the freedom to basically do whatever they want, they need to be told so, and that ideal has to be supported through the entire dev lifecycle. Meaning your team's culture has to have the restraint to not complain about implementation details. In my experience, almost no org is actually comfortable with this method though. In my experience it's best to literally define "how" a team solves the problems it is tasked with.

Every single job I've worked that used Jira, also used google sheets to "map" actual work to Jira work. It has always blown my mind. All the meetings to update the google sheet, and then to update Jira, and then to ask why the two aren't in sync. It feels like I'm taking crazy pills. Why are we using a manual tool (google sheet) to keep track of the work, that's in our work tracking technology? What?

It's def a slippery slope, but all of hiring is bound by implicit bias. If random people are evaluating random people against a set of subjective metrics, you're always going to get _some amount_ of bias in your decision making.

In reality, I think a surprising amount of bias goes into "tech screening", maybe even moreso than evaluating "soft skills." If you're asking random engineers at your company to conduct tech screens, the odds that those engineers are emotionally and mentally reflective enough to be fair and bias-free in the questions they ask and the solutions to those questions are very low. This is why so many places struggle with tech interviews that feel like debates. Engineers dislike candidates that do well on the tech portion of the screen because those engineers feel it is a competition that they must "win". I've seen this time and time again at FAANG and non-FAANG. Random engineers from a team should not be assessing candidates, pretty much ever.

Azure: Azure Resource Manager templates

It's weird the frequency with which the AWS Support Reps agree the issues we find aren't those that would've been resolvable on our own, as each time we file a ticket we follow up with our reps for appropriate training and support.

I understand that you like this tool, but you do not need to fight everyone suggesting it doesn't work as well as you want it to.

If your only comparison is "I used to work with Heroku", Terraform might seem not great. I would argue this is a blub example, in that this person's lens does not contain enough context or experience to be able to assess value.

Terraform's value becomes clear when moving in scenarios like moving from CloudFormation to Terraform, or when trying to integrate a second cloud's resources into your infrastructure workflow. Without experience in anything other than Heroku, of course a tool designed to do many many things is going to seem complex and at times frustrating.

> Iteration times are way longer than with even mobile apps. Like, “you’re liable to task-switch while waiting to see plan output” longer.

I'm over here laughing in my "over an hour of CloudFormation only to have a run fail, and then a rollback fail, and have to contact AWS support" life.

Yeah, I have had close friends go through code schools and it is kind of frustrating to hear them talk about their experiences. They get stuck, their instructor can't help, and ultimately they just kind of move on without understanding the subject matter. Then, three months later, they can't find a job after dumping their savings and quitting their previous careers.

Pretty much every single code school I have looked into (I have not looked into Lambda School specifically) hires students that cannot find jobs as teachers to be able to tout "96% employment rate post graduation". This is obviously an awful pattern, in that the students that might be good teachers (and/or good programmers) actually get placed, leaving only the students that cannot find placement to teach the next class.

I'm happy that you became productive in Rust quickly; I do not believe that to be the average case.

Most companies, in my experience, want tools that are easy to get right in 80% of cases, and in 20% of cases require experts. Go has the benefit of most benign work is deadass simple to get right. The things you referenced in your post are obviously the remaining 20%.

Rust, as an example, is a pretty difficult language to become productive in. Sure, once you've invested the time, you're equipped to handle a wider array of problems, but most organizations don't particularly care about the top. They care about becoming relatively productive relatively quickly.

Go's approach to certain problems require expertise, it is not a silver bullet. But there are no silver bullets, and the examples you gave require expertise in any language. The issue is that you've kind of just cherry picked those three concepts as proof of complexity, ignoring the boatloads of other examples in which Go's simplicity does add value.