[–] 2 points 19 hours ago

Ah yes, the old "the rubes aren't really against AI, they're just ignorant!" We don't actually have to change anything about what we're doing or stop doing it, we just need to hire the right PR firm so what we're doing seems "thoughtful."

  • source
  • Being able to write code well is a rare skill, and I think that fact contributed to software being rare among career fields in combining high earning potential with relatively few structural barriers to entry. If you were good at coding you stood a reasonable shot of making it in the industry, even if you presented as neurodiverse/queer/non-WASP, didn't go to the right school or any school, had a disability that would be difficult to accommodate in other fields, etc (we were by no means perfect at this, but a lot better than some other comparably well paid fields). And, if you made it in the industry, even if you didn't make FAANGbucks, you probably had enough to live comfortably. There weren't enough of us to go around, so companies had to hire on ability and skill rather than credentials to a greater degree than you see in other fields with similar earning potential.

    I think our field will still exist in some form in 5 years, and for senior folks I think the day to day work will probably not feel all that different. What worries me is what it does to the first few years in the field. If LLMs are seen as good enough at writing code, it's harder to justify hiring junior and mid level engineers, and it's harder to argue for hiring as many of them as we might have hired before (in addition to teaching them and helping them grow, we senior folks used to delegate much of our code writing to them). What management expects of them also changes: not to write code, but to grow quickly into someone who can responsibly herd AI. So management will hire fewer juniors, there will be more juniors in the market looking around for longer, and management will find that they can be picky in terms of credentials and still hire people, something they couldn't do as much before. I feel like that's going to yank the ladder up from people who would be good engineers but didn't go to MIT/Cal/Stanford and don't have the financial resources to spend a year job hunting after they graduate college, and sort of quietly gentrify the profession more than it already is. I have a pretty nice life as an adult because of that ladder being there when I entered the workforce, and it makes me sad to think that it wouldn't be if I graduated today.

  • source
  • [–] 6 points 1 month ago (1 child)

    ...the same junior developers that management and the investor class have stopped hiring.

    Most seniors I know like mentoring newer engineers and would happily have more juniors on the team, but we don't get to make hiring decisions. I don't like that we have a glut of unemployed/underemployed new college grads and I feel bad for them, but I do not remotely care that management may have to pay me more than they'd like in 5 years because they decided they didn't need a junior pipeline anymore. Play stupid games, win stupid prizes.

  • source
  • parent
  • context
  • [–] 5 points 1 month ago*

    This post is the piece those two were circling around: what happens to the bottom of the chart, and whose job it is to fix it. Spoiler — it’s yours, senior engineer. It’s mine. And most of us are about to get it wrong in a very specific, very tempting way.

    BS. Most good seniors I know would love to hire more juniors, feel badly for the mass of recent college grads who are unemployed, and enjoy mentoring new engineers without needing a wall of AI slop to tell them to do so. When you give us control over the hiring budget and let us hire juniors again, you can blame us for the future senior engineer shortage. Until then, blame the people actually at fault (management, executives, the investor class), not us.

  • source
  • [–] 11 points 1 month ago (3 children)

    I'm far from a slop advocate, so this is more of a devil's advocate point: plenty of code writing is not enjoyable.

    If I'm working on my own project, to my own standards, writing exactly what I want to write I'm usually going to get enjoyment out of it. That's pretty commonly not the case when writing code for an employer. Maybe the tech stack sucks, the product is inane or worse, you think the feature is a dumb idea but have to do it anyway, you're bending over backwards to work around tech debt that you're not allowed by management to fix, or you have to appease incompetent/out of touch architects or tech leads who presume to tell you how to do your job. I personally don't enjoy writing that code very much. At a certain point it's almost like nails on a chalkboard if you genuinely enjoy programming for its own sake: you know what good would look like, you know how far away what you're working on is from good, and you feel sad at all the organizational inertia you'd need to overcome to get to good or, choosing not to do that, at compromising your standards. That bugs me, at least, and at a certain point makes it hard to even start certain work projects.

    LLMs can make this at least bearable. Rather than spending hours looking into the change yourself, writing all of the code, fighting the shitty test framework and swearing at the past engineers who made it so bad, you let the robot figure it out and review its work. The result may still suck, but it was going to suck if you wrote it by hand too, for reasons largely out of your control. You can't be fully hands off, and you still have to deal with the things you don't like to get a good result, but you put yourself a step away from what bothers you and by doing so make it a little more pleasant. And, when you find work that's actually fun, interesting, or rewarding, you just cherry pick that for yourself. I've grown to appreciate them for this reason. I have a lot less dread for the nails on a chalkboard work than I used to, anyway.

  • source
  • parent
  • context
  • While I don't disagree with this post in spirit, it feels tone deaf. Many very popular and well used FOSS projects rely on one or two core contributors who are volunteering their time to build something useful, fitting that work in alongside their paying work and the rest of their life. If a maintainer of a project I use has 3 hours in between their kid's baseball game and dinner one Sunday to spend working on it, I'd much rather them spend that time making the project better than on giving pro forma replies to PRs and issues that aren't valuable to the project to adhere to some sense of decorum (and, as a former maintainer, even a polite "no" to a bad idea or a disguised request for free technical consulting is time consuming).

    As a tangent,

    Not acknowledging contributions and the work that goes into them, whether through a quick response or a kind word, undermines our entire community. Every time that happens, it’s a “fuck you” towards a contributor. That seems fashionable if we look at the wider society—things are falling apart around us as we burn the planet and let nations get away with exploitation and murder—, but that doesn’t make it acceptable.

    is kind of a wild connection to draw given the reality of many (most, I'd argue) FOSS projects. A busy single maintainer prioritizing their limited time by ignoring low effort contributions is in no way like burning the planet.

    (maybe the author is implicitly thinking of very large, well resourced projects with sustaining funding and a lot of maintainers, where I think a higher standard might be fair. That's not really clear from the post, though, and I don't think it's accurate to regard those as "the community", in the same way that we don't regard Google, Amazon, etc as the entire software industry)

  • source
  • [–] 49 points 1 month ago (1 child)

    I have a hard time telling AI authored LinkedIn thought leadership apart from formulaic LinkedIn thought leadership sometimes, but this feels AI written, which makes it fairly amusing considering the point it's making.

    (Does vibe coding feel incredible? Also, "Nobody’s asking what happens in Month 18 when the original dev has left and nobody understands the codebase" implies that the vibe coder original dev understood the codebase at any point, which isn't an argument I'd feel comfortable making for any of the ones I've worked with)

  • source
  • [–] 4 points 1 month ago (2 children)

    App Tracking Transparency on iOS devices is an interesting test case for this argument. When an app wants to track you, you're asked in plain language whether you want to be tracked. You can say no. You don't have to be a savvy user to say no, and the consent is explicit rather than being buried in a EULA that you don't read. If you say no, the app will likely still work fine. Specific numbers vary, but somewhere between a majority and a vast majority of iOS users opt out when given that choice. How much that costs advertisers is harder to reason about (a lot of the data comes from advertisers themselves, who are hardly unbiased), but the data are at least consistent in arguing that ATT opt outs produce a quantifiable drop in ad engagement (clicks, etc) and ad spend.

    I'm personally a big fan of ATT. You shouldn't have to be a savvy user to opt out of surveillance capitalism. I also don't personally care that much about how effective online advertising networks are. But I think LG and similar companies are probably not off base to worry about making it possible to cleanly opt out of everything. From their perspective, that wouldn't be a great outcome.

  • source
  • parent
  • context
  • view more: next ›