spuds

Yeah, I think there's almost always a point where a company decides they need to stop generally trusting their employees. Then all the trustworthy ones start getting more and more frustrated, or just start checking out. Agreed that most startups lean towards trust. Need to keep that going as long as possible, and stay away from hiring managers who think their primary job is "protecting" the company from anyone who might make a mistake.

Yeah. And all the time spent on those 100 half baked ideas take away from time that could be spent working on the most likely cause of the next outage. (Real forward-looking risk reduction work.)

Yeah, I'm facepalming on that one. Thanks!

Yeah I completely agree that a lot of structures work actively against this. Lot easier for me to write a bullet point about it than actually implement it at a company with an existing way of doing things. And I think it's almost impossible to implement from the bottom up, as it often requires some real process (and culture) changes.

Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly:

* Don't add process just for the sake of it. Only add it if seriously needed.

* Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.)

* Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week.

* Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.)

* Never forget your team is full of actual humans.

I have to say I'd be absolutely delighted to receive a letter like this. Not just the indicator that I'm doing something right (already huge for me, given the degree to which I struggle with people pleasing), but also the humor and extra care/time involved. Feels like it would strike enough of the right nerves to be quite moving even. Definitely agreeing with others that we could use more of this in the world (well, I could definitely use more of it, at least.)

As someone who's considered himself lonely for most of his life, I can very much relate with the idea of feeling like an outcast, like an alien, someone who doesn't really fit in or understand what others find interest in. I think, in my case at least, it was probably related to being told over and over as I kid that I was doing everything wrong, that I wasn't acting manly enough, etc. Being told I didn't fit in led me to believe it. After a long journey of rebuilding my self-worth, I'm a lot less lonely this days, but I still feel it pulling at me, especially when I'm in a situation where I feel like an outsider.

The part I always feel like is missing from the coding interview discussion is:

"Are you testing the candidate on what the job will actually require, and ONLY that?"

With an onsite whiteboarding challenge, you're most likely testing if they're really good at thinking and talking in front of a crowd when extremely nervous, not writing code.

Same with a live coding challenge over zoom (CoderPad style) - this tends to be a test of nerves more than coding ability. But, if you're planning on a lot of pair programming, and want them to be able to dive into that on day one, maybe it's the right way to interview.

I find take-homes often the most accurate way to interview, as it most closely reflects the reality of most coding jobs. You're on your own, you don't have to deal with the extremely odd (and for some of us terrifying) feeling of someone watching you type. Hopefully, the take home questions are carefully designed to reflect what the job requirements will be. As almost every other comment has pointed out, debugging an ancient code base without documentation may be a perfect question, or it may be completely irrelevant and unnecessarily eliminate candidates.

But please, make the interview match the requirements you're actually hiring for, otherwise, everyone's time is being wasted.

Oh wow this immediately sent me back, haven't thought about this game in decades. The room I played it in, the computer (486/33 w/8mb ram?) the friend I learned about it from (terrible friend in retrospect, for unrelated reasons). Generally just loving the humor and ridiculousness of it. Definite Monkey Island vibes. Thank you for the trip down memory lane, felt good to have some reminders of the positive things from of that time in my life.

I love the rawness of this. I've noticed I tend towards a feeling of everyone else in the world being so alien, living some totally different incomprehensible life from mine. (Or more than I'm the alien, and everyone else is living a normal, enviable life.) Seeing little snapshots like these, most of them seemingly just for memory's sake, makes me feel a little more human. Hard to get on any social media, where there's also some curation going on.

I struggle with this myself, especially around writing. My solution, from a coding perspective:

If I had a massive new app to build, it would indeed feel overwhelming if I felt like I just had to sit down and build it. I think we get extra stuck on that with writing, as it often feels like we just need to go from an empty page to a well-reasoned and edited blog post, with a lot of ambiguous struggle in between.

With programming, I start breaking it down into pieces of functionality, and smaller ones, until I have a list of concrete things I can actually get my head around and write the code for. I keep on doing those small things, build the structure around them, and eventually I have my app.

I do the same with writing now. Not an outline really, but a list of concepts I want to get across, then smaller ideas. I write out a few of those, often a paragraph at a time. The structure starts to reveal itself, and soon enough I have a new blog post.

I think the key here is arriving at something small enough that it doesn't feel overwhelming. New app or blog post feels like way too much in the moment, and my body and mind to everything possible to avoid it (procrastination). Writing out a paragraph, coding a function - very doable.

Yeah, I've gone from a place of not being able to judge my level of discomfort at all, to only being able to realize it hours after the fact, to eventually learning to notice it in the moment (after a lot of practice). I still don't do it perfectly, but it's a skill that I've found very valuable.

I like the nuance you're bringing to this. When originally writing the article, I considered using a gym/weightlifting analogy, as it felt extremely relevant. I agree that the cost/benefit part can really be important. I might lean a bit more into my edge if I'm talking with someone I really care about, even if the cost/risk to me might be a little higher. I'm also much less likely to lean into my edge if I feel the person is a potential powder keg.

Yeah, took me (author) quite a bit of practice to get there. I still struggle with it at times, though at this point I find I can generally implement it say 90% of the time. Definitely feels like a muscle I had to build up.

Helping others with their mental health (after my own struggles).

Worked as a software dev/manager for a decade, went through workaholism, burnout, then alcoholism, depression, all that. Doing a ton better now, and taking some time off to write about what I went through and hopefully help out others going through the same thing some: https://depthsofrepair.com/

  Location: Fort Collins, Colorado
  Remote: Yes, unless opportunity is in/near Fort Collins
  Willing to relocate: No
  Technologies: 12 years experience in Python, AWS, Javascript (Sveltekit, Node), GIS (ArcGIS, some MapBox), plus a wide range of experience in team building, architecture, management, product ownership, and general software soft skills.
  Résumé/CV: https://maguire.engineering / https://www.linkedin.com/in/patrick-maguire/
  Email: contact@maguire.engineering

Hey, I’m a very strong generalist, full stack plus many years AWS/devops experience. If you need a dev who glues teams together and can finally figure out that super weird bug that no one can seem to reliably reproduce, let’s chat.