Don’t build solutions just to pad your resume.
A few days ago I talked about not taking it with me. In that post, I waxed metaphorical on the importance of leaving a digital fingerprint and the conundrum of determining exactly what is or isn’t important with regard to a personal digital inventory.
Let’s dive back into development again.
I’ve had some interesting discussions with coworkers about a certain developer philosophy that I don’t agree with: That is, building tools and solutions to effectively pad your resume.
These developers typically take the bare-minimum approach to application development. They want to play, not provide robust enterprise solutions.
I Did It
Once upon a time, I had the exact same mentality. The current gig was temporary: I had bigger and better aspirations and I always looked toward tomorrow.
I constantly engaged in new technologies that would be interesting, dynamic and challenging: Sure, they could solve my current issue but really, I just wanted to experiment. I wanted to play.
I wanted to take the experience with these technologies on to my next gig. Not the code or the frameworks, but the experience!
What a shitty employee!
Eventually I came around: It’s critical to your personal success to build success for your employer: You may not truly enjoy the frameworks you’re using or the languages or the platforms, but learn them and learn them deeply.
You’ll discover richer engagement from your business sponsors and you’ll begin to “think bigger” by taking existing tools and platforms and expanding their currently limited functionality.
This is what you’re getting paid to do: Think.
If you’re absolutely itching to use the Next Big Thing ™, don’t do it on corporate time. Put together an open source project featuring your interests. Engage the community. If you really feel passionately about the technology and want to scratch that itch with your enterprise, start really, really small. Pilot the program on a very limited basis and make sure you have business and architect approval. Don’t do it solo.
Play off the clock.
Simple advice, but you would be surprised by the number of developers who want to incorporate untested, untried solutions into a production enterprise: It’s staggering! An in-memory key-value-store is not a drop-in replacement for DB2, Oracle or SQL Server for transaction processing.
Sorry, but it’s not.
And just because you want to engage in a new technology doesn’t mean you should.
Don’t work with technology just to take it with you. In the end, you’ll find it’s not very rewarding. I’d like to go back and deep-dive into a few of the technologies I dismissed during my more exuberant, youthful developer days in lieu of the Next Big Thing.
Doing so turned out to be a mistake. I hope you can learn from my shortsightedness.