Hacker Newsnew | past | comments | ask | show | jobs | submit | jdbernard's commentslogin

Maybe, but even so workflows like this don't exist in a vacuum. We have to work within the constraints of the organizational systems that exist. There are many practices that I personally adopt in my side projects that would have benefited many of my main jobs over the years, but to actually implement them at scale in my workplaces would require me to spend more time managing/politicking than building software. I did eventually go into management for this reason (among others), but that still didn't solve the workflow problem at my old jobs.


The solution is not to deny yourself the tools of persuasion or "manipulation" but to be authentic and transparent. It's deceptiveness that makes influence or persuasion manipulative, not the tools and techniques.


The combination of these things you're mentioning is one of the main reasons, at least for me, that WFH is so much more productive. A lot of tech companies have evolved a culture and built offices that are in opposition to doing good work. Open plan offices have been the norm in my experience over the last 10 years (maybe more). Anytime interruption via Slack/Teams is the typical culture.

I was much more open to working in the office when I actually had my own office.


It seems obvious to me, but there was a camp that thought, at least at one time, that probabilistic next token could be effectively what humans are doing anyways, just scaled up several more orders of magnitude. It always felt obvious to me that there was more to human cognition than just very sophisticated pattern matching, so I'm not surprised that these approaches are hitting walls.


Same. I don't hate it, but I do hate that things changed out from underneath me without any notice, opt-in period, or ability to go back.


In a few days, when the frenzy dies down, I will make a feature request ticket asking them to do this next time. Please do the same.


They don't deserve punishment. But they should understand that this is not just "their product" but it is also my tool. Tools like this do not need to change and absolutely should not change without there being prior notification. Yes, in many ways the UI changes are trivial. They don't fundamentally change what's possible. But my keyboard never changes on me without input. My workbench doesn't rearrange itself without my input. If they want this to continue to be my tool (I've been happy to pay them for it) it needs to respect my time and attention.


I think it is a result of the impersonal "contact us" intake forms companies have all moved to. You have no indication that you aren't just screaming into the wind. There is no personal touch. So you take to social media where your are sure at least someone hears you. It also scratches the justice itch: if the company doesn't pay attention it looks bad in public and you get some vindication for being ignored.

I'm not saying it's a good or bad thing to do, but I understand it.


> It also scratches the justice itch: it the company doesn't pay attention or looks bad in public and you get some vindication for being ignored.

This is an interesting point. There is some satisfaction from the likes, the comments, and the assurance that _someone_ is seeing your frustration even if the company does nothing.


I don't use tmux because I have to. I use it because I love the way it works. The issues the author of the article and Kovid Goyal raise are not issues for me in practice. If something is built that better suits my needs, I'll be happy to switch. I am particularly sympathetic to Goyal's gripes about the performance/resource wastes of a multiplexer.

But I also take issue with statements like "terminal multiplexers are a bad idea, do not use them, if at all possible" (from the kitty FAQ and the YouTube video linked in the article). Tmux solves a number of real problems for me that Kitty doesn't. Kitty also seems to be moving in a direction that I am not interested in. It's tied to a windowing system when I want a terminal that I can use headless. Even with the hacky workarounds the article mentions, it doesn't really support session persistence when I use this feature of tmux weekly. It introduces a lot of features that are likely to lead to visual noise when the constraints of text-only are one of the main reasons I like terminals (personally I don't want images in my terminal, full stop).

Now, all of this is fine. It's the other statement, "[tmux acts] as a drag on the ecosystem as a whole, making it very hard to get any new features," that causes it all to rub me the wrong way. The only reason you feel like tmux acts like a drag is because there are users like me who won't switch to something like Kitty if it doesn't support tmux. So don't worry about us. Build a new thing that is not backwards compatible and live with the fact that many people won't use it. If you really want to drive the ecosystem forward as a whole, be less condescending about real use-cases that bring benefit to real users.

To be clear (because text is a limited medium), I'm not grumpy, angry, or against Kitty because of this. But I am dismissive.


This feels like one of those "not obvious until you've seen it in production" requirements: any production-ready logging framework should have a mechanism to delay parameter evaluation until after the threshold/destination checks are performed. Most languages have some version of deferred execution (lazy evaluation, thunks, etc.)


If the AI actually outperforms humans in the full context of the work, then no, we won't. It will be so much cheaper and faster that businesses won't have to argue at all. Those that adopt them will massively outcompetes those that don't.

However, assuming we are still having this conversation, that alone is proof to me that the AI is not that capable. We're several years into "replace all devs in six months." We will have to continue wait and see it try and do.


> If the AI actually outperforms humans in the full context of the work, then no, we won't. It will be so much cheaper and faster that businesses won't have to argue at all. Those that adopt them will massively outcompetes those that don't.

This. The dev's outcompeting by using AI today are too busy shipping, rather than wasting time writing blog posts about what ultimately, is a skill-issue.


> If the AI actually outperforms humans in the full context of the work, then no, we won't.

IDEs outperform any “dumb” editor in full context of work. You don’t see any less posts about “I use Vim, btw” (and I say this as Vim user).


You're getting down-voted, I think, because you're missing the point. I would argue that the "I use Vim, btw" articles are themselves proof that there are still people for whom Vim is actually more performant. Similarly, you don't see people being passed over in hiring because of editor choice because it does but less to consistent results.

Compare to a hand saw. You still see them in specialty work and hobby shops, but you don't see them on construction sites. You see circular saws. Same with hammers. You'll probably still see them in job sites, but with far less usage than nail guns. And in many contexts nail guns have completely replaced hammers. There are still people griping about power tools but the industry doesn't care. I know a fair number of people in the trades and I can't imagine any of them seriously suggesting that you don't need to know how to use power tools.

My argument is that, assuming AI fulfills the expectation of those who hype it (and that assumption has yet to be proven), we will see a similar effect in software. The results will speak for themselves and make the arguments irrelevant. That hasn't happened yet, leaving room for genuine debate.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: