HN user
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.
I’m gonna go against the HN grain here and, despite having been fully for remote work for the first year or so of the pandemic, come out and say that life has really gotten a lot more repetitive and frankly disappointing since covid and the death of the office. I kind of miss meeting people in the office.
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.
But...you're aware that record profits aren't a blank check to employ whoever you want in whatever positions they want, right?
Curious, when was the last time you were in downtown Seattle?
(Unrelated to this post) Hello! I've sent two emails to hn@ for help with my account over the past few weeks. Is there a better way for me to contact you/whoever's on the other end of that email for help?
Sure, but I never seen that myself.
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.
Managed services offer big benefits over software.
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.
Personally, I think React is a bloated choice if you’re going to use both LiveView and JavaScript. In cases where I use both, I typically use a small framework like AlpineJS or vanilla JavaScript for client-side-only changes.
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?
Ah, TIL. I have no experience other than being a passive fan. Thanks!
Yes, I think to a large degree being able to build hard technology is a matter of being extremely fluent with writing code and reasoning about data structures and algorithms
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.
What a nasty thing to say a random/typical engineer is too stupid to assess talent and is basically racist…
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.
So let's be clear. You're honing in on this block:
"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?
I'd much rather my engineers have spent their time practicing their actual jobs and not brainteaser interviews. To wit, the interview questions I ask are usually in line with the role they're assuming.
You're welcome to flag my post if you think it's inappropriate.
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"?
I thought the purpose of LiveView was to remove the need for JS frameworks?
Take note of the time and let them do their thing. Answer any questions they might have as they go. The moment the program outputs the correct answer, take note of the time again.
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.
DDG, but actually returning search results.
Yes, I agree with this. Process exists to increase the bottom, but if you're trying to rely on TDD to get valuable tests, you're probably just thinking of the problem incorrectly (I think).
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.
I worked in games for a few years. We constantly got DoS'd. Probably twice a week. Luckily our content was extremely cachable, so once it happened a few times we just black holed stuff through Fastly. The attacks weren't super sophisticated, mostly just hitting a public endpoint a ton of times or trying to crawl API endpoints.
You may think Scrum is dogma, but my statements are factually true by reasonable definitions of the terms.
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.
If you aren't following the Scrum practices, then you aren't doing Scrum. For better or worse.
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.
Which goes to some assertions that have been made about this thread: Scrum is a tool to build standardized minimums in support of mediocre talent. Elite tech companies don't use scrum because they don't have (as much) mediocre talent.
My FB feed is lousy with these sorts of things. My family & friends seem to enjoy answering questions like "What was the first concert you attended?" I don't think it's for advertising purposes because I have not noticed any improvement in the accuracy of targeted ads. I don't think it's for political purposes because that is much easier to figure out without these oblique questions.
Hyper dystopian take: Gathering data to be able to create real-seeming narratives for fictional profiles to push political agendas.
If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc.
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.
As with all "Agile Frameworks", they are marketed as "If it worked it's because you did it right, and if it didn't work it's because you didn't do it right".
Is something actually valuable if it is A.) Inflexible and B.) Rarely goes well?
The brilliant thing about Scrum marketing is it's pitched and talked about as infallible. If it didn't work, it's because you didn't do it right. If Scrum worked for you, you must've done it right.
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"?
I think if you can be effective enough by showing up in person, there won't be a need for video calls.
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.
Certain elements of successs are best deployed by actually showing up in person.
Sure, but how does that relate to video calls? They are by definition not in person, camera or not.
Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract
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.
This is just handwaved nonsense. You're telling me that prior to video calls, people didn't cultivate relationships on non-video phonecalls? Just total nonsense.