On Learning How to Code as a 9-Year-Old
How I made a desktop app in the 2000s with minimal lines of code, added a 30-day trial period to it and packaged it in a CD.
All that remained was to sell it and wait for people line up to buy it . And how that would take place in 2020. Let’s take a trip in a time machine back to the millenium, and fast forward from there.
Of course I had been fiddling with LOGO (“REPEAT 360 [FD 1 RT 1]”, Turtles, turtles all the way down!) in the classroom a year before I was 9 years old in my school computer labs and I enjoyed randomly clicking around the matrix of buttons in Minesweeper or playing with colors on “Paint” on a monochrome screen of Windows 98 whenever my Dad took me to his office and let me fiddle with the office PC or chatting with people through Yahoo! Messenger in a cyber cafe paying INR 10 per hour, but the earliest memory I have about learning not just how to program, but have autonomy over a computer was when I was about 9 years old when my parents bought for me a new PC.
It was a shiny new HP Pavilion with a Pentium 4 processor and 256 MB of RAM and Windows XP and Office preinstalled. Instead of going with a standard CRT monitor, my Dad paid extra bucks for a TFT LCD monitor in those times when it was pretty new because the salesperson told them that it puts less strain on the eyes (a good decision in hindsight!). The person who came to provision the system for us brought along GW-BASIC, LOGO along with the standard software and loaded and installed them on our computer. And then I started using it.
The issue was that I would somehow cause the PC to crash in a few days by poking around system files and call the support engineer for help. They would come, do their magic and go back and I would crash the system again, and call on the local sales support again. After a few visits they stopped responding to our phone calls. It was then that I called HP Tech support and bless one of their phone support executives who actually stayed on the phone with this 9-year old for over two hours while they guided him through inserting the 8 system recovery CDs one by one and do a clean install of the OS, all by himself. I no longer needed to be at a support engineer’s mercy subsequently no matter how much I messed up things while learning, and this was the most empowering thing for me. To be able to make as many mistakes and recover from them.
Over the years I learnt things like partitioning and all the basic Sysadminning skills and became skilled enough to clean up whatever mess I could create. That’s how I gained autonomy over computer systems, by realizing that they are fixable in most of the common cases. Later in my childhood I was similarly empowered by a few engineers who were happy to show me how to open the back case of my computer and look at the components. One even let me disassemble and clean my computer (RAM sticks, PCI cards etc) myself so that later I could fix not just OS but hardware issues and I’m grateful for all their help.
Coming back to my PC purchase, a few days after my extended family learnt of the news, my mama (maternal uncle) found for me Visual Studio 6.0 (awesome Visual Basic 6, Visual C++ and the goodies that came with it) and said, “Enjoy!”. My computing journey had begun, not with Prince of Persia or Road Rash, but with an exposure on how to build desktop applications. All from the screen below.
Typically one would select “Standard EXE” in the window above, but I actually selected “VB Application Wizard”. My first ever rabbit hole that continued for several months, or years.
This wizard would generate for me a Microsoft Word like UI, which would have a Multiple Document Interface (MDI) window, which meant you could have multiple documents open within a single window at the same time. It would generate a toolbar which had the standard “Bold”, “Italic”, “Underline”, “Left”, “Right”, “Center” and Font face and size comboboxes too. All of this bundled by default as a scaffolding. It was awesome to click the “Run” icon and watch my application run in real time. I could open files, save files and do a bunch of operations as I would do in any other application and it would just work. There, I had built 30-40% of Word functionality without having written a single line of code, just by clicking a few buttons. But we were talking about learning to code, weren’t we?
So, I started to fiddle around with what was actually going on. I would double-click on a button and a strange window would open up which would use words like “Button1_Click()” and “End Sub” and the written text was highlighted in a few different colors [I was to learn later that this is Syntax highlighting and Code View]. Didn’t have an internet connection in the house yet, that was to come later. Gradually I started to find my way around through cause and effect - I messed around in these windows, clicked “Run”. If by chance I broke something, I would re-run the “Application Wizard” and have a clean state to start from.
What helped later was that my parents found a tech book shop and brought for me a book that looked something like this. I was pretty surprised that I was able to find the exact book cover that is on my ancestral home bookshelf.
Reading this book gave me context on the environment I was working in. I followed the book and recreated example projects. Of course they were not like the Application Wizard but making the projects themselves introduced me to the basic concepts on how things work in VB6. I also got access to the MSDN library, and started to dive into the documentation. Learnt about things like “MsgBox”, and “About dialog”. I customized the “About” dialog of the autogenerated application with my copyright message (because I saw them in almost all applications :) ) got a logo image somewhere and called it “TextWord”. Added a “Splash Screen” before the app actually loaded, progress bars with fake delay, just like the original MS Word Application seemed to take some time to load. For me, back then, it didn’t matter whether my app TextWord had substance, what I cared about was to make my app “the real thing”, at least in terms of appearance. Word has this, my application (TextWord) doesn’t. So I will find a way to make my TextWord behave the same way.
Then I also saw that some applications I downloaded had a 30-day trial period after which they would ask for a key or money to be paid to continue working. I thought I would implement the same thing in my application. It was easy by this time to add a new dialog box with whatever text I wanted to display. I could adjust the font sizes and stuff by now. So I added a “Trial Version” warning to TextWord that it would “expire” in 30 days and you would have to enter a “Product Key” to dismiss the warning. The key? A hardcoded random number I would check with an “If” condition :) - talk about cryptographic hashing to a 9-year old me and I would probably understand it if somebody explained it to me in a succinct way rather than saying “You’re too young to know this stuff; that’s out of your syllabus, kid!”. Did it matter if the app stopped working after 30 days? No! The 9-year old me didn’t know how to implement these features, let alone implement them in a “secure” and “uncrackable” way. But the warning, the idea of my app stopping to work after 30 days was enough and I kept it at that. Then I learnt how VB6 could “compile” my application and create an EXE so that I could run it outside of VB6, standalone.
Visual Studio had a bunch of other applications to it. One of them allowed me to create a “setup.exe” file using the Windows Installer Framework. I would tell it where my application lived, the exe file and maybe a few bundled images and things and it would create an installation package that I could use to install TextWord. I didn’t like the fact that the EULA (licence agreement that one would probably just click through “I agree”) was blank, so I copied a boilerplate EULA from some application (I don’t remember which) and put it in there. Then I burnt it into a CD, complete with an “autorun.inf” so that setup would auto-launch whenever somebody would insert the CD into their computer. Pretty neat. I could sell this and profit $$.
But I wasn’t satisfied. Why?
(Note that it took me several months/years after to figure out the answer to each item in the list, it wasn’t an immediate process)
- Office XP had that cool blue flat icon look in both the toolbar and the menus, and the menu items even had images in them! TextWord wasn’t even close, it had vanilla menus and the app looked like Windows 98 :(.
- Office XP had way more features. The font size combo box would list all the fonts in a WYSIWYG way, TextWord just had the font names vanilla.
- The “Settings” window for Word had multiple tabs and so many checkboxes. TextWord had none :( .
- Windows XP had introduced a distinct new style for the icons as well as the “Common controls” - the new Visual Styles (talk about how buttons looked pre-XP and post-XP) and none of my VB6 apps had the new XP look. Even the previous icons used a 16-color palette and looked so 2D when compared to the 24-bit color palette that XP apps and icons looked like? It was just so cool[Also note that the 9-year old me barely understood color depth and color palettes but I could feel the difference]
The fourth one took me into a rabbit hole of “XML Manifests” in the MSDN library. I learnt about the existence of a file called comctl32.dll where these buttons and “Common Controls” came from and that if you had abc.exe, you had to have a file called abc.exe.manifest and the manifest should have a certain XML string inside it - of course I didn’t understand fully what XML was at that point so I just copy-pasted from the MSDN documentation into a file and knew that this should work. Great! But then I also have exe files that don’t require this manifest and they still look XP-like. What I then learnt was that the manifests are embedded as Executable “Resources” and I learnt how to use a tool called “Resource Hacker” to manually embed the manifest into my exe file. What I then realized was that Resources are also the place where I store the exe versions and things. So I learnt not just about executable manifests but in the process also how to dissect exe files [Hint: do not open them in notepad and edit :) ]. That was my first deep dive into executable reverse engineering.
The first and second ones took me into a Rabbit Hole of what I learnt as ActiveX controls and the marketplace that was associated with them. They promised XP-like look, Office-like looks and what not. All at a price tag of just some $$. Their demos looked so cool and I wished I could just have them. But there wasn’t fun if I couldn’t make them myself? I came across a site called VBAccelerator that actually built these controls from scratch. I would just download them and use them but I tried to look at the code that made them tick, and in the process learnt about things like UXTheme, Windows API, OwnerDraw, concept of SendMessage and so on. I didn’t know the nitty-gritties, just that these things existed and they somehow worked magically and gave me what I wanted. So I used them as-is to make my application better.
Of course I moved away from VB6 to Visual Basic .NET at the very first opportunity I got. Also I was used to BASIC-like languages, but as soon as I got comfortable with C on the side and writing semicolons at the end of each line was no longer scary and became a natural habit, I moved to C#. By then I had a broadband connection and Express Editions of Visual Studio which were free to use (this was 2005), there was no looking back and I just took off. But then I still spent a considerable period of my time trying to create TextWord 2.0. By this time it was more UI-style friendly, Windows Forms was far more expressive - it offered nice visual styles and it took considerably less time to recreate the UI I wanted. I learnt about .NET Reflector and used it to decompile existing desktop applications and figure out how they are written and I realized that they are much more complex than I had imagined. I gradually left TextWord alone, but not before it had taught me so many things about coding and computer internals and creating desktop applications I would have never learnt otherwise. This wasn’t something like Algorithms and Data Structures as they are taught today but it was a practical self-apprenticeship, following my way through information rabbit holes is a skill I developed this way, and I know that given enough time and documentation, I will figure out a way to solve a problem. Of course I learnt things like the Model-View-Controller paradigm for application development and version control much later (which means college days) when I worked through my Google Summer of Code Project in my second year of college, but the learning framework that was established at an early age continues till date.
Looking back at the 9-14 year old me after several years into a technical career, I would have probably asked a different series of questions and chosen a different set of priorities to work on and develop as a kid. I am happy to be proved wrong, but I don’t know if an app designed to teach me how to code would have helped me learn how I actually ended up learning not just coding but about OS internals through my school days, even before I was taught these concepts formally in college. What was so unfortunate for me is that while I was growing and learning all this I had no one at school to share all these awesome findings with, students or teachers. All they would teach us in class was a few nested for loops, in Java and BlueJ, and there was no “extra credit” or things you would do once you are through the basic code examples.
In some way though, the 9-year old me if he existed today in 2020 would be happy to find that people have actually started to care enough about these things (even though the motivating factor is probably their parents' FOMO or ambition of fat pay packages). Maybe he can start discussing with his friends about the fact that he coded a simple “Flappy Bird” game yesterday and they show how they recreated PUBG over a few days - how awesome it was to learn about WebSockets, load balancers, Google Cloud Platform, Firebase and 3D engines. They can talk about Unity and Unreal 3D engines and which of them was a better choice. Or debate the coolest new features in VSCode vs Vim vs Emacs. Or talk about the VCs they are talking to for their apps and discuss term sheets. Or leave all that aside and share a virtual lunch over their favourite video-conferencing app.