Evil Stick Blog

Somewhere along the line I read an article (I think it was on http://www.joelonsoftware.com, but I can’t be sure) that stated that it takes a new programmer anywhere from 6 months to a year to become fully productive and competent in a new environment. In my experience this has been pretty accurate. Mind you I’m not saying that you can expect a new programmer to sit there with his thumb up his ass for 180 days - far from it! It’s just that there’s a certain amount of sluggishness in their work as they flounder in the unfamiliar code, finding their way around much as a new citizen would wander the town without a map. I typically take 4-6 months before I feel competent enough in a system to have strong opinions about its general function. Of course I’ll have made contributions by then - with my past jobs I’ve typically had functional code released within the first two weeks (depending on the company and the release cycle) - but inexperience with the system coupled with a need to discover the lay of the land tend to put a dampening effect on my desire to rock the boat.

My new position has been more of the same, so far, but with this being my fourth company over the past 5 or so years, I’m starting to notice some patterns:

Whether or not you realize it, you are being unconsciously judged by your coworkers based on how long it takes you to pick things up.

This is not something that will necessarily be set in stone for the duration of your employment, but it can color many of your early interactions. Of course you never exactly know how you measure up, not until it’s too late to change anything, but you can gauge your progress based on interactions with coworkers. Call it the “time to guru rapport” measurement - every company has its guru programmers, the guys that have been there since the beginning and know everything there is to know. The sooner you are on a comradely level with a majority of them, the better you are doing.

A coherent, well-documented code architecture is invaluable to ramping up new programmers.

80% of your development time should be spent in design. The architecture of a system is by far the best indicator of an organization’s dedication to code quality. It’s also the first evidence that a new developer will see of the type of coding environment at your company - will that neophyte see a culture that praises re-use and judicious application of patterns in a logical manner? Or will they see five solutions to the same problem written under a looming deadline?

No matter how intuitive something looks, it is not as intuitive as you think it is.

Everyone comes from different perspectives. Coworker A may have 5 years in .NET, coworker B 6 years in LISP, and you’re all writing in FORTRAN. What passes the “5 minute” test with you may not do so for someone used to a different idiom. What’s obvious in functional programming may be anathema in procedural programming (we’ll hold the “FP makes coders better” discussion at another time), and what seems like the simplest thing in the world may be a foreign concept to the most surprising of people.

There’s no such thing as too many comments for a programmer stumbling his way through a new system.

It doesn’t matter how ridiculous your current programmers think comments are. “Preposterous!” they say, “Good code comments itself! Anyone who can’t grasp this is a moron!” The question we need to ask ourselves is that if our organization is spending $50 an hour on a programmer, and one comment that takes thirty seconds to write can reduce their ramp-up time by an hour, how can you not write comments? I have yet to hear a decent argument that convinced me that there is any such thing as too many comments in the code - at the absolute worst, you lose nothing by having them (no matter how unnecessary they seem).

You can tell about a company’s commitment to code by the discussions that take place around its architecture.

If you kick off projects without an architecture meeting, you’re doing things wrong. It may seem like too corporate a model for your company, but keeping the knowledge of the overall program structure in the head of two or three people leads only to labor duplication. Conversely, multiple discussions for a simple service may point to a process that is too top-heavy.

Process is good if it is well thought-out, but process for the sake of process is overkill.

Having a clear sequence of steps from conception to realization is invaluable. On the flip side, though, one page of documentation per line of code is excessive. Similar to the previous item, balance is key in this area.

One can tell if a development shop is a firehouse with the answer to one simple question

“Was my workstation ready to go when I got to my desk?” An oversight such as this says more about the company than any two of these points combined. If your infrastructure group is not on the ball enough to have desks configured for new employees, or if there is not some process built up around onboarding, you’re sending a message that you like to fly by the seat of the pants and get things done quickly as opposed to getting things done well.

Firehouse development, while edge-of-your-seat cool, doesn’t lead to good code.

Every office has a hero - that guy who’s in until 4 AM, on his second pot of coffee working towards a release. Does your environment encourage this style of development? Many people have pointed out the negative correlation between hours worked per week and code quality, but organizations still persist in encouraging long hours in development with shortened schedules. The only time a programmer should be pulling 12 hour days is if something is metaphorically (or sometimes literally, depending on your job description) on fire. Any other time and it’s a failure of management, process, or both.

In any case, these are the things I tend to notice. What do you people look for in your first couple weeks on the job?