I started with this and still prefer it from a functionality stand point but the one use case where it falls apart for me is when you have an internet connection with occasional lag spikes.
This could be a variety of scenarios like working remote on bad ISPs or cellular or a crappy VPN but all that matters is when it acts up it will cause lag, or dropped connections depending on severity. Too many interruptions while trying to focus.
For this reason I keep everything local and use an rsync wrapper over my build system that streams output back. The added delay for each command disrupts workflow less than it happening during editing.
While air purifiers are a great idea I just want to put a warning out there about the current state of air monitors.
The current summary is that most of them are wildly inaccurate with false positives and you might just be better off checking your outdoor air quality from the EPA using their app.
Would love for someone to provide a better recommendation.
>The current summary is that most of them are wildly inaccurate with false positives and you might just be better off checking your outdoor air quality from the EPA using their app.
That's partially missing the point of air monitors. In most western countries the risk is less outside smog etc and more what you get up to. Fry some bacon and suddenly you're at 20x the recommended values.
Gdocs doesn't go without it's issues. Switching from GSuite to Office365 made me want to rip out my eye balls. The online version of word is awful comparatively and depending on always having an installation of word doesn't work in all contexts.
Gsuite in general is accessible and works well for Collab.
And of course Teams is on a whole different dimension of pain.
I agree. That's why I believe each of these apps should be a native app, built for your os. MS Word on windows 10 is an unbeatable word processor. Nothing else on the web comes even close. Same with Excel.
While I think most people will agree it's not a dead end tech stack and their will be companies hiring for decades to come there's a element of truth here that isn't being discussed.
From what I can see Microsoft stack is used mostly by enterprises that are not engineering centric.
For all of the largest engineering centric companies that pay top of market only one heavily uses Microsoft....and that is Microsoft. Furthermore most VC funded startups also tend to shy away from Microsoft stacks. (Exception being parts of Azure compatible outside of the MSFT stack and other polyglot tools like VScode)
So while I don't think you need to worry about employability I wouldn't recommend investment in the stack to new graduates. Obviously my perspective is limited so I'm curious to hear counter points.
> From what I can see Microsoft stack is used mostly by enterprises that are not engineering centric.
I'm going to counter this anecdote with my anecdote. I have spent roughly half of my time in the boring world and half in the HN "sexy" tech world. 25 years of programming experience and have had immense failures and some pretty good successes.
Unquestionably, the sexy tech people were—and to this day are—worse technologists than the boring enterprise software people. I have worked at two unicorns.
One of things I believe to be true (and which is probably offensive but here goes) is that the sexy work is a direct result of over-financialization of the sector. It's a form of signaling: "Hey, our business model is so successful we can afford this shitty niche technology and hiring too many people."
There is a direct correlation between people using trendy yet mediocre technology and comments like "let's be practical" and explaining why your software can be worse than it is, because those companies don't actually need technology. As well, the people that manage those organizations are not particularly impressive because they need large groups of people to scale. (It's also why people like a16z can have the gall to claim 10x devs is not a thing, because if it were, the SV model of get-big-quick and hiring huge amount of devs with big capital and unsustainable unit economics would not be a successful proposition.)
Since the late 90s, the governing model has been: "Hey, that's cool what you do. But have you thought about putting it on The Internet?". It's the Portlandia bird sketch but with Put a Web On It. Apply this to Big Data or ML etc. This model has been very good for growth, but it requires absolutely minimal technical expertise.
I feel like there is some true observation you've made, but I can not figure out what it is from this text.
I absolutely agree with your opening statement about the flashy new operations usually being crap engineers, but cannot follow any of the rest or see ho it supports that assertion.
Or what little I can parse, seems backwards from my own experience.
For instance, the most I hear the word "practical" is to justify doing something inefficient but safe, ie use a microsoft product or service and accept it's limitations and cost, or some other safe inefficient choice like vmware before azure was a thing, etc.
So it doesn't support the idea that it's something the ignorant kids say, OR the opposite that the better engineers say it, it's just sort of a non-sequiter or something.
Personally I've grown to hate the word even though of course one has to use it and it's a valid concept to be practical. I just see it way over used to justify predictability over goodness.
The manager types don't really care about advancing anything. They do lip service to the idea of making more money by making something more efficient, but really any change at all is worse than any promised gain. Really they would love nothing better than to just keep cranking the machine they have now exactly the same way forever. They only change by force when the machine stops producing.
> For instance, the most I hear the word "practical" is to justify doing something inefficient but safe, ie use a microsoft product or service and accept it's limitations and cost, or some other safe inefficient choice like vmware before azure was a thing, etc.
Sure, I hear you and I've experienced this too. I've been on nightmare ASP.net spaghetti code projects that would be good fodder for programming sites. VB projects that are a stitched-together set of tools with a frontend full of a million buttons, etc.
But on the flip side, have you never worked at a company full of Ruby/PHP/Python engineers that have trouble getting their software to build and run correctly? People with billions of dollars who find the prospect of putting something on a web page—for a business model that has existed for a century—challenging? I have many times, and it's a reflection of how insular that segment of the industry is that they don't find anything weird about this.
In contrast, there's an army of JVM engineers out there that don't spend any time on HN because the JVM solved the problems HN talks about 20 years ago. They don't need to talk about it or consider it "news" because it isn't. For instance, the technical level of InfoQ is whole echelons higher than here. This is not to disparage the very real benefits that the "Hacker" mentality has provided to the world. SV are accomplished business and product people, and they've managed to impress the world with the type of organizational scale they can deliver. But technical it ain't.
"have you never worked at a company full of Ruby/PHP/Python engineers that have trouble getting their software to build and run correctly? People with billions of dollars who find the prospect of putting something on a web page—for a business model that has existed for a century—challenging?"
> One of things I believe to be true (and which is probably offensive but here goes) is that the sexy work is a direct result of over-financialization of the sector. It's a form of signaling: "Hey, our business model is so successful we can afford this shitty niche technology and hiring too many people."
How much of that was a result of companies wanting to use Linux server-side and MS not supporting it?
Truthfully, I don't think that has much to do with it. There is a real cultural difference between the MS ecosystem, Linux or no, and the traditional open source ecosystem.
I was simultaneously an open source advocate (using FreeBSD 3.0) back at the point when NT4 was supposed to take over the world, and using VB and the Microsoft JVM. Back then and still today there's a lot of cruft with the MS ecosystem.
What I'm getting at is if you look at truly advanced software and what might be called "engineering" practices, there seems to be no correlation with marketing hype. Cosmos is to me the most advanced cloud NoSQL database out there feature-for-feature. I think Citus is the coolest sharded database in its particular space. C# has been pretty advanced relative to say Java for quite some time. Windows systems engineers did in fact know quite a lot, despite all the crud they had to put up with the endless parade of new MS features. The best ops person I know that built a huge unicorn that runs on Linux uses Windows as his laptop when everyone else uses Mac.
There's a bad habit in tech news of looking at the success of a company and equating it with the talent or technology choices of the engineering team. Very often, successful businesses provide enough padding for unsophisticated trendy technology to fail without consequence to the business. Likewise, many low-margin, crummy businesses are only around because they have high tech talent which can compensate.
Firstly, I guess we can ask whether Azure is genuinely the Microsoft "stack". Most Azure servers are Linux and the services they provide are mostly web, ML, RDBMS related. I don't think that's what the OP had in mind.
If by the Microsoft stack we mean Windows, SQL Server, .NET etc. Then it's definitely looking more and more dead end. In the past few months I've been working with MS tech a little bit again, getting back into a bit of Windows development. It's a mess. I am constantly left astonished by the state of internal decay that evidently exists inside the Windows divisions. Basic subsystems have serious bugs, even after being pushed for years. Their docs are a mess. Their platform is absurdly complicated - look at the schemas for an AppX manifest for an example [1]. UWP and Windows Phone are deprecated/gone yet references to it can be found everywhere. The recommended way to write Windows apps is still C++. The most exciting things they're doing with Windows are upgrading the command line support to match what Linux was doing 20 years ago. dotNET is some kind of mess with many forked versions, a language that's behind Kotlin and a runtime that's behind the JVM. And the problems just continue.
One thing that becomes clear when you look around is that very few people are really writing Windows apps at all nowadays. They exist, but they're mostly older codebases. Their attempts to move beyond Win32 have mostly tanked for this reason - the people who would once have been writing against the new APIs switched to cross platform tech.
So in this regard I feel it's a dead end stack, yeah.
I'd agree with most of your points - the nature of the MS stack, Windows dev being a mess, docs polluted by related-but-deprecated technologies/versions etc.
Where I'd disagree strongly is dotNET being a mess of forked versions, the language being behind Kotlin, and the runtime behind the JVM.
The DotNet versioning annoys me, but it is actually straightforward. The Windows-only framework stopped at v4, then cross-platform Core began at v1 and now we've reached the point where Core v6 is just DotNet v6 because there is no non-core alternative at this versioning point. If you set aside naming/numbering confusion, you have a forward-moving framework up to v4 being overtaken by a rewritten cross-platform framework catching up then replacing it. There were some mishaps on the way, but this is not a mess of forked versions it is actually a pretty fast deprecation and replacement of a huge system with a massive high quality effort.
As for the main DotNet language, C#, it is generally not considered to be behind any other language out there. Perhaps in some areas different approaches have been taken when it comes to syntax, structure, tooling, but it is a very well designed language that is professionally respected, advanced, and innovative.
As for the runtime, it really isn't behind the JVM. It is supported on fewer platforms, but those it is supported on are very well catered for. Including not needing a (shared) runtime at all as builds can produce single binaries too, as per Java.
So no, the problems don't continue.
I do wonder if your recent experience of it may well be true, but is influenced by it being Windows development. Outside of internal enterprise tools, the main work is on the web/network (not Windows) and that's where it excels.
Well, C# has a less convenient syntax than Kotlin but without any more powerful features (maybe linq?). That's what I was getting at. And .net Core doesn't have a pauseless GC or anything like Graal/Truffle.
I agree it's not really a bad stack or dead end for writing Linux web servers, but I wonder how many new projects are adopting it at this stage.
We vendored all of our third party dependencies into our Bazel build. There were a lot and it was a giant PITA but over a multi-year horizon it was worth it. That doesn't mean it's the right choice for every business but it paid off for us.
Vendoring all your third party dependencies is fine, but you still have to build them.
Personally I use the native build system that upstream uses for most of them, and just hack in my compiler flags/options where necessary. Then I use CI triggers to rebuild my projects when the dependencies are rebuilt.
Get a linkedin login and start looking. Seems like recruiting either are focused on other teams, or don't have enough context. Both of those can be helped by you doing some lead generation.
what are u looking for exactly, a good place to attract talented developers is to post jobs on some slack workspaces, many programming languages/frameworks have dedicated slack work spaces where enthusiast developers like to hang out.
i find that people in smaller communities have richer technical skills and often are easier to work with
https://shield.ai/products/nova-class