Know Your Tools

I usually talk a lot about the importance of understanding concepts. They are crucial as a common ground for discussion and collaboration to achieve the team’s goals.

In this article, I’ll talk about tools, telling my story on how I became dependent on Integrated Development Environments (IDEs) and what I did about it.

The Case of Ant Build File

When I was in university, I only wrote small programs in Pascal, Assembly, and C for Electrical Engineering classes. Some Matlab scripts and other things like that. As a professional software developer, I started as an intern writing code in Java.

I’ve read Sun’s Java tutorials and practiced a lot. At first, installing the Java Development Kit and using gedit to edit source code. I compiled my code with terminal tools.

As soon as I put my newbie fingers in productive code, I started using NetBeans as IDE. And it wasn’t just for convenience: the Ant build file for the project was generated by NetBeans. Whenever a new version of the IDE was installed in my computer, or if another person pushed code, it was necessary to open NetBeans and run the build, so the build file could be updated. I think the issue was a link pointing to the NetBeans embedded Ant executable, which was in different locations for Linux/Windows or different NetBeans versions.

Unless I made the build file NetBeans-independent, I needed to use the IDE. I was already learning Object-Oriented Programming and Java. Learning another tool (Ant) to have an IDE-independent build was something I didn’t even consider at the time.

Not much after, I started to realize the wonders of automating stuff. Why do I have to waste my time in repeatable tasks? Opening NetBeans to correctly set up the build file was one of these repeatable tasks. I was already reading about continuous integration, and I knew repeatable builds were necessary. I needed to do something.

And so I did: I studied Ant, adapted the build file and made it work from the terminal. I completely removed NetBeans files from the repository. Any developer (me) could import the project into the IDE as an Ant project, but it wasn’t a dependency. Creating the production ready artifacts involved some manual steps, like code obfuscation, installers generation etc. I have also automatized these and included in the Ant build file. I scratched my own itch and it was a huge technical improvement for the project.

What are Your Dependencies?

My first intention with this anecdote was to highlight one issue: dependency on the IDE. Of course, you need to select technologies you will work with. In this example, Java and Ant. I think the IDE selection should be up to developers. And they must have the option to select no IDE at all.

My second intention is to ask you a question: what dependencies do you have to develop software?

Some dependencies are hard to change, like programming language and build tool. But these are project dependencies, and it is not my point: I’m talking about dependencies you create for yourself.

Do you know how to build your software without an IDE? In the story, I was unable to do so until I decided to change.

Do you depend on the IDE to write code? Can you just open a text editor with syntax highlight, edit your code and build it from command line? I acknowledge the wonders of autocompletion, auto-importing, refactoring etc. on Integrated Development Environments. These features can make your life easier, and your relationship with code much more efficient. At the same time I think: if your very life as a software developer depends on IDEs, you’re limited. You may be missing how stuff works and how tools interact one with the other. This limits what you can do and may lead you to errors. For example:

• Your cartography application has a Map type (com.your.code.Map, because this name makes sense even being equal to java.util.Map).

• You start declaring a field of type Map and the IDE suggests to import java.util.Map, instead of com.your.code.Map. You blindly accept the suggestion.

• It takes you some time to find out you imported the wrong class.

Or even worse:

• You are going to use JUnit’s Test annotation. The project uses JUnit 5.

• You write the Test before a test method, but you didn’t notice the IDE suggestion to import this annotation from JUnit 4. You just accept the suggestion. You think it is OK because the code is working.

• Your POM file is automatically updated: you just added another dependency to the project. And you didn’t even notice.

These are examples of silly errors you can have if you depend on things you don’t understand, or didn’t pay enough attention, to get your job done. Your code can become pretty bad if you are OK with these dependencies: hard to read, inflexible, unmaintainable or simply wrong.

My IDE Dependency

A long time ago I noticed I was dependent on auto imports and other IDE’s features. Instead of thinking in what I needed, I was fiddling around, so the IDE would suggest something that would work. It made me lazy. And there are two kinds of lazy people:

• The ones that don’t like stupid work: they think to have less effort.
• The ones that believe that thinking is a lot of effort: They end up doing things incorrectly or inefficiently.

Most of the time I’m proud to be the first kind of lazy person. In this story I was the second.

I was learning the Java standard classes. I was also learning the classes from the application. When coding, I was using IDE suggestions to help me to code faster. But I was learning little each day. IDE suggestions made me lazy. There was no sense of urgency to understand what I was doing, because I could rely on the tool.

But IDEs has zero value if you don’t know what you are doing. It was a real professional-life-changing experience to leave NetBeans aside for some time. I used Vim to write code. To build, I used Ant in the terminal. I learned a lot. After some time, I started using IDEs again. Nowadays, I still use them. Now I understand what I’m trying to do and do not depend on the IDE to get the job done.

Conclusion

I think tools should work for me. If they get on my way to understand concepts, I may dig deeper into tools' details. Doing this, I will not depend on an auxiliary tools (like an IDE) to do important work (coding).

Of course, I will use tools. But not depend on the auxiliary ones. I will not depend on the IDE to generate a POM file to set up a Maven project, for example.

It can be challenging, sometimes overwhelming, to gather all this knowledge. But it pays off. Like when I needed to understand how Gradle works to contribute to Nextcloud News. Afterwards, I needed to use Maven. This previous knowledge helped me a lot.

More knowledge is never too much. Don’t limit yourself to what an IDE suggests you and be the best developer you can!