It’s Blog Battlin’ time here at SEP again, and though the rules have changed the sentiment is the same – Get out there and write. So, here goes nothing. If you haven’t guessed from the title my topic is ‘Been There, Done That’.
Experience
It’s fairly obvious the intention behind the phrase, but how does it apply to being a professional?
Well, what I’ll say is that I haven’t been there and done that. While I’m not the newest face at my company, I certainly don’t consider myself a veteran. My three year service here has been awesome, and I feel like there’s all kinds of interesting new things for me to learn about all of the aspects of software development that I wouldn’t be able to pull out of a book (and I like to think I’ve done some good for SEP as well), but this post isn’t a retrospective on my career – it’s got to be useful for you, dear reader, and this setup will be useful later.
The Story
In my first few months here, I was fresh out of college. While I’d worked on projects for clients as an intern, was fairly confident in the technology stack we were using and had been exposed to all the concepts we were using, I hadn’t dealt with a legacy project before, and that’s what I got.
How did I get through it? How did I learn to swim in this ocean of domain knowledge and millions of lines of code? I can confidently say I have my pair partner, Tim Burch, for getting me through that first patch of being lost in the wealth of things I didn’t know. How’d we find our way out?
Being There, Doing That
While we never used these words, this is the first thing I thought of when thinking about being there and doing that.
What’s it mean? The first task I worked on here at SEP was a whopper – a fairly large task which involved a fairly lofty amount of domain knowledge for someone with no experience in the field, which I’m proud to say I now find trivial. How’d we end up with that task? Being There. It was one of those tasks that it seemed like half the team was avoiding, and so we sought it out. Why? Doing That. Someone’s got to do it and we’ll learn more from it than anyone else. And learn we did (with some help from others who knew better than we did).
Now it’s an area of code I look back on from time to time to see how far I’ve come. I think about how long that took us and how much better that code would be if I wrote it today and cringe. I know I’ve come a long ways since then, been places, done things, but jumping off the deep end and learning to swim has taught me of the hairier portions of code in our code base and let me grow as an engineer. While I haven’t always been there and done that – I’ve tried to get that breadth of experience.
So if there’s any advice I can give to a new engineer it would be just this:
Be There, Do That
Take that task no one else seems willing to take and get help when you need it. If nothing else, you’ll learn why no one else wanted it and can say you’ve done that. Get help from a coworker when you need it and everything will turn out fine. Our culture here at SEP is very open and everyone is willing to help anyone if contacted with a problem (especially a puzzle), so take advantage of that and someday you’ll be such a resource. Learn what you don’t, teach others along the way and great software/results will develop.
