Programmer Competency Matrix – Education and Experience

By On 2012/12/21 · Leave a Comment · In Development, Personal, Reflection

I’m good at some things. I’m bad at some things.

I was looking through the *nix spellbook and – quite by accident – stumbled across the Programmer Competency Matrix. Again. I’ve seen it before on Hacker News (here, here, here,

I’m good at some things. I’m bad at some things.

I was looking through the *nix spellbook and – quite by accident – stumbled across the Programmer Competency Matrix. Again. I’ve seen it before on Hacker News (here, here, here, here, here and here, too), but today I actually took the time to read through the matrix and mentally quantify my abilities.

Because I like applying arbitrary opinions to my skill set and abilities.

Objectively, of course.

For a developer not formally educated in Computer Science, I did pretty okay. This comes largely, I suspect, from my dedication to constant learning and my passion for technology. And it’s not that this matrix identifies every single strength or weakness of a developer, but it’s an interesting identification mechanism nonetheless.

Recognizing where we’re weak will help us identify areas for improvement.

For example, according to the matrix my weakest area centers around algorithms. As an illustration, I understand the concepts behind Dynamic Programming, but I don’t yet possess the education to formalize the method. A degree is most assuredly in my future, and I’m excited to learn the math behind the science (among other things).

Early on, I wanted to dive right in to the experience of my chosen profession, gaining education while I worked. Dedicating myself to learning various technologies has always been an important aspect of my personality, but the decision to forego education for experience had far-reaching consequences. It was the right decision for me at the time, but I don’t necessarily recommend this path to everyone.

As John Sonmez notes, the more we know, the less we know. I could have used this wisdom fifteen years ago!

Indeed, after working in the industry for close to fifteen years and looking back on what I knew, what I thought I knew and what I learned I didn’t know, I can unabashedly state that – to be a truly competent programmer – a formal education isn’t strictly necessary, but it would be really, really helpful.

So here’s my wisdom: Irrespective of everything else, the one class I’d recommend every new developer take early in their career would be an Introduction to Algorithms course. Maybe even compiler theory. Even before looking at the matrix, I could have identified algorithms as the single biggest source of my programming weakness. Practical application of algorithms in my every day career has solidified my ability to use the appropriate algorithm for a given task, but it came at the cost: I had to work harder, not smarter in some cases. I had to read more books, more web pages than I may have needed otherwise.

Basically, I had to learn the hard way!

So don’t do it my way. Don’t learn the hard way. Education and experience go hand in hand, but make sure you do it in the right order.

And never be afraid to go back and learn!

Some people have 10 years of experience. Others have 1 year of experience 10 times.

Tagged with: • • • • • • • • • • • • • • • • • • • • • • • • • • •
 

Your Code Is The Only Meaningful Project Documentation

By On 2012/12/19 · 4 Comments · In Development

Have you a valediction, boyo?

– James Cromwell as Captain Dudley Smith, L.A. Confidential, 1997

I recently had the most interesting chat about documentation on the way to the local coffee shop.

My department has been having a lot of discussion around documentation. We’ve been working through software design specifications, functional design specifications, business [...]

Have you a valediction, boyo?

- James Cromwell as Captain Dudley Smith, L.A. Confidential, 1997

I recently had the most interesting chat about documentation on the way to the local coffee shop.

My department has been having a lot of discussion around documentation. We’ve been working through software design specifications, functional design specifications, business requirements documentation… all for a single release for a single project, and we have many releases and many projects. It’s a lot of writing and a lot of work and it takes a lot of time. Apart from the specifications, we also have process documentation, corporate mandates and email and wikis and SharePoints and intranets and thousands of Word documents scattered all over the network, not to mention all of the undocumented tribal knowledge that’s scattered throughout the entire organization.

It’s really kind of a mess.

We were talking about documentation in general, and one of the developers mentioned that the functional design specification needed to be updated every sprint in order to give QA the required documentation for testing, but that the time required for updating documentation was far too excessive, that too many details were being captured.

That it wasn’t sustainable. The developers were concerned (and rightly so) that documentation would stagnate as code matured. What good is stagnant documentation? Outdated specifications are rarely useful, or are only useful for their historical insight.

The whole conversation sent up a red flag. We should be generating our documentation, not writing our documentation! The only valid documentation is the code itself!

The fact that we were so concerned about the creation, publication and maintenance of functional specifications indicated a fundamental flaw with the importance we were placing on certain aspects of the SDLC. Yes, we need documentation. No, we don’t need to be writing documentation by hand for every release. Why? It’s impossible to keep hand-written documentation in sync with an amorphous project, just like it’s impossible to code within a team without revision control. Fine, not impossible, but it’s extremely prone to error.

The actual code is the only meaningful documentation in the entire project. TrackAbout had it right: A backlog involved an initial breakdown period which – more often than not – required the developer to read some code! We occasionally referenced a wiki, or interrogated a team member for tribal knowledge… but ultimately, the code itself documented the process.

I’ve already mentioned that I consider the ability to read code one of the most important qualities of a developer. In an agile environment, QA members and developers should be engaged the moment a backlog enters some workable state. Developers should read the actual code – the only documentation that matters – and communicate changes to the QA team.

Ever notice that code comments within a project drift from the actual code they’re commenting? I’ve met very few developers with the discipline to immediately reflect code changes in comments. That being the case, how is your organization ever going to keep a completely separate document like a functional design specification up-to-date with such a fast moving target?

It’s simply not possible. I’ll say it once more: The only meaningful documentation is the code itself. Find ways to automate the generation of your documentation, and consider your codebase the absolute central authority of your codified business processes.

Tagged with: • • • • • • • • • • • • • • • • • • • • •
 

Finding Quality Developers is No Easy Task

By On 2012/12/14 · Leave a Comment · In Development

This post took days to write. I didn’t expect it to take quite so long, but I think the fact that it took so long hits right at the core of hiring developers: It’s hard.

It’s no secret that finding great developers is hard [0, 1, .., [...]

This post took days to write. I didn’t expect it to take quite so long, but I think the fact that it took so long hits right at the core of hiring developers: It’s hard.

It’s no secret that finding great developers is hard [0, 1, .., n]. Innumerable methods exists for weeding out the bad candidates from the good, and everyone has an opinion about what works and what doesn’t, including me.

Hiring developers is an attempt to mesh the science of programming with creative problem solving and a whole lot of wisdom. It’s an attempt to combine the technical needs of your project with the candidate’s experience, desires and humanity. Finally, it’s a coordination of all other internal and external factors including resource management, benefits and pay, work environment, team personalities, etc.

What follows is an outline of my process for finding great developers.

Continue reading »

Tagged with: • • • • • • • • • • • • • • • • •
 

From Avid Gamer to Architect

By On 2012/12/10 · Leave a Comment · In Development, Personal, Reflection

A Love Letter to Games

I’ve been a life-long gamer.

I began my gaming career as a child, when my parents acquired an Atari 2600 in the early 1980s. Shortly after their divorce, we acquired an Intellivision, which I now consider the single greatest console of all time. The Intellivision captivated my interest in [...]

A Love Letter to Games

I’ve been a life-long gamer.

I began my gaming career as a child, when my parents acquired an Atari 2600 in the early 1980s. Shortly after their divorce, we acquired an Intellivision, which I now consider the single greatest console of all time. The Intellivision captivated my interest in gaming until the mid 1980s, when I was gifted an NES around winter of 1986. I instantly fell in love with Mario, Contra and Punch Out on a little 13″ color television that I had in my bedroom: I’d sit on the edge of my bed, mere inches away from the TV, fully absorbed in squishing goombas.

It was a great time to be 8.

Computer-based gaming caught my attention around 1987 when my mother purchased an Apple IIc. I was hooked on public domain games that she would bring home from school. For the first time, I wanted to know how these games were made, and so I began reading up on programming Applesoft BASIC. Later, a kids magazine (and I can no longer remember the name of the magazine) began publishing code snippets for Applesoft BASIC. This was programming gold, and I remember the frustration of transcribing line-by-line the code that let you inflate a balloon by repeatedly tapping the space bar. If only a single character was incorrect, it wouldn’t work. A valuable lesson, for sure.

I moved to PC gaming in the late 1980s. I became hooked on Sierra adventure games in 1989 (and I still posses boxed copies of the Colonel’s Bequest and Conquest of Camelot). 1992 rolled around and I became obsessed on Wolfenstein 3D, followed shortly thereafter by Doom in 1993. I have fond recollections of downloading Doom from a BBS and subsequently sending it to my friend over ZMODEM on a 300 baud connection.

It took all night.

Meanwhile, I had picked up a fully-licensed copy of Borland C++ and began the slow, agonizing process of self-learning the low-level details of the hardware and software. At the time, I had no idea what I was doing.

Between 1991 and possibly 1995, I had access to a shell-based internet connection provided by Nova Southeastern University. I ended up writing graphical “games” in no time, following tutorials I found online on something called the “world wide web” over an application called Lynx. This stuff was awesome! And few of my friends understood.

I wanted to make games like Doom.

Sometime around 1995, during a high school programming class, I wrote my first complete computer game in Pascal. It was a Space Invaders-style ASCII-based shooter, complete with powerups. The code was terrible. I wish I still had it.

PC games held my attention for over a decade. I didn’t return to console gaming until 2005 or so, when I purchased a (possibly used) Xbox. Then the Wii, then the Xbox 360.

By the mid-2000s, I was deep into a programming career. I had cut my teeth professionally on PHP, Visual Basic, and C#. Somehow, I ended up becoming an applications developer, not a game developer. But that’s okay, it’s what I wanted, really: Stories from the trenches of game development were always unpleasant, with tough deadlines and missed releases and late night and weekends and stress. It would have been fun, I think.

Looking back at what I’ve accomplished in my life so far, it’s really the classics that helped nudged my career and shape by interests. Luminaries like Shigeru Miyamoto, Roberta Williams, Christy Marx, John Carmack and Will Wright became my heroes.

Indeed, my software career began in the early 1980s, with those first awkward button mashes on the Atari 2600, followed by a fascination with gamepad inserts on the Intellivision, followed by the simple elegance of Super Mario Bros.

Pitfall, Astrosmash, BurgerTime, Lock ‘N Chase, and Armor Battle all paved the way for my lifelong fascination with computing. Without Punch Out, the Legend of Zelda, Super Mario Bros. or Contra, I doubt my interests in PC games would have blossomed.

Without Quest for Glory or Space Quest, Conquest of Camelot or the Colonels Bequest, I may never have had an interest in Wolfenstein 3D or Doom. I would not have had the desire to learn the low-level details of the machine. I would not have picked up Borland C++.

These weren’t just games.

They were gateways.

<3

Tagged with: • • • • • • • • • • • • • • • • • • • • • • • • • • • •
 

It’s Bugs All The Way Down

By On 2012/12/07 · Leave a Comment · In Development, Gripes, Personal, Reflection

Wherein I learn that some developers don’t know how to play well with others and get upset about it.

First, apologies to Stephen Hawking and Dan Rosenberg for the title.

Second, some back story…

Years ago, I was responsible for a web-based application that consumed a small XML payload, performed some [...]

Wherein I learn that some developers don’t know how to play well with others and get upset about it.

First, apologies to Stephen Hawking and Dan Rosenberg for the title.

Second, some back story…

Years ago, I was responsible for a web-based application that consumed a small XML payload, performed some calculations and spit out a small XML answer.

The application consumed and produced very precise coefficients, such as 0.000000000000007.

As the application matured and time progressed, we eventually had to split the calculation model from the validation model in order to handle change-management procedures. Additionally, we were slowly aligning our core platform with a future-state vision, little-by-little moving chucks of code from Platform A to Platform B.

In order to prevent a platform war and to Maintain Focus, I’m going to simply state that I developed on Platform A, while another team within my organization developed on Platform B.

To validate code changes in Dev, we’d run tens of thousands of rows of test data through both the validation model and the calculation model.

Test data was always constant.

Production data was variable.

Uh oh.

Continue reading »

Tagged with: • • • • • • • • • • • • • • • • • • • • • • • • •