91–100 of 389 posts
As the author points out, it does depend on the language. I switched to vim "full-time" when moving to a Go team. (Prev Java). Java is a language that does not lend itself to vim. Even just compiling and running a sufficiently large java program can be a pain without an IDE setup.
A good ide is all about auto completion and refactoring tools. The autocompletion means you don’t have to spend as much time memorizing apis, so you can focus more on simplifying your design and minimizing coupling. In something like unreal engine, the intellisense really sets ides apart. The refactoring means you can quickly and easily make large changes to make the code easier to work in. You can just work signific…
For large codebases, the code exploration features are priceless. Call hierarchy is an absurd productivity booster.
Meanwhile there are real 10x developers out there that while they care about the tools stay out of the weeds of them.
This line of blog post reminds me of a Paul McCartney interview I read where someone asked him what kind of strings he uses on his guitar. Paul replied “shiny ones”. I think Paul is actually a lot more technical than he lets on in interviews and probably knew full well what kind they were. What he communicated to the person asking the question was that it doesn’t matter so much.
Listen, long story short: just say no to nonsense like this. Given the choice of a) tooling, or b) no tooling, you’re not being smart, cool or clever by choosing b. Obviously, what tools you pick are important and heavy IDEs like IntelliJ are a trade off between speed and functionality, and yeah, more nimble tools do exist, and it’s definitely worth trying different development tools to see what makes you most produc…
“Power drills have batteries or cords and motors that wear down and they’re more expensive and complex and can break more easily and it’s just smarter to bring hand crank tools to the worksite.” - Nobody
The physical equivalent of an IDE would be a laser-guided auto-centering/levelling drill with automatic drill bit changer/sharpener, depth guide, dust evacuation and material sensor with automatic lookup for which hole size and depth to use for the given task. It would weigh 15 kg, need an external power pack and be unusable in tight corners. For some tasks it would be a great time saver, for others it would just be in the way. Some workers would love it, others would fight it. Some would be more productive using it, others would be far more productive if only that damn megadrill did not insist on using that oversized drill bit while they knew the construction would be much stronger by using a slightly smaller bit, necessitating them to override the megadrill tool selector for each and every hole they drilled.
I rarely use IDEs for code generation, I don't even like autocomplete. For this stuff I use code snippets; I develop collections of those for any language I use. You don't need an IDE for it; any good text editor has such features.
For me really important features of a good IDE are:
- Navigation. Being able to right-click on a function or method name and jump to its definition is very handy. Yeah, I may remember where it's defined; I can also use grep (which does not work all that well for methods). But jumping is so much faster and does not take you out of the flow.
- Code refactoring. I am refactoring code continuously as I work with it. Even simple stuff like renaming a variable or a function (or a method!) is much easier with an IDE.
- Error highlighting.
Note: I can and sometimes do work without an IDE (esp with more obscure languages which don't have good IDE support). There is some fun it it too, like going camping and living for a while without creature comforts like running water and electricity. But normally, if a tool is available, why not use it?
About languages: I agree that a well-designed language allows you to factor away most boilerplate code. (This was one thing I really liked about Perl! It basically allows you to develop a language dialect for your particular needs. The downside with Perl was that everybody was "reducing boilerplate" in their own way, but this is another story)
Just my 2 cents :-)
Listen, long story short: just say no to nonsense like this. Given the choice of a) tooling, or b) no tooling, you’re not being smart, cool or clever by choosing b. Obviously, what tools you pick are important and heavy IDEs like IntelliJ are a trade off between speed and functionality, and yeah, more nimble tools do exist, and it’s definitely worth trying different development tools to see what makes you most produc…
I'm not rejecting IDEs because I didn't like one thing. I like nothing about IDEs except the refactoring feature; but even that doesn't make up for the painful UX. IDEs are like MS Word: they do everything I need but I hate every moment of it.
There is a common perception with electric bicycles that the rider will pedal less hard to go the same speed. But there is an alternative: they could pedal the same amount and go faster. I kind of view IDEs like that. You can use it as a crutch, or you can take the energy you would have used thinking about the things the IDE is now doing for you and focus it elsewhere.
IDEs are similar. If you want to be as efficient as possible and get as much done as possible, you want an IDE. But if learning and exercising your mind is the goal, you’d be better served with a text editor.
> By not using an IDE, you have to remember the syntax of the language you are using, the subroutines from your own project and their arguments. You also remember (standard-)library subroutines better for your chose programming language. Use an IDE, and discover + learn the syntax by being assisted. Start biking on a unicycle, and fail. > When you have to manually find a file to change a subroutine implementation, or…
Just thinking setters and getters set and get the property is naive and retrograde.
So I reject the argument made in the article. Just choose your IDE wisely and make the tradeoffs you want to be productive.