I like new technologies as much as the next software engineer, but I have my limits. Maybe I'm just more conservative than some of my colleagues. Maybe I'm a Luddite. Maybe I'm too cautious. But some things drive me crazy.

The Problem(s)

It starts rather innocently. You have a new project. You have an upgrade to an existing system. Your team needs to implement a process solution to support your developers. All are perfectly legitimate projects and all can be solved by any number of platforms and systems.

However, this is where some developers get overzealous because they remember that one cool thing that they read about in the tech magazine that just came out in pre-beta that has the potential to be the perfect solution for all the ails this project seeks to salve. The only problem is that these developers have never used this platform/system before. No problem, we're all smart guys. We can teach ourselves along the way, right?

Right?

No.

I've seen this a few times now in my professional career. I thought we'd leave this behind in college as a industry, but I guess not. And I'm willing to bet that you've seen it as well where you work. And it invariably causes more problems than it solves. Sure you may end up with a solution to your original problem, but now you have a much worse problem: you have a monstrosity of a system that operates with all the stability of a tight rope walker that you and your team have to support for the next x number of years.

I did this in school, sure. I was still learning. Having an actual project presented to me was a great excuse to try to learn something new. Of course, that's the point of college; to learn. Most of the time, professors didn't care so much about the functionality of the overall project, but were looking to see if you were understanding the concepts of the lessons. Sure, your project crashes if you click that one button with a property set to null, but your sorting algorithm was spot on. Bravo. And you learned some new platform/paradigm/system along the way. Double bravo.

No More A For Effort

But businesses need things to work. That's why they hired you. Your place of employ is not in the business helping you learn the latest thing. Your place of employ is in the business of making widgits, selling widgits, or servicing someone who does one or the other. You owe it to your employer to give them the best solution to their problem that you can, which means working with that which you're familiar.

Don't fall prey to the marketing gimmicks and hype surrounding whatever the new thing happens to be. It may be great, but not if you use it to create a terrible mound of code that only barely does what it is supposed to do.

Engineer, Innovate Thyself

I'm not a crank, a luddite, or a developer particularly stuck in his ways. OK, so I might need a little more convincing about the latest and greatest than some of my peers, but I'm definitely not anti-progress.

You should absolutely continue to invest in yourself and your skill set. You should push yourself and train and be a good citizen in the universe of computer science. In fact, I feel that employers should invest in the further training of engineers.

Just don't do it on the job. First projects are learning experiences. First projects exist for you to learn what to do, and more importantly, what not to do. That means you're going to write some bad code. That is OK.

As long as you keep it to yourself.