This is a story about my journey as a programmer, the major highs and lows I've had along the way, and
how this post came to be. It's not about how ecstasy made me a better programmer, so I apologize if that's why you came.
In any case, we'll start at the end, jump to
the beginning, and move along back to today. It's long, but I hope the read is as rewarding as the write.
A while back,
Reg Braithwaite
challenged programing bloggers with three posts he'd love to read (and one that he wouldn't). I loved
the idea so much that I've been thinking about all my experiences as a programmer off and on for the
last several months, trying to find the links between what I learned from certain languages that made
me a better programmer in others, and how they made me better overall. That's how this post came to be.
The experiences discussed herein were valuable in their own right, but the challenge itself is rewarding
as well. How often do we pause to reflect on what we've learned, and more importantly, how it has changed
us? Because of that, I recommend you perform the exercise as well.
I freely admit that some of this isn't necessarily caused by my experiences with the language alone - but
instead shaped by the languages and my experiences surrounding the times.
One last bit of administrata: Some of these memories are over a decade old, and therefore may bleed together
and/or be unfactual. Please forgive the minor errors due to memory loss.
How QBASIC Made Me A Programmer
As I've
said before, from the time
I was very young, I had an interest in
making games.
I was enamored with my Atari 2600, and then later the
NES.
I also enjoyed a
playground game with Donald Duck
and
Spelunker.
Before I was 10, I had a notepad with designs for my as-yet-unreleased blockbuster of a side-scrolling game that would run on
my very own Super Sanola game console (I had the shell designed, not the electronics).
It was that intense interest in how to make a game that led me to inspect some of the source code Microsoft
provided with QBASIC. After learning
PRINT,
INPUT,
IF..THEN, and
GOTO (and of course
SomeLabel: to go to)
I was ready to take a shot at my first text-based adventure game.
The game wasn't all that big - consisting of a few rooms, the
NEWS
directions, swinging of a sword against a few monsters, and keeping track of treasure and stats for everything -
but it was a complete mess.
The experience with QBASIC taught me that, for any given program of sufficient complexity, you really only
need three to four language constructs:
- Input
- Output
- Conditional statements
- Control structures
Even the control structures may not be necessary there. Why? Suppose you know a set of operations will
be performed an unknown but arbitrary amount of times. Suppose also that it will
be performed less than X number of times, where X is a known quantity smaller than infinity. Then you
can simply write out X number of conditionals to cover all the cases. Not efficient, but not a requirement
either.
Unfortunately, that experience and its lesson stuck with me for a while. (Hence, the title of this weblog.)
Side Note: The number of language constructs I mentioned that are necessary is not from a scientific
source - just from the top of my head at the time I wrote it. If I'm wrong on the amount (be it too high or too low), I always appreciate corrections in the comments.
What ANSI Art taught me about programming
When I started making
ANSI art, I was unaware
of
TheDraw. Instead, I opened up those .ans files I
enjoyed looking at so much in
MS-DOS Editor to
see how it was done. A bunch of
escape codes and blocks
came together to produce a thing of visual beauty.
Since all I knew about were the escape codes and the blocks (alt-177, 178, 219-223 mostly), naturally
I used the MS-DOS Editor to create my own art. The limitations of the medium were
strangling, but that was what made it fun.
And I'm sure you can imagine the pain - worse than programming in an assembly language (at least for relatively
small programs).
Nevertheless, the experience taught me some valuable lessons:
- Even though we value people over tools, don't underestimate
the value of a good tool. In fact, when attempting anything new to you, see if there's a tool that can
help you. Back then, I was on local BBSs, and not
the 1337 ones when I first started out. Now, the Internet is ubiquitous. We don't have an excuse anymore.
-
I can now navigate through really bad code (and code that is limited by the language)
a bit easier than I might otherwise have been able to do. I might have to do some experimenting to see what the symbols mean,
but I imagine everyone would.
And to be fair, I'm sure years of personally producing such crapcode also has
something to do with my navigation abilities.
-
Perhaps most importantly, it taught me the value of working in small chunks and
taking baby steps.
When you can't see the result of what you're doing, you've got to constantly check the results
of the latest change, and most software systems are like that. Moreover, when you encounter
something unexpected, an effective approach is to isolate the problem by isolating the
code. In doing so, you can reproduce the problem and problem area, making the fix much
easier.
The Middle Years (included for completeness' sake)
The middle years included exposure to Turbo Pascal,
MASM, C, and C++, and some small experiences in other places as well. Although I learned many lessons,
there are far too many to list here, and most are so small as to not be significant on their own.
Therefore, they are uninteresting for the purposes of this post.
However, there were two lessons I learned from this time (but not during) that
are significant:
-
Learn to compile your own $&*@%# programs
(or, learn to fish instead of asking for them).
-
Stop being an arrogant know-it-all prick and admit you know nothing.
As you can tell, I was quite the cowboy coding young buck. I've tried to change that in recent years.
How ColdFusion made me a better programmer when I use Java
Although I've written a
ton of bad code in ColdFusion, I've also written a couple of good lines
here and there. I came into ColdFusion with the experiences I've related above this, and my early times
with it definitely illustrate that fact. I cared nothing for small files, knew nothing of abstraction,
and horrendous god-files were created as a result.
If you're a fan of Italian food, looking through my code would make your mouth water.
DRY principle?
Forget about it.
I still thought code reuse meant copy and paste.
Still, ColdFusion taught me one important aspect that got me started on the path to
Object Oriented Enlightenment:
Database access shouldn't require several lines of boilerplate code to execute one line of SQL.
Because of my experience with ColdFusion, I wrote my first reusable class in Java that took the boilerplating away, let me instantiate a single object,
and use it for queries.
How Java taught me to write better programs in Ruby, C#, CF and others
It was around the time I started using Java quite a bit that I discovered
Uncle Bob's Principles of OOD,
so much of the improvement here is only indirectly related to Java.
Sure, I had
heard about object oriented programming, but either I shrugged it off ("who needs
that?") or
didn't "get" it (or more likely, a combination of both).
Whatever it was, it took a couple of years of revisiting my own crapcode in ColdFusion and Java as a "professional"
to tip me over the edge. I had to find a better way: Grad school here I come!
The better way was to find a new career. I was going to enter as a Political Scientist
and drop programming altogether. I had seemingly lost all passion for the subject.
Fortunately for me now, the political science department wasn't accepting Spring entrance, so I decide to
at least get started in computer science. Even more luckily, that first semester
Venkat introduced me to
the solution to many my problems,
and got me excited about programming again.
I was using Java fairly heavily during all this time, so learning the principles behind OO in depth and
in Java allowed me to extrapolate that for use in other languages.
I
focused on principles, not recipes.
On top of it all, Java taught me about
unit testing with
JUnit. Now, the first thing I look for when evaluating a language
is a unit testing framework.
What Ruby taught me that the others didn't
My experience with Ruby over the last year or so has been invaluable. In particular, there are four
lessons I've taken (or am in the process of taking):
-
The importance of code as data, or higher-order functions, or first-order functions, or blocks or
closures: After learning how to appropriately use
yield, I really miss it when I'm
using a language where it's lacking.
-
There is value in viewing programming as the construction of lanugages, and DSLs are useful
tools to have in your toolbox.
-
Metaprogramming is OK. Before Ruby, I used metaprogramming very sparingly. Part of that is because
I didn't understand it, and the other part is I didn't take the time to understand it because I
had heard how slow it can make your programs.
Needless to say, after seeing it in action in Ruby, I started using those features more extensively
everywhere else. After seeing Rails, I very rarely write queries in ColdFusion - instead, I've
got a component that takes care of it for me.
-
Because of my interests in Java and Ruby, I've recently started browsing JRuby's source code
and issue tracker.
I'm not yet able to put into words what I'm learning, but that time will come with
some more experience. In any case, I can't imagine that I'll learn nothing from the likes of
Charlie Nutter, Ola Bini,
Thomas Enebo, and others. Can you?
What's next?
Missing from my experience has been a functional language. Sure, I had a tiny bit of Lisp in college, but
not enough to say I got anything out of it. So
this year, I'm going to do something useful and not useful
in Erlang. Perhaps next I'll go for Lisp. We'll see where time takes me after that.
That's been my journey. What's yours been like?
Now that I've written that post, I have a request for a post I'd like to see:
What have you learned from a non-programming-related discipline that's made you a better programmer?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
Since you enjoy metaprogramming I will recommend you to check out Io. www.iolanguage.com It even more reflective than Ruby.
Another good post!
Regards
Posted by Emil Ivanov
on Jan 14, 2008 at 08:01 AM UTC - 5 hrs
Thanks Emil - I'll definitely have a look!
Posted by
Sammy Larbi
on Jan 14, 2008 at 09:14 AM UTC - 5 hrs
Regarding the absolute minimum for a Turing-complete language - the Brainfuck language
<
http://www.muppetlabs.com/~breadbox/bf/> has eight operations - input, output, two control/conditional statements, and four data manipulation statements - proving you weren't far off in your QBASIC analysis. That said, control statements most certainly canno be dispensed with in the manner you described - a large class of programs can't be written with only finite-length loops. Programs that never terminate, such as servers, are a small but significant example. Programs that need to scale up indefinitely are another.
Posted by Roie Marianer
on Jan 15, 2008 at 03:27 AM UTC - 5 hrs
Thanks Roie - I wasn't quite looking for Turing complete but I'm glad you brought it up - it showed a major hole in my analysis:
I completely neglected data manipulation! I don't know how that passed me by.
I guess it was implied a bit by the story surrounding it, but definitely should have been in there!
Posted by
Sammy Larbi
on Jan 15, 2008 at 06:06 AM UTC - 5 hrs
Thanks for sharing your journey :-)
I've been thinking about writing a response to Reginald's "what I've learned from X that made me a better programmer with Y" for a while as well. I'll certainly do so in the future. I find your own question very interesting too; I've put it in the thought grinder right beside Reg's :-)
Posted by
Mathieu Martin
on Jan 19, 2008 at 05:42 PM UTC - 5 hrs
Thanks Mathieu, I certainly look forward to reading it if/when you get around to writing it!
Posted by
Sammy Larbi
on Jan 19, 2008 at 06:56 PM UTC - 5 hrs
Hi Sammy, for my part I find more and more in the past year that one of the big things I've been talking about with regard to programming turns out to be ... drum roll... cognitive science! And I know a lot of people will read that and have one of two reactions either "you mean AI?" (no) or "uhh... like brains and stuff?" (no) ... well... sort of... but not like they think... cognitive science meaning what's meant by people in the cognitive science world is real-world, testable experiments into how humans tick on a very fundamental level.
Behavioral psychology more than anything else -- in particular the observation that easily 50% if not more so of our day-to-day thought is non-rational, driven more by instincts and conditioning than by critical thinking. Critical thinking itself is an extremely challenging discipline for humans, because in an evolutionary sense critical thinking isn't a survival skill. It's responsible for all of our technology and that's amazingly impressive, but not because we're good at it, only because we persist at it in spite of being very bad at it. There's an 80% failure rate in R&D for that reason. Because of things like the 2-4-6 problem, otherwise known as "confirmation bias", a bias to which all humans are prone and which immediately predisposes us to be wrong in every attempt to excercize critical thinking.
I know... I'm long winded... Forgive me, it's an aspect of my Asperger Syndrome that I haven't figured out how to temper. :) Anyway, I thought you might find it interesting that of all the things I could cite as non-programming interests (I have no formal education) that have made me a better programmer, behavioral psychology and cognitive sciences are at the very top of my list. :) And less so because of the reason you might think. You might think it's because I feel it's helped me to be a better critical thinker, but I don't think that's it at all. I may or may not be a better critical thinker for it (or for any of a number of other reasons), but the reason I think it's made me a better programmer is much more like the reason learning different programming concepts makes me a better programmer.
As you learn new programming concepts (moving from procedural to OO for example), you begin to reevaluate what had been your standard approach to seemingly trivial tasks. You take a task that you previously would not have questioned, but simply written out and you brainstorm and you examine an array of alternative solutions to that problem that were previously non-existent to you.
Similarly, cognitive science causes me to reevaluate the standard user-interface decisions that most programmers make and look for alternatives that have the potential to be more ergonomic, more intuitive. At the end of the day, it's the ergonomics of your software that will win customers, because that's how they're going to make their purchasing decisions.
And that (ergonomics) really is I think much of the appeal of Rails... it certainly seems to be the way Rails is marketed... and being much more familiar with Rails, I'd really enjoy hearing your feedback on the quick-start guide for the onTap framework if you have a few minutes to look it over. :) Check out
http://on.tapogee.com - hit the "documentation" link around the middle of the page and then you should see "quick start" in the left navigation. Thanks! :)
ike
Posted by
ike
on Aug 21, 2008 at 10:02 PM UTC - 5 hrs
@Ike - thanks for the comment. You should write a little more in depth about the intersection of programming and cognitive science. I've been wanting to read some psychology to see where it applies, so I'm definitely interested in the subject.
Do you have any recommendations of books to read?
As for the docs for onTap - we're in the middle of our busiest time of year at work, so if you send me a reminder email (
http://www.codeodor.com/Contact.cfm) in a month or so, I'd be happy to take a look if I've got a spare moment.
Posted by
Sammy Larbi
on Aug 22, 2008 at 07:22 AM UTC - 5 hrs
Thanks Sammy. The book I've been reading recently is called Predictably Irrational by Dan Ariely, a professor of behavioral economics at MIT. I'll also recommend Freakonomics by Steven Levitt although that particular book is sort of the opposite of Predictably Irrational. PI shows situations when people stop behaving rationally whereas Freakonomics shows situations where people behave rationally in spite of the fact that they're not supposed to. Learned Optimism by Martin Seligman is a good one as well as Influencer. I also have on my reading list Blink which talks about how often an abundance of information about a problem will make the problem harder to solve and the Black Swan which talks about the nature of innovation.
But beyond all the books, I would also recommend just taking the time to read all the articles on Wikipedia that are linked from the list of cognitive biases. There's a ton of info in there. The difference is that the Wikipedia articles will give you a ton of raw information (probably more than the books), but it may be harder to assimilate because you won't get a lot of the history or "story" of these discoveries, which sometimes makes it difficult to remember the details. Check out memory studies too. Memory turns out to be a really complex process that involves lots of different areas of the brain. It fails quite frequently and can even be used as a tool to manipulate the senses.
No worries re: being busy. I'll try and remember to pester you in late September. :)
Oh and there are some articles on my framework blog
http://ontap.riaforge.org/blog that talk about some of my thoughts on the subject of software and cognitive science. I think there's a category for cog-sci related articles.
Posted by
ike
on Aug 22, 2008 at 12:41 PM UTC - 5 hrs
Thanks. I'd been wanting to read Blink, so I'll put that and the others on my books-to-buy list.
Appreciate it!
Posted by
Sammy Larbi
on Aug 26, 2008 at 08:40 AM UTC - 5 hrs
Welcome. Yeah, Blink and the Black Swan are both books I haven't had a chance to read yet. But they're high on my list. :)
Posted by
ike
on Aug 26, 2008 at 10:08 AM UTC - 5 hrs
