The Evolution of a Programmer
Usually around major holidays I become a bit more reflective and I "Reflected" recently on my kinda / sorta "evolution as a programmer".
I started programming seriously on an Apple IIe (and a bit on Commodore 64's) - at the time I was a broker with Merrill Lynch in Orlando, and I was fascinated by the Technical Analysis Department up in New York. These guys, like Bob Farrell and Phil Rettew, who've become legendary, would post their daily market calculations on the Quotron screens (for those who aren't old enough to know, the Quotron system was a hard-wired network with small monitors and keyboards for the brokers. The monitor had a screen with one glorious color - "puke green").
I started out copying down the TRIN, put/call and other indicators onto graph paper with colored pencils. It was fascinating (so fascinating that I eventually left the business when I realized I was more interested in technical analysis than sales!). While other brokers in the office would get excited about having some Muni bonds they could get a full point commission on, I was ranting about the put/call ratio making a new high.
There was an older broker in the office who had a Trash 80 with a printer. He wasn't much of a programmer, but he would let me write BASIC code that would actually print out these indicators as rudimentary graphs on perforated dot-matrix printer paper, and man - was I ever hooked! D00d, you wouldn't want to short GOOG at $500 without these graphs!
So I saved up and got my Apple IIe with the two floppies and the big cables and a dot-matrix printer. 64K of RAM! Anyway, I was fortunate because one of my customers was an engineer at what was then Martin Marietta in Orlando (now Lockheed) and he would help me with learning BASIC. I almost got divorced 'cause the Significant Other could not understand what I was doing up at 3 AM writing code...
So my first real entry into the programming world was driven by a need - to be able to analyze, manipulate via mathematical computations, and graph stock market data (this eventually led to a Ph.D. in economics).
My first programs were what I now refer to as Linear Buitoni. Everything was "inline"- from front to back. Then I learned you could isolate code blocks into what were called Subroutines - that could be called from anywhere in your code. This was nice because if you had 10,000 points of daily data and you need to compute a slow stochastic index on it, you could pass in each day's data to your subroutine and have it do the computation, and return you the result of that day's worth of data.
Oh, and let's not forget the glorious "GOTO" statement. That REALLY made things fun! My Grandmother always said "The way to understand recursion is to understand recursion." Bless her heart - she managed to recurse her way up to 100 years old before she finally threw a stack overflow.
It wasn't until much later, working with FoxPro 2.6 and writing much more organized code for real business applications that I began to think in terms of "Structured Programming" concepts. Try writing an Australian Binary MLM commission program in Foxpro and you will learn what "structured" means, really fast.
And, although I dabbled in JAVA and C++ in the 90's, I never really got the concept of OOP (Object Oriented Programming) until .NET came out in 2000. That's when things changed. One of the biggest problems with programmers who started out or are coming from the Visual Basic "space" is to UNLEARN all the "bad habits" and crutches you have come to rely on. For many, this takes a continued, concerted effort, and for some, they never get out of the bad programming habits and thinking. This is particularly unfortunate for VB.NET programmers because Microsoft decided to bring forward a huge amount of "backwards compatibility" and "crutches" in the VB.NET programming language. If Option Strict and Option Explicit are left off by default, how many VB programmers do you think are going to "explicitly" learn why they should both be turned "on"?
Being largely self-taught as a programmer is not for everyone. You have to be really, really motivated to begin with. There are a couple of other skills I've acquired and carefully honed along the way that have helped me:
1) Learn to search on the web (google, Live.com, whatever). The web is your personal "RTFM". The better a searcher you are, the less frustrated you will be.
2) Learn how to ask questions - whether it's a post on a newsgroup, or a verbal question to a peer, you must be able to express yourself clearly and concisely, stating the exact problem and what information you need. When I look at some of these newsgroup posts (e.g., "Urgent-Please Help me") - posts that ask for nebulous things and have no sample code - I often wonder how anybody could even bother to respond.
So anyway, I thought I would share this tidbit of history. Happy Thanksgiving (or whatever your favorite hoiliday is). And, thanks for reading!
I started programming seriously on an Apple IIe (and a bit on Commodore 64's) - at the time I was a broker with Merrill Lynch in Orlando, and I was fascinated by the Technical Analysis Department up in New York. These guys, like Bob Farrell and Phil Rettew, who've become legendary, would post their daily market calculations on the Quotron screens (for those who aren't old enough to know, the Quotron system was a hard-wired network with small monitors and keyboards for the brokers. The monitor had a screen with one glorious color - "puke green").
I started out copying down the TRIN, put/call and other indicators onto graph paper with colored pencils. It was fascinating (so fascinating that I eventually left the business when I realized I was more interested in technical analysis than sales!). While other brokers in the office would get excited about having some Muni bonds they could get a full point commission on, I was ranting about the put/call ratio making a new high.
There was an older broker in the office who had a Trash 80 with a printer. He wasn't much of a programmer, but he would let me write BASIC code that would actually print out these indicators as rudimentary graphs on perforated dot-matrix printer paper, and man - was I ever hooked! D00d, you wouldn't want to short GOOG at $500 without these graphs!
So I saved up and got my Apple IIe with the two floppies and the big cables and a dot-matrix printer. 64K of RAM! Anyway, I was fortunate because one of my customers was an engineer at what was then Martin Marietta in Orlando (now Lockheed) and he would help me with learning BASIC. I almost got divorced 'cause the Significant Other could not understand what I was doing up at 3 AM writing code...
So my first real entry into the programming world was driven by a need - to be able to analyze, manipulate via mathematical computations, and graph stock market data (this eventually led to a Ph.D. in economics).
Spaghetti Code
My first programs were what I now refer to as Linear Buitoni. Everything was "inline"- from front to back. Then I learned you could isolate code blocks into what were called Subroutines - that could be called from anywhere in your code. This was nice because if you had 10,000 points of daily data and you need to compute a slow stochastic index on it, you could pass in each day's data to your subroutine and have it do the computation, and return you the result of that day's worth of data.
Oh, and let's not forget the glorious "GOTO" statement. That REALLY made things fun! My Grandmother always said "The way to understand recursion is to understand recursion." Bless her heart - she managed to recurse her way up to 100 years old before she finally threw a stack overflow.
It wasn't until much later, working with FoxPro 2.6 and writing much more organized code for real business applications that I began to think in terms of "Structured Programming" concepts. Try writing an Australian Binary MLM commission program in Foxpro and you will learn what "structured" means, really fast.
And, although I dabbled in JAVA and C++ in the 90's, I never really got the concept of OOP (Object Oriented Programming) until .NET came out in 2000. That's when things changed. One of the biggest problems with programmers who started out or are coming from the Visual Basic "space" is to UNLEARN all the "bad habits" and crutches you have come to rely on. For many, this takes a continued, concerted effort, and for some, they never get out of the bad programming habits and thinking. This is particularly unfortunate for VB.NET programmers because Microsoft decided to bring forward a huge amount of "backwards compatibility" and "crutches" in the VB.NET programming language. If Option Strict and Option Explicit are left off by default, how many VB programmers do you think are going to "explicitly" learn why they should both be turned "on"?
Being largely self-taught as a programmer is not for everyone. You have to be really, really motivated to begin with. There are a couple of other skills I've acquired and carefully honed along the way that have helped me:
1) Learn to search on the web (google, Live.com, whatever). The web is your personal "RTFM". The better a searcher you are, the less frustrated you will be.
2) Learn how to ask questions - whether it's a post on a newsgroup, or a verbal question to a peer, you must be able to express yourself clearly and concisely, stating the exact problem and what information you need. When I look at some of these newsgroup posts (e.g., "Urgent-Please Help me") - posts that ask for nebulous things and have no sample code - I often wonder how anybody could even bother to respond.
So anyway, I thought I would share this tidbit of history. Happy Thanksgiving (or whatever your favorite hoiliday is). And, thanks for reading!
I heard people now instead of saying RTFM using STFW (Search The F'in Web). Thought that was pretty funny :-)
ReplyDeleteThanks Pete - that was really interesting!
ReplyDeleteIn my early IT days I had problems being taken seriously because I hadn't done lots of training courses. Several years of intensive self-study and experience later I've realised that a curious mind, an aptitude for spotting patterns, and Google, is all you really need.
As a contractor I've been through a lot of companies and I'm often shocked at how better trained professional developers have such bad coding standards and lack of full life-cycle experience. It does help me feel less of an amateur though!
Ben,
ReplyDeleteYes, well that and an IQ that's above room-temperature! I agree there can be a big difference between "MCSE" type book learning and "in the trenches" experience.
Thanks for sharing that tidbit of history Peter it brought back some memories. I laughed when I read that you started with the Apple IIe with floppies with 64k. What a difference in a few years. I wrote my first program (FORTRAN) as a result of a home work assignment in an Electronics class in 1966. My first step was to head to the bookstore to buy a box (2000) of 80 column punch cards, finding a book was hopeless. One of the hardest things in my programming career was to give up cards. In those days the only computers where at universities and large businesses. No monitors are CRTs. All programs ran in a batch environment. Well enough of that, I'll get to the point.
ReplyDeleteOver the years I have learned that these skills also help.
1) Learn Design Patterns and how to write algorithms. Languages come and go. In 41 years I have been through a lot of languages, but good design patterns and algoritms can be moved from language to language. The reason we have the various constructs in languages today is they where created to implement good design patterns. Early versions of programming languages had very few constructs and the use of GOTOs was required. A good design pattern has no place for a GOTO. Thinking of GOTOs, COBOL has a Computed GOTO, you can branch to various points in code based on the value of an integer. Very difficult to debug. .Net will not be around forever. Languages will evolve as more design patterns are developed.
2) Know the consequences of each line of code you write. I can code in vb.Net with Option Explicit and Option Strict both off, and then turn them on without any squigglys. The more thought you put in on a line of code the less likely that line will need to be revisited.
That's my 2 cents.
Hey! Even though i was born in '82 i get goosebumps when i read this article. Commodore 64 was my point of entry (wizard(s) of war rocks!). Then QuickBasic (GOTO's) on 386's i think, then came college which is recent history. :) (the goosebumps fade off). The funny thing is i can see my self programing even after i retire. Games of course!
ReplyDeleteMy two cents as a programer:
1) When searching around the web for solutions to a problem, before reading always look for a date when it was written!
2) Many things in programing are easier to understand than you might think when you are first introduced to the big terms and achronyms.