Darl: The Data Entry Developer
time to read 3 min | 506 words

Jeremy Millier is brining up a pain point to me here. I see quite a lot of people who treat developers as data entry guys for the Architect perfect design. It gets to the point where people argue with me (vehemently) that this or that features should abosuletly be removed, because it is too complex for Darl, their developer stero-type.

Darl is a nice guy, he got into the business a few months to a year ago, although I have seen Darls with quite a few years of experiance under their belts. He may have a CS degree, but that doesn't mean he can pass the FizzBuzz test. Darl best friend is the designer, and he is completely lost without it. He may be completely lost with the designer. Design and architecture are mystic concepts to Darl, they are handed from above, and are to followed religiously. Darl doesn't understand the business problems he is working on, nor can he understand the technology he uses. He was told: "Call this method with this parameter, and don't forget to use Try-Catch".

Darl should aspire to be a Mort, but he doesn't even know that such a creature exists. The last time that Darl has opened a technical book/article was cramming before an exam. He gets all the required information from the team lead or the architect, in the five minutes they have going back from lunch.

It doesn't take much to move away from the Darl arch-type. But is seems to me that this is something that a lot of business do not want or not willing to change. On the contrary, they would like to get more of them, and then they get tools that have "No Code Required" stamp on them, and expect to get results.

I have a junior developer working with me at the moment, my biggest pain point with him? He isn't lazy enough. It is something that I am working at right now, making sure that he will understand that Lazy is Good(TM).

Yesterday I spent two hours pairing with another developer, going over everything that we needed to setup the current project. This meant that I had went over the build process target by target, explaining its use, and showing how to deploy, we created a new project and setup everything from a database to the configuration file so we could get build the [ActiveRecord] class and going over the various database inheritance implementation scenarios and what the trade-offs.

The easiest way to work with good developers is to invest in them and help them grow.

Tweet Share Share 3 comments
Tags: