Take a moment to stock of where you are now. What skills do you have? How can you improve them? Every day of your career, you should be learning something, improving something, refining something. Your skill set should be undergoing constant refactoring. This can only make you more efficient. If the stuff you're learning isn't making you more efficient, discard it.
At some point, you have to have the guts to go against the grain. Just because a "best practice" works for someone else at some other company doesn't necessarily make it a "best practice" for you and your company. A "proven methodology" isn't necessarily going to be a "proven methodology" for you. Have the guts to challenge the status quo. If it's not making you more efficient, it's likely hindering you. Refactor it out.
If your team doesn't have the funds to learn some new technique, seek that knowledge personally. There is no reason that your company's inability to fund team education should hold you back. Buy books and read. Search the Internet. Read blogs and programming newsgroups. Experiment with code. Ask your peers. Never stop seeking knowledge. Never stop learning.
Take some of your old code, copy it, and then refactor the hell out of it. You'll be surprised what you can learn by simply refactoring code: more efficient ways to implement things that you did before (and will likely do again), better algorithms that work faster, use less resources, and are easier to maintain. Refactoring improves your skill set. Refactoring your own code, on your own time, is a personal competition against yourself to improve your own skill set.
You don't need to compete against anyone else. Coding cowboys, platform fanboys, methodology purists, conspiracy theorists...you shouldn't be worrying about them. You should worry about yourself. Make yourself as good as you can possibly be. Every day, ask yourself this essential question: "How can I improve myself today?" Find that way, and then do it. Set aside a little time every day to refactor your skill set.
Each day is an opportunity to make yourself a little bit better, a little more efficient than you were the day before. With each passing day, you have the opportunity to become smarter, faster, wiser, more valuable. But that means taking care to constantly revise your skill set. Have the wherewithal to discard habits and ideas that simply don't work. If you suspect you're doing something one way simply because you've always done it that way, or because that's the way everyone else does it, question it. If you can't see a tangible benefit to it, refactor it out.
Look, I'm not Gandhi or anything. But I can tell you this: I firmly believe that the key to success in this field is a personal commitment to growth. Don't trust anyone to just hand you knowledge, or to stumble across the skills you'll need. You have to actively reach out and take the skills and knowledge you need to be successful. It's an active task. It's not going to be something you just acquire through osmosis.
We all have to get to a point where we realize that we're not as efficient, not as smart, not as skilled, and nowhere near as good as we could be. There's always someone out there who's better than we are.
Our goal isn't to compete with them. Our goal is to constantly aspire to be better than we are right now, at this very moment.
3 comments:
You summed it all up so beautifully. You took it from the tip of my brain cells, something i wanted to blog about...:)
A utopian ideal if ever I saw one. Sadly it only takes one or two code jockies to bring down an entire codebase...a bit of wiring here, some globals there, sprinkle in a few dependencies; suddenly the whole thing is a train wreck - more broken windows for the pragmatists here. Even worse I can't see this trend changing as long as the corporate attitude remains the same = features first, defer maintenance to [insert event that will probably never happen].
You can learn as much as you like; unless you can find an employer that shares the same views (unlikely) then it's just dead knowledge that you'll probably never get a chance to use. In the meantime your colleagues are proving themselves, hacking their way through the codebase leaving a trail of destruction. and reaping the rewards of "increased productivity"...at your expense of course, as you'll get to clean up the mess afterwards at the cost of your own productivity.
I agree anonymous: without the corporate culture, much needed refactoring will never, ever happen. Perhaps plenty of these jokers don't truly understand the benefit of refactoring - especially to encourage business logic isolation.
Post a Comment