Advice for young developers

Author's note: This one from the archives was written back in March 2008. This is something I've seen a couple of more times since then. A new developer, usually fairly young, comes in and wants to rewrite everything using whatever technology or method he's most familiar with. It seems to be not so much a problem with learning the new codebase as it is developer hubris. "My chosen way is obviously the right way, so clearly that's how we should be doing things." The people who do this don't seem to stop and think about whether their chosen method or tool might not be the best choice in the current situation, or whether implementing it might just be more trouble than it's worth. Perhaps it's just a lack of experience - they haven't had enough rewrites go south to realize that this isn't always a good idea. Either way, enjoy the rant!

Here's a little tid-bit for you young, aspiring developers out there: When you start a new job, it's usually a good idea to wait until your second week before you suggest rewriting the entire existing codebase.

I say this because we recently hired a new developer. He's obviously very bright and knows his stuff, but his first suggestion, on his first day, was that we should rewrite our entire codebase from a custom PHP framework to Symfony. After all, it would probably only take a couple of months.

Now, I don't know much about Symfony, but I have nothing against against it. And, in all fairness, our current framework is a bit of a mess. So I'm not dead-set against the very notion of switching. However, the current framework has been tailored to our needs and it is perfectly adequate. I'm sure that Symfony is very nice, but it's not immediately obvious what compelling advantages it would offer. After all, we already have an application framework that does what we need and which all three of the established developers are very familiar with. Given that we already have a full plate as far as projects go (hence hiring a new developer), it's hard to imagine how you could make a business case for spending 2 or 3 months learning Symfony and converting the whole site to use it. And if the new guy things that we're going to convert in parallel with adding features to the existing codebase (which he actually mentioned), he's out of his mind.

The thing that really bothers me about this, though, is that the new guy suggested this on his very first day. As far as I know, he hasn't even written a line of code yet and he's already writing up the business case for switching to Symfony. Even though he's barely looked at our codebase and so couldn't possibly have any idea what kind of effort this would entail.

So, to all the developers out there, next time you start a job on an established development team, at least take the time to learn what technology they're using and why before you suggest replacing it. Do a project or two with the current stack. Talk to the other developers about the history of the codebase and the company culture. Pushing to replace major technologies before you've even written a single line of code just makes you look like a tool.

You can reply to this entry by leaving a comment below. This entry accepts Pingbacks from other blogs. You can follow comments on this entry by subscribing to the RSS feed.

Add your comments #

A comment body is required. No HTML code allowed. URLs starting with http:// or ftp:// will be automatically converted to hyperlinks.