Nostalgia

My first software project

Mohit Garg, who has been in the software industry for a few years, talks about his first encounter with a software project

My first brush with a software project was under a decade and a half ago, in the 10th standard. I wanted to learn a programming language hands on by applying it to a project instead just tinkering with a language through little programmes. So I signed up for a specific course in GW BASIC (the language du jour) with a training institute as part of extra-curricular activity during my summer break.

At the course we had the freedom to pick our project; my project partner and I decided to animate an Archie comic strip. The theme seemed simple—the scene started off from the back of a drive-in, showing Archie and Veronica watching a sci-fi movie. And just as Archie comments on how the possibility of life on other planets is unreal, an alien spacecraft takes off from behind them. I knew that we did not have to draw any detail, so animating this ought to have been simple.

We didn’t realise then how difficult even this little graphics project was going to be. As I tinkered with the graphics-related functions in BASIC that drew lines, circles, ellipses and filled closed areas with colour, I realised how the language fell short for even this relatively simple task. I knew then that the Star Wars graphics had been done in C. As I struggled with the language options and reworked the storyboard to fit the language better, I gained a little insight into the sort of feature-rich graphics library that the Star Wars developers would have needed.

Another constraint then was computer time. It just happened to be a time when a lot of kids were interested in getting their feet wet in computing. Those were the days when a computer was not a familiar sight. Even though 486s were the much-talked-about new kids on the block, the 286 PC used to be the jaw-dropper. Peter Norton’s comments about how the Intel 286 processor was a major architectural shift vis-à-vis its predecessors were still a novelty to me in those days.

As we competed with other enthusiastic kids to grab computer time, I learnt to map out screen action on paper co-ordinates and write code on paper. My project team-mate, who was a much faster typist, would punch in the code as I read it out to him and we would cross our fingers at compile time. Errors in visualisation, code or typing were costly in terms of time, but the two of us would always find a way forward.

We delivered the project and came in second. Significantly, the screens we had drawn made people smile. As an individual, I topped the course, but I learnt far more during that summer. Interestingly, I received a book on programming at the training institute’s award ceremony.

It’s been quite a journey into the software and IT areas of the industry since then. As I look back, I learnt some important lessons for a kid in his early teens grappling with technology for the first time.

One lesson: technology will change. Adapt to it just as much as you adapt it to your requirements. The second lesson was teamwork. No project can be a one-man show. My project partner—an avid gamer who introduced me to gaming—valued deadlines as much as I did. I could always count on him. The third lesson was to get the job done. Learn everything you need to deliver.

These simple rules have helped me a lot over the years.

Along with this was the stark realisation of how layer upon layer of abstraction on a simple adding machine can help you achieve some very complex tasks. That has been part of the magic of computing.

The author may be contacted at theprotean_1@yahoo.com