Hacker News new | past | comments | ask | show | jobs | submit login
Developer tools can be magic but instead collect dust (pathsensitive.com)
496 points by todsacerdoti 25 days ago | hide | past | favorite | 355 comments

Because in 2021 developer tools are fundamentally not profitable. Jetbrains is the exception, not the norm. Developer tools are loss leaders for large corporation to acquire developer goodwill and mindshare. Previously we sold developer tools/PaaS. Programmers do not like to pay for their tooling. You have to sell to management, and when your target is management, then the metrics are completely different from what developers want.

This is why no-code and low code are so much more successful than developers tooling startups in terms of revenue and profitability. The people using are the same people who are running the business. The value proposition is clear. "Better developer experience" alone is not sufficient for selling to enterprise. And programmer productivity cannot be quantified in lines of code written. This is hard point to explain and get across on HN because this forum is inherently dismissive of the value of RPA and RAD software.

Charging for developer tooling is really hard.

Over-monetizing their dev tooling was a significant contributor to Microsoft's loss of dev mind-share over the last decade. Free software took over the world because any kid in their bedroom could download Linux/GCC/MySQL for free.

Want to work in .NET/MSVC? You just run into barriers (gimped "express" versions, no free documentation etc.) Yes this has changed now, but it's been a long time coming.

"Kids in their bedrooms" had cracked versions of MSVC.

Even at my school, I don't remember a single student paying for any software. Teachers were obviously aware of that and while they didn't encourage piracy openly, when they showed something on a high priced software, "go ahead and get the cracked version if you don't already have it" was almost implied.

We also worked with Linux and free software a lot, that's just to say that price never was an issue, because we didn't pay.

It is debatable but I think publisher were happy with that situation, students wouldn't pay in any way, they might as well learn on tools that their future employers will have to pay for.

Things have changed. Most notably, the primary way of monetization is online services now. Software is often given away for free and piracy is either pointless (because free software) or much harder (because a large part of it is online).

As for charging for dev tooling, yes, it is hard, because charging for software is hard. That is, unless you have an online service component. That's a reason why "collaborative" tools are so popular now.

At my school, about 10 years ago, any student who was either a CS major or taking any CS class got free access to full versions of pretty much every MS product except enterprise versions. That’s full versions of Windows, .Net, SQL Server, Office, you name it. There was no need for anyone to pirate anything.

You have to jump through a bunch of hoops, if you even know about what's there. You have to make sure the right thing is registered in the right way, and if something's broken down in the link between your university's login setup and MS's setup then good luck getting someone to fix it as a student. It's actually a huge difference in practice from what you get with open-source (or piracy): download the thing and run it, that's it.

No, not really. I remember it being dead simple when I was there.

It's a pointless argument. You had access to all the software with a regular student license, it was obviously never meant for any production workload and never meant to be covered with any kind of support.

Since piracy was/is the norm, you might as well provide a few version.

I remember the process as 1) Submit my .edu email 2) Click link in email 3) Pay $50 4) Get keys to ALL the things.

All you need(ed) was an e-mail address that ended in @myuniversity.tld and use that in the registration at the shop.

Yeah, we had access to DreamSpark around 10-15 years ago and it was pretty awesome.

I was very much a Linux person at the time, but I could still appreciate all the free stuff MS lobbed at students.

Adobe CC apps used to be so easy to pirate, but recently Adobe has been going hard on anti-piracy detections (I imagine it is indeed getting abused by some businesses somewhere). I was under the assumption that a majority of their mindshare was from high school kids learning on cracked adobe then asking for licensed creative cloud apps at work.

I’ve also noticed the rise in Adobe alternatives over the last few years so must be working

This times 100. The open source alternatives are ridiculously good. Figma and Blender are the ones I use and we've made some extensions for specific jobs painlessly.

The free stack is even catching up where paid software used to excel - modern, usable UI. We're happy to drop a few hundred on donations.

Figma is not open... not open source, or even file format.

I would never pay for dev tooling as a SaaS because it would put me completely at the mercy of the provider.

I’d be happy to, and do, pay for some dev tools that I get to own for life. The Jetbrains model is really a great match I think for both the company and the customer.

For me it was my dad's friend who worked as an enterprise Microsoft dev, and would give me his old MSDN CDs when he was finished using them. So I got Windows NT, Visual Studio, and complete API documentation -- even Windows 95 when it came out.

Not sure what you mean by “no free documentation” but even when I worked there we just used MSDN’s free online website like everyone else. VS did cost $$ but not sure it was overpriced, I’m still less productive on Linux than I was with the real VS (code is nice but not the same). I’d pay for a Linux version in a heartbeat.

The real reason Linux took over is Windows just didn’t make a good server. Even if you looked past the bloated footprint, licensing was a nightmare just to figure out what you needed to buy let alone the licensing costs themselves.

Even good dev tools can’t make up for a bad platform.

I believe by "no free documentation" they are referring to the 90s, where MSDN was a subscription service, hence the "long time coming" comment.

The comment was about the last decade? Seems kind of irrelevant to bring up an obstacle from the 90s.

> Over-monetizing their dev tooling was a significant contributor to Microsoft's loss of dev mind-share over the last decade.

I don’t know about the author of that quote, but I mentally often think of the 90s as “last decade”

Interesting. Is that a reason behind it? I can see why the 2000s might seem like "last decade" (it might still feel like the 2010s), but the 90s are another decade behind...

I don’t really know, but Y2K and 9/11 were fairly notable in a way that most of the other decade transitions weren’t.

I also don’t really know if this is common: but the individual years of my adult life just seem less real than my childhood for some reason.

Because the human brain perceives time in odd ways.

That joke was funny 10 years ago.

It's probably not a joke. Many people report things like this when talking about time. Our brains are just not that great at accurately thinking about long periods of time.

Clearly his directly outer conscience thinks it's the 2010s

Also at that time you could for about 60 dollars buy 'the win32 bible' which had pretty much every call you wanted in print form. Also about 50 bucks got you the CD with the docs. Only when you went to the 'I want MS in a box' MSDN that you paid more. MS dominated in that market in the 90s because they had tooling that was wildy cheaper than most of their competitors on other machines. Sun/IBM/Apple easily priced their docs in the 20k+ market. I bought many of these docs for these different archs at the time. MS was by far the cheapest of them. Borland and Watcom had 2 different setups with and without docs. You paid accordingly (usually 100-150). Also once the internet came around MS put its docs up on the web pretty quickly. They were about equivalent to the CD's. I would say around 96/97 they did it. I have not paid for MS docs since. I paid a few times for MSDN as I would need a lab of machines and ACLs were dumb expensive.

There is an incredible UserVoice thread that's been going for years asking for a Linux version of Visual Studio. It's such a microcosm of Microsoft problems.

- Naming confusion between three completely different products Visual Studio, Visual Studio for Mac, and Visual Studio Code.

- Complete failure to comprehend how old VS's codebase is. "Dotnet Core runs on Linux, right?"

- Most people use about 10% of the functionality it offers. Unfortunately no two users use the same 10% of it's features.


I think the cost of the tooling did matter but I also agree about licensing costs for their server products.

The first time I got to work with Linux for money (as opposed for fun at home) was when I had a project where the MS Licensing would cost a lot more than the hardware it would run on.

They let me do it with Redhat, PHP and PostgreSQL. They bought the box from Dell and that was it. No licensing to track or pay. The freedom was just amazing and made business sense.

You can now deploy .net core apps on Linux. Even SQL Server can run on Linux now. Plus, if you want to, debug it locally on your Windows machine on Linux using WSL (as simple as changing a drop-down to WSL and it'll install everything required on your WSL instance).

On the negative-side, the asp.net core team is obsessed with dependency injection and async, which results in tons of shitty boilerplate. So you either have to strike off the beaten path and get nice clean, terse code, but constantly fight the tooling, or accept their dogmatic styling and end up with ridiculously bloated code.

I haven't worked with ASP.NET Core for a while now, but what exactly do you refer to with "ridiculously bloated code"? async-await doesn't add much extra code, save the occasional await keyword sometimes?

Yes, that's just the DI that does that, the async/await just gives you ridiculous call stacks and untraceable errors, usually for zero performance gains.

> I’d pay for a Linux version in a heartbeat

We should enter a world where people pay for open-source. OSS has been fine, but they never had the correct resources for marketing and UX. The should be a paywall for access to repos, even if you could theoretically find the code everywhere else, but ey, want the code updated automatically? $5 per month. (I’m paying 1% revenue for OSS but as long as it’s not everyone, it doesn’t make the developers filthy rich and able to hire UX and marketers, and that is what we need).

There is zero blockage to paying for OSS right now. Just Do It. I've been a member of the FSF for years.

What hasn't happened is a culture of offering financial feedback to favored projects.

Patreon and Kickstarters seem a start.

Suggestions are welcome.

> I’m paying 1% revenue for OSS

So I’m already paying, as you sure have read.

> but as long as it’s not everyone, it doesn’t make the developers filthy rich

You asked for suggestions, it is right there. Ask people to pay for access to the repos, or let them download for free from alternate sources. It will make big businesses pay because they require a chain of custody, while the amateur can still download for free, and it conserves all other advantages of OSS.

I do have a feeling that your comment was adverse, I constantly regret being generous when people talk to me like a thieve anyway, just because I give, but not enough (How much is enough for people like you?). Also, you are possibly trying to solve the problem of freeloaders by having possibly adverse comments, not seeing that I’m trying to solve your same issue of freeloaders by finding an incentive which both conserves all advantages of OSS and still leverage money en masse from larger businesses.

FYI I also mis-read your comment. I had to double back to see you mentioned paying 1% of revenue for OSS.

“Assume good faith”; Hanlon's razor applies.

I admit to missing this point.

The problem with paid for OSS developer tools is:

* The customers making serious money off improved developer tools - the kind of customers who'd pay $10,000 per seat for a great developer tool - are big businesses.

* Big businesses basically won't pay for things they can get for free. Oh, they might occasionally sponsor a conference for PR purposes - or even pay for developers implementing features they want - but nobody's paying $10,000 a seat for Eclipse out of the goodness of their heart.

* You might think I'm saying "Well then, closed source tools all the way!" but the tools in other engineering sectors that do manage to extract that much money from companies (SolidWorks, Altium...) have a bunch of problems as well - mostly around user lock-in efforts blocking anyone making compatible tooling.

How about FOSS have a commercial licence and a body to collect payments from enterprises, pays out the open source devs. Basically a more focused and more opinionated/vocal patreon.

> Over-monetizing their dev tooling was a significant contributor to Microsoft's loss of dev mind-share over the last decade.

I disagree. I think the biggest contributor was the loss of Windows as the platform to reach paying customers.

All throughout the 90’s people paid massive amounts of money for Visual Studio and MSDN subscriptions. There was also a huge ecosystem for such things as VBX or OCX controls to simplify development.

Developers easily paid the price for Visual Studio because that was the way to reach paying customers. In addition, Microsoft was very aggressive in giving free copies of Visual Studio to students. My university had a program where you could get access to all of Microsoft’s Operating Systems and Development tools for free through your .edu email account.

Then the web and mobile came, and Windows as the place to reach paying customers faded away.

I think you nailed it. The web & phones took over, and the world underneath changed. Servers and mobile tended to go UNIX-based for obvious reasons, so it's not hard to see why people moved toward developing on UNIX-based platforms. Had those revolutions not happened and if we were still on desktops, we might very well still have been dealing with expensive tooling licenses for Windows (and expensive Windows licenses too).

There's clearly a bit of a chicken and egg problem here. I would say that the web revolution gained so much momentum because so many developers could easily get the best tools to learn and experiment with for free with zero barriers.

It's possible to imagine a world where few ever thought to push HTML/CSS/JS to their breaking point to get desktop-like functionality from a website, because developing for the Windows desktop was free and a nice experience.

> I would say that the web revolution gained so much momentum because so many developers could easily get the best tools to learn and experiment with for free with zero barriers.

IMO (based on my limited view; I haven't studied the history) it happened because the market for smart mobile devices enlarged (one could argue Apple basically created the future & the market with iPhones, which Blackberry didn't manage to), Firebug and then Chrome made it easier to develop for the web, and developers found that these tools let them make cross-platform apps from a single codebase, with a much larger audience to go with it too.

Which is why I didn't see it as being an issue of price-point: I don't recall any better alternatives to it, whatever the price. Even if you were willing to shell out $1000+ for software tools, what alternative tools could you have bought to make it nearly as easy to make apps that ran on practically every major platform out there? Your only practical option for language was JavaScript (or if you were really desperate, Java, or I guess Flash), and Firebug and Chrome had (and many say Chrome still has) the best dev tools for JS. I don't see how being more willing to spend money on dev tools would've changed this on the client side.

On the server side, Windows had more to offer (and perhaps ASP.NET was a decent alternative), and prices probably mattered a ton there. But that's not primarily about dev tools, that's about the Linux being free and Windows Server very much not.

Firebug and Chrome were just icing on the cake. The band wagon was well going long before that.

Yes. Maybe if MS strategically invested in excellent, free tools, Windows Phone would have the best apps, and win most customers. "Developers, developers, developers" was right direction, insufficient magnitude.

Note that Android chose Java, not for its performance on constrained devices, but for... developers.

I really can't see how to tell how plausible this is, that MS Phone could have won, through better long-term strategy, of free dev tools.

As someone who did cross platform development for iPhone, Android and Windows Phone way back when, Windows Phone did actually have the superior dev experience by far (talking about WinPhone 7+ here). It wasn't free, but neither was iPhone development.

They didn't have any market share though, so there wasn't much money to be made making apps for them. I suspect they failed because they launched 2-3 years after Android and iPhone, so the other platforms had accumulated the network effects of an existing user base and app ecosystem that they couldn't catch up to. And they tried hard, IIRC, Microsoft offered to build a Snapchat client for Snap Inc, and to pay them to be allowed to do so, but were denied.

No, MS Phone became irrelevant because there's no space on the market. Indeed there's barely space for more than 1...

Apple managed to claw its position out of pure first-mover-advantage, and it's choice to build on top of a proprietary API. Had they gone with some HTML/js morass, it would have been easily dogged down and ground to dust on the interoperability battlefield.

Microsoft could wrestle Android out of Google's hands though... I mean, why not spinning their own Microsoft-oriented build around AOSP?

>and it's choice to build on top of a proprietary API. Had they gone with some HTML/js morass, >it would have been easily dogged down and ground to dust on the interoperability battlefield.

Actually, initially Apple expected people to deploy apps as webapps and provide links on the homescreen. There was no ios SDK. Only after a lot of loud complaining by devs did Apple release any tools or an SDK for ios native apps.

I think it was Joel of StackOverflow who wrote that that was not the case at all. His statement was that MS would have loved to give away Visual Studio, however they wanted to make sure there was a viable 3rd party market for developer tools. They didn't care what you developed with just as long as you were targeting Windows. Visual Studio pricing was designed to create a price floor that any third party dev tool company like Borland could rely on.

The reason for not keeping it freely accessible doesn't matter. It's either freeware and some hobbyist or student can easily get, or they cannot.

MS dev tools were freely accessible in the same nudge-nudge-wink-wink way that Adobe tools were. I don't think I ever attended a LAN party where people weren't trading cracked versions of the best MS had to offer. And MS never lifted a finger to stop this process. Hobbyists and students had access to everything MS had to offer and often wanted to keep using them in a professional setting.

It is but also the price has something to do with it. They are all hundreds of dollars.

Java was in the right place at the right time have a Hype Cycle that aligned with availability of the internet and search engines.

If you were graduating and thinking MFC or Java you just had to look at the price of the bookshelf of books required to get anywhere with the former and have some second thoughts.

Depends, if you wanted to do Swing apps that didn't suck, the books for Java were exactly the same as for MFC.

It is quite telling how Swing got its fame.

Also, I remember trying to download their software onto my modest home PC as a teen, and just the size it was taking up on the my drive, and how long it took to download everything scared me away. I wanted space left over for games.

Similarly, I see people leaving jetbrains every day. VS Code is getting better and better, and jetbrains tools are becoming more and more niche. While jetbrains may always be ahead, the gap is widening.

I doubt it - VS code is nowhere near a proper IDE like VS or IDEA - the only place where it's comparable is JS/TS because of how close those two teams are.

It does work when you needs something light weight - but it often craps out on large projects - ironically it slows down way more than the IDEs. For example I'm writing a Flutter/Dart project ATM - the VS code plugin becomes unusable after a while of working on the project even on a relatively small ~30kloc project. IDEA works just fine and has much better tools.

"VS code is nowhere near a proper IDE like VS or IDEA"

This statement kind of misses the point: it's not that 'VS Code is an IDE', rather it's that the value of an IDE may not be as much as what some think it is.

I would have made the same conclusion a decade ago, but with sufficient plugin/ability ... I have come to prefer VS Code along with many others and have little reason to go back to using an IDE.

That's not to deny the IDE uses case - for specific kinds of projects it's fine, but there's no doubt VS Code - a non-IDE - is picking up in an a ton of areas wherein traditionally and IDE would have been a first choice.

Even for basic stuff like symbol rename in a project it's behind good IDEs - search and replace is tedious when a tool can make it more specific without effort.

And like I said it often craps out on autocomplete alone with larger code bases for me (had this happen in Dart and C#)

It's the perfect IDE/editor for JS/Typescript - the rest is subpar.

For example I'm writing a Flutter/Dart project ATM - the VS code plugin becomes unusable after a while of working on the project even on a relatively small ~30kloc project.

I use VSCode on a project that's about 3* that right now (not including things like node modules or config) and it's never failed.

Are you sure the problem lies with VSCode rather than the Flutter/Dart plugin?

Oh it's absolutely the dart/flutter plugin. Just as it was the C# plugin when I attempted to use it as a VS replacement, and it was down to Rust plugin when I tried that.

So in the end the only decent experience I had with it was Typescript and JS.

Compare that to IntelliJ or Visual Studio. If I was mostly doing Web frontend or node I would 100% use vscode. Otherwise I just find it's too unreliable and I don't want to waste productivity energy on it. (I wish it was on IntelliJ level, I would pay for that with vscode remoting possibilities, more than I pay IntelliJ even)

> it often craps out on large projects

I wonder if that is because VsCode runs on top of Electron

I doubt it - it feels like it's more of an issue with language server implementations, Typescript is excellent even on large projects (better than IntelliJ and VS IMO)

> I see people leaving JetBrains every day

I see people leaving iOS every day for Android, but this people are balanced out by users going the other way.

The same is true, I believe, for JetBrains and VS Code.

Indeed, I just moved from VSCode to PyCharm a few weeks ago as VSCode and their error checker/syntax highlighter is vastly inferior. Looking to do the same for JS at some point but for now VSCode is still the best I’ve found for it.

Every time I change developer tools it's because the one I've been using has become bloated with add-ons as part of the install. When the installer has options for choosing packages, they aren't granular enough to be worthwhile. So the IDE becomes a hinderance, using memory, CPU, and screen real estate intrusively. JetBrains is there now, but it still has better language support for my needs than anything else more lightweight. I use VS Code for everything unless I absolutely need to fire up JetBrains.

> So the IDE becomes a hinderance, using memory, CPU, and screen real estate intrusively.

The screen space used is highly configurable, but if it wasn't, I'd agree. I don't care about memory or CPU at all.

Maybe it's different for other languages, I mostly do PHP + JS/HTML/CSS, but PHPStorm vs vscode (+ plugins for both) is not even close, and PHPStorm makes me so much more productive and takes so much annoyance out of my day that investing in a beefier machine seems like a small price to pay. I've easily made that money back once a month just because I get more done.

I like vscode, but I pretty much exclusively use it as a text editor and notepad.

PHPStorm gives you so much, it feels like too much because it takes forever to load.

Developing with php should feel fast. I feel like phpstorm slows me down. I like sublime, it opens the last project in .5 seconds. For me ctrl-p start typing is usually quicker than scrolling down a tree structure.

I want to use phpStorm daily again but it gives me zend eclipse flashbacks. I wish they offered a light verson.

Are you on a 15 year old laptop or something?

The Jetbrains stuff really isn't _that_ heavyweight.

Loads faster then vscode for me - the only real hinderance I find is it expects a “project” and isn’t very good at “I just want to edit this one file”

There is something exactly for that: https://www.jetbrains.com/help/idea/lightedit-mode.html

You might be having a different usage pattern than me. I typically work on only a few projects in a day, and I have those open in parallel and switch between windows.

It's a shared process, so they're not each taking up resources (I wish that was changeable, since they've had and continue to have some annoying bugs around it).

VS Code has only just barely beaten out Geany as far as it's base functionality and plugin ecosystem goes.

A Scintilla-based editor is still going to crush it on the resource usage front.

VS code with Python is just frustratingly buggy. The only reason I'm forced to use it is the WSL/remote integration. Pycharm just works.

And VS code with C++ is downright horrid, almost nothing works properly using the official C++ extensions. Yes it autocompletes and it sometimes manages to find the right files when you switch header/source, but that's about it.

I still use it at work though because we don't have CLion there and that code base does not use CMake, but only because it is just slightly better than plain VIM with some plugins. But compared to CLion + CMake it's just one small step beyond a glorified text editor.

CLion has non-terrible Makefile support now too

We use SCons at work, nothing really supports that :-/

> Programmers do not like to pay for their tooling.

Because it is too much work to convince the company that spending $500 on JRebel to have me not go on Hacker News for 5 (and it turns into 15) minutes while the thing compiles (my last company). I also have no real stake in whether the product ships in one month or two so I am not paying for it myself.

To pay for tooling, productivity needs to be a priority. I have never worked anywhere where productivity was discussed.

Exactly this.

Ultimately, the tools I try out are the ones that don't make me involve other people in it, whether to inform or to get approval. This is extremely important at the beginning - particularly when I don't know the tool beforehand, so testing it is a bet.

Thus, extrapolating from my experience, I'd consider the main problem with paid tooling is that it usually requires getting other people in the loop. Even if it's sold in a way where you could use your personal paid license at work, that fact is very often unclear from the license text - unclear enough that you probably don't want the risk of procurement/legal disagreeing with your assessment.

(If we're talking SaaS/anything with on-line components, there's no way I'm touching this on my own - I have enough headache with exports control around remote work, I'm not going to risk anything I do be considered technology transfer.)

I feel I'm not atypical with this - I suspect developers in general have an opposite relationship with software licensing to that of their employer. For a company, OSS is random, unpredictable - while commercial licensing is safe, because there's a contract and a way to sue someone. For a developer, OSS is easy to understood, zero risk, no need to involve other people - while commercial is completely arbitrary, every piece of software has a different license, and thus it's very strongly preferred to involve management/procurement/legal in this, because you don't want the liability on your shoulders.

I cannot possibly agree more with that last paragraph, you’ve summarised that so well.

A discussion I was party to recently was debating which of open source vs several competing commercial products to use for a new development. Chief complaint raised about open source product by the team members on the business side of things was “oh it’s open source, that means there’ll be no support right?”. Comparatively my teammate and I had the reverse reaction: we know for a fact the open source alternative is at least 90% as good, if not better than the alternatives, we don’t have to wait to go through the rigmarole of purchasing, approvals, waiting for someone to sign contracts, finance to sort things, finding out you need another key because another person will be working on it as well, discovering the support is invariably shitty, and then being stuck with it when it turns out to be poor software and the business side won’t budge, because that means they’ll need to do things again (which will take weeks at best) and they’ll inevitably just end up re-signing the contract for another year.

Some companies will care. Some won't. I mentioned something like this to mine and they upgraded the build server in response.

For Jetbrains products, if you enjoy them you can use your personal license commercially. Your company just can't pay for it or reimburse you for it. This is the route I go because I use their products for personal projects too. For me it's a no brainer at $150/year for their all-products option (...for the 3rd year, 1st is $250, 2nd is $200).

I'm toying with the idea of selling developer tools only as personal licenses that can be used commercially. Like a driver's "license", companies must hire "licensed" developers to drive the software. (also licensed plumbers, electricians, accountants, surgeons etc - though true all are skill/knowledge credentials, not simply purchasable; so include an exam).

Companies need to hire and pay more for "licensed" developers.

It gives power to developers - and then I don't have to sell to managers or deal with uninterested clerks.

> It gives power to developers It gives power to senior, rich developers, at the cost of newcomers. It's a toxic zero-sum play, which contributes to, e.g., shitty 10x overpriced health-care.

Same here. It costs me less than fifty cents a day to be able to use all the JetBrains IDEs and developer tools and get all their updates, both for my personal projects and for work.

I can only speak for myself, but to me, "no brainer" is an understatement.

I do this as well - its pretty easy to justify a Jetbrains Ultimate subscription for myself since it makes life so much easier.

I get this for free with an annual UX interview, but yes I would pay for Jetbrains personally.

That is all way too much money.

If they want more adoption, they need to be under the $100 mark.

$150/year is too much for developers who earn $100k+/year?

I guess you proved the original point of this thread.

Don't forget there are a couple hundred countries besides US. I make a relatively decent living by our standards, but nowhere near close to $100k/year. $150-250 per year is quite a bit of money for us.

I'm surprised it's not at least $1000/year.

Even if you make 30k a year, $200 for access to a variety of tools you rely on to do your job is a no brainer.

It should be possible for a small devtools company to price differently based on locale, but I expect the support costs would then dominate any of the lower prices customers.

I think the core point missed in this thread is: developers write software for a living. They do not want to pay for something they would love someone to pay them to write.

You see this in other professions. A car mechanic doesn't want to take there car to someone else. A doctor tries to avoid general checkups with other doctors. A realitor will sell their own house. A grass cutter doesn't hire someone to cut his lawn. The person who makes lawnmowers doesn't buy one he makes one even if it takes longer.

I would love for someone to pay me to write an IDE. I've been in that situation a couple of times in the past (SQLWindows, Visual Basic) and it was a lot of fun.

However, my current job is developing a voice response system for restaurant drive-thrus. I don't have time to write my own IDE right now!

So I farm that out to JetBrains and get to use all of their awesome work for less than fifty cents a day.

If that's too much, their free versions are very good too.

I may also take exception to this:

> A doctor tries to avoid general checkups with other doctors.

Wouldn't the opposite be true? As far as I know, every psychiatrist has a psychiatrist, every counselor has a counselor (or should), and I would guess that every doctor has a doctor.

A doctor is more likely than the rest of us to have particular insight into their own health, but I don't think they try to do it all alone.

Of course I'm only speaking for myself. If anyone prefers to write all their own tools, more power to them!

Agreed. I also run Linux, because at the end of the day, I don't want to write a new OS when someone else had already done that.

Then there is this saying that if a lawyer represents himself in a court, he has a fool for a customer

> Then there is this saying that if a lawyer represents himself in a court, he has a fool for a customer

Also making the reverse assertion true too: that client has a fool for a lawyer :-)

Of course, many unsuspecting non-lawyer clients also have fools for lawyers; it's hard to tell whether or not your lawyer is any good (unless his name is Saul Goodman)

That's a lot of money to me, despite how much I earn.

Especially when the options are free.

Sure you can walk instead of having a bike, a car or taking public transport.

I think that's a bad example.

A car lets me do a lot of things, not just a single thing.

I think development tools are overpriced. Under a $100 I can see. Over that is just too much.

The username makes it even funnier.

Only if you don't think about it.

I pay more for Apple products because they bring a lot of value.

I don't see the value for many developer tools at their price.

That's the price for an all you can code subscription to everything. Individual licenses are much cheaper.

$250 (the initial all-you-can-gobble) is a day's wages or less for anybody making more than $62500 (post-tax) per annum, which at least in the US is not a lot at all.

That $250 isn't (generally) tax-deductible. At the moment, I'm making ~€80k as a SWE in Belgium (reasonably good pay but not the highest), and my net income is closer to €150/day. At the top of my career, I expect that I could increase that to at most €200/day because taxation is brutal.

This is not to say that I don't pay for tools; I subscribe to the full Jetbrains set among other things. It's just that that wasn't as simple of a decision as you present it.

Is it not in Belgium? In Germany you can count this as 'Werbungskosten' which you can deduct from your income. Anything you use for your job or for professional development counts as this type of expense. Don't other countries have similar concepts in their tax systems?

Then for someone in your position it'd be a day and a half of post-tax salary (for the first year), which doesn't sound like a lot either.

$250 is a lot of money for many people, even if they make over $62,000.

And the price goes down over time, third year is $150...

On my team of three, my teammate and I had to create a presentation for our project leader that he could share with our director making a case for buying ReSharper licenses for the two of us. Then of course our director declined to spend the money. It was tedious and infuriating.

You were probably paid more in salary to make that presentation than those licenses cost, lol.

That is literally how I have justified every single expenditure on tools for myself and my team for going on twenty years.

I've spent many, many hundreds of dollars for development software out of my own pocket, because, just like with high-quality hand tools, good software tools pay for themselves over time. Even given what I make in the manufacturing world, these expenses don't account for a lot of my take-home pay, and I make half (or less!) of what hot-shots in tech make. I'm not worried about being reviewed on my productivity, I just want to get the work done faster and better for myself.

I think you make an interesting point. The employer maybe thinks like this: If those dev-tools are so great then let the programmers pay for them? If it increases productivity like they say and price is small compared to their salary, wouldn't they want to pay for it.

One alternative approach I could think of that the employer should give each programmer a dev-tools -budget per year. That would encourage programmers to experiment with better tools and find the best ones.

Depends on the company and the manager. If someone on my team wants something at or under $500 then no problem unless they have a habit of buying tools they never use. It's my job to make sure my boss doesn't raise a fuss about it and not the developers.

I don't think you have this right. The problem is not paying for developer tools, the problem is investing your time in proprietary solutions that might go away any time. For a long and resilient career developers have to stick to tools and technologies that are not dependent on ephemeral corporate support.

this exactly.

I'm fine to pay for tools (and I do). But I hate the idea of becoming dependent on proprietary tools. Imagine leaving your job and going to the next and because they don't pay for a tool you've become critically dependent on half your skills are useless.

And its not just for myself but I think its harmful that it creates barriers within teams and organisations. All the investment in infrastructure and knowledge connected to the tooling can only be shared with the people licensed to use it. If your team processes depend on it then nobody outside the team can even properly work on the software.

So we end up in a catch 22 where I will say, we can pay for software as long it is still perfectly practical to develop our code without it. But if you extrapolate from that, it means nothing we ever pay for can have a very high value proposition, and ergo we can't justify paying for it.

That is my feeling as well I never wanted to become dependent on tools. Right now I use WebStorm and I'm happy paying for it. But I don't really have dependency on it, I could easily switch to VSCode but I think I am happier with WebStorm.

The issue is it took me long time to learn how to use WebStorm effectively. That is now a good reason for me to stay with it.

I get the all tools pack from jetbrains and every time I’ve switched languages they have an ide that’s basically the same for it - it’s fantastic

Thats why I pay for my individual full jetbrains package. First year was $250, next year $199 and the next $149. Quite an investment the first year ok. But now I own my tools, and it turns out I also use them a lot for personal projects so I'm happy with that as well. I would not work for a place that doesnt let me bring it or offer it to me (because I can afford saying no).

AFAIK this is why Microsoft let windows and excel be pirated for personal use up to certain level.

Proprietary tools is worse for developers / companies that develop with many languages and / or other toolings (unless it doesn't interferes with the process itself).

> Because in 2021 developer tools are fundamentally not profitable.


But monetization might not be the root of this since we have very sophisticated tools delivered as open source. The question then would be why the "dev comunity" is not interested in building tools like those mentioned in the article?

My guess is that tools like Reflexion Models doesn't ring any bells for junior/mid-level developers. They don't know exactly what to optimize when it comes to long-term maintenance. That's why we have so many parsers, linters, etc. and now typed languages (again!) and not Reflexion Models.

The other day I was looking for something similar to Reflexion Models: a tool that I could describe high level modules and its files (like a package), describe the dependency hierarchy between then and check if there is any calls between modules that break the hierarchy. For instance: getting a alert if there is a call to a repository from the a controller (DDD). It's a common problem for big teams with junior developers that could be solved by automation.

Hey I've recently been looking at http://www.structure101.com and it does exactly what you mention, and integrates with both your IDE and sonarqube

Senior developers with 20 years of experience do not "believe" in debuggers, IDEs or writing tests. Same things are reinvented every 3 months with a new name written in a custom font. We are in many ways still in the bronze age of software development.

> Senior developers with 20 years of experience do not "believe" in debuggers, IDEs or writing tests.

Speak for yourself. I've been paying for my own developer tooling for 25+ years.

What do you find to be worth purchasing?

Off the top of my head:

- The JetBrains suite of tools (Rider, CLion, DataGrip, Webstorm)

- Sublime Text

- Prior to offering Visual Studio Community Edition, I used to pay for MSDN if my employer didn’t supply it.

- Beyond Compare

- Recently paid for Tabnine Pro, the jury is still out if this is worth it.

Debugger is just a nice interface for prints.

IDEs should be replaced with libraries that allow one to operate over the code (or make IDEs allow you to script their AST manipulators)

Writing tests is not connected to the two above.

I’m sorry but that just means you have not have learnt how to use debug tools.

No, I know how to use them, except that in my cases I never need to look a the debugger because I rarely need to know the state of the program at a given time.

I need to know how the program ended up in that state. I can't reproduce this from a core dump or via a debugger.

> I can't reproduce this from a core dump or via a debugger.

Because you don’t know how to debug. Time travel debugging does exactly this.

You can... are you familiar with the concept of a call stack?

That’s definitely not what a debugger is. You can’t add prints to a coredump and the run->add prints->compile->loop sucks a lot, especially if the bug is hard or slow to trigger.

I think the main promise of an IDE is being integrated. But maybe it could just be done with libraries.

> You can’t add prints to a coredump and the run->add prints->compile->loop sucks a lot, especially if the bug is hard or slow to trigger.

Yeah, but the core dump doesn't give you an answer on how the program ended up in failure state, does it?

Use something other than DDD?

Debugger might be a nice interface for prints in kernel. It is also not usable with distributed systems where prints are also not all that useful and you need some kind of central logging. But developing a desktop application without debugger is like writing code with a line editor. It can be done but it is not very productive (I can still remember editing BASIC programs one line at the time).

I meant "prints" as in "logging events into a file".

Which is why I grew disappointed with FOSS and decided I was happier working for the enterprise overlords, where such tools are common.

It is incredible how so many devs don't want to pay for tooling, yet expect people to pay them.

Here is an idea, what about being paid in the exact amount that one is willing to pay for their tooling.

> Here is an idea, what about being paid in the exact amount that one is willing to pay for their tooling.

A better idea: what if all companies had to pay for all the software they expect to make money using, right down to the metal? No leeching off linux for you. Also no gcc, llvm, postgresql, mysql, python, ruby...

When people try introducing proprietary software into the FOSS ecosystem, I find it equally "incredible" how little they acknowledge that most of their piddly 10k lines of "magic" depends on the tens of millions of lines of code underneath being written by people who decided to take the other path.

It sounds like you're better off out of FOSS, but I can guarantee your job is propped up by its existence, almost no matter what you do.

My dear, that was exactly what used to be when I started programming.

Plenty of successful companies used to live from selling all the stack.

In fact GCC only picked up steam the day Sun decided to start charging for the Solaris C compiler.

Thankfully the GPL hate crowd, by pushing MIT/BSD licenses has just brought us the future that will be the reinvention of the public domain and shareware of the 80's.

Computer systems have gotten much more complicated. The closest you can get to the "full stack" ideal is probably Microsoft, and even they've given up on maintaining a web browser. Full-stack worked for a while, but nowadays you'd need to be a goliath. You can't even pay for all the components you use, since many parts of today's critical infrastructure are community projects with no corporate backing.

Those of us on Apple, Microsoft, Sony, Nintendo, IBM, Unisys, SAP, Oracle,... platforms mostly do pay for the whole stack, even if it means paying to various vendors.

I'd rather they pay with employee time than donating money. Developer time is most of the time the more scarce resource.

But so many of proprietary tools are horrible! Some years ago, I worked in embedded space and after experience with Nordic's small devices and Analog Devices IDE for Blackfin, I dread using any sort of proprietary tech.

Those were pretty expensive products (we are talking $5k-$10k price range) and they were working way worse than just a single emacs window with command-line uploader.

The amount of time I wasted fighting with those tools was huge. And the worst thing, this was really time wasted. If I spend a week setting up OpenOCD I can at likely apply this knowledge to my next project. This was not the case with proprietary tools.

Paid is not always better, and we should not feel obliged to pay people just because they are in the same industry.

I should use that perrogative the next time I take the car to the repair shop, maybe they will provide it for free for my well being and happiness.

Then I will go into the bakery that give a cherfull morning to the baker so that he can give me a couple of breads for the evening.

you are using the wrong analogy. You are implying that people are using proprietary products, but not paying for them - pirating or stealing them instead.

This is very much not the case. True, people are not paying for tools, but they are not using them either.

It is like a person went to fast food place and got a food poisoning. From now on, they are avoiding all fast food places and cook their own food instead.

You could argue they are missing out or wasting their time, but there is nothing immoral or un-ethical there. Even if I am a commercial cook, I don't have a moral obligation to go to restaurant. And if I have working open source tools, there is nothing wrong with saying "let ADI keep their overpriced IDEs, I will stick with Linux, gcc and gdb"

If you are a cook I expect to be able to eat gratis at your place.

And I gladly will place a RFP for you using Linux, gcc and gdb, which I expect to be delivered gratis, regardless of the works put into it.

Yes, if I am a cook and I am voluntary giving out food for free you can expect to eat gratis. (Perhaps the place has recently opened and they are attracting new customers?)

If I am a cook and I didn't invite you, then this a theft and you are breaking the law.

You are welcome to place any RFPs you want, but you might not get too many proposals for them if you won't pay ehough. You are still welcome to do so, there is nothing illegal or immoral in doing this.

---- I think we have too many similes in this thread, so I am going to say it directly:

When choosing a software tool, there are many factors: monetary cost, time spent getting the license, time taken to get started, time doing the primary task (like writing application code), time reading documentation, time spent fixing bugs, experience learned, how easy to transfer knowledge for other people, and so on.

A lot of times we can ignore "monetary cost" because work will pay; but even then proprietary software does not always win. It often has much better "time to get started", but it is often worse in other aspects. We should choose the best tool for the job, and let the market decide.

For example, in embedded world, proprietary software is common, expensive, and for some reason, very bad. If I had to start a project on Blackfin, and my company would be ready to pay for whatever ADI SDK licenses I need, I'd still choose Linux/gcc/gdb if I could. This is not because "I don't want to pay for tooling" -- my org would pay anyway. No, this is because ADI SDK is horrible and ignores all modern software development practices. And ADI IDE is slow, crashes and does not support threaded debugging.

On a more minor front, I have an expense budget, and I am sure my work would be happy to Beyond Compare license for me, but I keep using open-source kdiff3. I am sure BC is nice and I wish them all the best; but I like to be able to teach other developers on my team, and they are not likely to have a BC license.

> You are welcome to place any RFPs you want, but you might not get too many proposals for them if you won't pay ehough. You are still welcome to do so, there is nothing illegal or immoral in doing this.

Ah, so you don't want to play by the same rules, thought so.

It’s so weird watching tech people drool over 3D printing hardware, raspberry Pi stuff or woodworking tools.

I suspect there’s overlap between “but your own software tools” and this group but I’m fairly sure there are at least some experiencing a degree of cognitive dissonance.

happier working for the enterprise overlords, where such tools are common

Which tools brought the most of happiness (or convenience), and how’d you rank them among other, free or “cheap saas” tools?

Visual Studio Professional/Enterprise, Delphi/C++ Builder, Qt, Oracle, SQL Server, Informix, Enterprise Architect, Windows Professional, macOS, Tableau, Aix, HP-UX, Solaris, Turbo Pascal, Turbo C++, Sublime Text, jAlbum.

Regular donations, Notepad++, Eclipse, Thunderbird, Firefox, VLC, Ubuntu.

Thanks! But honestly I used most of them and expected some life changers instead. Borland’s VCL was the one indeed, but now it’s gone.

The issue with paying for all of that is that as a developer, I simply don’t need it for that price. If the world of FOSS suddenly became expensive, we’d just rewrite few tools from scratch, cause it’s not so hard. It only takes few man-years to implement a decent scripting language with ui toolkit and then you have a world of developers who, like you, do not understand what’s in these 10gb monsters that cost $$$$/year that cannot be done with that FreeLang+FreeUI+FreePackageManager+FreeEtcEtc. FOSS and Enterprise are not competitors, these are natural ways of developers life and of enterprise life.

The way I see it people producing tools are developers as well, and they need to put food on the table.

I agree, and then they set up a price. Piracy is especially bad when you’re pirating from a particular person.

But not all developers have that “I made it and I will charge them the maximum equilibrium out of it” mindset. That’s where “free” part of FOSS began. Do you think that it’s unfair to use things which someone published for everyone to use?

Depends, only when accepting to be paid exactly the same way.

What I don't agree is the expectation to be paid, while refusing to pay other developers for their work.

Even the gratis stuff I use, back in the early FOSS days I bought CDs and magazines that distributed the software, the few times I went to FOSDEM the full volunteer package, nowadays books written by community members and occasional donations on stuff I use regularly.

So it is just not empty words about what is right.

Developers write developer tools. Developers wants to be paid to create the tools not pay someone. If they can't find someone to pay them then they will use a foss product and at times contribute back.

Why would you expect a toolmaker to buy someone else's tools?

The same reason cooks have to buy ingredients. The same reason a factory making tools first needs to buy other tools.

A backend developer will not write an IDE, heck, he probably won't even write most of the code in his own codebase even if he's a single dev.

The best ones grow their own ingredients. It changes the product.

They may source locally but they avoid national chains.

But yes most backend developers will never write an IDE. Most backend developers would love to be on a team creating one.

"To make an apple pie from scratch, you first need to make the universe" :)

Developers are not a monolithic group, there are tons of developers who want to work on things that have nothing to do with making developer tools.

There are plenty of toolmakers who gladly buy others tools so as not to have to make them for themselves. CNC mills sell quite well, for instance.

> Because in 2021 developer tools are fundamentally not profitable.

Apparently it is possible make $100k with an IDE color scheme:


> Programmers do not like to pay for their tooling.

I can't count how many times I see someone using Sublime Text professionally who hasn't paid for it. If anyone should have empathy for a developer, it's a developer, likewise with someone who can afford it. Once I put this together, I realized developer tools are for the most part a business dead end.

One of the minority of people who paid for their Sublime Text (and soon Sublime Merge) licences, checking in.

> Programmers do not like to pay for their tooling.

Maybe not for their personal/hobby projects, but they wouldn't be the ones paying for tools at work.

So it's the companies not willing to pay for dev tools or understand the value they can provide

Companies are made up of people. The only people who might understand the value that they can provide are the programmers, but the programmers are not familiar with the tools because they don't want to pay for them in their personal/hobby projects.

One would hope they would provide some kind of "community" version which I believe is pretty much a must these days to gain any traction

Selling software to software developers is a bit like trying to sell shoes to shoemakers. Your shoe needs to be pretty damn amazing to pull that off.

There's a reason 98% of popular developer tools are FOSS projects.

Such an important point that. I would just add that the lack of enthusiasm for paid tools I think is because of the lack of significant developments in the space itself. The fact that we can still use clis and 40 year old tools like Emacs without losing much on the benefits of the modern day tooling system says everything one would need to know. And I don't mean it in a degrading way, but there needs to be a paradigm shift from the HCI side. You can't just throw in a debugger, syntax highlighter, linter, and expect people to pay for it; when I can do all of that and more on Emacs with probably a weekends worth of tinkering.

I remember going to a sales pitch for proprietary mobile app automated testing software . I was the developer looking at this product. It had crap documentation, it was hard to use, and our mobile app was not designed to be testable. But internal efforts to improve the speed at which QA happened were slow. Even though this software was crap, management bought it because it was a problem they could through money at to try and buy their way out of not listening to developers. We wanted to make the app testable and use free, open source tools that would actually work.

I went to work at a place that made a code obfuscator, thinking I’d get to work on it. By the time I arrived they were essentially EOLing it (providing support, spending nothing on sales and no new development), so they assigned me to something completely different. JetBrains and Atlassian really are the exceptions.

> Programmers do not like to pay for their tooling.

Eventually they’ll have to. Everything is trending to SaaS offerings and eventually we’ll be paying way, way more. The amount of money people spend on SaaS CI blows my mind and if that’s any indication the move to massively over priced SaaS tooling is inevitable.

I'm not sure I buy this argument. The one group of people who certainly can create good alternatives that don't rely on that lock-in effect are programmers, after all. It's their livelihoods and happiness we're talking about, not to mention often their own pockets feeding the SAAS beast in the case of small businesses and freelancers, so they have a lot of incentives to do exactly that. And there are millions of them, many of whom already contribute freely to projects they find interesting anyway.

The pricing of SaaS CI or any kind of advanced server infrastructure is engineering salaries saved, not raw AWS bills. It's completely B2B software and you could do very, very well with just 1000 corps as your customers.

SaaS CI is valuable because it's not seen as something a programmer could easily make by themselves, unlike the vast majority of SaaS offerings, a lot of which are more marketing than code (not that that's a bad thing, but don't ask the average programmer how highly they value marketing).

May be I'm missing something, but CI looks like the thing that's trivially implemented by a few bash scripts. It won't be as pretty and as reliable compared to battle-tested service, but generally it'll work. I did that in the past and it worked pretty well for our uses.

The most valuable part of CI where I work right now is it being run on a reference setup, with persisted builds and logs attached to each merge requests.

We are all supposed to run tests, coverage and benchmarking localy. The point in CI is to guarantee nobody cut corners and keep verifiable proof of good builds.

We could fulfil the same requirements with a hand made setup on a box somewhere uploading subsequent artefacts, but I am not sure we would be happier on any specific aspect. Even cost wise, setup and maintenance could non trivial compared to the amounts we're paying now.

A few bash scripts work up to some size. For many projects at some time demands increase and you got longer test runs, which eventually require more machines and and different independent build steps (maybe you don't want to build the core libraries which are rarely touched for each commit of other parts etc.?) and at some point it breaks apart and you need something "proper" especially if you then also want to integrate test results with code review and track them from the single planning tool.

yeah nearly every developer I encounter does not want to pay for anything. Yet they love to get paid to program. An odd disconnect there for me.

Yeah nearly every person I encounter does not want to be eaten. Yet they love to eat. An odd disconnect there for me.

Your analogy only works for people who are cannibals.

Works for non vegetarians

I'm not entirely sure plants want to be eaten either

I don't see it as a disconnect, my baker friends seldom buy bread and I suspect jewelers seldom buy jewelry for example.

Why buy when you can make?

That is not my impression at all.

All the chefs I know go out to eat way more than anyone else I know (don't know any bakers, though). Graphic designers I know, buy art and graphic designs (don't know any jewelers, either). Musician friends buy tons of records and tickets to live shows, friends who brew, buy more beer than friends who don't brew.

Software is a fun field where the people who make it want to consume as little of it as possible.

You hit the point on the head. The chefs might go out of their way to buy their direct product (consumer software, like games or hardware, like ipads) but would not buy a shit ton of kitchen pots beyond the basics.

I have a family member who's a young musician, and he says musicians don't really care about audiophile grade speakers or headphones really.

I can't deny that this is plausible (in general I mean, not just your specific experience). So what makes our professions so different?

I imagine people who like to make things but don't like to spend money are attracted to software in particular because it is one of the few things that one can make with very little investment. Many of us may have found different loves if other hobbies weren't so expensive. This, perhaps, biases the type of person you find in the profession.

You can make unlimited copies of software would be my first guess

The disconnect I don't think is about protecting their turf.

I think it's mostly about 1) not having an instinct for how powerful the tools are and 2) not being able to internalize the value of leverage vs. cost.

$1000/year 'feels' expensive to a developer. That's 'a lot of money'.

But if it makes you >1% more productive, it's worth it.

Some of these tools are not just productivity enhancements but multipliers.

But that takes a different kind of intuition that very few people have naturally, you kind of have to be in a position to make those decisions.

Those that have the instinct often are not programming.

I’ve paid for various tools over the years: ultimately, I’ve never really found that the commercial tools are significantly better for the problems I have. I’ve generally found that Emacs and/or Unix shell utilities make it really easy to make a tool that solves exactly the problem you have while commercial tools end up having frustrating limitations or are really hard to learn because they solve the general case instead of the 70% case that you actually have.

> But if it makes you >1% more productive, it's worth it.

For an individual, it depends on whether your compensation is tied closely to productivity or multiplication.Being 1% more productive is not going to get your average person anything in a corporate environment.

"What's in it for me? Right now? In the short term?" is not very civic posture.

The 'bigger the corp' the 'bigger the productivity gains' available to the team and customers. A 1% gain would probably be worthwhile though it's probably the purview of a director or CTO, that said, developers are part of the process.

Making little productivity gains here and there is literally how the world moves forward.

It's why we are wiping our rears with toilet paper and not seashells.

One of the commenters made the point that 'such tools are not always very useful' which is entirely reasonable, but to the extent they are, the math works.

In an adjacent area - we use Jira, which we all loathe, but it's considerably better than nothing for example, it does the job and it's worth 20x the meagre cost to us. Such is an example of productivity leverage. (And of course, it's not always the case that it works out so well)

> But if it makes you >1% more productive, it's worth it.

Does it, though? I get paid for my time, not my productivity

You get paid right now for your time.

You get paid next year a rate based on how productive you are today.

Even when companies don't give proper raises, this still ends up applying when you quit and go to another company because you've spent x% more time actually coding instead of waiting or busy work, and you can command a higher salary.

> You get paid next year a rate based on how productive you are today.

Not particularly. While highly paid developers like to pretend the industry is some platonic ideal meritocracy, no one has any real ability to measure individual productivity, or to predict it with any precision in hiring, so, no, that's not a particularly good approximation of reality, certainly not where a 1% improvement would would even be noticeable in the noise of assessment.

Realistically, you might be justified in saying that my pay 5 years from now will be affected by the aggregate productivity in the past of developers generally and the broad, easily observed factors that conventional industry wisdom assesses as individual predictors of productivity within those broad aggregates. But, with that in mind, investing time in promoting online the idea that things I already have on my resume are predictors of productivity, while unlikely to have noticeable real impact, is probably a better cost/benefit trade-off than paying for dev tools, even if my employer was going to let me use personally purchased tools, which they aren't.

Outside of corporate work, in the personal development time I spend which does have impacts on bit actual productivity and my ability to have indicia of productivity that the market values and where I do have the choice of tools, assessing and paying for dev tools is more friction than benefit. I did it more when the gap between paid tools and free tools in quality was much higher and (because the internet as an easy discovery/distribution medium was not what it is today) the friction between the two was closer. Even though at the time the financial cost compared to my means was much greater.

I can't imagine that even a 20% shift in productivity would be noticed.

An interesting paradox of the programmer job market is that spending time mastering developer tools and reaping the corresponding productivity improvements at one job has zero value when confronted by a whiteboard coding interview for another job.

But they may have value once you get past the interview.

Don't forget another interesting paradox - spending time mastering tools and technologies tangentially (if at all) related to your current job has low value now, but is also what makes it possible for you to take that another job a year later and double your salary.

Meta-work is pretty profitable for individual.

This is a negative approach - and the opposite of what you would want on your team.

The narrow view that some 'productivity gain' will result in 'less work' is almost entirely not true, unless you're doing commodity work, like answering calls etc..

An Engineer who can do the work 10% faster because of better tooling, isn't putting himself or peers in jeopardy, rather, moving up the stack a nudge to work on slightly more important problems.

Any company that counts technology as a pillar of competitive advantage needs to adapt responsibly and make process improvements especially as they become normative.

People that work against this are literally a drag on the company, like the kind of unions that forbid other groups from 'moving the hammer because it's not in their job spec'.

Consider that helping the company be more productive is part of your job, and that you're not going to lose work as a result of it, probably the opposite :).

Because you can’t make every tool you’ll need to program effectively. Unlike bread, which only takes hours to make, good tooling will take months to years if done yourself.

Yeah, but a baker also can’t make one loaf of bread that everyone can then eat forever.

In software, you actually can have your cake and eat it, too.

to me it's more like "the value of this thing i do is for others to be happy"

The disconnect is not odd for me. Developers know you will essentially pay for a sub-optimal experience. Proprietary software vendors almost always treat their users as dirt. The piece of software would almost always be better if it were open source. And developers know this.

I think this is a temporary phenomenon. We're still in some ways reeling from 2000 and 2008, where free tools came to dominate (because no one could afford the paid ones).

If you get paid to program, then your employer can pay for tooling (assuming salaried work, if you're a contractor then you need to buy your own stuff).

I think there is some bias in that younger developers are the ones with the time to share their opinions over social media, but also have the least amount of money / influence with which to buy tooling. Certainly, when I started programming, I didn't have any budget for tools. I was lucky to even have a computer. Thus, I had no choice but to use free tools. People hold on to that experience long past the point where the monetary cost of tooling is meaningful.

Influence is the biggest problem, which is why I mention the junior vs. senior divide. When you want to buy software at work, you aren't typically given a budget and a credit card with which to buy the tooling. You have to justify every case. No junior developer wants to be the squeaky wheel that's always begging for cash for tooling, so they do without. Or, if they do decide to buy tools, they're met with the "alternatives analysis" phase of approval -- you invested time learning this tool that you now want to buy, go do that three or four more times while still completing your normal work, to make sure we don't waste any money. (You can see why writing your own stuff from scratch is so popular -- no approval process. You just do it.)

Tools are also special in that they come with a time cost and a dollar cost. I have never seen a product that will save me time without any effort on my part, but would love to buy such a thing if it existed. Instead, you have to pay the fee, and then learn the software. (So the actual cost is your hourly rate * the time to learn, plus the actual dollar cost. At least free projects or writing it yourself don't have the actual dollar cost. The training cost leaves the most sour taste in my mouth. I've wasted countless hours reading, excuse the term, dogshit, documentation for something I paid a lot of money for. Every time this happens I think to myself that writing a version of this software that actually works would have taken longer, but at least I'd be enjoying myself. Never forget that your mental health has value.)

Finally, software vendors are doing a terrible job, in general, of pricing their product for the developer market. The biggest problem that I run into is per-user pricing. It gets costly very quickly, either in money or in toil. The monetary cost scales with the number of people that use it, and if you want to avoid the anguish of deciding who is a first class citizen that gets access and who is a second class citizen who has to beg someone with access to do something for them, you have to buy an account for every user. Even for things that one person may use once a year, you take a lot of autonomy and the potential for ownership away if they can't use the tool. But, they charge you like every user is using it for 8 hours a day, 40 hours a week.

Personally, that has been a recurring problem for me. The tools that take me longest to get approved are minor productivity enhancers with per-user fees. Tools that have a per-organization or usage based cost are easy. (Examples: CircleCI, Sentry.) Tools that have a per-user fee are hardest. (Examples: Github, Codecov, Cypress Dashboard, Retool.) I work on a cloud service that had a per-user charge, and it went exactly as I expected -- few people would sign up, and when they did, they shared accounts to keep the cost down. We changed it to a usage-based fee, and a month in the people that actually sign up and start using the service increased dramatically. No longer do customers hit a paywall where their 0 -> some usage costs an amount of money that requires an in-depth approval process with their higher ups. No longer do customers hit a wall where some team members have to be made second-class citizens that can't use the software. People can gradually go from a $0 bill to a $0.01 bill, and invite everyone on their team to contribute, without having to come up with some way to share accounts. It's really great, and everyone that sells per-user licenses should think long and hard about how many people they are flat-out turning away.

Anyway, my point is that developers aren't selfishly collecting money without spending it on software. I'm sure they'd love to, but there are a vast number of complications standing in their way. Remove the complications to collect their money.

Hey there, I'm from Codecov and I just wanted to say, this point is really smart. I had never thought about the challenge of per-user pricing precisely this way.

Codecov was the first per-user service that I bought successfully. I like the feature that lets you pick who to apply your license to. In our case, our office manager manages the billing, but she doesn't need to view coverage reports. So that saves us like $12, which is appreciated :)

But isn't there also the opposite effect if they must pay for usage then they start minimizing their usage, and start actively looking for free tools to do the same?

Also as mentioned by other it takes time to learn to use the tool by using it. But now you would think twice whether use it and pay for using it just to learn it.

Actual proof that not capitalism can work. Free software writers don't need a profit motive. They mainly do it for the love of creation itself. They are an implementation of the ideal un-alienated individual that marx dreamed all humans could hopefully become like.

Celebrate developers refusal to commodities their means of production. I hope it stays firmly in the GNU ecosystem.

While I support the principle, what actually happens is that the companies which make money use your work to generate that money for free. And your desire to build something useful 'for the love of creation' means people who could have got paid to support their families can't because you've undercut them in the market with your zero pricing, using the privilege which allowed you to spend significant time on building something valuable for the hell of it. Then when you try and charge for something this is viewed as somehow immoral, thus pressuring you to provide your work for free and making the multinationals even happier.

> Free software writers don't need a profit motive.

Yes until someone takes their free software and packages it as a cloud service. Then all you hear is "I want to get paid for the software I shared for free."

There's a big difference between paying for the required tools for a technology and the bonus tools. Java's basically impossible without an intelligent IDE, and C++ isn't far behind. But Ruby/JS/Python? You're just fine with VIM+Tree (if that).

Then you can upgrade with Sublime (or the like), and things like Visual Assist (by Whole Tomato) which made a huuuge difference in my first job.

I disagree that developers don't like to pay for their tooling, I think the issue is that fewer people will be using the tools if they are not free and that means that languages that are bound up to expensive tools (e.g Delphi) are going to lose the network effects other languages gets. Thus even if the language itself is inferior, that will be made up for by the much larger number of people who can create libraries and tools and answer stackoverflow questions.

Note that there is a free IDE for all the languages Jetbrains makes IDEs for.

Developers are a tough market (I am one). They're also a pain to manage, expensive, and still human(ish - if you're lucky) :p, with all the ego and mistakes that come with the territory. No-code for simple wiring/boilerplating once good enough/widely adopted enough, will kick our asses. But then again on the opposite side, in many cases business types bring mainly money to the table, leaving the expensive nerds to do the rest, and have fun with their RG machines in the process.

> No-code for simple wiring/boilerplating once good enough/widely adopted enough, will kick our asses.

By "our asses" I assume you mean programmers'? I don't buy it. People think coding is hard because they think thinking is hard. No-code doesn't remove the latter part, it'll only make things easier for programmers.

If anything it makes getting into programming easier, but that means more programmers not fewer.

Do not forget the possibility that no-code systems will result in a worse outcome but still technically get the job done, with a lot less sum total thinking required.

Most software is plumbing, not competitive advantage, so it doesn't really matter how good it is if it technically works.

If you doubt that, I point you to the world of enterprise software, where terrible software flourishes and thrives.

I will not be at all surprised if no-code systems eat the bottom of the software market, replacing many software developer jobs.

The history of abstracting the hardware as something easier for people to understand is exactly the history of programming languages.

Wake me up when someone writes a compiler that reliably turns "Hello computer, please make me money" into an executable.

Part 1 yes. Part 2 ... no.

'No Code' generally have a different use case. For every 'software project' there are probably 5x as many 'simpler projects' that require a basic front/backend but not much material CS knowledge, and that's where no-code shines.

'No Code' should be a euphemism for 'Didn't Need Code In The First Place'.

In other words, there's a legit level of abstraction there with it's own world of tooling etc..

Edit: I will double-down and say that within 5-7 tears, the number of 'no code' projects will be greater in number than the number of 'code' projects [1]. 'WordPress' is the original foray into this: people want to make simple sites, they don't want to have to deal with tons of tech. Shopify, is a kind of ultra 'no code' solution - arguably it's a service not a 'no code' solution but it exemplifies the potentiality of entities wanting to solve problems while not getting lost in the hey.

[1] https://airdev.co/post/how-no-code-changed-in-2020-and-whats...

> Programmers do not like to pay for their tooling.

Programmers definitely don't want to pay for tooling they haven't used yet. Of course, once they have found a free way to use a tool, they aren't likely to go back and pay for what they already have.

One of the biggest things that turns programmers away from tooling is UI/UX. Every programmer is particular about the way they interface with their tooling. The less familiar a tool is, the steeper its learning curve. The more simplified a tool is, the less powerful its abstractions are.

UI/UX norms for tooling need to be rethought. Trying to make a tool appeal to a wider audience of programmers is extremely difficult because every tool has baked-in assumptions about how it will be used.

Ubiquitously popular tooling tends to be extremely configurable and extremely malleable. The more control the user has over a tool, the more useful it will be to them, and the more interested they will be in using it.

There's a reason the shell hasn't died yet. Even with a long list of gotchas and decades of cruft, shells allow users to personalize them to an attractive extreme. The same goes for Vim/Emacs.

> Ubiquitously popular tooling tends to be extremely configurable and extremely malleable. The more control the user has over a tool, the more useful it will be to them, and the more interested they will be in using it.

I disagree; if the workflow and UI offered by the platform is good, I don't need to change it. Case in point is xcode, it's very opinionated in how people work with it, but it works.

I don't feel like Xcode is a good example of developer tooling ubiquitously popular because of developer preference. If you want to develop for iOS it's a requirement.

Depends on what you call tooling. Aren't all the SaaS services needed for modern dev part of tooling? Most companies pay for that stuff. Could be Digital Ocean, GitHub, Auth0, Chargify... To me, those are all dev tools because they do stuff I don't have to do manually, just like an IDE is a dev tool that's more powerful than notepad. They're not standalone services because they don't do anything without me configuring them. And they're really only useful for devs, not anyone else.

Digital Ocean is, to me, a great dev toolbox and keeps me from wasting time setting up machines, IPs, etc. We gladly pay for it. Even tools like Notion are really dev tools just deployed as SaaS.

I think dev tooling has just moved into SaaS and probably gotten more profitable, if anything.

Yes, developers are in the way. A selling point of SQL was management could use it directly for analysis; and spreadsheets were a kind of no-code solution. Yet developers were still needed.

Wikipedia's description of RPA suggests something somewhere has gone terribly wrong:

  RPA systems develop the action list by watching the user perform that task in the application's graphical user interface (GUI), and then perform the automation by repeating those tasks directly in the GUI. 
Not analogous, but reminds me of The Feeling of Power (Isaac Asimov) https://archive.org/stream/TheFeelingOfPower/The+Feeling+of+...

There are plenty of profitable developer tools out there. I usually encounter 2 issues when evaluating a dev tool:

1) Complexity & bad UI/UX. It's often not clear what i'm buying or all the features are hidden "under the hood". Many devs don't understand that user experience matters, even if the users are also devs.

2) Trust. This also ties to the first point, i need to have a clear picture of what this thing you're selling me does. I don't trust someone else generating code for me, i don't trust magic solutions and i don't trust tools that look like they were built in the 90s.

I think there are plenty of opportunities for more developer tools but unfortunately it takes a unique kind of dev to build a product + engineer a marketable solution.

>Jetbrains is the exception, not the norm. Developer tools are loss leaders for large corporation to acquire developer goodwill and mindshare. Previously we sold developer tools/PaaS. Programmers do not like to pay for their tooling.

It's really funny to me that this is the top comment, because one of the reasons I use Eclipse instead of Jetbrains is due to the tool mentioned directly in the article, Mylyn. Any time I mention it, programmers always respond with, "Huh? What's that?" I choose Eclipse over Jetbrains, not because Jetbrains costs money, but because Jetbrains is not as feature rich. Eclipse is more capable than Intellij Idea at any price.

More capable perhaps, but I’ll take software I can use over Eclipse any day. I repeatedly get pushed towards eclipse for a number of different things all the time and every year I give it a shot because I know things can change over time... and every year I walk away deeply frustrated and spend another year throwing anything that requires working with eclipse based tools, strait into my mental trash bin.

I have a personal JetBrains subscription which I use for my personal projects as well as work projects. Their EULA doesn't restrict this.

I see it as a very well justified use of my money.

I dunno; there's a lot of SaaS that are in daily use by developers; build tooling, version control, code reviews, chat / collaboration tools, etc. Editors not so much anymore, but I've got an intellij license which I use intensely.

I mean I get where you're coming from; for solo developers and small clubs, free tools get you very far. But at larger enterprises you'll want to pay for the extra services and less management.

> Programmers do not like to pay for their tooling

Turbo Pascal and Think C enjoyed some success in the 1980s and 1990s.

Then again it looks like those environments were simpler, more responsive, and more enjoyable to use compared to the clunky modern IDEs of the 2020s.

(And of course there were fewer free alternatives, and modern apps have to deal with horribly complex APIs, networking, concurrency, distributed systems, etc..)

> This is why no-code and low code are so much more successful than developers tooling startups in terms of revenue and profitability

These are developer tools though, just marketed differently. "No-code" and "low code" are simply fancy terms for high level languages, and the developers in this case are people without little or no experience in traditional programming languages.

Yeah I was working on a diagram software [1] that looked similar to VS Code and can be extended easily. Applied to YCombinator but they didn't think it's worth it, so .

[1] This was the Angular+Electron version (ported to React afterwards) with the Visio logo: https://imgur.com/a/UDkitDm

Ah seems Hacker News removes emojis. After "so" was supposed to be a shrug emoji.

They accepted Dendron, conceptually similar. Try again!

What developers want most is a way to market their work, see app stores. Developers are willing to pay up to 30% of their revenue.

Even the hosting and download function of app stores is valuable. It replaces auto update frameworks embedded in the app and earlier download sites were all super suspicious and full of ads with fake download buttons.

Even Sourceforge started out good, then sold to someone who put adware in the downloads - although it's back to good now.

There is also no VC money in this. Even mature areas like static code analysis are a dead water.

There will be a renaissance in tooling, once AGI is realized ;)

Once AGI is realized, no human developer will ever be paid again.

I personally doubt AGI will ever come to exist, but if it does, that's an obvious result that will happen within a few years.

> Once AGI is realized, no human developer will ever be paid again.

Well, we'd be in the boat with teachers, reporters, authors, attorneys, bankers, management, some artists... and a lot more of professions which were done in by AI without a G earlier.

Here's to hope it all happens fast and goes straight to UBI worldwide.

What is repl.it’s monetization strategy?

Hosting, I guess.

I've paid thousands through the years to buy various versions of Visual Studio. While there are free alternatives I don't even bother paying the money because of the value that beautiful piece of software offers me.

The kinds of tools like those in the article suffer from being outside of the "main loop of coding".

What is the main loop? Well, as it's defined since the rise of interactive computing, it's typing in the editor, compiling, then testing and debugging.

Thus we optimize for:

1. Typing code fast(or typing less code)

2. Compiling code fast(by doing less compilation)

3. Minimizing testing and debugging time(by narrowing our definitions of testing to that which is easy to automate).

The main loop of coding is not software development. It does not study the domain problem, define new benchmarks for success, untangle communication issues, or refine principles of development. It is a path to coder flow state, feature factoryism and shipping the org chart. These things sort of resemble development - a happy coder delivering features within a definite architecture does serve someone at some point - but also manifest dysfunction. Development failing is just shrugged off as bad programming or bad management.

Tools like a Whyline or Reflexion models are not in the main loop. They are an invitation to look carefully at whatever horror has been wrought and address it at a deep level. But that really needs a researching mindset, not a shipping one.

In practice, the available tools very slowly move in the direction of the suggestions of research. There are improvements, but they need projects that put together the pieces and make it a goal from the language design(the main interface) upwards.

Whyline would not help you understand why a multiplication of two million by million matrices gave a 0.7374920 in row 6478 column 474995.

What would tell you that?

But also, what percentage of typical code is multiplying massive matricies and what is doing simple arithmetic or data transformation or rpcs?

You are not paying attention to the issue at hand here: the data here is the issue, because it drives the logic.

The moment your code is driven primarily by data you need to start building tools that infer decisions from that data.

Some automatic inference engine tightly integrated with your code is just going to give you the location of where a bunch of cells from the matrix are multiplied.

As many on this discussion have noted, JetBrains tools not only don't collect dust, they are widely used, and the company is profitable. The company is privately held. I hear that they are constantly turning down investments. This proves 1) there is money in tools; 2) The VCs who routinely say "there is no money in tools" are insufficiently imaginitive, which is not surprising if you've spent any time with VCs.

Why is JetBrains so successful where others have failed? A few thoughts:

- Intellij was released in 2001. Eclipse was a close competitor for a while, which made no sense to me. Intellij just worked, and it was intuitive. I found Eclipse to be uglier, slower, flakier, crashier, and far less intuitive. Haven't heard of it in years.

- It was always the case that at least some version of Jetbrains tools are zero cost. I got hooked on it early on. I have been using emacs far longer, and yes, while a sufficiently dedicated developer can make emacs behave like an IDE, it really isn't one. Intellij just worked out of the box. In the preceding two decades, there were high-end development tools available (Lisp machines and their all-encompassing environments, Lucid for C++, Purify for C/C++ memory problems, Atria, Rational. Trivia: Did you know that Purify was founded by Reed Hastings, the guy who went on to found Netflix?) The tools were expensive, and I don't think there were free versions. These companies all went out of business, or were acquired.

- Jetbrains is incredibly focused. Having been through several VC-funded technology companies, I can easily see how VC brain farts can destroy a company's focus. (This dynamic isn't entirely the VCs fault. Founders stretch the truth to get funded, and then VCs insist on the fairy tales they've been told.)

- Jetbrains has expanded to other languages, and other kinds of tools (besides just refactoring Java code). The number of languages, technologies, and frameworks that they support is just mind-boggling.

- Consistent focus on improving developer's lives, through steady improvements in functionality, performance, and quality, over 20 years at this point. They started far ahead and have widened the gap.

OPs tools look useful. I suspect they would attract a much wider audience if made available through Jetbrains products.

I always have this weird sensation when people talk about Jetbrains.... I feel like some in some circles, usage of Jetbrains tools is ubiquitous, while in others it is unheard of. I have been a professional software developer for 15 years, and have never seen the tools in use anywhere I work. But I read things on the internet where people will say things like “well, every ruby developer uses Jetbrain” and seem to not even question this.... weird how circles like this form.

It's similarly shocking to encounter entire companies where nobody uses a debugger. Millions in revenue, dozens of programmers, and the level of debugging is still sprinkling printf-statements and desperately perusing source code

My hot take: Schools don't touch the practicalities of professional programming enough. Homework is mostly small-time enough that you can keep the entire codebase in your head, and solve issues with printing variables. At least my CS master's degree was very much limited to 1950s level tool use.

I found that my use of debugging peaked a few years into my software career, and then fell off rapidly. Debuggers are great for single-threaded code, less useful for multithreaded. And close to useless if your problem spans processes.

As the problems I was debugging got more complex, I found that log files became far more useful. The logging is always there (assuming you do a run with the right logging levels selected). You can get a high-level view of what's going on far more easily than in a debugger, which has you rooting around at a very low level. You don't have the phenomenon where you just miss the critical thing while in a debugger, and then you have to laboriously start over. If you miss the critical thing with logging, you turn on more of it and run it again.

If you have one of those bugs that occurs extremely rarely, just keep running the code, and turn on logging. When the problem occurs, you have the evidence leading up to it.

This assumes you have the right logging there to start with. I put a lot of development time into my logging code -- making it informative, compact, readable, carefully selecting what to log and where and at what logging level. I make sure that I get log rotation right, and then I use some simple scripts to download, consolidate, split and search the log files.

"Desperately perusing source code": Yes, you need to read and understand code in order to debug it. You obviously know that, so I'm not sure what "desperately" is meant to convey.

>You don't have the phenomenon where you just miss the critical thing while in a debugger, and then you have to laboriously start over. If you miss the critical thing with logging, you turn on more of it and run it again.

This is rather confusing to be honest. Are you saying restarting the software is hard, or that restarting it is easy? If you just missed the critical thing, just add a conditional breakpoint ("Stop here if ptr is null") and restart the software.

Restarting is easy. But you know how it is. You get to your breakpoint, go forward carefully, and then step over something you should have stepped into. Oops, start again.

Colleges generally teach computer science, not programming. They're different arts with different goals.

Bootcamps teach ... I don't know, really. I keep seeing an ad to "become a developer in 14 days," and I waver back and forth between amused and angry.

I think there's room for a happy medium, some kind of trade school for software development. A curriculum that teaches you practical skills like debugging and clean architecture, and prepares you for an actual job.

I suppose it depends on your comfort level in the stack you’re dealing with. I’ve been writing software for 40 years. I’ve been doing Rails since almost the start, and find RubyMine slow and overwrought. However, I had to do some Java work (which I had never done in anger before) and found that IntelliJ really is worlds better than Eclipse. So much so that I paid for it out of my own pocket, even though I knew the project was doomed to failure. I hear good things about Rider, but I have yet to try it, as, after all these years, I’m pretty comfortable with VS. Rails work is EASILY done with a terminal and a text editor; the others not so much.

Yes, odd. Data point: me and most of my SE friends/coworkers pay for JetBrains IDEs (I was pretty deep into emacs and vim for many years prior to switching).

I definitely haven't "switched". In fact, I have a key binding for escaping to emacs to work on the current source. I find that useful because emacs kbd macros are so much less clunky than the Jetbrains equivalent. But yes, Jetbrains products have taken over much of what I used to do in emacs.

> I have a key binding for escaping to emacs to work on the current source.

Are you aware that you can set the Jetbrains editor to use emacs key bindings?

Not OP but they're not saying they want to use emacs keybindings, they're saying they want to use emacs keyboard macros [1], which I agree really are a very handy feature having no equivalent in JetBrains.

[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Ke...

Emacs keyboard macros have an inferior equivalent in Intellij (and, I'm assuming, their other products). But also, emacs just somehow feels faster. Maybe keystrokes are marginally faster, maybe it's my expectations, but there it is.

I know that Intellij has emacs key bindings, that's not the issue, I'm happy with the Intellij default bindings.

Oh, wait, I just figured out part of it.

In Jetbrains products, I am CONSTANTLY hitting Esc to Tab to deal with the helpful predictive suggestion. I find that feature sometimes useful, so I have not turned it off. But it definitely produces a different and maybe slower experience than typing in emacs. Maybe there is a mental mode switch between typing and handling the hint?

It's really stack dependent. In Java & Android, it's jetbrains IDEs, iOS is Xcode, etc. I think it comes from what that subindustry has converged on the best served dev stack for them. If jetbrains isn't the most used, then it's not the best.

" If jetbrains isn't the most used, then it's not the best."

Oversimplification, when comparing free software and paid software.

I was talking about an industry stack. Plenty of open source java software devs use IntelliJ to develop their open source modules and libraries, not to mention there are free editions of their IDEs on top of that.

I think a very important point you are missing is that JetBrains was founded in Eastern Europe. Their developer costs when they were founded were probably ~20-25% (if that) of what developers cost in Silicon Valley, yet still at an amazing skill level.

I honestly don't think JetBrains would have been able to succeed if they were founded in the US.

A thing which made Jetbrains successful probably was their deal.with Google. By making AndroidStudio free they got a large userbase. This also was my first direct encounter with them.

I see that AndroidStudio was released in 2013. Intellij was pretty well established by that point. No doubt this deal helped them grow far faster than they would have otherwise.

No. They were popular and making money before AS.

Yes, they were known and used especially in Java-Sprache before and had a good quality product.

Having a company like Google pushing it into the AppDev community and offering it for free certainly have attention and certainly a nice financial contribution from Google.

> Intellij was released in 2001. Eclipse was a close competitor for a while, which made no sense to me. Intellij just worked, and it was intuitive. I found Eclipse to be uglier, slower, flakier, crashier, and far less intuitive. Haven't heard of it in years.

Eclipse is still in use.

And don't let the above scare you: it is not as beginner friendly as VS Code or Netbeans but it is a walk in the park compared to learning emacs or vim from scratch.

It is just different, and if you come frome a file-centric and line centric workflow you should probably just as well get used to thinking about classes, functions interfaces etc: i.e. don't think "I'll open this file, look for that line", instead you jump to a class or a function or even better just go to the implementation of the function you are looking at. It just works.

And you mostly don't cut, paste and update manually, you just ask eclipse to move it and then verify it in the scm commit view before you commit: "Moved x to y to make z possible"

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact