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.
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.
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.
Since piracy was/is the norm, you might as well provide a few version.
I was very much a Linux person at the time, but I could still appreciate all the free stuff MS lobbed at students.
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.
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.
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.
> Over-monetizing their dev tooling was a significant contributor to Microsoft's loss of dev mind-share over the last decade.
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.
- 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.
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.
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.
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).
What hasn't happened is a culture of offering financial feedback to favored projects.
Patreon and Kickstarters seem a start.
Suggestions are welcome.
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.
“Assume good faith”; Hanlon's razor applies.
* 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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
It is quite telling how Swing got its fame.
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.
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.
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.
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?
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)
I wonder if that is because VsCode runs on top of Electron
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.
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.
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.
The Jetbrains stuff really isn't _that_ heavyweight.
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).
A Scintilla-based editor is still going to crush it on the resource usage front.
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.
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.
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.
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.
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).
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.
I can only speak for myself, but to me, "no brainer" is an understatement.
If they want more adoption, they need to be under the $100 mark.
I guess you proved the original point of this thread.
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.
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.
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!
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)
Especially when the options are free.
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.
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.
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.
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.
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.
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.
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).
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.
Speak for yourself. I've been paying for my own developer tooling for 25+ years.
- 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.
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 need to know how the program ended up in that state. 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.
I think the main promise of an IDE is being integrated. But maybe it could just be done with libraries.
Yeah, but the core dump doesn't give you an answer on how the program ended up in failure state, does it?
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.
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.
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.
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.
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.
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"
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.
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.
Ah, so you don't want to play by the same rules, thought so.
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.
Which tools brought the most of happiness (or convenience), and how’d you rank them among other, free or “cheap saas” tools?
Regular donations, Notepad++, Eclipse, Thunderbird, Firefox, VLC, Ubuntu.
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.
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?
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.
Why would you expect a toolmaker to buy someone else's 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.
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.
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.
Apparently it is possible make $100k with an IDE color scheme:
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.
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
There's a reason 98% of popular developer tools are FOSS projects.
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.
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.
Why buy when you can make?
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.
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 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.
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.
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)
Does it, though? I get paid for my time, not my productivity
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.
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.
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.
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 :).
In software, you actually can have your cake and eat it, too.
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.
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.
Celebrate developers refusal to commodities their means of production. I hope it stays firmly in the GNU ecosystem.
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."
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.
Note that there is a free IDE for all the languages Jetbrains makes IDEs for.
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.
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.
Wake me up when someone writes a compiler that reliably turns "Hello computer, please make me money" into an executable.
'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 . '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.
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.
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.
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.
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.
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.
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.
I see it as a very well justified use of my money.
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.
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..)
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.
 This was the Angular+Electron version (ported to React afterwards) with the Visio logo: https://imgur.com/a/UDkitDm
Even Sourceforge started out good, then sold to someone who put adware in the downloads - although it's back to good now.
There will be a renaissance in tooling, once AGI is realized ;)
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.
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 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.
But also, what percentage of typical code is multiplying massive matricies and what is doing simple arithmetic or data transformation or rpcs?
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.
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.
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.
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.
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.
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.
Are you aware that you can set the Jetbrains editor to use emacs key bindings?
I know that Intellij has emacs key bindings, that's not the issue, I'm happy with the Intellij default bindings.
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?
Oversimplification, when comparing free software and paid software.
I honestly don't think JetBrains would have been able to succeed if they were founded in the US.
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.
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"