I’ve recently had extensive experience with an IDE from Tibco designed to graphically build integration type applications. Without getting into the unimportant details, suffice it to say that it works OK to that end, but the UI was built with a very peculiar mindset – or more likely mindsets.
The IDE clearly has its foundation in the 1998 era of Swing Java GUI development. That style of GUI development has since been eclipsed by Eclipse (too easy), but having been there once, I recognize the manifestations of tricks to squeeze out just the right behaviour or performance.
A more junior coworker of mine frequently laments that when he changes a component’s output definition, the components that depend on it don’t automatically adjust to the change. The IDE “doesn’t pick it up”; instead, one must go to all the dependents and adjust their expectations of output appropriately.
I didn’t really understand the reason for the complaint. After all, if you are changing the defined output format of a component, it stands to reason that one must fix the components that consume that output data.
However, I later realized what it might be: starting a programming career with IDEs like Eclipse, that support more sophisticated refactorings beyond renames. He’s used to an IDE that can automatically fix tedious and menial problems like typos. It was a surprising realization for me; perhaps it’s further proof I’m considered a “seasoned” developer now? It certainly has analogies to more mundane progressions; I’m sure most kids can’t imagine an era where calls required going home to use the single house phone.
The lesson for me? Pay a little more attention to the ramblings of even more experienced developers (if I’m seasoned, are they “dried up” or “spicy”?). I do that already, of course, through the technology principles books that I read to religiously following certain blogs. There’s always room for a little more consideration though.
