zerkten

My fingers are curling up at the look of the angle on that keyboard. I love the idea and the aesthetic, but I could never use this full time.

Putting everything behind a VPN seems like the solution selfhosters have landed on. That way you have some control over how quickly you have to respond.

You still need to manage that change to varying degrees. For every organization which can shift on a whim, there are many more which require mitigation. Normally, there are a lot of things carried forward for internal or external reasons. Developers tend to discount the amount of effort from other actors in the system because they don't understand all of their priorities and which map neatly versus not.

Anything that reduces the blast radius helps. There should still be a focus on further hardening. Most value comes from exploits that enable pivots. Attackers will focus on other vectors that enable broader pivots because immediate high value notes only exist for a limited set of users.

>> But they are so common, i don't know who designs them and makes me feel like 5yo.

Often these are the product managers building follow-on features that don't get the usage they want. Users aren't using them, but monthly usage is the currency of so much PM work that they have to try to draw attention to it.

Prisoners do get taken in situations where they'd be taken without drones. Drones hitting support groups behind enemy lines are akin to airstrikes. When drones are used on the frontline to support ground forces, the enemy will emerge and surrender. Some Russian units in the current invasion of Ukraine have surrendered to drones when ground forces haven't been as close as they'd like to accept the surrender.

There will always be war crimes in a conflict of any scale. That is human nature even if we don't like it. If both sides aren't doing it with drones they are doing it with something else. You now see the action in every situation because there are cameras everywhere and incentive for all sides to shape the narrative with this content.

As far as AI is concerned, there is the huge risk for problems. That said, you can have entire sectors of a battlefield that are kill zones for artillery but now you have drones taking more targeted action. Western artillery capabilities and approaches are more precise than those used by the likes of Russia, but it's a still a case of pummeling certain places. Drones hitting within a sector aren't much different and possibly have some long-term benefits.

Integration points increase the risk of compromise. For that reason, I never use the desktop browser extensions for my password manager. When password managers were starting to become popular there was one that had security issues with the browser integration so I decided to just avoid those entirely. On iOS, I'm more comfortable with the integration so I use it, but I'm wary of it.

My point is that they don't capture the effects you describe - unless designed in. There is little motivation to do that though because they can track larger effects which are aligned with current leadership priorities. That's why I included the part about the PM that has recognized the problem.

I can guarantee you that the class of problem you describe has been discussed at the individual contributor level, so is known to some extent. Getting it from recognition to action is the problem. It is a huge lift to get some of these small things through the gauntlet to execution. Meanwhile, as you say, competitors with taste and attention to detail are building a better product.

This is very much a problem of large organizations. Those same PMs at a small company. If Google Maps was an independent company, the impediments would be fewer and priorities more aligned with building the best Google Maps.

>> Then before you know it, the devops folks have decided that they need to put a gazillion other services and an entire software-defined networking layer on top of it.

I don't work that closely with k8s, but have toyed with a cluster in my homelab, etc. Way back before it really got going, I observed some OpenStack folks make the jump to k8s.

Knowing what I knew about OpenStack, that gave me an inkling that what you describe would happen and we'd end up in this place where a reasonable thing exists but it has all of this crud layered on top. There are places where k8s makes sense and works well, but the people surrounding any project are the most important factor in the end result.

Today we have an industry around k8s. It keeps a lot of people busy and employed. These same folks will repeat k8s the next time, so the best thing people that who feel they have superior taste is to press forward with their own ideas as the behavior won't change.

In enterprise, you have little chance of getting the real story from end users in many cases. IT will also tell you that things are used one way, only for analytics to tell you it's the opposite. If you spend some of your UX research budget to deep dive on the area you can then finally get to the bottom of it.

I think the root of the complaints here is prioritization. The things they care about are prioritized. Qualitative feedback is likely already telling PMs that something is wrong and really should be fixed, but other feedback has more data supporting it.

The reality is that most product leaders only care about the feedback that has visible consequences. If users aren't performing some action like quitting the app that shows in the telemetry, then they aren't going to pay attention.

They'd probably call the issue you see a "craft" issue. Some PM is likely raising it. What happens is that leaders in big companies want perspectives based on data. You can go in with issues like yours but if you don't have clear data that shows significant numbers of users leaving, or users piling in, then you might as well not show up. People care about craft primarily will really struggle in these large organizations. That's not a good thing but how it is.

In large organizations, you'll see a lot of A/B testing or experimentation. Some of the worst decisions from a craft perspective are ones where they only look for "did this cause some kind of negative impact on numbers?" situation. If your feature is neutral (on abandons, uninstalls, or whatever negative outcome), then it can get shipped which overrides any qualitative question around "should we ship this in this state?". Doesn't matter too much according to these folks because it's not making things worse (in terms of numbers.)

There is probably more to explore in modern "product management" that's at the root of many of these problems. HN tends to focus on engineering but within large companies there is now a bifurcation and development of a field that forgets lots of PM was already invented.

I don't think this is always true, but it's true a lot. I think there are better descriptions than moronic as well. People use moronic when people are just as smart but have a different (and possibly better) direction. It's just the case that it defies the will of the other person.

These people go to the extreme and feel they have to outdo each other in an arms race to win whatever category it is today.

You can have extreme ambitions without being a moron. It's possible for someone to be empathetic, but also really driven. The problem is that they are locked in a downward spiral and they can't possibly be vulnerable. It's only when they run out of money, or some other extreme event occurs that they change tack. That's moronic, especially when the outcomes are predictable.

There is a lot to be said about SV culture and the people that surround these VCs. A lot of people love these environments and more than tolerate the environment these VC folks create. It's hardly a new phenomenon.

They have a perpetual pricing option available alongside the subscription one. It's still worth thinking about the economics of this.

How are they supposed to fund development? It's important to differentiate independent devs and the goliaths. When you release an app like this, it is "good enough" for more people. Your incentive to build the thing is that you can make a living off of it and continue crafting it with the intent of building other great things. The biggest software companies have many revenue streams and ways to cover costs that are very different from independent devs.

When you sell perpetual use software, you have the incentive to release yearly versions (or whatever cadence is best.) You are incentivized to only put bugfixes into next year's version to force upgrades. Users lose out because they don't get bug fixes and the developer is put in a spot where they have to look for more devious ways of making a profit.

To make money the cost of perpetual software is also very high. Devs make terrible compromises here to seem reasonable, but you need to move a lot of units to reduce the price to the level possible with subscription software.

Subscriptions are far from perfect, but they bring some balance. Next time you complain, it would be an interesting exercise to state what you would be prepared to pay and how often.

SQL Server 2000 was well received in the segments that mattered as a challenger. Oracle was in first place running on Unix. However, it was viewed as expensive and the procurement experience was regarded as unpleasant. People wanted competition even if they didn't think SQL Server, or another alternative, could unseat Oracle for the most important stuff.

Windows was really picking up steam and there was a move to web development in the Windows-based developer space. Visual Basic and Delphi were popular but desktop development had peaked. ASP was for building your apps and SQL Server was the natural backend. SQL Server fed off this wave. It wasn't dislodging Oracle, but rather than every app being built on Oracle, more apps started to use SQL Server as the backend.

Then ASP.NET appeared on the scene and demand grew even more. It was a well-integrated combo that appealed to a lot of shops. I started my career in a global pharma and there was a split between tech budget. IT was a Windows shop for many reasons and ran as much on SQL Server as possible. R&D was Unix/Linux with Oracle. There was a real battle going on in the .NET vs Java (how about some EJB 1) and the databases followed the growth curves of both rather than competing against each other.

The SQL Slammer worm brought a lot of attention to the product. There were instances running everywhere and IT didn't expect so much adoption. Back then you had a lot more servers running inside offices than you do today. My office was much like my homelab today. This validated the need so the patches got applies, IT got involved in the upkeep, and adoption continued to grow.

Oracle's sales folk and lawyers were horrible to deal with. I had some experience of this directly as they tried pushing Java-related products and my boss dragged me into the evals. One of my in-laws was outside counsel in the IT space doing work with enterprise-sized companies. He claims they are the worst company he's ever had to deal with and wouldn't delegate any decision-making locally which endlessly dragged out deals. They had a good product but felt they could get away with anything. Over time he saw customers run lots of taskforces to chip away Oracle usage. This accelerated with SaaS because you could eliminate the app AND Oracle in one swoop.

>> And "the community" isn't moving to Codeberg because Codeberg can't support "the community" without a massive scale up.

People have a superficial knowledge of the space (I think this extends beyond Codeberg) but feel strongly that they need to advocate for something. Codeberg themselves seem to have opinions about what they want to do but people are suggesting they can do more simply because it gives them an outlet.

The constraints that Codeberg set seem to, on the surface at least, ensure they can scale based on their needs and protect them from external threats. Hosting random sites comes with a range of liabilities they probably understand and want to avoid right now. There are EU regulations which can be challenging to handle.

This is an interesting point when the question is "how do I build a Windows app?" and a decision needs to be made. React is definitely one of the options that some consider when this question arises.

I think you miss the more common reasoning though. This starts with "can we build a Windows app?" The answer to that was "no" for many more people until relatively recently. The .NET Framework wasn't as available by default until the second half of the 2000s which caused some Windows app devs to hold off beyond the performance reasons and WinForms vs WPF. Electron and React go hand-in-hand here as they made a (crappy) Windows app easy.

What I feel popularized this was the webview approach on mobile. In 2010, there were a ton of frameworks popping up for hybrid mobile development. This was carried forward to desktop although some of us had been embedding IE webviews much earlier. This let people say "yes" and it went from one thing to the next with diversions into React Native.

One issue is that 95% of the integrations will be fine with the default configuration. The others including some with high profit potential will have weird configs that will frustrate your customers the first time they try if not well tested/documented. It's better to take time and get it right. Enterprise customers love piloting and spending time, so best to approach that the right way too. Going with less complex options, that arguably have better APIs, makes it easier to develop your core product too and get real feedback from users.

There can be different cohorts of students. If a student is at the point where they can start exploring iOS development they can perhaps have a swing at it with this machine. In reality, they'll have been using this machine, know enough about the limitations, and be thinking of upgrading.

Kids already are well aware of iPhone upgrades. Parents will get them this machine. They'll get going and soon enough be badgering their parents for an upgrade to a more competent machine. That is all by design while being an affordance for people who can only get in at the cheap end.

I found mixed results given underlying anxiety that hadn't been diagnosed at the point I was trying this. Talking to new people at work, while out pursuing hobbies, and around town, all accrued to more and better conversations.

It was a much bigger struggle with conversations where I was putting extra pressure on myself. Being able to have those other conversations was helpful though. Eventually, I found a therapist and am in a better place with this.

We delegate power already. Is unleashing AI in some place different from unleashing JSOC on an insurgency in a particular place? One is code and other is a bunch of humans.

You expect the humans to follow laws, follow orders, apply ethics, look for opportunities, etc. That said, you very quickly have people circling the wagons and protecting the autonomy of JSOC when there is some problem. In my mind it's similar with AI because the point is serving someone. As soon as that power is undermined, they start to push back. Similarly, they aren't motivated to constrain their power on their own. It needs external forces.

edit: missed word.

A big part of the problem is being permitted to teach this stuff. As a UK CS grad from the early-2000s, my observation was that academic staff recognized the need for these skills. They weren't permitted to teach it due to time available and the view that it wasn't academic. Thankfully, my university's CS department offered courses in these kinds of topics taught by the support staff (read: sysadmins). These courses existed to help other departments with skills but were open to students.

Fast forward twelve years and my wife did the MCIT at UPenn (https://catalog.upenn.edu/graduate/programs/computer-informa...) where git and other topics woven into the curriculum. Even then, they were perhaps a novelty because their focus was bringing non-CS undergrads into a CS Masters program. So-called "conversion" master's degrees were the norm in the UK in 2002.

I think it's reasonable to distinguish which side drove this. RAM prices are going up but it's not engineered primarily by RAM manufacturers. They are naturally jumping on the bandwagon and responding, but they aren't the drivers. Of course, how they respond matters. They could make other choices. Over time we'll see how this goes because AI could cool and then RAM manufacturers end up in a spot where they choose to manipulate prices to keep them higher.

Kusto is similar: https://learn.microsoft.com/en-us/kusto/query/

I don't believe that devs are the audience. They are pushing this to decision makers where they want them to think that the state of the art is further ahead than it is. These folks then think about how helpful it'd be to have 20% of that capability. When there is so much noise in the market, and everyone seems to be overtaking everyone else it, this kind of approach is the only one that gets attention.

Similarly, a lot of the AGI-hype comments exist to expand the scope of the space. It's not real, but it helps to position products and win arguments based on hypotheticals.

Even if you talk to users, you can do it the wrong way. Big companies are incentivized by the stock market to care more about new users than existing ones because their only focus is growth. Growth can't be rooted in your existing users is a common feeling in product management circles. If you try to do things for people other than your existing users, then you end up doing odd stuff that at best is a mild annoyance. More likely you hurt their ability to continue using the app.

It's not just about the language. The good money for these low-code tools is larger organizations which have deployment/hosting/compliance/maintenance concerns that need to be accounted for. You can knock out as many apps in whatever platform you want, but they don't want these at the IT gatekeeper level.

They want a tool that makes this file share talk to this SharePoint site which updates this ERP tool over there. The LLM approach is great for the departmental person (if they can still host shadow IT) but falls down at the organizational level. The nature of this work is fundamentally different, crappier, and less interesting than what any person on HN wants to be doing which is a contributor to misunderstanding of the market.

EDIT: fixed grammar.

>> Being a "transparent umbrella" does require knowing the personalities of your reports, some people do get distracted when they think higher-up decisions or unhappiness are going to affect their team.

There is the expectation that the manager knows who will be distracted. This is a basic part of knowing your people. I know which of my colleagues is going to get distracted without having the level of communication that my manager has. On one extreme, they just forward information knowing a report can work with it. One the other, the manager has to translate and communicate every element.

Ideally, the manager is already working on a way to ensure their report can handle transparency because that means they can work autonomously. You can't have individual contributors lead, if they are going to run into issues as soon as they discover what is going on overhead. They may not understand it yet, but they should have coping and mitigation strategies.

Engineers can be the worst group you could deal with when it comes to overhead conversations when they expect things to be orderly. Your organization is failing when everything has to go through managers and people can't operate independently.

I've wondered if people who write detailed specs, are overly detailed, are in a regulated industry, or even work with offshore teams have success more quickly simply they start with that behavior. Maybe they have a tendency to dwell before moving on which may be slightly more iterative than someone who vibecodes straight through.

>> Perhaps LLM's will force developers/companies to change their stance and to stop users from recreating what they have already created, just buy an at-a-time snapshot of their app for a one-time-fee? Probably not but one can hope.

How would the economics of this work universally? Jetbrains is a bit of an oddity in terms of SaaS. For the most part, it's desktop or on-premises software that was sold with a perpetual license. If you've bought a subscription and canceled, they've generated some revenue. Maintaining a subscription generates more revenue for them, but they can slow or stop development without stopping you from using the product.

SaaS is typically some server software hosted by someone else which most often doesn't have an on-premises version. They can stop making feature updates, but if they turn off the servers, the service ends. They still have costs even if you use the software less. You can argue about the profit margins, but that's not the point here. As most SaaS companies don't start with on-premises, they can't ever get their software working there for many reasons. There are a few like Atlassian and GitHub that do both, but if you look at the heritage, both are really on-premises first.

This is a better article than other recent ones on XML vs JSON. "The S-Expression Connection" is something that resonates having been in the .NET space where Don Box was active and whole bunch of web services things (good and bad) overlapped.