I have come to know many different people and engineers in the recent years. Many of them use IDEs for the day-to-day work. So far, so good. Though, I noticed some of them are not able to help themselves our of weird situations where an IDE corrupted some project config files or generated other strange output. Some of them don't even know how to use subversion or git without a GUI.
Instead of trying to figure out how to fix things a layer below (aka editing files), they try to find a solution using a GUI. They just don't seem to care about how things work on the inside. The whole point of this post is to raise awareness of this issue (especially for beginners).
I can fully understand why people don't want to tinker with some obscure and complex project config files created by their IDEs. Or HTML/XAML files generated by a GUI editor. Or use git on the command line to perform a more complex operation impossible using the current IDE.
A whole different layer of abstraction can hold you back from acquiring deeper knowledge of a system. It's human. The simple resistance to look at the unknown. I experienced it myself and if you ever suffer from this, make sure you make the leap and learn.
As a system grows more and more complex, it tends to leak abstractions. Joel wrote a nice article about this matter. This is also true for an IDE. It is a highly complex system bookkeeping and juggling thousands to millions of files in a fragile way in order to provide a streamlined development experience.
Despite its fragile nature, it is usually a great time-saver: it finds errors more quickly and more reliably than you, it autocompletes variables, functions, etc. more quickly than you (and definitely typo-free), it provides efficient workflows for common tasks, etc. etc.
As long as you know what you do, IDEs are great.
Mostly, I don't have time to dig into the nitty-gritty details of everything either; even when I care. I don't need to know which assembler instructions are executed when I write a Python application. I don't need to know how Linux handles file access when writing an HTML template using the jinja engine. It just works, I don't need to know how it works and I am damn grateful for it.
However, knowing at least one layer below of the your tool can help tremendously. When the shit is about to hit the fan (and that usually happens when there is no time for it at all), you can fix things and get back on track quickly.
Besides all the practical benefits, it can be a journey into history when familiarizing oneself with the "lower level". The development of current de-facto standards is a worthwhile education. Obscure design decisions (also speaking of your company's own software portfolio) suddenly make sense and relationships between system components become clearer and simpler ("DocumentDuplicationManager" becomes "ah, it just copies a good ol'file from location A to location B).
Broaden your horizon will accompany you throughout your life as an engineer. Getting your hands dirty (aka descent to a lower level) will give you stronger knowledge and more value to your project and company.
Applying this knowledge to IDEs results in this three-step How-To-IDE:
1) Do things manually to get a feeling of what needs to be done in the first place.
2) Identify common workflows.
3) Utilize IDEs to streamline your workflows into shortcuts or one-button clicks.
Next time when your favorite IDE screws it up, keep that in mind. Maybe, there's a better solution for your problem once you understand the underlying issue.
Pros and cons of IDEs.
No comments:
Post a Comment