Abstractions
I wrote this a few months ago. At 1am. In a coffee shop. I haven’t published anything in some time, so I thought I’d share this today. Take what you will from this, on some level it means a lot, on others it means nothing at all.
One of the things I’ve always loved about working with computers lies in the very nature of abstraction. I just love how I can use something, with very little upfront understanding, but then as I use it more I can dig deeper and do more amazing things.
I must admit, my first encounter with the word Abstract in a programming context
was not pleasant. I was in grade 12 programming and we finally got to learn a
“useful” language (Java). Java has an Abstract
keyword, and I was mostly
learning on my own, so I didn’t understand what it meant. Abstract classes were
very frustrating to me at the time. I was trying to set up an applet that used
2D Graphics, and the API Documentation had all these classes that I wanted to use,
but couldn’t, because they were just Abstract Base classes for something that did
actually do something. I still don’t completely understand what they were, but
I imagine they’re similar to an Interface in C#.
So that got me off to a rocky start with the concept of “Abstract”. But over the years, I’ve learned a different meaning of the word. The car analogy is great here. I could drive a car without understanding a thing about Engines, or the chemistry of Gasoline. All I needed to know was move this stick to tell the car to move forward, backward or stay still. Push this pedal to go, and this one to stop. Turn the wheel in the direction you want to travel.
But when things go wrong, you need to dig a little deeper, and peel back some of the layers of abstraction. What happens if the car won’t start? Is it the Battery? Is it the Starter? What’s wrong with the Starter? How does a Starter work, anyway?
I absolutely love peeling back the layers like that, in any topic. I spent the last few years learning to grow field crops before we decided to focus the business on Maple Syrup. I had a lot to catch up on since I spent my High School years studying computers programming and electronics. But I found similarities even in studying the field of Agronomy. “This path of the field looks yellower than the field around it. Is there something wrong with the soil? Are there bugs feeding on the plant? How do I identify the bugs? What do I do about them?”
But you don’t need to know about N-P-K values for fertilizer to plant a seed and watch it grow. That extra knowledge just helps grow bigger, greener, more productive plants. The same goes for computer programming. I didn’t need to understand TCP, HTTP or any other Networking protocols to make a Web Site with HTML when I was 11 years old. But understanding more helps me make better solutions, and solve more complex problems.
Of course sometimes I have a love-hate relationship with things that I only understand at the high level. Like Linux. I learned everything I know so far in Windows, but there’s this whole other world where there is software that does nearly Magical things. I know enough to read a tutorial and get the system up and running, but there’s just so much going on underneath that if something goes wrong it takes me a long time to debug. But every time I invest the effort to fix something I learn more, and it becomes easier.
That being said, I think it is a very valuable skill for life in general to be able to look at something at that “just enough to use it” level, and dig deeper to fix any problem that comes up. I know many people who just do not have the desire or confidence to look deeper into something and learn more. They just throw up their arms and say “I could never understand that!” and give up. My life would be very dull indeed if I thought that way!
Mind you, sometimes you just have to know when you’re in over your head and get help… but I’d never go to a mechanic who wouldn’t show me what he’s doing to my car.