The other day I wrote a blog post on why I don't use a traditional IDE. If you haven't read you go check it out. I got an interesting email response (a comment would have been better) from a friend of mine about a particular part of that post; Intelligent Code Completion. Here's what my friend had to say about ICC.
I am arguing against the idea that it either discourages or encourages the learning of a new system - instead, it can assist with either!"my argument is basically that one's desire to grok a particular system is a personal one, driven by various motivations ("to each his own"?), and that although ICC makes it easier to avoid diving into the nuts and bolts, it greatly helps those that do want to learn
After reading this I can see that my argument against ICC is one sided. It only focuses on the negative side of ICC. That's mostly due to the fact that, in my experience, I've seen it have a negative impact on more people than it's had a positive impact on. But my friend is correct that it can be used as a tool to help those who truly want to learn.
I think I understand why I've seen it have more of a negative impact than a positive one. I think that people tend to fall into 4 general categories when it comes to learning.
- Want to learn and are disciplined
- Want to learn but are not disciplined
- Don't want to learn and are disciplined
- Don't want to learn and are not disciplined
People in the first category are the folks that you interact with that "just get it." They're the ones that tend to grok things quickly because they've learned discipline around learning and have become efficient at it and have learned how to learn things that are difficult for them. These people are VERY successful in their jobs. I think this group makes up like 5% - 10% of the average software development shop. These people benefit from ICC.
People in the second category are people who "are hard workers". They tend to understand systems but it takes a lot of work. Usually a lot of trial and error. These people tend to gravitate towards particular types of learning (learn by example, classes, learn by reading, etc...). These people are successful in their jobs. Some of them are really successful and some are just mildly successful. I think this group makes up anywhere between 50% - 70% of the average software development shop. These people are, in general, hindered by ICC but believe that it helps them. They are not typically aware that it takes them more effort to learn because of their lack of discipline.
People in the third category are the people that "just get by". They don't tend to make it very long in any particular organization. They stay for a year or so before they get fired or they get frustrated and leave. They tend to be satisfied finding solutions to their work on Google or Stack Overflow and leave it at that. They don't typically dive in to find out why the Google or Stack Overflow answer works. They're pretty efficient at finding the answer though because their discipline helps them out. These people are hindered in the long run (i.e. growing in their career) by ICC but are helped in the short term. I think this group makes up anywhere between 20% - 30% of the average software development shop.
People in the last group are just there to collect a paycheck. They don't really care about technology, they only care that technology jobs pay well. ICC actually helps these people stay in their jobs because it removes some of the tediousness of learning. ICC hinders their employers in rooting them out and moving them on sooner because they can do just enough to get by. I think this group makes up like 5% - 10% of the average software development shop.
Because the second and third category of people make up the vast majority of people in the office, and are in general hindered by ICC, I tend to see ICC as a negative.
What are your thoughts?
Back in the day, the Visual Studio team came up with a set of personas (google Mort, Einstein, Elvis), and tried to ensure that the VS toolset met the needs of expert developers as well as less-expert developers. Interestingly, assistive features like code completion were actually targeted at the Mort end of the spectrum on the belief that they prevented silly syntax errors, and helped with API discoverability. Sure you could use Intellisense to shoot yourself in the foot. But the absence of the feature wouldn't have prevented foot injuries. Mort was never going to go and read the API docs from beginning to end. If he couldn't grope the API in the IDE, it would just be copying and pasting from stack overflow anyway.
ReplyDeleteI would contend that taking away code completion doesn't necessarily fix the problem, it probably just frustrates people who like code completion. If you want to instill discipline and add safety, how about things like group code inspections (that give less experienced developers a chance to learn from the experts), static analysis tools that look for dangerous code patterns, and even language selection (e.g. do you want Mort writing refcouting code in your C++ application?).
note: many of the best developers I worked with just used NotePad. Or emacs. (but never vi!).
It's unfortunate that we've never worked together. I myself am a VIM guy unless the development requires a specific toolset. :)
DeletePaul, as you know I am not a professional programmer, I am an integration and solutions type person. I find ICC useful in reminding me of things I have forgotten, or most likely so I can use long variable names and not have to type them over and over. PowerShell is were I use it the most, I hate that environment so much, but it has its uses. For any other development I use VI (VIM kills me, so used to VI on Solaris, with it auto exiting edit mode), I have been using spyder for python, which is really just an editor with a way to look up language information or to use the debugger.
ReplyDeleteAs for your types of people, I could fit between 1 and 2, I tend to believe. I find that if I am using technology then I learn everything I can about it. If I am just exploring it I tend to just get the jest of it and move on, leaving me to use more tools and relying on them to complete the task.
Having worked with you I'd definitely say you're in the one of the first two types; probably the first. And your the case that I actually believe ICC is good for :)
DeleteOkie dokie, Paul - my email has been added as a comment to the other post. Where I mention that the comment is connected to this post, possibly creating some recursive commentary paradox that will destroy Everything.
ReplyDeleteI'm just sayin.'
Anyway, at my previous job my team was thrust into a situation that definitely touches on this topic in multiple ways, although exactly how and what the moral is - if any - is something I'll leave for discussion. We were working on a game that used a Lua-based "IDE" (there's no way I'll say that it's an IDE without using air-quotes) to create scripts that attached to "objects" (again with the quotes) to provide functionality for in-game behaviors and such. Think Unity, but make it an ever-changing beta system that had two distinct set of APIs, neither of which were fully implemented and all of which was constantly fluctuating as a slew of new requirements were constantly being addressed (normally incorrectly, breaking everything). The editor was extremely basic and barely functioned, to the point where we eventually requested tools to allow code written in other, external IDE's to be imported. No ICC here, and even if there was some it wouldn't have helped any (due to the noted API issues). Also note that the team working on it was located in a different state, had their own set of priorities (different customers using a different code base), and worked on a completely different release cycle than we did. As a side-effect of this, different engineers had different answers to the same questions, and even when one of those answers was the "right" one it would often be deprecated at some point, requiring new answers and a rewrite of whole swaths of code.
Yeah. Fun, right? And that's just an extremely basic, dumbed-down explanation of what we were dealing with.
Additionally, we were running an in-house framework on top of it for UI and other client-side stuff which - unlike the Lua-side of things - had a functional IDE with functional ICC. This was built by one member of my team (more or less), and so not only could you rely on the API and ICC working as expected, but everyone had the ability to find out the "why's" of the API system and, when needed, directly request features and changes to it.
Yeah. Fun, right? Absolutely.
Thus, when new members of the team were brought into the fold, they had the challenge of learning two (or more, really) discreet APIs, in different languages but directly interfacing with each other, in an environment that was moving so fast that every ask for help had a noted effect on the productivity of the individual(s) providing the assistance. You could literally take your 4 different "learning groups" and, from top to bottom, use them as an indicator of how beneficial a given individual was to the team - to the point where the #1's were put in charge of the most complex tasks, while the #4's were relegated to the easiest (busy-)work and/or eventually fired.
A working IDE for the first system, one that included ICC, would have likely done more harm than good for everyone on my team. A missing IDE and corresponding ICC for the latter would have likely done more harm than good for everyone on my team.
We didn't have an effective IDE - one with ICC - for the first. We did have an IDE, with ICC, for the second. And the ability to find your own answers was essential to yourself, the team, and especially the overall project.