You are a very important, talented, enterprise-level programmer!
You write and maintain millions of lines of code, compiling your applications takes several hours, and your databases contain hundreds of tables with millions of rows.
Even the best and brightest and most experienced programmers, now and then, come upon a class or library or technique that is new to them. That's right, even you! You can admit it, no one's looking. But it really has no effect on your productivity, because you can quickly refer to the documentation or books or Google or many other resources to obtain the knowledge you need without missing a beat. Heck, you don't even need to post a question in a programming forum -- who could help you, after all? It's usually the other way around, right?
So, you've done your research and gained the knowledge to use this feature and it's time to put it to use. Implementation -- that's what separates the men from the boys! You have a hectic schedule and you are very, very important with no time to waste, but you're armed with knowledge, you're feeling good, you just drank 4 diet Pepsis for the caffeine and you have an unlimited supply of Cheetos ready to go. No pressure, but the fate of the entire organization
is counting on you.
You open up your enterprise application in the development environment, wait 10 minutes for the massive project to load, and then you spend 20 more minutes carefully going through code and checking to see where the new feature needs to be implemented. It might be a new T-SQL feature in SQL 2005 that you are using, a library in .NET that you haven't worked yet, a general programming technique that you are about to employ for the first time, or maybe an external library that you will incorporate into your project. It's really irrelevant -- the key is, it's time to make some changes and you, and you alone, have the expertise to get it done on such a large scale application.
After all, who else can go through millions of lines of code to figure it out? Not those junior programmers, that's for sure. They sure have a quirky way of doing things, mostly because they are not on the same time constraints and at the same level as you.
You see, those junior programmers are just not capable of implementing and testing this new technique on your enterprise applications. They don't have the patience, the skill, or the know-how to do it. When you see them "working" on applications, you notice that a lot of time they seem to instead be working on "Hello World" projects! Simple 10 line projects! Single SELECT SQL statements! Talk about programmers who have much to learn! You haven't touched
a simple project or SQL statement in years
and you wouldn't be caught dead
doing so! The horror! Could you imagine such a scenario?
Hypothetical CIO: "Hey, have you finished the deployment of Complicated Enterprise Application 2007 yet?"
Hypothetical You: "Uh no, sorry ... I am trying to get this console application to print my name."
I mean, come on!
So, the development environment is ready to go. You've read the documentation, you know exactly
how to implement the new technique into your code, and after 10 or 15 minutes -- it's done! Not too shabby, eh? Time for a compile, another Pepsi, and a test run.
Now, even the big-time programmers get bugs. You may be the best, but even the best experiences these, right? Sure enough, you get a run-time error. Back to the documentation. Ah ha! This class library requires a few more properties to be set up or there's some other tweak to make that wasn't specified in the documentation. Clickety-clickity-click -- done! Recompile ... wait ... execute the application ... wait ... drink a Pepsi .... wait ... bathroom break ...wait ... run the test ... wait .. Damn! Another run-time error. You notice some other quirk that wasn't clear in the documentation. Hmm, you may have to try this a few ways to get it to work right. Fair enough, that's how it goes for enterprise level important programmers, right? This stuff almost literally is
rocket science, after all!
Well, after several more changes and compiles, now it runs, but something doesn't quite look right. The new technique isn't doing just what you thought; time to make some changes. Back to the source code, check it out line by line, and run it again. You'll get it figured out before too long, right? Unfortunately, this is what happens when you work with complicated systems,and it's what you get paid for.
One day, while waiting for the latest compile and then for the testing process to run, you look over and see "junior programmer #5" working again on yet another silly little program.
"Hey junior!" you shout (they hate when you call them that), "what you got there? Tic Tac Toe??"
"Um, no," he replies meekly, "I am testing a new component. I created a small, simple program that I can tweak and run quickly and easily so that I can be sure I understand how it works."
"Whoah! Sounds complicated, junior!" You belch back sarcastically. "I guess that's why you make the big bucks like me, right! Look at this puppy," you say, pointing an orange cheese-covered finger towards your monitor, "over 10,000,000
lines of code! 10-tier architecture
! I don't need no silly 'test application' to tell me how to program!"
"Yeah, I guess I am pretty lame," junior responds, ashamed. "Remember last week when you recommended that I exclusively use FULL OUTER JOINS in my SQL code? I didn't understand how they work, so I did something similar to this ... I created two small tables, put in a few rows of sample data, ran some simple scripts in Query Analyzer and looked at the results, testing different joins and verifying the effect on the results. Because I am so new and inexperienced, it was the easiest way for me to learn how it works. Kind of embarrassing, huh?"
You laugh. "Yikes! A newbie
!" you exclaim, crumbs of Cheetos spitting from your mouth. "When I first used the new T-SQL features in 2005, I went straight to the General Ledger and started changing the reports! I don't have time to mess around! The data looked good to me after a few runs, the totals seem to match, it all compiled and worked after only a few tries. There were a few bugs here and there we are still looking in to, but I think it's unrelated. The real problem is waiting for those damn QA guys to finish testing and tying out the ledger reports to let me know if things are working right. How the hell can I be sure that these T-SQL enhancements work correctly until they get back to me with the results??!! It takes them forever! Idiots!"
Junior nods and goes back to "work" on his "important project." Ah, kids these days ....
Anyway, the compile is done, the program is executing -- and it looks OK! It took several weeks of work and lots of tweaking, but it looks right as best you can tell, the new technique you've used seems to work fine. There was some trial and error (the damn documentation wasn't clear!) but you've got it now. You send off the latest build to the QA guys, and add another bullet point to your resume!
A job well done, you sit back, put your stocking-and-sandaled feet up on your desk and look over at Junior while you absent-mindedly play with your pony tail.... Poor Junior, he has a lot
to learn from you about programming!