I would try to learn some new tech. Definitely not something you can do in a vacuum with no goal for months in a corporate setting, but e.g. learning more about a programming language you already use, or some libraries, some tooling, you can easily spend a few weeks.
After that, yes it'd make sense to find something else.
Not sure what you mean by spec and design, but around me, that's always been paid more than simply coding. If you have a clean technical spec that's detailed enough, the code naturally flows and is often left to more junior engineers, with more senior folks reviewing the code but rarely writing it.
That, and it also needs to be mentioned that if an engineer is given a tool like claude, they will be given _more_ work. As an example, you might give an intern the following task:
"we have service A that receives a request, it now has a new flag in it, we need you to pass it through to in the call A makes to service B, and then add it in the where clause of the query that B makes".
and expect it to take 2 days including manual testing.
Now you would expect the same much quicker. Any weird bug of the kind "flag not showing up in B because its another weird place where the request _actually_ goes through" that would before suck up 5 hours, would now be found out by the LLM in 2 minutes. "Oh because of this feature being activated in <random yaml file>, this new path is used, so you have to add the flag passing logic there". And the next day they get a new task.
This was an extreme example, and it's also not a silver bullet, since now you need to ensure that the intern does the task in a way that they still learn the codebase and the service structure (ideally, they learn quicker) and doesn't become completely beholden to the LLM. So that will also become a skill teams look to hone, how they use tools like this.
Same here, music is too important for me to give up this kind of control. I probably miss out on the discovery system of streaming services, but there are enough other sources (e.g. radio paradise).
If "things go catastrophic" your hard drive is not usable at all anymore. At the very least some files can't be recovered at all. So you need backups in any case. Once you have backups, you might as well encrypt your hard drives, especially if you store these in different locations (which you should).
An advantage of encryption is that it makes it easier to give away or resell devices. With recent encryption schemes (well the ones on Linux, given this article), I feel confident that overwriting the encryption keys gets me close enough to not leaking my data once I get rid of an old hard drive.
That’s not true. I’ve had many computers that refuse to turn on and I was able to recover the files by removing the drive and loading it into a USB hard drive reader and recover the files.
I was looking for a good markdown / file editor on Android available the Play Store on a device where I can't install F-Droid / arbitrary apks, as I had been using https://github.com/gsantner/markor which is not available there. My conclusion was that there's basically none, to the point that it looks like the best solution would be for me to publish a version of it there, just so that I have access to it.
But it's the kind of things you'd expect Windows to take care of automatically, or in the worst case, to prompt the users to install on first boot, especially if Linux (with overall less driver support from manufacturers).
And with a preinstalled Windows (tuned to the laptop) this behavior should not be observed at all.
I have never personally owned one, but I have been told that some Alienware and similar flavored devices have had issues like this when you closed their bespoke Alienware management software because it was the thing driving the fan controls.
Nobody cares about costs until they pay them themselves.
Regarding code quality and tech debt, it's sensible not to care if it doesn't lead to anything observable. Do you really care of some "bad" code somewhere that hasn't changed for 5 years but keeps working fine, and has no new requirements?
On the other hand, if you work on an active codebase where fixing one bug inevitably leads to another, maybe it's worth asking whether the code quality is simply too low to deliver on the product expectations.
It's not even obvious to me in which direction coding agents move the needle. Do you want higher quality, at least at a higher (design) level, when you heavily use agents, so that you know know the mess will at least compartmentalized, and easier to deal with later if needed? Or do you just assume the agent will always do the work and you won't need to dig into the code yourself? So far I've mostly done the former, but I understand that for some projects, the latter can make sense.
> I've yet to be saved by an airbag or seatbelt. Is that justification to stop using them?
By now, getting a car without airbags would probably be more costly if possible, and the seatbelt takes 2s every time you're in a car, which is not nothing but is still very little. In comparison, analyzing all the dependencies of a software project, vetting them individually or having less of them can require days of efforts with a huge cost.
We all want as much security as possible until there's an actual cost to be paid, it's a tradeoff like everything else.
The funniest part is that it always gets traded off, everytime. Talking about tradeoffs you'd think sometimes you'd keep it sometimes you'd let it go, but no, its every goddamn time cut it.
After that, yes it'd make sense to find something else.
reply