141–150 of 310 posts
I think this favors stacks and frameworks where the business logic of a domain is already reflected, at least partially.
This might explain why some open source frameworks persist and thrive even while their "tech" is deemed obsolete / deficient...
Generally observed that the less you see engineering as an ideal state or set of standards, and rather as a living and breathing organism in your company, the easier your life will be. If you're ever working on a 100% refactor of something to a new framework or system, chances are you're not focused enough on the top line problems at your company. Which is related to https://rkg.blog/desperation-induced-focus.php
Reminds me of a frequent problem I observe with developers and operations teams moving Java workloads to Kubernetes. They focus on scalability, but miss the whole point of how the runtime (and not exclusive to the JVM) behaves - and prefers - when given proper resources. Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs/Nodes and containers with limits to 1,000 milicore (or 1 vCPU), and then the team solves t…
So you can’t scale java horizontally?
As the OP points out, GC in java-land isn't worth writing home about on 1vCPU. When you throw a 16GiB heap at it though, with 16vCPUs then you'll unlock some of the really interesting optimizations and garbage collectors that the showcase the JVM in an advantageous light.
So it's not that the JVM can't scale horizontally - that's a matter of system architecture - it's that scaling it as 100 tiny nodes is far less impactful than having 5 large nodes.
This article didn’t resonate with me as much as I was expecting. While the insights on developer influencers was sharp, the article itself felt like more of a reaction than an evaluation. I’ve worked in many legacy companies. The rationale for staying on the tech stack they have, and the approach they take to DevOps, is not particularly well reasoned. Often they are experiencing painful consequences due to their adhe…
I think the point that should be well taken is that if you're hoping to service the greater programming community, you can't do so in your ivory tower solutions on a community Ill equipped to utilize them. From experience, DevOps done poorly is terrible and demoralizing. Agile done poorly (often) is terrible and slow. Take any best practice and try to apply it to any organization and you'll get a lot of flaming wreck…
In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code…
I think it's much more profane - Microsoft didn't understand what the real world needed, they just leveraged a monopoly (that IBM let them establish) to frame what a computer looks and feels. They shaped the world to their liking and now it looks like a match. duh.
Great to see that big VCs are having these deep insights. As a developer, I've essentially had to leave the industry because all the small software companies are constantly coercing all their developers into using specific tools and processes from big tech companies and unicorn startups and I was constantly pushed towards solutions which are too bureaucratic to work efficiently in a small company setting. I was too p…
Weirdly one of the reasons I moved from development to a test engineering role is you have way more technical freedom. I can basically use whatever tool I want because there’s way less oversight as long as the job is done. Want to test a CLI? Use Go/Rust. Want to load test a website? Use Scala. Data parsing? Write a lexer in Haskell. I think I’ve used almost every language in the top 30 in production thanks to this.…
Excellent article. Most people need to get some data from a database to a web page and back again, to paraphrase dhh (I think). This does not require a huge amount of architecture or infrastructure in most cases, even at scale. The engineering challenges should be elsewhere , not in this relatively simple and solved problem.
I'd say it's so close to every single case, thinking about the rest is best characterised as daydreaming.
Certainly not for me personally, nor for the 10 or so companies I've worked for as a freelancer over the last 10 years. Among them are some - real - market leaders as well as small and fine companies that are extremely demanding when it comes to self-used technology (including development tools, of course).
Just look at who the owners of github (most people know it) and especially gitlab (most people don't) are.
More generally, just the single arbitrary picked difference between one company producing something tangible and another producing a pure software product should be eye-opening to anyone who has had both types of experiences. As for my career path, I've worked in instrumentation, avionics, cars, and Embedded, among others. Each with a very different culture, even among themselves, not to mention compared to software companies.
In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code…
Just look at the default contents of .NET6 vs everything else out there and it doesn't even seem fair anymore.
We build a product for financial institutions that serves interfaces to multiple classes of devices and integrates with 15+ different 3rd party systems. It has to address concerns of multiple lines of business and regulatory regimes simultaneously.
Guess how many non-Microsoft dependencies we need to get this job done? I'll give you a hint- it's less than 5.
Any sort of ideological hang-ups are dashed to the rocks in my mind when I see how amazed the customer is with the final result. All of that principled idealism melts away after receiving their sentiment.
Earlier quoted context omitted.
I specifically avoided mentioning examples as that'll stir up a lang-war.
Your rules are so vague that I have no idea which languages/frameworks would qualify and which ones wouldn't. Does React specifically mention big companies, have a young developer base and is a "kitchen sink"? I have no idea. Is Python a "bad" language? What about Go? C++ kind of seems like a kitchen sink, is it "bad"? I really have no idea how to figure out if these rules apply to any languages/frameworks.