This is bit like a philosophical post. Just some thoughts regarding our perception of developer tooling.
First – a question. Which IDE do you use? Eclipse? NetBeans? IntelliJ IDEA? Visual Studio? Vim? Emacs? Yeah, really – Vim counts as an IDE as long as you can configure it to behave like one. Or maybe Sublime Text, a really awesome text editor?
Second question. Do you leverage the full power of your favourite IDE/editor?
Mostly, people will say that the just use the IDE and I haven’t really seen many people leveraging the power of refactorings, shortcuts, other awesome IDE features that are out there. Why? Lazy? Careless? Neglectful?
I was reading a nice theory article The IDE Divide, which is already 8 years old. The point of the article is that it points out two extremes among the developers: language mavens and tooling mavens. Language mavens are those who case about the deepest nuances in the programming languages and don’t really want to rely on tools (or just don’t have time to explore the features of the tools). Tooling mavens are the ones who are obsessed with learning (and creating?) the tools and not spending as much time discovering the mysteries of language features. The article also mentioned that it is enormously hard to be both, the language maven and the tools maven at the same time, since the time for learning all this stuff is limited.
But generally, I think, knowing the properties language and runtime is more important as it is the produced code that will eventually run on the system. The tools are just used to create the programs. However, I rather consider myself a ‘tooling maven’ type of developer. Not that I don’t care about the languages, no. It is just the interest shift towards tools for me.
Despite the above, I noticed something (or it is just my perception). When a the new-born programmer starts, you will first try to reach the comfortable level of using the language. Once you’re successful, there comes time for you to write the programs more effectively – faster, using shortcuts… click, click, click. This is where the tooling kicks in. Eventually, you start appreciate those nice features of your IDE that help you to write the code more effectively. The next stage is when you realize that actually you do not write code as much as you read it, and then you will start to appreciate the features that help you to navigate the code, analyze it, maybe refactor it. Language becomes a bit unimportant.
I was chatting with Jacek Laskowski one day and he asked an interesting question:
‘If you’re given awesome tools/components/frameworks to work with, would you really care about which programming language to use?’. Really good question. I wouldn’t care, I guess. You will learn the language anyway. Or you will learn the tooling anyway once you’re comfortable with the language of your choice, because normally you would like to be more effective (this is my perception of curious programmers, I hope you
are a curious programmer).
What do you feel when a colleague next to you just moves around the project like a pro and finds everything he needs just in fractions of a second, and types with shortcuts creating new statements with just a few strokes? And then you try to type:
‘p’ ‘u’ ‘b’ ‘l’ ‘i’ ‘c’ ‘_’ ‘s’ ‘t’ ‘a’ ‘t’ ‘i’ ‘c’ ‘_’ ‘v’ ‘o’ ‘i’ ‘d’ ‘_’ ‘m’ ‘a’ ‘i’ ‘l’ [oooops! a typo!]. Frustrating…
It is every so often I was keeping myself back from screaming at my colleague ‘just Ctrl+Shift+E !!!!’ while the team mate was looking for the class in the project tree the name of which he did not remember.
Modern IDEs have revolutionized the way in which we are able to work with the code. Sadly, most programmers are held back by some mysterious myth that if you learn the tools too much you’re doomed as a programmer as you start depending on those tools. Don’t be held back by such fears! Go learn some tooling instead – it will save you some time later!
Improve software development by passing along shared knowledge and best practices.
One of the biggest challenges in application development today is how to factor in application-specific information. The answer lies in the ability to capture application evolution and developers' knowledge of building and extending the application as metadata so that it's not lost in time or translation. Once that can be done effectively, the combination of the application code along with application-specific metadata can be meaningfully packaged into reusable software asset modules. This white paper will discuss how 'Application Factories' can transform an IDE to play a central role in capturing both the application evolution and the developers' knowledge.