The glow of the screen off the keyboard.
Sitting back, I’m remembering days when I spent hours trying to write some of the simplest code; appreciating what I went through to attain my current skill level, looking back upon the frustrations that make me smile. Many years and programs ago (it was 1986, I was 6 going on 7), I came to the understanding that I could control
something in my life: the computer! My father played a key role in getting computers into the mainstream, and interesting me in coding.
I was greeted with hours of green on black text, learning the basics of program design, debugging the non-successful attempts, and gaining a greater understanding of my skills in coping with frustrations. I was persistent, I was hooked, and at some times I felt like an addict, but never did I feel like quitting. It was this emotional attachment and the hours of critique from over my shoulders which formed my habits that made me the developer I am. I found that I was thinking differently in general. My logic skills were growing and my diagnostic skills were blooming.
I still remember that daunting, thick, IBM-gray case and its brown three-ring binder – my bible of sorts. Though I had someone I could ask questions of, I found it more fulfilling to scour through the `IBM BASIC Reference`. Initially I read through the documentation a couple of times in the first two months. My goal: to get a lay of the land, an idea of the different functions and commands held within, not remember all of them; this was a crucial element to my success. I still find myself doing this today, not with the static content that are books, but with the new technology we call the internet. I pull up php.net, navigate to the documentation, and just peruse it.
A lesson I learned really early on, after learning to cope with frustration, was that if you have an idea… wonderful. However, until you have a plan, don’t bother coding! Testing out concepts is one thing (and I strongly recommend it), but unless a solid deadline is near, work on a solid plan of design. When I say design, I am referring to the process of breaking down the overall program into its essential building blocks. The nice thing about building blocks, besides the re-usability factor, is that they can usually be broken down to smaller blocks. Don’t believe me? Think about something as simple as a user-defined function, nine chances out of a ten you’re using more than commands. I guarantee you’re also using functions – maybe even a class or two.
Break it down! Components of components of components: flow-chart the program, create some pseudo code, if anything else at least create a brain-blast chart (I like to use a white-board!). After this process, assuming that deadline isn’t looming, determine if you can consolidate code and look through that tool-box of pre-written code that you have. Now this is starting to look like a design! As with learning and understanding any language, you modify the way you perform its art. With this in mind, keep your box of tools up-to-date with your skills. While I stood watching my father one day in his office, staring at one of the many screens and typing away furiously, I (unknowingly) took a step in a direction I have yet to regret!