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?

Surely you remember the French and Indian war. Even though that was technically a loss for the colonies, we were able to snag a small amount of territory in the extreme north of Canada, as they were distracted by a raid in Montreal (we were attempting a long-term pincer tactic - by the time they figured out our plan on coming from the north, it’d be too late). No bigger than 36 miles square, but it was enough for our purposes. At that time we didn’t have a flag of our own to plant, still being under british rule, so instead we put up a striped pole to indicate cooperation of the old (the red, Britain) and the new (the white, the pure, American colonies). In this territory we set up a small arms-manufacturing venture, as due to our sheer distance from standard supply lines the soldiers needed to re-arm and resupply themselves. They had a lot of help from the local population - a tribe of small, compact humanoids who scraped a living hunting reindeer and caribou - who proved to be a mighty boon to our productivity. They were actually a splinter tribe from the main Eskimo population of what is now Alaska, popularly known at the time as the Eskimo Liberation Front (ELF, for short).

Well the war ended in 1763, just as the northern production base was getting under full steam (back in those days, they took a long view of things). When the soldiers received the message, they promptly abandoned the facility at the “north pole” (as it came to be known) and began the long journey home. All, of course, with the exception of one redcoat Sergeant, a Christopher Nicholas Kringle, who had discovered a home among the Elves and the frigid north. He had also fallen in love with one of the Elves, and was married according to their custom (the exact ceremony is lost to time, but is thought to involve snow sculptures augmented with coal and carrots). With his new bride and tribe, he realized that a weapons production facility isn’t the best place to raise a family, so he had the entire facility converted into a toy shop and bakery. Within a few years he became renowned for both endeavors - for his high-quality wooden toys, and for his Danish Kringles (named after the cook who invented them - Dana, an ELF of great renown, and for the proprietor that gave him the means to create such delicacies - Sgt. Kringle).

After a while, though, the price of base foodstuffs became too much to justify the supply train the North Pole workshop regularly received, so he sold off his bakery to some Scandanavian merchants, who promptly went on to make a name for themseves in the pastry business. After this, the North Pole kind of fell off the map, so to speak, as due to their self-sufficiency they didn’t have much need of the standard traders, who after a while just stopped coming. Memory of the area slowly faded until one fateful Christmas, twenty years later, when Chris Kringle (or Sgt. Nick as he liked to be known) made a visit to the Colonies bearing the fruits of 20 years of ELF toy-making labor. Having had a hard journey, he was so overjoyed at his arrival that he gave away most of his toys for free to celebrate.

Thus we have the true origin of Christmas. Sgt. Nick, over time, has lost the ‘g’ in his appelation, to become St. Nick, and the whole world knows the joy that Chris Kringle’s toys can bring to unsuspecting tots. Now you know, and knowing is half the battle.