I think it's an interesting psychological phenomenon similar to virtue signalling. Here you are signalling to the programmer in-group how good of a programmer you are. The more dismissive you are the better you look. Anyone worried about it reveals themself as a bad coder.
It's a luxury belief, and the better LLMs get the better you look by dismissing them.
It's essentially like saying "What I do in particular, is much too difficult for an AI to ever replicate." It is always in part, humble bragging.
I think some developers like to pretend that they are exclusively solving problems that have never been solved before. Which sure, the LLM architecture in particular might never be better than a person for the novel class of problem.
But the reality is, an extremely high percentage of all problems (and by reduction, the lines of code that build that solution) are not novel. I would guesstimate that less than 1 out of 10,000 developers are solving truly novel problems with any regularity. And those folks tend to work at places like Google Brain.
That's relevant because LLM's can likely scale forever in terms of solving the already solved.
> I would guesstimate that less than 1 out of 10,000 developers are solving truly novel problems with any regularity. And those folks tend to work at places like Google Brain.
Looks like the virtue signalling is done on both sides of the AI fence.
Not sure how you equate that statement with virtue signaling.
This is just a natural consequence of the ever growing repository of solved problems.
For example, consider that sorting of lists is agreed upon as a solved problem. Sure you could re-discover quick sort on your own, but that's not novel.
I agree sibling comments are not quite correct about persistent email access. You could fix the email problem while the "backdoor" to Gitlab remains.
The problem statement says this about corrective action:
>I discover the hack and change the passwords on every account I know about
In actuality, the corrective action is to change the passwords and revoke any SSO integrations.
To the original point, this does add more overhead to the process, probably isn't obvious to most people, and depends on the site having clear UI for the topic.
I agree with you but take it further, what's the point of different spaces? Just put all apps to full screen size (not "fullscreen") on the first screen and alt tab instantly
I like some of my apps full-screen, like nvim in the iterm should be full-screen. The top bar, tab bar and controls is not something i wanna see all the time there, as i'm using only keyboard in my workflow. I'm mostly into zen black screen with 100 columns of text in the center when it comes to editing documents, and nvim + iterm can provide such flawless black zen screen. Also games, books, graphic apps, all look better taking 100% of the height not 80%, as the 20% on top is usually mouse controls for those who don't remember any hotkeys
Too many tabs is overwhelming. I know for myself when the tab count gets high it's a sign that my mind is cluttered, I'm unfocused, and I need to prune and centre myself again.
Bookmarks are one way, but I mainly just use the search bar directly for history. Things to read later are put into Pocket or linked in Obsidian notes or somewhere more relevant.
Me, my problem has always been eagerness to please, so I'd agree to "just do it" and skip the first part.
Don't, under any circumstances, do that.
If the client asks for a fixed price, then don't propose an implementation cost. Instead, propose a discovery cost. I can easily say how long I'll need to figure out what needs to be done and deliver a documented solution with an estimate of the work needed.
If they refuse this approach, then the only other option is "time and materials", i.e. I will send you a log each week of the hours I've worked and the product I've delivered, and you will pay me each week.
If they refuse discovery as well as time and materials, and insist on fixed price, then I walk away.
It can be difficult to find work that pay per hour but almost impossible to find fixed price work that does not result in at least some feeling of being exploited. And I would only do fixed price work again if: a) The deliverables are commoditized and I own the codebase; b) I am desperate.
I think there is a conflict of interest at the root of fixed price jobs. You are incentivised to provide as little as possible within that fixed price and the customer is incentivised to extract as much as possible.
Isn't it quite obvious, don't do stupid contracts.
As a contractor/freelancer you can do any kind of contracts. You can commit to free work for whole year if you want (or are stupid enough to sign a contract that requires you to work for free).
With normal employment there are lots of laws that protect you so you don't have to think about your contractual duties. Just turn up and do what is told and you will get paid. When you do contracting it is quite different game.
Pretty much this. It was a stupid mistake and it cost me dearly. My choices were to suffer and work for a few dollars a day, or suffer even more and be blacklisted in my local community, if not being dragged through the unknown depths of some legal dispute that I had no recourse to fight. And to be fair, I agreed to do it, so it was kind of on me for not doing my homework. We live and learn to protect ourselves, but when there's a glut of people who haven't learned yet it's very lucrative for people who will exploit ignorance deliberately.