_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?

You are making a very common complaint, that comes from ignoring the problems of the tools you know while making a fuzz over anything you find on the new one. It's almost certain that whatever languages you are used to, they have a much larger pile of gotchas than Haskell (because Haskell has an atypical small number of them), but that doesn't stop them from being useful.

"Yeah well your language isn't good either" isn't a very good argument for why a language is _better_. If the idea is "Haskell works better than other languages as long as you happen to know how to make it so", isn't that just every language that exists? Due to Haskell's branding, I was under the impression that the issues the above user is describing should be impossible. If Haskell doesn't even make good on those guarantees, but instead shifts that guarantee as "Things you should've known not to do" onto the user, how is that different from any other language?

edit And since this thread has a lot of tension and vague hostility, I will add, I am not attacking you or the language you enjoy. I legitimately would like to better understand.

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.

I might-should've rephrased my original post to suggest that mocks for non-code-you-wrote deps are a waste, but being able to inject different implementations of code you wrote for the sake of testing still has value.

If you want to test how your code behaves when getting/setting data from a database, you fundamentally cannot mock the database. If you want to test how your code forms arguments to send to a dependency, you probably can, as long as you do both. If you're just testing that your args are correct without actually using them, you'll never really know.

A specific example stands out in my mind when I watched a TDD-minded developer suggest that their code was complete because they injected a mocked version of DynamoDB into a service and then verified their tests ran. They committed and pushed without actually testing against DynamoDB. When tasked with _actually running it_, they found that there was a fundamental flaw in the way that developer perceived Dynamo's behavior, which obviously meant their mock was totally useless.

If you want to test that you're pulling the right ID off an object to send to a database you can mock. If you want to test how your code actually behaves with a database, including failure scenarios and invalid arguments, you cannot.

As usual, solutions are much more nuanced than I previously stated. I've moved away from mocks, not banished them entirely.

I have moved into thinking that mocks don't really have much value. Testing real things is the only way to verify real things.

If you can, set up a real DB, cache, whatever, and run your services in tests with real instances of their dependencies. Obviously this falls through for external APIs and things that are very expensive, but your savings in "But the tests passed" confusion time will be huge.

I will take it after a year or two. The US did a great job at politicizing the virus such that I don't really trust that pharma companies actually did their due diligence with regard to testing and safety measures. I accept that doctors and scientists will take it under the guise of them "knowing it's safe", and I accept that lots of people will say "If they're doing it, you should too", but I think this strategy just generally ignores common sense. Doctors use and prescribe drugs all the time with unintended adverse side effects, the difference here is that those side effects are known and well studied. A vaccine that showed up to save the world (and also start a culture war in some countries)? I do not accept that the powers at be have verified this drug's safety.

I think that this vaccine is a choice, and once it's readily available it is still a choice. If you choose not to get it, you are accepting the possibility that you might get COVID and die. Once the vaccine becomes available to my age group and health demographic, the people that actually need it will have been given the option to make their choice as well.

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.

Well - it's abnormal in that it is not what the US's coming-of-age systems look like. Hit 18, move out, get a job. Whether that is good or bad or right or wrong is irrelevant, it's definitely abnormal from a cultural standpoint.