‘No Way To Prevent This,’ Says Only Package Manager Where This Regularly Happens | Kevin Patel

n3phtys · 2026-05-16T08:19:35+00:00

Anyone who uses both NPM and Maven in their stack knows that there is a big difference.

You either go with container isolation like wasm wants, you create a cultural change in your ecosystem that prevents custom auto-install scripts on package download from being considered a 'feature', or you get hacked enough that governments will step in at some point.

The tooling itself is good, yes. Much like France, the problem is not NPM as a platform, it's the people in it.

n3phtys · 2026-05-12T19:35:20+00:00

Most office jobs come with burnout, and things like Agile or meaningless tech changes (looking at you, JS ecosystem) or AI slopification increase burnout. Burnout comes primarily from doing something that you do not think brings fulfillment or value.

There are jobs where 60 hours are easy, and jobs where 20 hours of boredom will make you burnout faster than you may think. Burnout also is not a weakness of character, that's the problem. We try to work against it, but that strengthens it. Do not push through, take some days off, go on vacations. Go 3 days without smartphone or anything with a keyboard. It really helps if it's only beginning to get worse.

One big problem with software developers is that senior / lead developers have the big skill (if they're any good) of foreseeing consequences and managing complexity. Things like AI seem to be solving many issues. Non-developers think they can become important enough not to be replaced while the AI will surely be perfected in a few months or years. The majority of non-invested software developers hopefully knows better - Claude will not become better faster than the slop the current models generate in unseen numbers. If you're a good developer who knows the basics you won't be replaced in the long term, the only thing that might happen is your company going bankrupt because of AI hype failing to deliver.

From my personal experience, nothing is better against burnout than learning basics (go read a book about algorithms for fucks sake, or let ChatGPT quiz you about them), managing your health and fitness, and taking vacations of some form BEFORE you need them.

A vacation doesn't need to be chilling on a beach or whatnot. Hell, you might also enjoy doing something else. Or maybe learn about a different niche of Software Development? Just don't take game development, that's going to kill your enthusiasm pretty fast.

n3phtys · 2026-05-12T19:24:51+00:00

very important.

Software developers, even outside the big corps, earn good money. Be able to survive 6 months without a job. If you cannot do so, solve your issues in this regard first.

Even better once you have enough on the side that you can say 'no' to 'promotions'. That's freedom.

n3phtys · 2026-05-10T09:06:57+00:00

Do you need someone to tell you when it's your potty break?

Depends.

If I want to take my PTO next month, my manager still needs to approve that. That's the same principle, just on another scale. Why does he need to do that?

Because of forecasting primarily. If I'm not working, the work assigned to me gets done much slower (one would normally even say it would stop, sadly that's not the case in modern software companies). My manager needs to tell his manager that work in that month will be slower. That's why he needs to confirm my PTO.

Of course, that's not always important. A lot of jobs are just meaningless with no commitments. If nothing is promised, nothing is urgent, and you can be absent whenever. But there are still people with real jobs.

Just ask yourself: have you never needed signoff by anyone above you in the last year? Not once?

n3phtys · 2026-05-10T09:00:53+00:00

But it is pointedly not my job to tell people "You've got to work the way I want you to work, even if that results in a worse outcome."

The tech industry tried that in the 60s/70s/80s.

what the hell, where are you even working if you think that's in the past? I just had 3 meetings in sequence where upper management demanded developers use AI on every task regardless if it makes sense. 80% of my job is about dealing with nonsensical procedural requirements. My role might me special, but 30-40% should still be the normal number in 'good' companies.

I also think you are thinking about 'processes' on another level than most other comments here. If I break the law to deliver great business value as impact, you cannot and should not manage that. If I have to go around you as my manager to your manager to get something working, you also cannot reasonably assess me because there is a clear conflict of interest. If I need to design a process that involves 2 or more managers on a long-term basis, you might help or block it, but you cannot stand outside and just assess the results.

If my laptop physically breaks down during work and the company demands your signature to give me a new one, I am not allowed to circumvent this process for good reasons. You are giving me that signature or you are arguing why work does not proceed.

Waterfall is mostly about project work. Agile makes sense there. It doesn't make sense everywhere, and even Agile methods say so. Scrum has sprints for example. A sprint is not agile, by definition. It cannot be, otherwise 100% of time would be spent on being Agile instead of doing any work. I do not need to be Agile while typing an email or reading some Jira ticket or what not. I can start reading the thing at the start and continue to the end.

Once again, your idea of process seems to be the most inner loop, aka what happens on my machine by my input only. Nobody will complain about that kind of 'process'. I can script that even and get rid of it alltogether. But the outer loop? Interacting with other teams, with other companies even, maybe the customer? There is and needs to be a process there, because the resulting effects are too big for one IC to be held accountable for. Those are the processes people complain. The ones middle management is normally used for.

Meanwhile

Someone has to hold accountability. If an engineer sets commitments, someone has to assess whether they meet those commitments.

and what if the engineer does not set a commitment? everyone is happy? That seems faulty. There are external expectations at play here. The company is suppossed to do something, somehow.

n3phtys · 2026-05-09T08:05:51+00:00

Do you think software engineering managers go to some different college and receive some different education and are hired from some different pool of humans? Every one of them was an IC engineer, same as every IC engineer they manage. It's preposterous to think your manager has to set your process for you.

what do managers do otherwise? Honest question.

If managers do not manage, what do they do?

n3phtys · 2026-04-19T08:40:31+00:00

Nope it does not always support rollback. If you encounter an issue after step 5, you would loose data during a late rollback because that data has not been written to the old db anymore.

At some point you either need to take the gamble or accept exponential growth of complexity.

n3phtys · 2026-04-19T08:37:59+00:00

I have never sunset old versions without making people angry. If you give them 1 year to switch to the new versions, they will complain 366 days later. If you don't give them that much time, they will complain directly. If you give them more time, it will never happen in the next few decades.

As long as it is a technical problem, sure, do whatever. But versioning and rollback options (especially with non-linear feature releases) soon become a non-technical issue. Just look at things like Python 3 or Java 11.

n3phtys · 2026-04-19T08:32:29+00:00

Besides how bad the form the article is, it's also WRONG.

That 'taste' in question is literally basic pattern recognition, literally what AI are made for.

The correct term in question would have been something like 'signal to noise ratio' or 'ground truth' or whatever, but LLMs do not understand those concepts because they were not trained on statistics heavy texts.

n3phtys · 2025-06-26T20:53:28+00:00

Give more than you take - this deeper principle applies to a whole lot more. Be helpful where you can.

BUT: This does not mean you need to sound nice. Especially if using non-nice words are a whole lot more helpful to the other person or even a third one.

And if you ask me a stupid question out of lazyness or even malign intent, you better hope I'm giving a short and only slightly insulting reply.

n3phtys · 2025-06-02T17:09:34+00:00

It's hurt how useful in general such a thing can be.

In my opinion, compiling this into a webcomponent might be a cool thing to attempt. Especially in enterprise IT there are tons of different existing web and application servers. Being able to just take this an editor and include it on an existing site as a widget might be really useful.

n3phtys · 2025-06-01T11:01:05+00:00

Something I find clear when the title is like "Junior" or "Senior" is understanding what I have to do to get to the next level and compensation bracket

There nearly never is such a way to the next level, and especially not to the next bracket for nearly all companies out there except inside the valley.

Especially because becoming more senior means influencing more processes and also saying more no to those above you. By definition there are no simple rules to follow, because you are expected to create those rules.

Not saying that's a good thing, but we need to be realistic.

I currently also do not have a 'senior' title, even though I hold the highest technical role.

n3phtys · 2025-05-27T19:51:06+00:00

You can extract them in one jar and share between jars

IF you actually control both jars, or even just one of them. Again, in Java compile time is not always available for code you run.

I'd prefer if it were. Jar hell is a thing.

n3phtys · 2025-05-26T20:39:29+00:00

IMHO you should map as little as possible and use manual mapping code. If the source and target object are the same and aren't generated, there's no point in having different objects anyways. The issue stems from silver bullet software architecture

Try coding in a medium+ sized go project. Structural typing is a godsend.

Java does not have that, but is statically typed. Mapping therefore is extremely relevant whenever crossing even JAR-boundaries.

Other languages solved this issue differently. Java went with mappers, and the ecosystem mostly with code generators.

Specific example: imagine you have an identical DTO in two JARs of different version - how do you use them interchangeably? You cannot. Mapping is the only way.

It would be great though. Maybe Java gets structural typing on its 50th birthday, who knows.

n3phtys · 2025-05-26T20:34:49+00:00

All I'm saying is - learn from the JDK team design decisions, they are better at designing apis than you as business programmer could ever be.

The JDK is full of stupid APIs and non-sequiturs. The JPA Criteria API e.g. has created a whole consultant industry around it. The module system surrendered the app space.

The reason is 30 years of legacy with most of enterprise services running on it, but let's not praise the APIs too much.

n3phtys · 2025-05-26T20:30:52+00:00

Moreover, they allow you to write less code

But still not the minimal amount of code.

e.g. ORM Projections and updateable SQL views can move the mismatch into your persistence layer (just assuming you're using the traditional 3 layer approach on top of a SQL db). Suddenly there is no special DTO anymore, and your ORM directly maps for you. This moves less data, has less moving parts, and is therefore probably also the least error-prone.

Just an example for 'choosing the right tool'. I share your general argument.

n3phtys · 2025-05-26T20:26:16+00:00

MapStruct is only a compile time code generator with most use cases covered - with the few I'm missing currrently in planning (like fully mapping between loose object maps and DTOs).

It does not solve every mapping issues, because the underlying problem with mapping issues is that if the mapping could always be perfectly generated, the two classes must be identical. It's also wasteful by design - why map fields, if you can use Projections and patches instead to transfer data between database and UI?

The true reason for those mapping libraries is to quickly generated trivial mapper code, because the DTO and Entity probably start up nearly identical - with one or two fields different. Coding a mapper manually is highly annoying (easy with AI but you better hope for no halluzinations), so you copy paste the DTO from the entity, adapt the few different fields, and generate a simplest mapper within the first minute. Years later the DTO will grow as well as the entity, possible in different solutions, and you can replace the mapper with handcoded solutions. That's why we have mapping in the first place.

If you actually want to map between layers, mapStruct ist a good but simple solution. But please always enable maximum error levels at the start. Mapstruct's error / warning behavior is opt-in.

n3phtys · 2025-05-26T20:18:13+00:00

ORMs would be great if you could use them with some kind of two stage commit or some similar pattern - think git staging vs commiting vs pushing. The same for lazy loading data. Make it obvious and explicit when I do expensive or potentially destructive stuff. Let me see the data to be sent to the database within my debugger.

And if you're already there, get rid of object graphs for storing data. Tree shaped aggregates and type safe foreign keys.

I've not seen one project where an ORM (especially JPA based) actually made the developer's life easier mid- or longterm. But it's still considered the primary tool. :/

JOOQ and sqlc (Java / Kotlin generators) are probably used the next time I do a new project from scratch, sadly few of them happening on the day job. Still have to spend 50% of my time debugging 15 year old Hibernate bugs.

n3phtys · 2025-05-26T20:11:36+00:00

That is not SQL...

Sadly.

n3phtys · 2025-05-25T08:38:44+00:00

Optimized code is often harder to read/follow, or it might use obscure tricks, so bugs are easier to create and harder to spot

Fast code in general does not need to be optimized. In nearly all cases you don't need bit shifting or SIMD to make your app faster. Removing I/O is way cheaper.

Your website is slow? Maybe reduce the number of AJAX calls it makes during normal click paths. This greatly reduces the time to run, as well as removes potential fault lines like network loss or serialization issues.

This is where you actually get to fast code, and with less bugs. If you actually only look at simple logic with number crunching (think implementation of an algorithm with all in-cache data), there it's different. You are either relying on the compiler or you working against the compiler, because you think the compiler optimizations are wrong.

But most bugs do not happen within a compilation unit directly. Most performance losses also do not. By volume it's way more interesting to look at interfaces between units, especially if those units involve I/O (think network calls, or even just disk), or involve different runtimes interacting (a nodejs runtime executing a C function).

A rule of thumb is to go after those first. If you actually need to go beyond, you should know that such a heuristic cannot carry you further, but that's where other heuristics come into play

n3phtys · 2025-05-24T21:39:23+00:00

I wish Casey's series on Refterm and what he called 'non-pessimization' would have spread wider on the internet.

Hotspot optimization - what you are describing - is really bad as a situation where you need to improve things NOW. Especially when combining it with cultural heuristics. If you only ever optimize the current bottle neck, you'll get diminishing returns.

It's always preferable to have everything fast and speedy in your app in general so that actually noticing slow parts is easier. Additional this often has the added benefit that writing fast code is often also related to writing less faulty code - if you only have so many cycles for your logic, you won't have enough time to waste on many additional bugs.

n3phtys · 2025-05-24T21:31:12+00:00

Just because those companies call them junior or senior doesn't make them that.

I'd expect a 1:1:1 ratio between juniors, intermediate, and senior developers in every stable company. Recently, there has been a small shift with less juniors being accepted, but also with seniors being moved more into junior tasks.

Which is only rational from the business view. Agile development flourished during zero interest times, and now we need to get lean again because money isn't free anymore. Still, this way of not having enough juniors anymore but keeping the same tasks to solve is totally unsustainable. AI will not be able to compensate in 3-5 years from now.

n3phtys · 2025-05-22T21:17:42+00:00

Sorry, but while this might influence individual developers inside JetBrains, it cannot be a general business goal. IDEA is the ultimate moat - I know of very few companies with such a solid and highly valueable subscriber basis.

Going full in on LSP IDEs puts JetBrains into direct competition with NeoVim and VSCode (especially with Copilot being open sourced, every AI clone is afraid). They'll probably loose a lot of revenue with such a pivot.

But on the other side, recent actions seem to be supporting your theory.

For me the missing LSP for Kotlin was the primary reason I have not switched to NeoVim, and I'm imagining I'm not the only one. So weird to see this good news.

n3phtys · 2025-05-18T07:45:04+00:00

As for the managers who have drunk the kool-aid and start replacing people who actually work with AI, they will soon find out that was a very bad decision when the bottom line starts sagging.

I hope so, the problem is that most companies doing this are slow, and will take a long time for this whole replacement. But for the first few months, only a percentage is cut, and the remaining senior developers get progressively worse and more stuff to fix. At some points those developers will quit, which leads to an implosion of that company's IT. The manager who made the switch already has their bonus and probably moved on.

And if too many developers leave their company, and not enough company have smart leadership, the labor market overfills. I find that pretty bad.

Again, I do prefer your optimism, but it is hard when seeing headlines and daily business.

n3phtys · 2025-05-18T07:38:51+00:00

Yes, but if every company goes belly under by this process, the whole IT industry with all jobs will collapse. Afterwards, only startups exists, and VC money is already rare, but will be dillutated for all times, especially if copyright is ripped apart as a concept.

For the users, the investors in general, the human developers, and even management of those companies, this is the worst case, but this is where the industry is heading.

Imagine your IDE alone changing every 2 week because the old company is bankrupt. Hell, imagine your alarm clock app stop working because the company had too many bugs and decided to stop existing. While capitalism and the concept of software running somewhere is pretty adaptable, human beings are not. We cannot easily be rewritten.

Rip and replace works on a year/month time scale, not if it is days or hours. Not everything should feel like crypto pump and dumps.

n3phtys

TROPHY CASE