I am surrounded by conversations recently about learning how to code, and wanted to write out some aspects of my journey to being a coder…
The Apple ][
When I was a kid, my dad got an Apple ][ at his office. And on some Saturdays, I would go in and play with it. I had nothing but the manual that came with it, so I pretty much would load up BASIC and start coding the same kinds of things every Saturday. I would write basic loops, counting from 1 to infinity, then enjoying making it overflow. I moved on to random number generation, and would write up basic programs to pick a random color and place it on the screen in random locations, then I figured out how to do the same in high resolution. There is something meditative about watching a screen fill randomly.
The Apple also had DBase on it, so I played with that a little bit and learned how to build a database. But I did not have a reason to build a database as a young boy, so while it made complete sense to me, I could not think of why it would be useful.
But then I hit a wall – I remember thinking that I wanted to learn more, but I did not have resources to help me. There were professional programmers in my town, but they worked in FORTRAN at the insurance company my mom worked at, and she did not think that they would want to take on a child to teach them more. In hindsight, I’m not so sure that was true, but that is about where my childhood programming career ended.
Although I did not do anything truly impressive in those days, I did learn some of the basics of how to code – variables, loops, input, output.
Logic puzzles have nothing to do with technology, but I credit them for much of my ability to think analytically. If you are not familiar with them, there are books available, or you can generate them online at: http://www.logic-puzzles.org/
I had a large book of these as a kid, and over what felt like years, but may have just been a summer, I worked my way through that book, eventually completing all but the hardest puzzles.
Aside from the basic logic skills, I believe this helped me to know how to visualize data, and relationships of data points to each other. This is a skill that I find very useful as a professional coder. All coders can walk through code, understanding the instructions and making code do what it is supposed to do. But all code eventually needs refactoring, as the usage of the code and the related business evolves and changes. Being able to visualize representations of a codebase in your mind lets you better break it into components, understand how they all relate to each other, and see ways to re-organize code into better structures.
Writing a Video Game
I failed to write a game when I was in 7th grade. I would go to the library and play games on their computer, and continue to play on computers at my dad’s office, but wanted to try to figure out how to create my own games. This continues to be a popular reason for learning to code, event today.
Without any resources to learn from, and knowing only the basics of coding, I utterly failed. I drew something on the screen, then wasn’t sure how to animate it. I could draw a background on the screen, but had no graphics frameworks, so I just wrote each pixel. I simply did not know what to do, and had no resources to help. So I failed.
But I did realize that there was a lot more to creating significant work than just what I had learned. At least at this point, I realized what I did not know, which is a great starting point for learning something new.
In high school, I did little with coding. I was a teenager, so I did the things teenagers do — video games, sports, lots of bike rides, time with friends, etc.
I played with computers more on the hardware side -learned how they were built, how all the components actually worked. The one coding project I recall doing was when I figured out how to directly control the pins on a dot matrix printers, and started sending it specific pin instructions to draw images. It was tedious and painful.
I took no computer science courses in college. I had this crazy idea that I should study topics that I could not teach myself, so I studied fine arts and philosophy.
In hindsight, this was an excellent decision for someone who wants to be a coder. It is not the only path, of course, but it was quite effective.
Fine Arts is an excellent background for coding. Although the thinking is completely different, the creative process is exactly the same. You need to have a vision of what you want to create, determine the best methods to reach that vision, plan how to create your work, and actually start the work and execute that plan. You need to develop skills in whichever medium you are using, and know what tools are correct for which jobs. These same principles directly apply to coding.
Philosophy teaches you to understand the core goals of a project – in philosophy, you are normally trying to answer a question or prove a point of some kind. You critically evaluate the premises building up to your conclusions, you can argue for or against most points, and decide what answers to accept/reject, to help build you towards a logical conclusion that holds together. Again, this is like unto coding. You are building logical pieces up, to reach a goal. You make critical decisions on the best way to reach that goal, and implement them in code.
In general, a liberal arts education teaches you a process – how to deconstruct anything, but more importantly, how to pull the best parts back together, and build your concepts back up into something better than where you started.
That reconstruction process is one of the most important skills that I have. Anyone can tear something down, but the ability to improve it as you build it back up seems rare.
Oh, and I ran computer labs for my college, too. *shrug*
Early Career – Support Roles
The first few years of my career was all about tech support – doing direct deskside support at IBM Research, sysadmin work at IT research firms who eventually grew into Gartner Group, stuff like that.
At those positions, I learned Lotus Notes. Although it is a dying technology today (that people mock), in those days it was good stuff. We could whip out a database with forms, UI, data views, without knowing how to code. We could replicate data to different clients, and used it to publish our research. It has not aged well, but it was my first exposure to building an application to handle what a business needed.
It is important to note that I was building simple applications at this point in my career, before I even knew how to code. Although coding is the most common tool for building business solutions, it is not the only tool. It is important to know what tools are available to you, and use what you have to the best of its ability before ever writing a line of new code.
Transitioning to Coding
I was a full time application developer and team lead, before I ever knew how to code.
I worked as a consultant for IBM during their rollout of Lotus Notes after they purchased Lotus. Although my job description was for deskside support, due to my prior experience, I knew more about the product than most IBMers. I became involved in the rollout, and quickly started helping people understand what could be done with the product.
My boss hired me on full-time, as gave me a team lead role to focus solely on building out applications for that division of IBM, including training some of my team members on how to do the same. I built a team of 4 developers, and started holding training sessions for other application developers throughout the division.
I still did not know how to code…. but soon learned. IBM/Lotus added a real coding language to the product. Well, at least real enough for our purposes. LotusScript was added in version 4. It was based on BASIC, but added an object model that opened up the capabilities of the product.
So now was the time that I actually learned to code. The learning curve was steep, even though I had the base analytical and logical abilities, with some solid application development experience under my belt. It is like learning a new language. You know exactly what is supposed to happen, but have to learn how to express that in the way your computer understands. The first time you go through this process, it takes time and effort.
My learning process was a top-down approach. I would do as much as the system allowed before coding, then learn how to code one specific task. In that way, I eventually worked through the commonly used objects, method, and functions. It really only took a few months of work to make the leap to actually coding.
Once you make that leap, and no longer need to look at the help or reference books for every line of code, you are working the way most professional coders work. We do not know everything off the top of our heads, and with the speed of searching online, we don’t need to. The code that you use all the time becomes as easy as speaking English, and you just pull up references when you forget the exact syntax or parameters for uncommon functions.
At this point, the story is done. I knew how to code. I was not good at it yet – that is a different process and a different story, and a story without an end. But if I could tell anyone learning to code one thing, it is that the actual coding is just the cherry on top of a larger sundae. It is the logical and analytical thought, the ability to deconstruct and reconstruct concepts, and the ability to design not only the final result you desire, but the structure to get you there… those are the key components to being able to successfully build applications or other systems.