On Learning

As programmers, we work in a discipline that is a bit different from that of many other people we know. Many other disciplines have developed to a point of reasonable maturity and stability, with a broad, long-agreed-upon base of knowledge, educational path, and perhaps even certification of some kind to show mastery. Programming, on the other hand, is comparatively an infant. The idea of programming as its own discipline is really only a few years old. Programming has no agreed-upon education of any kind- though degrees in computer science are widespread, it's not widely accepted that a computer science degree is necessary, or even particularly helpful for those going into a programming career. In contrast to a long-agreed upon base of knowledge, programming has gone through revolutionary changes every few years. Whether it's change of programming language or the changes in software development methodology, programming-related knowledge has a very short half-life.

Surrounded by a constantly shifting landscape of knowledge, we can't stay satisfied with the knowledge acquired a few years ago, or even a few months ago. Granted, it is probably a bad idea to constantly switch to the newest and coolest thing like some kid always reaching for the shiniest toy, forgetting the pile of neglected toys at his feet, but the discipline of programming is young enough that new, field-changing ideas emerge all the time. We're still finding the ground rules here. I suppose you could keep on working the way you always have, using the languages and techniques that have worked for you for years-however, if you do that without keeping an eye to the future and embracing key improvements, you will likely find yourself in a backwater of software development after some time. Not to mention, if truly improved ways of working come about, it could be considered unethical to blithely ignore them and deliver inferior products. On a different note, I feel that it's intrinsic to programming to explore-if exploration of new ideas doesn't excite you, you may find a career as a programmer a long trudge.

As a programmer, you must take responsibility for your own learning and the progression of your career. Perhaps you currently feel your company should do this for you; after all, it's work-related, right? If you feel this way, either change your mind right now, or think about reconsidering your career choice. Here's the thing-it doesn't *matter* to the company how you personally progress in your career and if you learn the new tools -all an organization needs to care about is if the staff as a whole progresses - and it can do that through new hiring if needed, saving them the work of training you. Truthfully, though you might find it unpleasant, your company might be perfectly happy if you don't learn-you can be the guy who babysits the old apps which you already know, and they can hire new, fresh guys for new projects. That's not so good for you though. If your project gets canceled, you can find yourself with antique knowledge and a lot of years of catching up to get to get yourself in a hire-able state.

From a company's perspective, keeping up with the pace of things is incredibly important - you don't want to be the company producing horse-buggies when Ford comes out with the Model-T. Though it can be "easier" to keep moving through turnover and new hiring, actively encouraging learning can really keep employees caring about your company and actively looking out for ways to get better. Though you might luck out on hiring the right visionary, creating and keeping a whole staff of loyal visionaries is going to be a lot easier and successful in the long run. (yes, it's practically a stereotype now, but think of google-many of their successful products emerged through side employee side projects actively fostered by the company)

On a final, personal note: as of early December, I joined the staff at Headspring, in Austin, Texas. One of the things that makes me happiest to work at this company is its commitment to growth and development of its staff, and its excellent balance between recognizing the things that have made the company a success, and recognizing that continuing that success means not resting on its laurels. Today, I will be spending the day at an all-day technical staff retreat, and I'm looking forward to it. Learning can be a lot of work, but it's really fulfilling. Off to learn now...

Posted 12-28-2009 9:01 AM by Anne Epstein
Filed under:



Thomas Weller wrote re: On Learning
on 12-29-2009 2:51 AM

I wholeheartedly agree with your arguments. They formed essentially one of the main reasons why I quit being employed altogether and became a self-employed contractor - I wanted some more freedom to decide on the things that are important to learn and the time that should be invested for it. Now I can take me that time and can then bring that to my customer's account as appropriate - and hey, it makes me as well as my customers much happier...

I think, there are two general problems - at least in my corner of the world:

* First, the people who decide upon the hire/fire issue, often are business people who have no deep insight into the problem domain. Most people think that programming is 'writing code' and overlook the fact that it is much more something like 'providing solutions based on technical knowledge'. I even saw a developer's competency and productivity being judged by the produced number of code lines!

* Second, many companies tend to look only at the short-term financial gain of a software project. So all too often, 'code-and-run' is the preferred programming style in such companies - of course it's not an official strategy, but it's intrinsically promoted by the companies' policy.

I have heard of companies, that understand the problems and know that sustainability in software development is a huge cost factor (mostly the biggest one, much bigger than immediate development), and that this means that they need a loyal team of well-trained, highly capable developers to be successful in the long run. But I've never seen one in real life yet...

Rob Reynolds wrote re: On Learning
on 12-29-2009 5:49 PM

@Thomas: I work for one of those companies. I imagine they are far and few between though.  The developers that work here on average have been here for 5+ years (to give you an idea).

@Anne: This is wonderfully written and encapsulates much of how I feel about software development. It's so unlike anything else you can do and that's why I love it.  

Congratulations on the new job! Is there a nickname for the retreat? Anything fun like Practice with Palermo or Progresssion with Palermo?

uberVU - social comments wrote Social comments and analytics for this post
on 01-02-2010 1:48 AM

This post was mentioned on Twitter by devlicious: New Blog Post On Learning: As programmers, we work in a discipline that is a bit different from that of many of the... http://bit.ly/83snWj

crork mattew wrote re: On Learning
on 03-09-2015 3:47 PM

Al3hSH I've read some good stuff here. Definitely worth bookmarking for revisiting. I wonder how much effort you put to make such a excellent informative site.

bestass pron wrote re: On Learning
on 10-14-2016 3:16 AM

oBZ9DW Muchos Gracias for your blog post. Really Great.

Add a Comment

Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)