In other words, does a16z ask for startups to attack MS on their home turf? There can be a niche for the product creation stage. But how does a company scale in MS's market? Sooner or later, it's a Slack vs MS Teams situation.
To be fair, slack kinda messed up themselves. I am still astonished that they never built video calling. Like MS did use their existing sales channels to stop slack growing, but if slack at least had feature parity with Teams then it would have been a harder sell.
Slack launched video calling in 2016. You can say whatever you want about their UX or ease of use, but you can't say they never built it.
I never jumped into the React wagon, just as I never took the Wordpress train. You do not hire an 18-wheeler to deliver a pizza. Engineers on any subject have one job: design the optimal solution, be it a bridge or an SPA to take online orders.
React makes sense for FB's bloated, complex web app. Your CRUD app will do fine with far simpler dev tools. Even vanilla JS does the job in most cases.
99% developer feels compelled to learn and adopt what is trendy because that is what the client/market/boss demands; but it is you the 'engineer' who has to tell the client/boss how that bridge is to be built. When was the last time you went to a doctor and said: hey doc I have this, give me that medicine.
>"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…
I am curious to know how you evaluate a new development product in respect to the ROI? What characteristics should a product have to satisfy your criteria for considering it?
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…
> Everyone for whom coding is something that gets in the way of their real objective.
While tech is (allegedly) evolving as fast as ever, the problems to be solved often do not. Sure, scale is always an issue and you want to reduce maintenance. But how many project do you have that have to scale to millions of users?
> Visual Basic, Access
Very true, but those tools have evolved as well. Sure, everyone laughs about people not using SAP or Salesforce and instead use a self-made CRM. I have seen terrible things here, but also good ones with more features than both other tools could provide. And it made working far more efficient. Of course Access is only used as a front end today, but the fact that there are no real alternatives is a certificate of failure of those that criticise these tools the most (I did so as well). And it is surprisingly adaptable to new feature requests.
Greatly successful projects often have horrible(from developers perspective) codebase that barely doesn't fall apart. They call it technical debt and fix il later when things stop moving fast. I think it's happening because successful projects focus on the product delivering on the reason it exists(i.e. facilitate file transfer in the most intuitive way possible) and to do that quickly as possible for the lowest cost…
> An example for this is UK's covid case tracking early on. Your choice of the UK's Covid tracking spreadsheet debacle to illustrate your point is curious, to put it politely. As The Register [1] (and many others) pointed out at the time, it was the wrong tech choice, executed slowly and at huge cost, by the wrong people with little knowledge of better choices, and directed by management and government leaders with t…
I don't say anything different, actually. As I said, had they chosen something that's not that unreasonably limited, we would have never known about it since there wouldn't be a cockup. When the policy(back then nothing was clear) is in place for good, then they can build something elegant and efficient. IMHO, they should have had it before the pandemic even was a thing but that's totally another discussion.
I never jumped into the React wagon, just as I never took the Wordpress train. You do not hire an 18-wheeler to deliver a pizza. Engineers on any subject have one job: design the optimal solution, be it a bridge or an SPA to take online orders. React makes sense for FB's bloated, complex web app. Your CRUD app will do fine with far simpler dev tools. Even vanilla JS does the job in most cases. 99% developer feels com…
>When was the last time you went to a doctor and said: hey doc I have this, give me that medicine.
Allow me to introduce to you: pharma advertising in the US
That's what I meant with "opening multiple connections doesn't increase concurrency so don't do it unnecessarily (by using a connection pooling library for example)". I was suggesting to only use a single connection for the entire request and NOT to use a connection pooling library. Now, PHP doesn't share memory between requests so there's no way to re-use the same connection across requests. That's just a sad fact a…
> Now, PHP doesn't share memory between requests so there's no way to re-use the same connection across requests. That depends on the execution model/PHP SAPI. mod_php and php-fpm use long-lived PHP processes and so can support persistent database connections depending on the configuration.
FYI - PHP doesn't have native connection pooling (due to the execution model). And Persistent Connections is much different than a connection pool.
Reminds me of: > Here's my point: yes, the whole Internet runs on Unix philosophy. But businesses sure don't. The big problem comes up in my description of pipelines up above: they only parse about 99% correctly, which is fine for your idiotic comments about YouTube videos, but pretty nasty when you mangle critical business data. And when the business dudes get involved, they'd rather do anything than mangle their cr…
This makes no sense to me, if business types care about their business data and thats why they use windows, why does the argument start off by pointing out that all the mission critical stuff like email and customer facing sites run on unix? Even Microsoft runs its mission critical stuff on unix. Windows isn't popular because its good at anything its popular because windows it meets the bare minimum and has a huge ma…
Windows is an ecosystem, linux is an OS... that's the difference. For the most part, Windows is far far easier to configure and maintain than linux based systems (and I say this as someone who runs a large enterprise system with Windows, Fedora, Debian, OpenBSD, FreeBSD, SoNIC, Dell OS10, MacOS, Azure... etc, all mixed together).
Microsoft wasn’t the clear market leader in the 70s and 80s. Look for example at the spreadsheet. Multiplan was loosing against Lotus 123. (123 being the VisiCalc killer itself) Microsoft first launched Multiplan as its spreadsheet software on Macintosh (1984), it was something like the 22th or 23rd port of Multiplan! Then in 1985 very first version of Excel (Macintosh only) It was an incredible step up from text-scr…
They were the market leader for PC operating systems since they entered the market with MS-Dos and managed to preserve that monopoly after the transition from TUI to GUI. And later they expanded into applications as we know today and built monopolies for email, texts, presentations, spreadsheets and browsing the information superhighway. All prior art, indeed, near zero innovation. The accountants love it.
Microsoft used their monopoly position to expand throughout the 80s and 90s. AARD code, Stacker, Ichitaro etc.