Nobody would think that a woodworking master do what he is capable to do because of the tools in his toolbox. Few people would care about the pencils, the brushes, and paints elaborations which Rembrandt used for its marvelous paintings. J.K. Rowling is not famous by the word processor she used to write her famous novels. The soccer ball has nothing to do with Messi genius.

Therefore, why would you think that a Programmer tells apart because he or she uses or knows about some IDE, the new Tool on the market, or their proficiency in this or that specific language or mechanism?

Contrary to other disciplines and arts, computer programming is commonly assessed by the knowledge of «tools». I would not mention a brand or a technology trend, to avoid conflicts and my very particular biases—after all I’m a strong Microsoft’s tools consumer—but some examples will clear the picture of what I’m trying to explain.

For programmers the IDE is like the word processor or the spreadsheet is for the office clerk. You have two or more of those applications always open and had accumulate years of experience with them. You know all the shortcuts and intricacies, including the bugs—someone would suggest the «features»— they have. Likewise, the persistent mechanisms and the UI frameworks are the most common tools or mechanisms in the ordinary graphical user environments with databases back-ends. The typical «data-entry» application is everywhere. You create a new record, enter the data, and click the save button. All of this in a square window, full of text boxes and labels, on the web or locally in your machine. These applications hide the mechanisms to store the data into a database for further recovery, search, edition or also destroy. All «business» programmer knows how to build them and have a vast experience in designing, constructing, testing, and maintaining those applications.

Through the last 30 years—maybe more—, enterprises with programming environments (IDEs) have conduct the preferences and technology applications of programming languages, UIs and persistent mechanisms. You, the programmer, might remember all of the IDEs —from Oracle, Microsoft, Apple, etc.—, the «new» tools to store data (databases and frameworks), and the particular way you construct a UI (from web or windows), the big vendors had offered to you. After 10 years, after 5 years, where are those tools now?

Programming mastership, gained by putting into practice your well-established knowledge, doesn’t arises from tools that you will have to forget the next years. You should know the core of how to build a UI, not by tools, but by the patterns and principles that support its construction. You should know the core patterns of a persistent framework or subsystem and—why not—get some practice by building one. You should try the most ugly UI plain text editor you know with a compiler and a linker. Try to implement your designs with different languages and platforms.

Programming is about design software pieces with algorithms and data structures. You shouldn’t care if your hammer or hand plane is of this or that manufacturer. Programming is about how you can solve a difficult problem with well-known design patterns.

Of course you have to implement the designs and master your tools! But the beauty of programming is not in how you write a conditional statement, declare a variable or call a function. After all, an experienced programmer, is capable to learn the building blocks of a language in a week. Why is that? Because almost all the languages you will use have the same structural items: variables, operators, loops, conditional statements… Once you master one or two languages in the same paradigm, you have a high possibility to successfully translate your knowledge to the new grammar. I must say that including the paradigm shifts in languages and platforms aren’t a big challenge. More than a decade ago, I knew of a programmer who learn by himself COBOL in one night to share data in a windows environment with a main frame!

In the mid 90 up I used a very popular mechanism to store data in a database. After all these years, and after more than three or four of such mechanisms, such technology is more or less an archaeology piece of software. On the contrary, the canonical Design Patterns book view the light at the same years and every day I use many of thus beautiful constructs in design real solutions.

Vendors want you to buy the new version of their tools. You need them. But don’t mix computer programming skills with the path of the business goals of your software supplier. Most programmer friendly environments—the big players— know that. They hire you by your mastery into solve problems and design software components, paying little attention to the languages you know or the tools you use. They want to see what you have built. The want to know the skeleton, the foundations of your designs. But also, they will increase your actual value, by coaching and teaching you the attributes of good, maintainable software. They want the skilled guys in the company to seat near the new ones to share their knowledge and experience. They know how to make value that persist over time.

On the other side, please, if you are assessing a new candidate for a Senior Programmer position these days, ask more than «Do you know SQL?».