• 1 Post
  • 28 Comments
Joined 3 months ago
cake
Cake day: July 16th, 2025

help-circle

  • “13 interviews with 11 different people for one job at one company and ultimately they went with another candidate”

    That about sums up the best case scenario in this market. This report is grim, and doesn’t even begin to scratch the surface of all the other red flags and warning signs.

    I have 20+ years experience in one of the most in demand jobs and in one of the hottest markets, who ticks all the boxes in all the qualifications for each of the hundreds of jobs I have applied for, who lives in one of the top regions for the industry, and (I have to at least acknowledge) whose demographic traits are the very stereotype of privilege… yet even I haven’t gotten so much as a callback in six months.

    Economic uncertainty is one reason the job market is dead. The surge of both automated candidate screening bots and in automated job application spam bots creates artificial competition for jobs, compounding the real competition from sustained and accelerating unemployment rates. The widespread availability and use of LLMs has been devastating for resumes, cover letters and portfolios in particular, which are intrinsically conventional and derivative of the job posting to which they are attached, and thus optimal for LLMs to produce.

    So on top of the general economic reasons and the supply/demand issues resulting from rapidly accelerating unemployment, LLMs have irrevocably and single-handedly destroyed what was left of traditional job seeking procedure, wisdom, and etiquette.



    • Solve the problem directly in front of you. You are not as good at predicting the future as you think you are. (aka: YAGNI)

    • Organize your code around the problem domain, and name things accordingly. As a basic razor, consider someone seeing your codebase for the first time – they should be able to easily glean what your app does, not just what language (Java) or frameworks (Rails) or design patterns (MVC) you might be using.

    • Each function must Do One Thing. And yes, each test case is a unit, too.

    • It must be clear to someone reading a function call what is expected to happen. Only use positional arguments when this is true and when order matters and is reasonably intuitive. Otherwise, always use named arguments.

    • Your tests must run quickly. Your code must build quickly. Your CI/CD pipelines must be measured in seconds, not minutes or hours.

    • Take nothing for granted. Declare all dependencies, and avoid implicit globals.

    • Use a linter, and enforce compliance. It doesn’t matter what the rules are, but once established, avoid changing them.

    • Never isolate yourself from your team for too long. If you’re working on a multi-day implementation, check in with the people who would be reviewing your code at least every couple of days. The longer you isolate, the more exhaustion and conflict you can expect during review, for both you and your reviewers.

    • Learn to work iteratively, validating minimal implementations that fall short of the full feature as requested, but which build up to it. As opposed to One Big Release. It helps everyone to experience and validate early and often how the feature feels and whether it’s the right direction.

    • Never rush. Always take the time to build properly. Your professionalism and expert opinion is non-negotiable, even if (especially if) there’s a deadline. I’m not saying to say “no” – rather, just give honest estimates and offer functional compromises or alternatives when possible. Never “try” to do more than is reasonable.

    A lot of this, I attribute to Martin’s books (“Clean Code” and “The Clean Coder”) and his Laracon talk from several years ago (you can find it on YouTube).




  • Every now and then this question comes up. It’s a timeless software engineering conundrum. Kind of like how med students might start to think they have all kinds of diseases and conditions because they’re learning all these symptoms.

    Software engineers, especially new ones, tend to be heavily biased toward applying technical solutions to non-technical problems. Most never actually grow out of this.

    I’ll advise what I advise every time someone approaches me or one of my peer groups with this very question:

    Get yourself a notebook and a pen.

    I’m dead serious, not trolling, and not some kind of technophobe zealot.

    When it comes down to it, if you let go of what you think you need in a to-do list app, you’ll find that what you actually need is much simpler.

    Notebooks are e2e encrypted. Self hosted. Offline. As ephemeral as you like. Indexable for search. Versatile. Take a picture of a page if you really want to. OCR it if you need to.

    Pen and paper.






  • Seems like something you may need to change in Transmission’s configuration, somewhere. Because it’s Transmission that is redirecting you and what you want is for that redirect to include the uri prefix.

    Otherwise, I see two options:

    • use a regex location block and match against all expected patterns
    • use a dedicated subdomain (i.e: server block) for this (each) service you want to proxy and just proxy all traffic to that domain with a root location block.

    The latter is what I would do.








  • It’s complementary to robots.txt.

    • It’s weird that it’s XML, in 2025.
    • It’s weird that it doesn’t use the .well-known/ prefix which has trended in the last decade for placement of files like this.
    • It’s weird that it canonically uses the generic “license.xml” file name instead of “license.rsl” or “rsl.xml” or something that more clearly indicates its semantics.

    But I do like the idea of having some widely adopted conventional way of expressing, in unambiguous terms, which usages are expressly prohibited, and that AI training is among them.