• 0 Posts
  • 12 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle

  • It’s a little worrisome, actually. Professionally written software still needs a human to verify things are correct, consistent, and safe, but the tasks we used to foist off on more junior developers are being increasingly done by AI.

    Part of that is fine - offloading minor documentation updates and “trivial” tasks to AI is easy to do and review while remaining productive. But it comes at the expense of the next generation of junior developers being deprived of tasks that are valuable for them to gain experience to work towards a more senior level.

    If companies lean too hard into that, we’re going to have serious problems when this generation of developers starts retiring and the next generation is understaffed, underpopulated, and probably underpaid.





  • Unfortunately, in doing so, Signal became Yet Another Messaging App. It really damaged their value proposition in my eyes.

    If I need a separate app for SMS, WhatsApp, Messenger, Telegram, Signal, etc, it just becomes a chore to find enough friends willing to move to it exclusively.

    The IM ecosystem really needs to be harmonized on the user end. I remember Trillian was this great app back in the day that brokered all your MSM, Google Chat, etc IM accounts into a single app that let you just focus on messaging people and not worrying about what platform was being used. We badly need this again.


  • There’s kneading and there’s scratching. Handle them differently.

    If he’s scratching, he’s usually standing and stretching around the same time. They need to do this, but you can redirect it to someplace that’s ok for them to scratch.

    Quite often you can do this by placing a scratch post near the place they’re nuisance scratching. Something carpeted works well, but I really like the cardboard ones. It looks like a board of cardboard glued together, with a waffle-ish pattern they can really dig into. Another nice thing about cardboard is its nothing like furniture or carpeting, so less likely to confuse the cat about what he’s allowed to scratch.

    Kneading is more of an expression of comfort and love. You should nurture this, because it’s adorable and they will do it less intensely as they grow up. If they’re kneading they’re often purring and rhythmically kneading dough.

    In both cases, you should be trimming his claws regularly. If you do it calmly and gently from an early age, this should be trivial. I have 2 cats and trim their claws every couple of weeks. It takes about 30 seconds per cat.

    This does require confidence on your part (cats smell your hesitation and stuff body language and hate it), and it requires your cat to trust you enough to let you handle his paws.

    Look up a handful of guides and videos online on the technique. Jackson Galaxy is a popular YouTuber that probably has some content on this.

    My mom has a semi-feral cat who simply will not tolerate her claws being trimmed. As a result she’s a nightmare - damaged furniture, accidental scratches, and she’s constantly getting caught on fabric. Don’t let that happen!






  • My org has issues with e2e, but we keep them because they usually inform that something, somewhere isn’t quite right.

    Our CI/CD pipeline is configured to automatically re-run a build if a test in the e2e suite fails. If it fails a second time, then it sends up the usual alerts and a human has to get involved.

    In addition to that, we track transient failures on the main branch and have stats on which ones are the noisiest. Someone is always peeling the noisiest one off the stack to address why it’s failing (usually time zones or browser async issues that are easy to fix).

    It’s imperfect, and still results in a lot of developers just spam retrying builds to “get stuff done”, but we’ve decided the signal to noise ratio is good enough that we want to keep things the way they are.


  • It works for us to some extent, but there are ultimately people who specialize in various areas. Nobody can be a true master of absolutely every area in a large system with enough knowledge queued up to be able to be an independent power player. And I think that’s reasonable to anybody who works in or near the trenches.

    It should be expected that any member of a full stack team can figure out how to do any particular task, but it’s a waste of resources not to have people lean on teammates who have more recent deep experience in a particular area.

    This goes for both technical areas as well as domains. If my teammate just spent a couple of weeks adding a feature that makes heavy use of, I dunno, database callbacks in the user authentication area, and I just picked up a task to fix a bug in that same area, I have two choices. I can consult with my teammate and get their take on what I’m doing and have them preemptively point out any areas of risk/hidden complexity. Or, I can just blunder into that area and spend my own couple of weeks getting properly ramped up so I can be confident I made the right change and didn’t introduce a subtle regression or performance issue.

    As the number of tech and domain concerns increases, it becomes more and more important for people to collaborate intelligently.

    My team oscillates between 4 and 6 developers and this has been our practice with pretty high success. Quality is high (when measuring our ability to deliver within our initial estimates and our bug count), morale is good, and everyone is still learning with minimal frustration.

    I think the issue of team cohesion comes into play if people are all independent and also stop talking. If I take the couple of weeks in my previous example instead of talking to my teammate for some knowledge transfer, I’m disincentivized from leaving my personal bubble at all. I’m also less likely to stay within overall software patterns if I think I’m always trailblazing. The first time you write new code, you’ve established a pattern. The first time someone repeats what you did, they’ve cemented that pattern. That’s often a nasty double edged sword, but I generally lean toward consistency rather than one-off “brilliant” code.

    Where this can start to break down is when people become pigeonholed in a certain role. “Oh, you’re the CSS guy, so why don’t you take this styling ticket?” and “Kevin, you do all the database migrations so here’s another one” are great ways to damage morale and increase risk if someone leaves.

    Tl;dr: everyone should be able to pick up any task, and they should endeavor to keep their axe sharp in every conceivable area, but it needs to be carefully offset against wasting time by refusing to lean on other people.

    As with most things, it’s usually a matter of personalities and not policies.