Premise: When you are deep within a great forest, trying to get to the other side, it is very easy to get lost amongst the trees. The leafy canopy, the dark moss on the ground, the hairy spiders attacking you.
Ahem.
Let me start this article by transporting your mind with a song. Picture your favourite musical, or that episode of the Simpson’s where Mr. Burns sings "See My Vest".
If you go down to the woods today,Be sure it is with a goalIf you code down in the woods today,You’d better get in control
For every time you push further in,And forget to take a moment outWell that’s the day that you project comes to eat you
Ahem. Again.
The idea (and title) for this article came directly from a conversation with Bill. I’m deep within a project at the moment, coding like a maniac, and realising (slowly), that it’s not good enough just to code. Just to port across the old code, or even transform the old code into new. That’s good, but only part of the picture.
Development, done properly, is really hard. Your brain has to not only be code orientated, but also global-direction orientated. And probably a few more directions as well. Definitely.
That is, when you are deep in the midst of coding a window with half a dozen different windows underneath it and some very complex logic to calculate certain values, calling a few more different procedures/functions, it is very hard to pull out and check the direction.
Let’s get serious. Most development is about creating a solution to a problem and/or need. There are a bunch of rules that drive the project that don’t have anything to do with the underlying code. That is, because we are the best at what we do (heh heh, Ego), we can get the code to assimilate whatever Rules are thrown at us.
This is good. But it’s easy to lose sight of those Rules. Especially in a complicated project.
So how do you do manage these two poles?
I think the answer is easy to realise, but much harder to implement.
It requires great discipline of mind. Well, to start with. Then, hopefully, like some, it will become almost second nature. To be able to split your mind and make sure that as you are thinking through the coding functionality, and even the low-level Rule functionality, that you are maintaining a grasp on the high-leve Rules.
There is more to this. It’s not just about thought processes. You have to do the unthinkable, stop coding, and test the sucker.
This applies to the developer doing a project on their own, and the developer who is part of a fifty-man team working on the next Duke Nukem, Hail to the King Baby! (Sidenote : What’s going on with this? I want to shoot pig peeps!). Every project you develop, or part thereof, is your own little kingdom, even if for only a moment. Make it your own.
Testing. It’s like drinking coke after years of diet coke abuse. Urggg.
But it has to be done. And you gotta change your palate to accomodate and make it part of your total development package. If you follow case-studies, or something similar, and add real data to your project as you code it, then you will come out the other end not only with a far more polished product, but also a better developer. Because you will pick things up, and evolve your development brain.
We have to grow our development brains. They are what is going from project to project. Own the project, for sure, but it’s gonna go. Until we leave this mortal coil, and probably a little before then when the mental faculties start to break down, our development brains are what gives us our vocation. So feed them, nourish them, work them.
As always, writing this article has uncovered other things. I wanted to talk about not losing track of the Rules of the project when in DeepCode, and discovered a further Dev Dawn purpose. Or rather, a development in the purpose of Dev Dawn.
The Development Brain.
More later. Thanks for showing up.
