I attained my IT degree (B. S. in Computer Science) 12+ years ago at a traditional midwestern college, so the education was fairly well rounded. Looking back more than a decade later (having gained a not insignificant amount of real-world experience), there are certain bits of information that, since they were lacking in the classroom, left my well-rounded education with some hard right angles.
1. Requirements gathering
I wish someone along the way had told me that the most difficult part of the job was this right here (most difficult in my estimation, anyway); and that they had included more (or I guess some at least) education on the matter.
To be fair, the “capstone” course of my degree involved actually completing a real-world project (ours was a web page for a non-profit). This, of course, did involve gathering requirements, but there was little information as to how to approach this, neither leading up to, or during the project.
Experience has taught me that it’s not just about asking the right questions, but in asking them in the right way – and being flexible enough to recognize when you need to change the way you ask them, depending on the audience. This difficulty is increased when you have minimal business knowledge on the subject at hand. It is, of course, very beneficial when you have business analysts on hand to help facilitate this, but that is probably a topic for another day.
2. Configuration: Spring, Maven, Hibernate, XML Parsers, Eclipse, etc.
In any large-scale project, multiple components have to play together nicely. In a perfect world, this would happen seamlessly, but as we all now know, this isn’t always the case. Of course, there are any number of integration solutions in existence, both in published form and online. It’s been my experience, however, that eventually you are going to run into some integration conflict that you cannot find a solution to.
Full disclosure, however, I have been referred to by a coworker as a “snake-pit” because I seem to always run into these scenarios (through no fault of my own, just sheer dumb luck it seems). On occasion, configuration problems can cause cause an inordinate amount of delay, simple because it comes down to a “process” of guesswork and trial and error. Configuration involves its own set of skills and knowledge, above and beyond that of logic implementation. I certainly didn’t have any education on this, and doubt that such a thing could exist anyway, given the speed at which component technology progresses.
If I did receive any formal education on documentation, then it’s certainly not something I recall. Not so much as how to document (which is also important), but more as to when to document. Certainly code documentation is not needed to clutter up every single method in your code base.
A good rule of thumb seems to be to only document when:
(a) it’s not immediately obvious what your code is doing.
(b) you are implementing logic that is out of the ordinary or inconsistent with the surrounding system, and you need to explain why you are breaking the pattern.
More formal, non-code documentation falls in with the requirements gathering I mentioned previously; the “capstone” course required usage of it, but up to that point, there was no class that addressed it directly.
When I started composing this blog entry, I wasn’t really sure about where my intent was heading; now that I’ve written it out and given myself time to consider it, I have a takeaway. Provided things have not changed in the past decade, it might be suggested that Computer of Science degrees in traditional colleges require more classes that concentrate on the non-technical knowledge necessary to program the highest quality software products. And to students, I recommend that you take courses that give you experience with these subjects to better prepare yourself for the IT world.
Because it’s not just pounding out quality code – it’s communicating effectively with business specialists, users, and quality assurance providers. It’s also communicating effectively and efficiently in the written word. And, of course, having the ability to solve problems, not only logic problems, but problems in such areas as software system integration and configuration. These are all essential abilities of a well-rounded IT professional.
— Robert Rice, firstname.lastname@example.org