> It just seems harder to meet people _in general_ than it did even two years ago. Like where is everybody? Does everyone stay home literally all the time now?
The pandemic is probably a bigger deal to others than it is to you.
1,942 karma · joined March 27, 2021
The pandemic is probably a bigger deal to others than it is to you.
I'm sorry you're having a tough time with it. That sounds really unpleasant.
> My company is hybrid at the moment and I’m actually writing this from the very empty office. Things just aren’t the same.
Ignoring the pandemic, it sounds like the people at your company just don't agree that in-person work is necessary for them to get what they need out of their employment. The issue is either side attempting to force its preferred working conditions on the other. aka the solution isn't to make all of those people that don't want to be in an office come in again, but instead for you to find companies/circles that have people with similar interests as you. Being around people that don't want to be around you is unpleasant for both sides.
Right, your post is mostly "I like the thing that I've used, and I do not like the thing I haven't used". They're apples and different apples.
> Again, all places I worked had enterprise support and even rep assigned
So, again, you've worked at places that were deeply invested in CF workflows.
> but since they introduced YAML it is actually better than HCL. One great thing about YAML is that it can be easily generated programmatically without using templates.
Respectfully, this is the first-ever "yaml is good" post I think I've ever seen.
> Over nearly 10 years of my experience, I never seen that to be a case. I'm currently in a place that has an interesting approach: you're responsible for deployment of your app, so you can use whatever you want, but you're responsible for it.
I'd love to hear more about this.
> And IMO I see a lot of resources that are not being cleaned up (because there's no page like CF has, people often forget to deprovision stuff), also seeing bugs like for example TF needs to be run twice (I think last time I've seen it fail was that it was trying to set tags on a resource that wasn't fully created yet).
I guess we're just ignoring CF's rollback failures/delete failures/undeletable resources that require support tickets then?
> There is also situation that CF is just plain better. I mentioned in another comment how I managed to get datadog integration through a single CF file deployed through stackset (this basically ensured that any new account is properly configured). If I would end up using TF for this, I would likely have to write some kind of service that would listen for events from the control tower, whenever a new account was added to OU, then run terraform to configure resources on our side and make API call to DD to configure it to use them.
Again respectfully, yes, the person that both doesn't like and hasn't invested time into using Terraform at scale probably isn't going to find good solutions for complicated problems with it.
TF can be used as a managed service.
> Managed service providers offer big benefits over software. With CF and AWS support, help with problems are a support ticket away.
The same is true with TF, except 100000% better unless you're paying boatloads of money for higher tiered support.
> I only run workloads on AWS, so the CF syntax, specs and docs unlocks endless first party features.
CF syntax is an abomination. Lots of the bounds of CF are dogmatic and unhelpful.
> I have seen Terraform turn into a tire-fire of migrations from state files to Terraform enterprise to Atlantis that took an entire DevOps team to care for.
CF generally takes an entire DevOps team to care for, for any substantial project.
Good to know! That's probably why this boilerplate generator only has a handful of (what I think are) smaller JS libs and not Vue/React?
Sure. Again. I don't really think an algorithm that shows up as an introduction to algorithm proves much more than a person read "Intro to Algorithms". So again, a timed introductory problem proves some elite technical skill?
> If you don't agree with me that the fluency I described is a significant asset to advancing the state of the art in CS
You're building a cute lil strawman. I think the question is totally out of line with the stated goal. If a college sophomore can answer a question, you're not really assessing much of anything. Also, working at a "hard startup" has nothing to do with "advancing the state of the art in CS".
> what do you think a significant asset is?
If I'm handling hiring for a "hard startup" and am in search of engineers fit for an "extraordinary team", I'm probably going to spend more time finding applicable skills than opening up to Chapter 1 in the closest algorithms book.
Quote me in my post where I said these things. Otherwise please don't misquote me. It's text after all, it's pretty easy to copy and paste.
> "It's applicable if you're building an extraordinary team at a hard technology startup."
And you're accepting that a timed question about tic tac toe is enough to prove you're capable of being on an "extraordinary team" at a "hard technology startup"?
Really?
The author of this post is either ignorant or malicious. Some of their behavior is so ignorant or malicious that it warrants direct adversarialism. This blog post is gross.
Curious, what about my post included a "playground insult"?
Gross.
> If you decide you want to hire the candidate, the interview must last at least six hours (with an hour break for lunch). Have your engineers interview the person, one by one, for about 45 minutes to an hour each.
Gross. The hardest pass.
> First, the candidate needs to feel they've earned the privilege to work at your company.
Gross. Equally hard pass.
> Second, your engineers need to feel they know the measure of whoever they're going to be working with.
Gross. Random engineers aren't qualified to assess talent or fit. Random engineers _may be_ qualified to pick candidates that match their gender/race biases though.
> and more importantly spend time having a little trepidation about how they did.
I would go so far as to say "Fuck you" to this author.
In my experience, the absolute best way to get valuable tests is to have someone whose job it is to own them, their correctness, and add to them when new issues arise. An SDET, or a rotating team member, or whatever. The average dev isn't going to write a test that's super valuable if they also wrote the code.
Your statements are dogma. "You must've just done it wrong" is scrum marketing. If it works it's scrum, if it didn't work it must not've been.
> Strawman.
Go on then, explain? Your gripe was that your team, that you admitted didn't find value in retrospectives, didn't bring up process issues in retrospectives. Why would they? They didn't find them valuable. Probably because the things brought up in retrospectives never got addressed. Agile solution? Add more process. Again, this is dogma.
> Of staff or customers? Attrition is very low of both. Not sure it's that relevant though.
If I employ 500 engineers and they're all miserable and constantly leaving, and we're never adding value to our clients, should I be proud that I employ 500 engineers? What does team size matter? Value-creation and employee happiness are the metrics that determine the health of an engineering org. Which I chose to label as "throughput", or how much value is created, and "attrition", a proxy for employee happiness.
Dogma.
> It's like baking a cake without adding sugar; it's not really a cake anymore.
Nonsense.
> No doubt they weren't getting value out of them
This piece goes against this piece:
> , but that doesn't mean they were doing things well and they lost opportunity to improve as a group.
Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end?
> For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now.
Less interested in size, more interested in throughput/attrition.
Hyper dystopian take: Gathering data to be able to create real-seeming narratives for fictional profiles to push political agendas.
Yeah this is the nonsense propaganda I'm talking about. "If it didn't work, it's because you needed to do it more", which I think is absolute nonsense.
Is something actually valuable if it is A.) Inflexible and B.) Rarely goes well?
> If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.
So, if you do exactly as Scrum prescribes and do not find success, in what way aren't you "on your own"?
The opposite is true as well. Why show up in person when you can be effective remotely?
I feel like we're just saying things now though.
Sure, but how does that relate to video calls? They are by definition not in person, camera or not.
As I said, you put it at the top of the backlog and alert the team of a new deadline. You work on it until the deadline. If you make it, great, if not, you move on. Asking for an estimate wouldn't have made you make it, it might've only prevented you from trying.