Now you know all about
ints and how
I was once in your shoes. But I soon learned that there’s a big difference between the skills you need to build working software, and the skills you need to build working software that
- is well factored
- meets today’s requirements while being adaptable for tomorrow’s
- is structured so others can understand and make use of your code
- is self-documenting
- is tested well (as opposed to merely being tested)
- has sound logic and reasoning behind it
- is idiomatic in the language
- is smart without being clever
With a bit of experience under my belt I can pick up the basics of a language or framework in a matter of hours, or perhaps days. But it will take me many times longer (months/years/never) to write anything “good” in that language. It’s the same with software engineering in general. And that’s what I want to talk about: how do you go from competent to “good”?
What this entails would fill several books, never mind one quick blog post. My aim isn’t to give you “7 Shocking Things That’ll Make You A Rockstar Software Engineer Overnight”. Instead I want to make you aware of some of the places your amazing journey will take you on.
Problem is, you don’t yet know what things you don’t know. To start finding out, look around you at your new colleagues and try to deconstruct why they’re so good at their job. I assure you, it’s not because they know every esoteric way to interrogate arrays in Ruby.
It’s likely that they’re able to think about problems in a more abstract way than you are. It’s also likely that with experience they’ve gotten a hang for not just how to test something, but what to test in the first place. And, they’re a whiz at debugging not because they’re software gods, but because they understand the why and how of the code.
Talk to these people. Pair with them. Read their Pull Requests. ASK QUESTIONS. Find out if any of the more senior engineers are interested in mentoring. Or even just find one who’s patient enough to feed your inquisitiveness.
Ask them who their mentors are? Who do they learn from? “I’d love to hear your opinions on this method I’m trying to refactor, do you have a few minutes for me?”. Senior engineers love sharing their opinions!
TL;DR there’s more to being a software engineer than knowing how to code. It’s knowing what to code, and why. It’s about knowing how to talk to stakeholders. It’s about learning how to apply your considerable skills to solving their problems. (Ideally the problems they have, not the problems they think they have - but more on that in a later post).
I’m sharing all this because I’m excited for you. To me, this is the most rewarding part of being a software engineer. Learning how to be a better craftsperson, a better communicator, a more effective problem solver, and a better salesperson.
I’ve been doing professional software development for a handful of years now and I was lucky to come to these realizations early on. I still have so much to learn but I have been very lucky to work with some really top notch engineers who were also great and patient teachers. I’ve always tried to join teams that are made up of better engineers than me. I think that this gets more important with seniority, not less. Through a little luck, and knowing what to ask, I’ve continued to find great and patient teachers.
* cough * we’re hiring * cough *
Most of all, I’m telling you this so that your eyes are opened to the potential in front of you. In life, we generally don’t know what we don’t know. Hopefully now you have some idea of the road ahead.
Ok ok fine! Here’s your “7 Shocking Things That’ll Make You A Rockstar Software Engineer Overnight” list:
- Never be the smartest person in the room.
- Never be ashamed to say “I don’t know”. Great things happen when you ask for help.
- Be confident in what you know, but never believe that you know it all.
- Never stop learning.
- Try to teach what you know.
- Always ask “why”, then follow up the answer with another “why”.
- Have strong opinions, weakly held.