The IDE - The beginner's trap !

Coer illustration


Hello everyone, today we talk about IDE's !

But first..

What's an IDE ?

For me, an IDE is a software that allows us to write code with a comfortable environment for the language we're using. We can do thing faster and better. I would even say that it is not a software but a set of software offering a lot of tools like syntax highlighting, a debugger, code completion, code reformatting, ...

Why we love IDE's ?

Don't you think having an IDE can change a life? We are always defending in comments and forums that our IDE is the best. Why? Simply because it really changed our lives and the way we code. We do things faster and better.

Whether it is self-completion, reporting problems with our code, reformatting our code, etc... Our IDE saves us from many struggles sometimes.

It is not only a tool but also a way of working

But for a beginner, the IDE can be a double-edged tool ( and a very sharp one) because of some of the things we will discuss, if you don't mind, in this article.

Why I say that's a trap ?

What I will say throughout this article is the result of my personal experience and those of the people around me (classmates, colleagues, ...). Do not hesitate to give your opinion and share your point of view 😁.

The first trap a beginner can fall into, for me, is to use an IDE to learn a new language. Because, for me and for most people, it is easier to learn by using a maximum of senses, the fact of reading only one course is not enough to learn correctly and in a productive way. It would be better, for example, to read the course, reproduce the code, and even watch a video to make all your senses work. (sight, hearing, ...)

Using an IDE leads to this, because even if you copy the code you find on the tutorial or the course or anything else, the IDE helps us and self-completes some keywords and that's how my classmates learned java with Netbeans in class but as soon as they had to write a simple code that will display "hello, World!" they were incapable because they didn't know exactly how to write this code because some element was automatically generated by the IDE as public static void main (String[] args) {} and this is one of 100 other examples ! I have also fallen into this trap in the past, now, when I learn a language I tend to copy all the keywords on notepad in order to remember more precisely each element that characterizes this language.

The IDE can also be a calamity for people who are too perfectionist. I know people who spend more time looking for a beautiful theme for vs code than learning to code, it makes me laugh at times 😆.

I also had the opportunity to meet people who only knew how to use git with the help of the buttons available on the IDE they were using, you know, the buttons that commit & push at the same time automatically. And then, when they change their IDE, they're lost, because they can't figure out how we this or that. They were too dependent on their tools!

What we can do ?

That is why, I think that before you can make your life easier with an IDE, you have to go through a learning stage without it and this way understand exactly the tools that have been used and the technologies behind it.

An expression tells us that we must walk before we can run, and I think it can be applied here.

If you know what you're using you will be more productive and that's what we're all looking for. Productivity.

So, start learning without you're IDE, take some time to learn the tools inside, and try to use always the same to be comfortable with.

Like a said before, try to learn with a video and then reproduces the code, then fidgets with the code. This is the best way to understand an element.

I had a lot of other reasons in mind last night, but I made the mistake of not writing them down directly! I should get better at that. ALWAYS TAKE NOTE 😭 !!

That was my last advice for today. 😜


I hope you have enjoyed this article, as mentioned above, I invite you to give your opinion and share your experiences on this subject and

Happy coding and Happy new year!

a little bit late...😁

  • Peter Witham
    6 years ago

    Hi Yafkari,

    Thanks for this. I think a great point you raise in particular is learning a new skill like a language can often be overshadowed by the tool. A great example of this is Git, I encounter a lot of people who only know Git via a UI tool.

    This is fine at first, but as soon as they hit a problem the most common response they get is to switch to the terminal to figure out what is going on. This often leaves them in a place where they hit a wall and now have to learn Git from the terminal before they can start working on the actual problem they are trying to understand.

    IDEs are great for getting things done and improving productivity, but I feel that is only beneficial once you have a grasp of the power you are taming with the tool.

    2 Replies
    6 years ago

    I totally agree !

    Martin Huter
    5 years ago

    Well I think for most CLI tools it is often mire productive, if you use them once you're used to them.

    One of the main reasons: You only can handle a tool, if you use it often.

  • Max Ong Zong Bao
    6 years ago

    For me, The reason I use IDE is due to it's debugger as I learnt to depend on it due to visual studio's awesome debugger.

    Thus despite I use pycharm on a daily basis I always uses the debugger extensively when I encounter a problem in my code.

    1 Reply
    6 years ago

    We should consider using the debugger more, you're right.

  • Matthew Daly
    6 years ago

    Personally I have never, ever used an IDE without sooner or later wanting to kill it with fire.

    I've used Vim for most of my career, but recently switched to Neovim and took the opportunity to audit my plugins, remove a lot I no longer used, and adopt some new ones. In particular, thanks to Phpactor, I now have excellent autocompletion and the same sort of refactoring tools PHPStorm provides with a fraction of the footprint.

    1 Reply
    Jackson Elfers
    6 years ago

    You can do so much with Vim. It's definitely worth the learning curve I still have much to learn. I've never enjoyed the memory footprint of most IDEs and usually they're abstracting away important information that becomes fickle later.

  • Casey Cole
    6 years ago

    The only time I use ide is to compile or debug otherwise it's just slower than the editor.Also I can't stand error correction before I have gotten my thoughts into the code.

    1 Reply
    6 years ago

    Personally, when I have to write something quickly I use sublime text, the loading time is equivalent to the microsoft notepad.

  • Ricardo Rivas
    6 years ago

    I friend of mine works at google and he doesn't know how to use git via terminal. As a VIM user I can tell this is true, IDE such as rubymine might help you do things faster but you won't learn how things really work

  • Younes
    6 years ago

    I think they are totally right, I keep saying it in my school 😂

  • worc
    6 years ago

    a point in IDEs' favor is the actual tokenization and static analysis they do. no matter how fancy the plugins for your text editor get, an IDE is built around the idea that the machine should know how to link your code together. it's not just making a best guess that if two tokens look similar in the source code they must be related, an IDE knows that given the rules of the language that you're writing in, that those tokens are actually equivalent.

    you can move through source code (and library/vendor code) much more quickly and accurately when you're not just doing a glorified find-all.

  • Jason C. McDonald
    6 years ago

    I'm definitely an advocate for learning to program without an IDE. Learning to write, compile/run, commit, and debug without an IDE provides a solid foundation for continued mastery.

    That said, once you know what you're doing, the safeguards a decent IDE offers help considerably reduce coding errors and style inconsistencies, while increasing efficiency.

    Related, The Curse of the IDE

  • Maria Zaitseva
    6 years ago

    IDEs can also be painful when things go badly wrong, especially when the toolchain is complicated.

    It's immediately apparent when you try doing low-level development for, say, MCU-based systems, some library could suddenly stop linking correctly and you have no idea how to fix that. If you've spent some time linking libraries manually, then you could make educated guesses to eventually fix the problem, otherwise your project is broken and you waste a couple of days trying solutions from first two pages of Google search.

  • Shalvah
    6 years ago

    I don't agree. I learnt programming with an IDE (Visual Studio - C++). Despite its awesome IntelliSense, it didn't make me "stupid". I was actually able to form a program on paper as well. I only learned the intricate details about compilers and linkers later. And until I moved on from C++ three years later, I was never able to get a GCC installation working.🤣👏

    I learnt Java working with an IDE too, and I knew my stuff. The only stack I learnt outside an IDE was PHP. I used Notepad++ and it frustrated me, till I discovered PhpStorm.

    I personally feel the opposite: beginners should learn with IDEs because it hides complexity, allowing them to focus on learning the language and building stuff. With time, they can dive deeper.

    (Another parallel: when I was new to PHP/web dev, I always used LAMP/XAMPP. As I got to understand more about the language and operating systems, I started to install and configure each component separately. But I'm glad I started out with XAMPP.)

    2 Replies
    6 years ago

    I agree (with you).

    The analogy used in this post is that you should learn to walk before you can run. I don't think that fits with "don't start with an IDE". The analogy that I would use is that this is suggesting you should start to learn to climb by free-climbing actual mountains instead of going to a climbing gym and learning on a wall with ropes.

    3 years ago

    Agreed! After programmers become experts they forget what it's like to learn when they were newbies. Milk first. Using and editor without good autocompletion and code hints when you're a beginner prevents newbies from learning to think like a programmer to use code to solve problems. With practice, those code-hints and autocompletion reinforce and become automatic, and soon every programmer discovers the power of knowing those commands by heart. So they do. Those who don't probably just don't use that language enough.

    I think the real downside of intuitive coding helps is that it allows newbies to do things they probably shouldn't, resulting in bad code and tech debt, but that's another issue that should be resolved by better systems like unit test, to evaluate and qualify code and coders.

    And the complaint that people don't know their way around git because of IDE's is a completely different issue. Git is not programming. It's housekeeping ... important, essential, but don't blame the IDE.

  • Scot McSweeney-Roberts
    6 years ago

    I think the first trap is more "use an IDE before learning the basic of software development (ie, what compilers, linkers, debuggers, etc are)" than a new language. For example, I don't really see why a competent Java dev shouldn't use an IDE when learning Scala/Kotlin/C#/whatever.

  • Tobias SN
    6 years ago

    Not just that, but for some reason there needs to be an IDE for almost every language or framework. .NET? Visual Studio. Java? IntelliJ IIDEA. C? Qt Creator. I’ll admit that I have fallen into IDE hell. In fact, four of the IDEs I have installed are just different versions of the same one (IntelliJ, WebStorm, PyCharm and Android Studio). Good thing I never bothered to learn any GUI Git tools, and just use the terminal instead.

  • tuljmdev
    6 years ago

    For a CS degree, I completely agree this is the best course of action. I still carry a number of bad IDE habits from my early study years.

    But I personally don't think VS Code meets the IDE qualification. It sits in the middle ground as a very code-friendly text editor.

  • Muhammad Arslan Aslam
    6 years ago

    I work on a couple of different javascript frameworks throughout a typical day at work (it's a services-based company, so different stuff comes up every day). So, WebStorm has always been the first choice and I love it. The code hints, code references, and other stuff are really well supported.

    Last week, I told an internee not to use an IDE but use plain editor e.g., Notepad++ and the way he looked at me had me terrified for a moment. Then I explained him the whole IDE vs plain editors thing and how it will help him in the learning.

  • Jackson Elfers
    6 years ago

    We should encourage people to use the terminal from the start. Just a shell a compiler and a text editor. IDEs should be an extension of your work not a dependency. Just some thoughts, good article. 😁

    1 Reply
    6 years ago

    Thanks !

  • Ganjar Gingin Tahyudin
    5 years ago

    vim ftw maybe

  • Simon Massey
    5 years ago

    personally I think people just using an editor not an ide need to level-up and try an ide. in particular being able to set a breakpoint and step through code is a massive advantage to learn new code. if folks want to do things the hard way without an ide then I think that's simply misguided. sorry.

  • Sai Chimata
    4 years ago

    Frankly, git - being an implementation of an acyclic directed graph - is made for GUIs The git CLI is useful for shell scripting, but for everyday use by humans, GUIs are far better. The reason why they get a bad rep I think is that features of the CLI are often left out of GUI implementations, the scripting they perform underneath is sometimes buggy, and the UX design of GUIs is lacking. SourceTree has an especially bad GUI for cherry-picking and at one point had a bug where the merge flag wouldn't be removed when aborting a merge. I often feel like a lot of these problems could be solved if someone created a GUI on top of the actual git source code rather than just having the GUI manipulate the CLI behind the scenes.