This is how some folks on my team work. Ran into this when I saved a file manually and the editor ran formatting on it. Turns out that the dev that wrote it only codes via CLI though reviews the files in an IDE so he never manually saved it and ran the formatter.
I expect the formatter/linter to be run as part of presubmit and/or committing the code so it doesn't matter how it's edited and saved by the developer. It's strange to hear of a specific IDE being mandated to work around that, and making quick edits with tools like vi unsupported.
Part of a healthy codebase is ensuring that anyone can hack on it, regardless of their editor setup. Relying on something in .vscode and just assuming people are using that editor is what leads to this kind of situation.
Or just enforce that the team all uses the same tools, and you save quite a lot in productivity between making things work on different tools, more so than whatever productivity gains individual devs on the team get from using their own preferred tools. Many teams I know issue everyone MacBooks and enforce VSCode usage, for example, and that has saved so much time compared to other teams I've seen where devs can choose between macOS or Windows for example.
No, it's saving time because some things might work on one OS but not another, and then dealing with updates to each OS that might break something, or we need a new piece of software but it doesn't work on Windows for local development, et cetera, et cetera, et cetera. There are so many ways it goes wrong, I speak from personal experience.
I would not recommend this. A hook that modifies files causes Claude to have to re-read the file before modifying it again, which can build up your context window fast
What most interviews get wrong is that there are usually just a few "bullet points" that if you see them, you instantly know that the the candidate at least has the technical chops.
Instead of creating a test that specifically aims for those bullet points, many technical assessments end up with convoluted scaffolding when actually, only those key bullet points really matter.
Like the OP, I can usually tell if a candidate has the technical chops in just a handful of really straightforward questions for a number of technical domains.
If you have a test that can identify a good candidate quickly then you have honestly struck gold and can genuinely use that to start your own company. I mean this with absolute sincerity.
One of the absolute hardest part of my business is really hiring qualified candidates, and it's really demoralizing and time consuming and unbelievably expensive. The best that I've managed to do is the same that pretty much every other business owner says... which is that I can usually (not always) filter out the bad candidates (along with some false negatives), and have some degree of luck in hiring good candidates (with some false positives).
Good candidates are not universally good, they are good for you after hire.
One of the best business analysts I worked with (also a profession, mind you) was almost fired when working under an old, grumpy and clearly underskilled one.
I was hired once without interview into a unicorn, was loved by colleagues but hated the work, the business and the industry, then left rather quickly.
See? There are mismatches and unknown unknowns, not just bad or good developers.
yup, the worst performance i did on any job was due to the complete unavailability of a manager when i was a team of one. and then that manager would not even fire me. i had to quit to get out of there.
Yeah sourcing developers / collaborating with developers is a huge barrier of entry. More than others factors such as deciding what software to produce for the market
But along that thought, I’ve always held that a human conversation is the best filter. I’ll ask you what do you work on recently, what did you learn, what did you mess up, what did you hate about the tool / language / framework.
I strongly believe your ability to articulate your situation corresponds with your ability to do the job.
Take your current technical assessment and think about the types of responses or code submissions that really impressed you. What was special about them? What did you see in the response that drew a positive reaction from your team?
Can you re-frame your process or the prompt to only elicit those specific responses?
So instead of a whole exercise of building a React app or a whole backend API, for example, what would really "wow" you if you saw the candidate do it in the submission for a project? Could you re-frame your whole process so you only target those specific responses and elicit specific outputs?
Now that you've taken what was previously a 2 hour coding exercise (for example) and distilled down to 3-4 key questions, you can seek the same outputs in 15-30 minutes instead.
There are several advantages to this:
1) Many times, candidates know the answer but they actually can't figure out what you're looking for when there's a lot of cruft around the question/problem being solved. You can end up losing candidates that know how to solve the problem the way you want, but because of the way the question was posed, the objective is opaque.
2) It saves a lot of time for both sides. Interviewer doesn't have to review a big submission, candidate doesn't have to waste time doing a long project.
3) By condensing the cycle, you can evaluate more candidates and you can hopefully select a top candidate before they get another opportunity. You shorten the cycle time because the candidate doesn't have to find free time to do a project or sit down for long interviews, you don't need to have people review the code submissions, etc.
There are quite a few people who can code but have 0 social skills and can’t talk well or at all. In that sense I have to disagree with you, but I still wouldn’t hire them because they drag teams down.
These days there are more people in the industry that have great social skills, memorize leetcode but have 0 ability to patiently sit down and do meaningful work.
They don't just drag teams down, they destroy once great companies.
I argue that there is a strong, strong benefit to reading the docs: you often pick up additional context and details that would be missing in a summary.
Microsoft docs are a really good example of this where just looking through the ToC on the left usually exposes me to some capability or feature of the tooling that 1) I was not previously aware of and 2) I was not explicitly searching for.
The point is that the path to a singular answer can often include discovery of unrelated insight along the way. When you only get the answer to what you are asking, you lose that process of organic discovery of the broader surface area of the tooling or platform you are operating in.
I would liken AI search/summaries to visiting only the well-known, touristy spots. Sure, you can get shuttled to that restaurant or that spot that everyone visits and posts on socials, but in traveling that way, you will miss all of the other amazing food, shops, and sights along the way that you might encounter by walking instead. Reading the docs is more like exploring the random nooks and crannies and finding experiences you weren't expecting and ultimately knowing more about the place you visited than if you had only visited the major tourist destinations.
As a senior-dev, I have generally a good idea of what to ask for because I have built many systems and learned many things along the way. A junior dev? They may not know what to ask for and therefore, may never discover those "detours" that would yield additional insights to tuck into the manifolds of their brains for future reference. For the junior dev, it's like the only trip they will experience is one where they just go to the well known tourist traps instead of exploring and discovering.
The article is quite light in its definition of "monopoly".
It's hard to take this seriously given that the ecosystem of alternatives has never been richer, IMO.
Word processing? Notion for web natives; my kids are growing up on Google Docs and Canva and will never know Office.
Email? Same for Gmail vs Outlook.
Messaging? While Microsoft gets a big chunk of the market via bundling Teams, there's Slack and a slew of options on the market for enterprise chat and messaging. They've also been forced to unbundle Teams in the EU market[0]
Cloud? AWS still holds a commanding lead and there are other vendors like Google, Oracle, et al. that offer competitive products.
Operating systems? My kids are growing up on ChromeOS. My dev team is maybe 80% macOS and 20% Linux. All of our software is shipped as Linux containers. The OS that most of us are interacting with is probably made by Google (Android, Android Auto, Android Watch, Google TV) or Apple (iOS, CarPlay, Apple TV) or open source (Linux) and not Microsoft. The OS running most of the software we access via the web is not Windows Server. The database that is backing the majority of those servers is not SQL Server and more likely to be Postgres or MySQL.
AI? Microsoft has aligned themselves with OpenAI, but it's not hard to see that Google is very competitive in this space as is Anthropic not to mention the Chinese teams doing stellar work with model advancement despite (or maybe as a reaction to) Western restrictions on hardware. Microsoft's open source VS Code and Copilot let you pick from a slate of Anthropic, Google, or OpenAI models.
Browsers? Search? Ad platforms? Social media? No, not even close to a monopoly.
Gaming and leisure? Nope.
To be clear, I'm not here to defend Microsoft; I'm voicing my disdain for a very poorly written article that in no way backs up the claim of Microsoft's "monopoly". By all means, please point out Microsoft's monopolistic behavior, but do so with evidence and facts -- not your feelings and dated takes from the 90's. Very, very hard to take this seriously without more specifics or context (possible in some narrow context, Microsoft does indeed have a monopoly). At least from my perspective, for Microsoft to survive these days, they have to have at least a decent product at a competitive price; otherwise, there's always a strong competitor in every one of their major profit areas.
That's an incomplete view. Office is a strong incumbent not because it's a good product, but because there's decades of processes built around it. To take a small slice from my world, if you do any kind of government-funded research, you must use Microsoft Office because government funding agencies have in-house templates for budgets and technical reports. They'll reject proposals and contractually-obligated deliveries if you don't use their template. Those templates break in spectacular and unpredictable ways on non-MS-Office suites.
People use MS Office because other people use MS Office. It's network effects.
Well, I don't know how you define it, but here's Wiki's first paragraph[0]:
> A monopoly (from Greek μόνος, mónos, 'single, alone' and πωλεῖν, pōleîn, 'to sell') is a market in which one person or company is the only supplier of a particular good or service. A monopoly is characterized by a lack of economic competition to produce a particular thing, a lack of viable substitute goods, and the possibility of a high monopoly price well above the seller's marginal cost that leads to a high monopoly profit.
And Merriam Webster[1]
> exclusive ownership through legal privilege, command of supply, or concerted action
Do these hold true for Office? Azure? VS Code? Teams? Windows?
You are using the dictionary definition of monopoly, not the legal definition according to any particular nation’s laws or looking at how it has been enforced/on what basis, which is the only version that really matters in this discussion.
I imagine everyone on HN knows that simply linking Wikipedia is generally considered little more than a snarky, passive aggressive response. I don’t need the dictionary or Wikipedia definition of a monopoly for this conversation. I didn’t ask for it and you know that it wasn’t necessary or productive.
If you want to have an actual discussion I’m all ears.
I never said it was Microsoft's problem. I'm just showing you that "oh, switch to something else" is a naive view if you actually have real work to do.
Find any definition of "monopoly" and it should be pretty clear that it's not merely marketshare but the active manipulation of markets and market conditions to produce that marketshare.
> A monopoly is a market in which one person or company is the only supplier of a particular good or service. A monopoly is characterized by a lack of economic competition to produce a particular thing, a lack of viable substitute goods, and the possibility of a high monopoly price well above the seller's marginal cost that leads to a high monopoly profit.
I'd argue it's more than "just inertia." It's that end-users don't have any real meaningful choice. If you deviate from the standard in your field (MS Office in my case), you take on immense costs for minimal gain.
Microsoft knows this, and they make business decisions to maintain and expand this position. They may not be a monopoly in the strict sense (and I never said they were), but they're not a passive player either who accidentally fell into this situation. We don't need to give trillion-dollar companies the benefit of the doubt here.
> Microsoft knows this, and they make business decisions to maintain and expand this position
For the edification of the readership, please share how Microsoft's business decisions are being made to maintain a monopoly in your space. Are they buying out competitors? Are they using contract terms that forbid the use of other vendors? Are they under-pricing their product relative to the market?
If the cost of migrating results in "minimal gain", doesn't that mean that they have a top product and the market has other competitive products by definition?
If you can provide some evidence of how they actively use business practices to maintain a monopoly, it would go a long way to advancing this discussion instead of showing long-held biases and I'm sure some lawyers out there would be ready to make a name for themselves.
Someones template breaking is not a real problem. The office alternatives work perfectly fine for "real work". If your template doesnt work fix it. You fixed it all those times it broke on office.
School issues every student a Chromebook starting from 3rd grade. Outside of gaming, my kids do all of their work on Chromebooks. Presentations, documents, email, messaging are all on Google products.
The word 'monopoly' may be not quite right but the premise is.
The notion of 'there are other choices' is simply not the measure of a competitive landscape in systems with very high switching costs, incumbencies.
The pedestrian view that we have for 'competition' is 'retail' - you move from one shop to the next.
Big Industry is nothing like that.
They entrench themselves, with standards, process, procurement, brand, strategic leverage at the Executive layer, regulatory capture.
My local 'pharmacy corner store' has the same 10 chocolate bars my whole life: KitKat, Coffee Crisp etc. It never changes.
Does anyone in the world think that KitKat has some magical 'product quality' beyond the 10 000 other variations of chocolate?
No - they have 'market power'. They control distribution, they have deeply entrenched relationships with retail, they have relationships with coco producers, which shows up in a lot of ways.
If a buyer want access to the release of the 'New Swiffer' - you can't just try to 'drop our other products' like KitKat, besides, consumers have not been trained on a different product.
Consumers have seen a lifetime of KitKat ads, we don't necessarily like it, but it's a known quantity and we basically 'submit'. There are other choices, but a bit further back, a bit more expensive, a bit more unknown.
The very fact that 'chocolate bars' are unambiguously a commodity - and yet - there is no 'apparent broad market' should well serve to starting thinking more about how these systems work.
Google pays Apple an absolute fortune to be the 'first choice' on iPhone.
Google pays a fortune to create/control Chrome - which makes $0 in revenue, but which is a critical distributional component.
So your kids use 'something else' because they're in a situation where they can - but when the go to the office - do they make their own choice? No - IT does.
If IT wants to move away from just Word - then they loose deep integration with so many other things: MS Office is designed to be fully integrated precisely to thwart off all of those individual incumbents - the only way someone can make inroads, is on the margins with something really powerful, like 'Airtable'. Even then, it's relatively niche.
Combine that with the Operating System, which integrates deeply with chipsets and scale, and you can see the power.
I think that Slack is essentially a superior product, but the law firms, energy companies, gov offices are going to be sold 'Teams' and that's it. I know a lot of people who use teams and have literally never hear of Slack.
Slack is the 'niche chocolate bar in aisle 3 that costs 20% more, that they have never tried and not sure about - just buy KitKat'.
I have colleagues - very educated - who only use Copilot for AI - they think that's AI. They're not allowed to use anything else - because 'security'. Copilot is a ridiculously inferior product, not only do they exist in the ignorance of that, they actually think it's 'great', partly because 'It's Microsoft'.
The power of 'Brand at Scale' is really hard to fathom - managers and executives particularly are moved by this. They probably believe in institutional power and legitimacy more than anything and so MS because a 'hard default' that becomes difficult to overturn.
If there's a problem with some 'uppity gov. official' somewhere - MS can make discounts, steak dinners, custom integration, talk to people higher up in government, and make a strong case as why disrupting the 'default' should not happen.
ERP like SAP ... are just interminably integrated, and AWS/GCP are practically different products they are so different.
All of that is the tip of the iceberg.
There is no 'free market' in the way our instinct may apply, which is mostly derived from our 'retail' position in the value chain - the market operates a bit more differently at that level.
At that level 'Market Power' is the dominating factor, and 'product' is always second, generally things need only be 'sufficiently good'.
MS is an ok company and can create 'workable products', Google has some 'great' (and some terrible products), it's all they have to do to perpetuate - there is absolutely nothing anyone could do to displace them without some non-market force (aka government regulates competition).
If this dependency becomes a problem , and I would suggest finally in 2025 it is, then the only way out is coordinated action.
After all that I just said, the true power of institutionalization is not always hugely critical: if KitKat disappeared tomorrow nobody would care. If MS word was removed ... and everyone just choose something else, the world would not miss a beat. I truly believe that if we all woke up tomorrow and had to use Bing, it wouldn't matter that much.
Aside from major market disturbances, like AI in which those 'adept players' will probably be ahead anyhow, then it takes coordinated action to disrupt these systems.
It's much better to view those things through the lens of 'power' and not so much 'product', unless 'product' is absolutely decisive, novel, and/or it exists outside of locked-down value chains.
Not even EF Core? C# pattern matching and switch expressions? Linq? I find these very hard not to miss when working in other langs. C# is a fantastic programming language nowadays.
IMO no ORM. I've only had issues with ORMs. They work okay-ish in the very bare-bones usecases, like inserting one record into one table or fetching one record. After that, their semantics just impede your velocity.
You can represent really, really complex data retrieval and consolidation semantics in SQL. ORMs are really more of an organizational tool in my mind.
I just throw all the SQL functions into a repository class around one "thing". Not even object, it can be related functionality or operations.
SQL in code can be awful, if spread out across your codebase. So I think just don't do that.
We have a monolith that gets maybe ~1000 commits a day. We don't use an ORM, just SQL and query builders. It works out if you have good modularization.
My observation is that many teams lack strong "technical discipline"; someone that says "no, don't do that", makes the case, and takes a stand. It's easy to let the complexity genie out of the bottle if the team doesn't have someone like this with enough clout/authority to actually make the team pause.
I think the problem is that this microservices vs monolith decision is a really hard one to convince people of. I made a passionate case for ECS instead of lambda for a long time, but only after the rest of the team and leadership see the problems the popular strategy generates do we get something approaching uptake (and the balance has already shifted to kubernetes instead, which is at least better)
I 100% agree with you but also sad fact is that it’s easy to understand why people don’t want to take this role. You can make enemies easily, you need to deliver “bad news” and convince people to put more effort or prove that effort they did was not enough. Why bother when you probably won’t be the one that have to clean it up
I've implemented a distributed worker system on top of this paradigm.
I used ZMQ to connect nodes and the worker nodes would connect to an indexer/coordinator node that effectively did a `SELECT FROM ORDER BY ASC`.
It's easier than you may think and the bits here ended up with probably < 1000 SLOC all told.
- Coordinator node ingests from a SQL table
- There is a discriminator key for each row in the table for ordering by stacking into an in-memory list-of-lists
- Worker nodes are started with _n_ threads
- Each thread sends a "ready" message to the coordinator and coordinator replies with a "work" message
- On each cycle, the coordinator advances the pointer on the list, locks the list, and marks the first item in the child list as "pending"
- When worker thread finishes, it sends a "completed" message to the coordinator and coordinator replies with another "work" message
- Coordinator unlocks the list the work item originated from and dequeues the finished item.
- When it reaches the end of the list, it cycles to the beginning of the list and starts over, skipping over any child lists marked as locked (has a pending work item)
Effectively a distributed event loop with the events queued up via a simple SQL query.
Dead simple design, extremely robust, very high throughput, very easy to scale workers both horizontally (more nodes) and vertically (more threads). ZMQ made it easy to connect the remote threads to the centralized coordinator. It was effectively "self balancing" because the workers would only re-queue their thread once it finished work. Very easy to manage, but did not have hot failovers since we kept the materialized, "2D" work queue in memory. Though very rarely did we have issues with this.
Yeah, but that's like doing actual engineering. Instead you should just point to Kafka and say that it's going to make your horrible architecture scale magically. That's how the pros do it.
Kafka isn't magic, but it's close. If a single-node solution like an SQL database can handle your load then why shouldn't you stick with SQL? Kafka is not for you. Kafka is for workloads that would DDoS Postgres.
Kafka is really not intended to improve on this. Instead, it's intended for very high-volume ETL processing, where a classical message queue delivering records would spend too much time on locking. Kafka is hot-rodding the message queue design and removing guard rails to get more messages thru faster.
Generally I say, "Message queues are for tasks, Kafka is for data." But in the latter case, if your data volume is not huge, a message queue for async ETL will do just fine and give better guarantees as FIFO goes.
In essence, Kafka is a very specialized version of much more general-purpose message queues, which should be your default starting point. It's similar to replacing a SQL RDBMS with some kind of special NoSQL system - if you need it, okay, but otherwise the general-purpose default is usually the better option.
Of course this is not the same as Kafka, but the comment I'm replying to:
> Ah yes, and every consumer should just do this in a while (true) loop as producers write to it. Very efficient and simple with no possibility of lock contention or hot spots. Genius, really.
Seemed to imply that it's not possible to build a high performance pub/sub system using a simple SQL select. I do not think that is true and it is in fact fairly easy to build a high performance pub/sub system with a simple SQL select. Clearly, this design as proposed is not the same as Kafka.
No, I implied that implementing pub/sub with just a select statement is silly because it is. Your implementation accounts for the downfalls of this approach with smart design using a message queue and intelligent locking semantics. Parent of my comment was glib and included none of this.
> ...and internal systems they have to use, whose sole purpose is to make sure nobody does anything
I once had to use Lotus Notes after the company I was at was acquired by the now defunct Computer Sciences Corporation. I decided I would never, ever work for another company that used Lotus Notes.
In a lot of ways Notes was ahead of its time. You could easily have encrypted replicated databases with offline work, which was very handy for traveling users back before high bandwidth connections were widely available, and you could build quite complex apps on top of those databases.
I saw at least one large company that migrated from Notes to exchange and they got the email/calendaring bit done quite easily and were still running notes servers for line of business applications years later.
Notes was pretty decent as a groupware/ nosql platform. Lotus script wasn’t great. I might be biased because my first CS job was to write applications with it.
It felt like they basically tacked on the email functionality to to Notes to sell it, but it always seemed kinda ok to me.
reply