Reading through one of Karl Seguin’s blogs on ASP.NET isn’t always the right tool it convinced me more that there is a gap in software education. Not in formal education, but in continuing education.
Computer-science and programming curriculums at tertiary institutions have remained fairly static over the years inline with accommodating their primary objective: concepts. They will use a set of technologies in order to convey those concepts but not often do they specialise in that technology [at least early on in the program] purely for the sake of that technology. That’s where continuing education takes over. You won’t go to university to learn Apache, but you will learn web server concepts. Outside of university, it’s your ability to join the dots between web server and Apache and apply that knowledge [wisdom] that determines your worth.
Formal education has the advantage that concepts don’t change as rapidly as the tools and technologies. It’s continuing education that sit with the task of trying to keep up by providing “expert” education on new technologies. And since this is an ever-changing and time-consuming task, the foundation established by formal education is not taken advantage of. It’s not an objective. That is to say, the language of function [the what] disappears from the curriculum and the course becomes a powerpoint presentation dripping with the language of form [the how].
Considering that business processes and requirements have increased in complexity, programmers are required to know [minimally] “how” to solve these issues. The available toolsets have managed to meet those demands [and some] and assist the solutions, but there is a lot more going on that you need to be aware of, albeit even vaguely. And when you engage in advanced tools to faciliate advanced business needs, the demand that you know what you’re doing and not just how to do it, increases. From managing a web farm to architecting an e-commerce site, knowing how to do it is half the task. When you know what you’re doing, you’re better equipped to handle the esoteric stuff Mr.Murphy is well versed in at throwing your way.
How to distinguish postbacks in ASP.Net seems trivial. Look up the sample code and documentation and without further ado, IsPostback will solve all your problems. But what is a postback? Why do i even need to distinguish it? [you think i’m kidding? :)] What data is riding on a postback? What methods are invoked during a postback? What happens when i have dynamic controls? Knowing a little about the what behind the scenes goes a long way to solving a “but it just doesn’t want to work” scenario. It will also eliminate the many “WT..?!’s” you might come across when reviewing code before releases.
The problem and the solution is shared between both continuing education providers and learners. Learners need to realise that just because InstitutionX gave you a certificate that says you can do the job, it doesn’t mean you can. When you learn “how” to assign directory permissions, or “how” to nest repeaters, keep in mind “what” you are actually doing. To understand the impact of “what” requires you to invest further in your own education. It’ll only make you stronger. Educators don’t have the time/resources available to point out what may seem to be obvious.
Think critically. Remember what you have learned or at least know where to find it when you need it. Be conscious of every line of code you write. Know exactly what you are doing. Write tests! And if you don’t know why it’s breaking, it’s because you probably don’t understand why it was working in the first place… :p