I was reading a recent blog entry by Eric Sink, and he made some comments that I thought I would take the time to share. Nothing profound on my end, mind you... ;)
In "In defense of Petzold's WPF book", the founder of SourceGear writes about a recent trend in books and tools for developers that focus on "quick results", and the trade off that goes along with this trend - loss of "deep understanding". I too have noticed this in working with various developers. While it is admirable that one is able to produce results quickly and ship a product in record time, or add some features in the blink of an eye, it seems that much of the productivity is lost when problems crop up - problems that are at least partially a lack of - you guessed it - deep understanding. As I'm one who likes to have Deep Understanding, I'm probably biased. That said, I can fully appreciate Eric's statement that "When I hire a software developer, I look for deep understanding". I think that it is important to understand how something works so you are able to use it as effectively as possible. Perhaps this is why I am inclined to consider writing software an art, as opposed to a means to an end. Sure, it's both, but how you treat it can have a significant impact on the quality of the end product. At least, that's been my experience.
To me, Deep Understanding implies passion - if one takes the time to understand something fully, to explore all venues of a topic or a technology, they truly care about what it is they're doing and are excited by it. And I can't see doing something as a profession and not being passionate about it.
»
2007-06-04
Deep Understanding?
Subscribe to:
Post Comments (Atom)
Posts
4 comments:
I can't agree more.
I provide solutions into a large company and it is scary how many fellow "developers" don't know how the underlying systems work.
Then they get stuck when something goes wrong.
You end up having to write guides to cover the gap.
robbinma
Yes!
Actually so many so called developers doesn't know virtually anything about underlying technologies... Although they know how to use SQL from .NET application... :P
They create poor quality application software... And it is pretty catastrophic when they try to create something system wide (a "quality" driver for example)...
I'd like to add my 2 cents worth. I come from a background of 20-odd years as an 'Analyst/Programmer' on both IBM Mainframe and Unix boxes. To me 'Deep Understanding' rulz.
Not that I've read the link to DU yet, but the 2 words alone speak volumes. You can't expect an auto-mechanic to repair your clutch when all they've ever seen is the rear diff-housing. Granted, an obvious sign like a linkage hanging off could be picked up on, but the clutch-plates themselves? Where are they, how do they work, and what do they do? If I don't know that to start with, how can I expect to fix a tricky problem?
Much the same can be said of computer software. But there's 2 levels of Deep Understanding here. One is of the complexity and intricacies of the application itself, the other is for the language that it is being written in. Each and both can have their fair share of 'traps for young players'. Then there's a thing called 'style'... and most importantly 'STRUCTURE'. A solid foundation structure is rudimentary in setting something up that is bullet-proof.
I have worked at sites that have little or no structure to sites that have onion-skinned the structure to death. Common sense should never be overlooked here.
And a good 'style' is hard to beat - good structural approach and lots of concise meaninful comments. What the heck, the odd ramble is soul-cleansing too. If you can go back over what you wrote 5 years ago, and still understand what the hell the thing is supposed to do, you're half way there.
This applies to applications just as much as it does to the language that you're writting it in - all good an well to have a heap of 'bells and whistles', but if no-one can understand how the thing works, you're behind the eight-ball before you start.
My wish? Simple. Whatever you are creating/writing - structure the thing properly and stick to a readable and predictable style.
Apart from crap code, what's the worst thing you can trip over on? Error-handling. All good and well to say that there's been an error, but for Gawd's sake, make the error-message meaningful and traceable. While "Error 5 at offset 'h'00FD104C in module 'h'AABBCC" might be accurate, "I don't have the User-Id I need to continue" shines a whole new light on the same problem. And while I'm harping on errors, please-oh-please make sure that every module that calls another module firstly checks if an error was encountered, and then actually *does* something constructive when and error-condition is detected. We had noob coders in a while back, and while what they wrote was technically brilliant to the cause, it was totally unmaintainbable and full of logic-holes. Think about that for a minute.
I've seen way to many apps that receive an error, but still continue on their merry way whether they report the error or not. The same can be said at the nuts-and-bolts level of the language itself. Don't matter if it's 'dinosaur' procedural stuff, or OOP. Something is on the fritz? Report it acurately and with some English words that we all can unserstand, then get the hell out of there.
Go with me Luke - on deep understanding. Understand the nuances of the language that you are writing in. Learn every day something new and more powerful, but never forget the KISS principle. You can make it as complicated as you like - but there is often a more simple and elegant way to get things done. Feel the force, Luke. And if the rules change, so too must your code-base. And learn what your application is supposed to do. After all, it's supposed to help the user, not bury them in a quagmire of ridiculous work-arounds.
Living in the real-world, we always seem to paint ourselves into a corner. "No, don't restructure the thing because it takes too long and will cost too much. Just tackle the issue at hand". I'd like a dollar for every time I've heard that one. Sometimes we have to take a step backward before we climb the next yard on the greasy pole.
And could someone please explain to me why huge business industries that rely 100% on their IT/IS continually try to cut back on that sector? If my business relies so heavily on my computer systems to generate my income, what could possibly motivate me to I want to cut corners? If you have that answer, your reply would be must welcome. At the end of the day, if I can't bill, my customers don't get invoices. No invoices, no income. It's that simple.
There, I've got if off my chest now so I feel better.
Quokka.
Actually, I said the same thing quite a few years ago.
I started out with GW-Basic, and moved on to Pascal, Assembler, C++, and then Windows. In school they taught us Turing, Authority, and Java.
I chose to learn lower and lower languages (the only thing lower than assembler is microcode). But people are being taught higher and higher languages. What are we at now 5GL? 6GL?
Several years ago I complained about how people who do HTML are not really programmers, and even scripters are questionable (although writing BAT files is comparable to assembler/RISC prgramming).
I also complained about how the more abstract the languages become (with frameworks and junk), the less that new “programmers” actually know about how computers actually work.
I pointed out that eventually, there will be a small, elite force of true programmers who know things like assembler who work on Linux or on Windows at Microsoft, writing code to actually program the hardware, whereas everyone else just writes “drag-and-drop programs”. We’re already getting there; Flash reminds me a lot of Authority.
(Redcode is considered a novelty language right? I know that BrainFuck sure is.) :)
Post a Comment