HN user

dvtrn

5,002 karma

will code for cereal. Drives a Honda. Takes Jean Baudrillard way too seriously.

this isn’t my only account. or is it?

No it is. (it’s not. probably.)

Posts12
Comments1,831
View on HN

who will even notice if you don't show up to the office?

They don’t have to “notice” it. They don’t even have to see it.

Do you have an access badge to get into your company campus/building/suite?

My last job started tracking access badge activity to monitor and enforce RTTO compliance.

Found it funny to get nagged about not hitting the required minimum number by a boss who lived four states away.

Laughed all the way out the door and into a new company whose policy is “if you wanna wfh, then wfh. If you want to come to the office, be our guest.”

If I had to justify myself every time I took the basic initiative of fixing errant, problematic or poorly performing code just because it wasn’t ordained and blessed for me specifically I am out the door SO fucking fast…

Happy to have discussions and elucidate to others the change, and make whatever documentation necessary available, but if some leader somewhere things I’m a “problem” for merely having done the work…okay, let me solve that problem too: bye.

That’s an environment with serious trust issues manifesting as micro-management and I’ve got a severe case of post-micromanagement-stress-syndrome.

I’m left wonder at what point does the “give a man a fish/teach a man how to fish” method of pedagogy apply in terms of ‘acting like a human’ in this context?

Asking as someone who otherwise generally agrees that there are some truly poorly written errors and exceptions out there, but has also been on the admittedly frustrating end of the constant requests for help deciphering error messages that were very plainly stating what the problem is for someone who didn’t even try looking for the fishing rod.

These are fascinating responses to me, as with the example given my mind first went to someone for whom English is a second language. that group having trouble with this message I would understand, or at least have an easier time understanding having trouble, if even a very little amount.

For someone who was born speaking English and spoke it their entire lives, the example provided couldn’t possibly be more to the point in my opinion.

Though I agree overall with the general idea and that yes there are some pretty baffling and downright awfully written error messages and log entries that take a minute to grok (I just don’t think the example replied to is one of them).

I’m not seeing how what the message already is any less direct or clear than what you’re saying it should be? It straight up tells you it can’t find the var and what to do about it.

Can you help me understand what isn’t clear about the message as is, or maybe point out the ambiguity to someone who just isn’t seeing it? I want to write better error messages but I share the frustration of the above poster. The message tells you specifically what to do, but you’re coming back saying it’s not clear.

DVD Bouncing Logo 4 years ago

Man Invader Zim, haven’t seen that referenced in a long time, that little cartoon was the perfect kind of weird for its time.

I made the conscious effort before leaving Facebook to trade phone numbers, addresses and birthday dates from the people I wanted to really wanted stay in touch with, and put them in my phone. This was all within the last three years.

I’ve sent birthday gifts in the mail, and I’ve gotten gifts in mail from these very people.

Sometimes, when I wonder where the convenience that gets talked about in the context of Facebook and “staying in touch” ends and a more delicate form of “you’re probably not as close to some of the people on your friends list as you think” (which was absolutely the case for me) begins.

It took really minimal effort on my part to find other ways of staying in touch, but I think maybe the key is you have to WANT to stay in touch with people?

Just a shower thought.

How about people own up to their mistakes instead of relying on random Joe who happens to be on call to fix it? I have been burned too many times by write only code written by some coworker who wants nothing to do with it. This is not just an on-call issue btw.

Sorry for my french but

Jesus fucking christ, thank you.

I was being woken up constantly at last job due to a bug in the application because I was the Devops guy and this is exactly how I was treated. I spent weeks finding contributing causes to frequent failures. Gathered all the evidence I could find and begged for a fix, I scheduled calls with the product team; I poured over documentation and diagrams “this is the problem, this is inherent to the way these requests are being made, until it’s fixed we have no choice but to throttle the app”. I recorded a ticket each time I got paged and linked back to the team who owned the feature.

What was infuriating in the end was finally being told that they knew about the problem long before I brought it up and even HOW to fix it; it was just consistently being deprioritized by people who had the means to influence the decision on “fix this” or “write new shit”. Eventually I just suppressed the application in PagerDuty and stopped waking up whenever it would fail.

SLA slipped, customers complained, I find myself in a meeting being asked very aggressively “what’s being done about this and why are you ignoring PagerDuty?”

I said I wasn’t ignoring PagerDuty and presented a log of 20 something tickets I created linking back to the original “Please fix this request”. I told my leadership “I’m not the one ignoring this problem, I have been trying to get this addressed and prioritized for months”.

Laid off a month later. It’s becoming a growing reason why I want out of Ops and never want to return to it: companies hiring Ops people and treating us like the kitchen sink for work the company is too lazy to actually address and properly prioritize through staffing, planning or both.

Is there some magical keyword or ‘tell’ that you’ve zeroed in on and want to share with the rest of us when looking at a job ad to tell if it’s a “code assembly line” or not before applying?

From the rest of your comments you seem pretty confident and specific about not having these problems, so I’m curious to know what’s in your secret sauce.

Not gonna lie, I vastly prefer that. Not to say I bombard people with entire encyclopedias when messaging, but…I dunno. I guess, maybe this is the result of being one of those “elder millennials” I send text messages with the kind of intentional and to the point messaging style with the brevity of someone who pays $0.50 per message like it’s 1999 and isn’t running across the house to respond to every blip and beep my phone makes.

(Interestingly once I scared off a potential dating partner who is heavily into texting constantly and called me out for my asynchronous messaging habits and I flatly responded “sometimes I just want to put my phone down and do literally anything else”)

I have a few people who send text messages like this. Each stream of thought comes as a separate message which can be incredibly annoying when I’ve turned my brain off for the day because I only have so many spoons for anything other than sitting there with my thoughts (actually very enjoyable) or maybe a book and the phone out of nowhere starts dinging every two seconds because I’m on the receiving end of a disjointed and scattered series of someone’s thoughts.

I love my friends. I hate how they communicate over text.

Now that’s a name I’ve not heard in a long time. Is it still under development?

Back in my teens I was really wanting to get into 3D animation and virtualdub was one of the first tools I used to create reels since the free modeling and rigging tool I used at the time didn’t have any editing capabilities.

Complexity is inherently problematic

I wouldn't necessarily agree, but curious to hear this thought developed some more, if you'd be willing to indulge me? Maybe I'm missing some implied context here that you have experience with that could change my mind.

where does the opposite idea stem from?

Good question. For me personally, it stems from my subscription to the dichotomy of accidental vs. essential complexity as written about here (and other places) https://simplicable.com/new/accidental-complexity-vs-essenti...

Sometimes complexity is unavoidable, but I don't conflate something being complex with a thing being complicated. Complicated systems I would agree, are inherently problematic.

(also, your username just made me very hungry for a falafel sandwich. Excuse me for a moment)

Sometimes it's about having a common deployment platform at different locations, on premise.

That’s fair, that’s valid, that doesn’t however strike me as a compelling case to go off and hoist all of your stuff into k8s if there’s other equally performant and fault tolerant methods of running your application that require less operational complexity and cognitive load to triage and resolve failures.

It seems to me the problem you bring up would serve an engineering team well to solve and solidify even if the application isn’t running on k8s

I want someone to check me on a strongly held belief, I promise I have an open mind:

There’s nothing wrong with experimenting with k8s in your org. Nothing wrong with k8s, it’s complex yes but that’s not inherently problematic.

But it’s been my experience over the last several jobs that many orgs are throwing mission critical workloads and hinging a lot of people’s productivity onto k8s and asking operators and engineers to ostensibly figure it out as they go. And from rants and vents I see on other tech communities, I’m not the only one making this observation.

Which is sheer madness to me.

Change my mind: unless you have probably, razor sharp engineers who know what they’re doing with k8s enough to give you more than a few days of availability before livened probes start falling off the face of the planet, AND can make this their sole focus, maybe you’re not ready for k8s?

Not to mention being able to cancel a streaming membership without going through the eight layers of contact center hell that still exists to this day for many cable providers.

he told me directly that it was hard for him to know what to do because it was outside his field of specialty and the senior dev had more experience and a long tenure at the company.

This is what lead me to leave what was otherwise one of the most fulfilling jobs I’d ever had working as an engineer for a B Corp that provided tech consulting exclusively to non-profits humanitarian organizations.

Loved the mission, appreciated the leadership team, but absolutely loathed the this one developer on my team. So did the rest of the team.

Guy went through a divorce and became the worst kind of person imaginable. The engineering director suddenly retired due to a life-threatening medical condition, and this fella made it his mission to usurp as much power as he could. Pretty soon people started leaving the company because of the guy, leaving me and the other juniors as the only people behind.

Guess who was made the new engineering director. His code was fine and performant but he was an absolutely miserable, awful, truly rage-filled person but those open ears when anyone tried reporting up just happened to be attached to the same body that would shrug and point to his seniority and tenure as a means to not do anything about it.

He’s still there. I can see his picture on the company about page to this day. Everyone else is smiling jovially and he’s literally, actually, I’m not kidding you scowling at the camera.

And I’m still remiss because aside from that and that alone, I really enjoyed what I was doing there.

What, and break down all the monitoring and alerting silos we built by hiring a Devops engineer to come in and break down the development and infrastructure silos that were built when the company went ham adopting "Capital A" Agile?

Take what works you, ignore what doesn't, good luck.

- Why are you hiring Devops/SRE?

- What is a Devops/SRE going to bring that isn't/can't being done by engineers presently?

- Why isn't it being done presently? What have you tried so far?

- How many other SREs/Devops do you have? When will I get to interview with them (if applicable)

- Who is responsible for platform? Infrastructure? Deployments? How are they involved? When are they involved?

etc. As mentioned in my last comment, a lot of it comes through the baptism of working at a lot of really crummy shops to know the kind of bullshit you don't want to put up with. You gotta deal with some of it no matter where you go, but you sure ain't gotta deal with it all.

This is a lot of boilerplate stuff, sometimes you're lucky and these questions get answered before you can ask them, sometimes they're in the job description. So let me talk about that for a minute.

You really want to take your interviewing to the next step? Learn how to inquisitively, but tactfully challenge what you're reading in job descriptions. The answers I've gotten have been far more revealing than "what will I be doing day to day?" if you ask for more details about a bullet point or two and why those bullet points matter, or who they matter to. That includes, yep, on-call.

Most of my other questions are very probing questions about things in the job description; not necessarily because I'm looking for a specific answer, I want to see how the hiring managers and others describe those topics. Can they actually talk about why they're looking for someone to do x, y and z? Can they have a meaningful dialogue about what those responsibilities mean for the team or are they just parroting back what the job description says, like someone in a zoom call just reading words off a powerpoint slide?

Here's an example:

Job says they want a Devops to come in and also be responsible for security, risk and compliance in the infrastructure? Okay, here's my counter-inquiry about that: if Devops has the responsibility for security, risk and compliance, talk to me about the authority Devops has to recommend or deny certain actions in the platform if it is assessed to be too risky or costly to maintain a compliant and secure posture were we to do it anyway (if you've ever been in that unenviable position, you probably know exactly what I'm getting at with this question).

Interviews are two way streets, and in my thirties with a family where "family time" has no fungible cost, I'm driving very defensively on my side of the street.

Maybe it’s not about anting to write perfect code but a higher business unit that starts wildfires because a important and influential stakeholder from that one group of high paying customers complained loudly about something not working at 2am and next thing you know there’s a “planning for on call” meeting on your calendar

Ok simplification of affairs here but…I mean…

I don’t know anymore, and honestly I don’t care anymore. If the job wants to call me an SRE fine, if they want to call me Devops, sure.

I’m more focused nowadays on “what problems are you hiring me to solve?” since it feels more and more like the Venn diagram of the three job titles has nearly completely coalesced into a perfect circle.

Difference for me is I’m scrutinizing far more intentionally in job interviews about why an org is hiring for SRE/Devops before accepting any offers. Too often orgs are hiring for this talent and turning them into kitchen sinks for anything and everything the SWEs aren’t doing.

Compliance? Send to Devops.

Upcoming audit and need a pen test done in 3 days? Send to Devops.

Did a bad job prioritizing bug fixes and now shits crashing? Devops.

Etc. once you go through that a few times you start to figure out the right questions to ask in an interview and figure out if you’re about to join a company with Devops practitioners or pretenders.

Some companies hire dedicated tech people whose only job is to be oncall, handle alerts, and improve the oncall infrastructure. This role is called ‘DevOps Engineer’ at some companies, SRE (Site Reliability Engineer) at others, and may also be called ‘Operations Engineer.’

Someone finally said the quiet part out loud about ‘Devops Engineer’ as a job title. Only a matter of time before we wise up about SRE as well, I suppose.