271–280 of 310 posts
Earlier quoted context omitted.
It was true then and it's true today. Certainly not in HN or at 8-person startups nobody's ever heard of, but the vast majority of developers work on boring business software in Windows.
Do they prefer or are they not given a choice?
Earlier quoted context omitted.
Why is it at every tech conference you see a vast preponderance of Mac's? Are conf goers not representative?
I dunno, I kinda dislike Macs. At least Windows has the decency of not even pretending to be Unix-like. Other than the fact that it has a bash-like shell, and some token support for Posix APIs, the Mac is just as proprietary and opaque (I'd argue even more so) as Windows. At least Linux allows to poke around its innards and explore with nothing but a terminal.
Strongly recommend reading this response by Terry Lambert on getting OSX to POSIX compliance.
https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...
Article mentions a tweet which narrows in on a prime culprit: https://twitter.com/copyconstruct/status/1456129831821709315 > a lot of what most “developer influencers” say is fairly aspirational. Their own companies don’t necessarily do things as smoothly as they preach to others. There's a pride element there: developers don't want to admit that they work in less-than-stellar conditions. Some developer talks also do…
One of the things I've learned the hard way is you're never going to attain aspirational software purity in a corporate, commercial software environment. I used to say naive things like "Software should compile cleanly with every warning enabled, produce no lint warnings, have zero memory leaks, and zero crashes." But the only place that is true is in my own personal hobby projects that I am under no pressure to rele…
Fun problem a few days ago: a slight design flaw allows a class of bug that a typechecker can't currently catch. Fixing the design flaw involves updating 25,000 lines across a few thousand files. Only 6 of the 25,000 lines demonstrated the bug (~1 in 4,000).
If we wait two months we can build a tool to catch the errors (and many others like it) without updating the code. The design flaw stays, but its impact is nullified.
Earlier quoted context omitted.
It'd be a nightmare to support for anything more than trivially simple, though.
Quite the opposite: the simpler the stack is, the easier to debug it is; also fewer moving parts means fewer things that break.
Hand-building a reactive (lowercase r) table with sorting, filtering, etc. that's performant at large data volumes to keep your stack "simple", would be a nightmare to maintain and wouldn't allow other developers to bring prior experience with them when they later have to maintain that code.
Earlier quoted context omitted.
I'm literally running 5 sites and $40k MRR on a $5 linode
Wow! What kind of sites are these to generate $40k MRR and fit on a $5 linode? I can think of one or the other but not put both together
"Sweaty Startups"
- Lawn work
- Accounting/Bookkeeping
- Power washing
- House cleaning
And a single content site monetized by affiliate/ads
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…
Some (Excel) were wildly successful while also introducing anti-patterns. Some (Access) were just anti-patterns.
Earlier quoted context omitted.
Example - I have JSON based RPC so that systems from other vendors can talk to mine (enterprise backends written in C++). It works like a charm and has ben doing so for years. Here comes this architecture astronaut and tells ma that I should do GraphQL and proceeds to explain me how powerful and cool it is and how everybody and his cat uses it. So on the downside I will waste a gobbles of time and money, on upside -…
Thank you for taking the time to answer. You sound like a good rational engineer. Things that work don't need unnecessary splash of coolness. On my previous job, I had been working for 15 years on the development of a complex business system. It included desktop apps, mobile apps, webs, on-premises and clouds. Throughout the years, we have introduced many then cutting-edge technologies for new products within the sys…
>"Now, I am a maker of the new development tools."
This is a part where I spend money. Good tools are very valuable as they directly save me time / money.
>"The point is that many new tools and technologies bring a very limited value to the finished working products."
Even for new ones. For example my servers are modern C++. In theory I should be using Rust / Go for new ones if I listen to a chorus. Guess what modern C++ works just fine for me and produces stellar results hence no reason for me to switch. I do some toy projects with new languages / tech to get a grip and be aware just in case.
>"Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers.Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability…
> Coolness factor, fashion, corporate propaganda / indoctrination mean zilch to me. You are absolutely right. Unfortunately this puts us in a minority in the CV-driven-development era.
Earlier quoted context omitted.
Building a high availability system? The downtime (especially scheduled downtime) of many of these "99%" services is shocking compared to the cutting edge consumer services we're used to. The "hug of death" is an affectionate meme that basically describes the remarkably common scenario where a "99%" website goes down at the precise moment at where it's peaking in popularity and profitability. Or how about high perfor…
Those are usually business decisions. Pay an extra $$$ for an outage scenario that occurs once a month, and doesn't materially impact our users? Hell no. Spend XXX developer hours and/or $$$ on hardware to make the site 50% faster, instead of adding new features our users pay for? Hell no. And let's be honest, for touting speed, Google's awfully slow and bloated these days.
What a perfect demonstration of "Those scenarios are rare if you have gotten used to what 99% can and can't do and therefore just dismiss many solutions without thinking since you know the 99% can't do those thing."
Yeah I wonder why these orgs always find these XXX hours & $$$ costs cost-prohibitive even though the benefits have proven to be substantial in cutting edge tech industries. It's almost like they typically dismiss smarter and more cost-effective technical solutions superior to naive "throw hours and hardware at it" approaches, because 99% can't do those things.
Earlier quoted context omitted.
Do they prefer or are they not given a choice?
As someone who has worked in large budget games for much of my career (where windows is everywhere) most of them prefer it.