When I was a young junior software engineer, I thought I knew it all. I was brash, cocky, independent … I didn’t like collaborating with others and I thought being technical was the only thing that mattered.
Fast forward to today and I’ve realized just how naive and inexperienced I was. I suppose that’s a universal human truism … the follies of youth eventually tempered by experience and hard life lessons.
I’ve gathered some thoughts about my personal take on the differences between junior and senior software engineers.
IT’S NOT JUST ABOUT CODING
If you’re a software engineer, you code. You spend all day typing on a computer, translating a set of business requirements into computer code that the machine can understand…ultimately, a long list of 1s and 0s.
Make no mistake, coding IS important. At the end of the day, a software engineer needs to produce WORKING code.
That said, it’s not ONLY about coding.
It actually took me the longest time to realize this. After all, coders CODE. Right?
You can write the most elegant code in the world, using the most whiz bang technology stacks, with more design patterns than you know what to do with.
But if it doesn’t actually SOLVE the customer’s problem, is it even worth a damn?
At least when I was a young software engineer, I thought I knew what was best for the customer. I had cursory conversations with the customer to get a BASIC idea of what they were looking for.
Emphasis on the word “BASIC”.
I’d furiously start coding like a madman, going off a rudimentary customer spec, enjoying the act of pure coding. As a matter of fact, I still do, to this day.
But when I would turn in my final deliverable, my customer would end up telling me it wasn’t what he was looking for. At the time, I blamed the customer for not providing enough information.
Of course, that was the cocky, brash version of me. It wasn’t the customer at fault.
It was ME.
I should have the been one that should have paid more attention to what the customer’s requirements were. An initial customer meeting won’t cut it.
A programmer isn’t just a programmer. A programmer needs to ANALYZE. I even had that word in my official job title, “Programmer Analyst”.
It actually should read “Analyst Programmer”.
One of the differences between a junior and senior programmer is the senior programmer understands truly understanding the business requirements is key to successful software development.
THE IMPORTANCE OF SOFT SKILLS
I’ve written about this before, but I can’t overemphasize the importance of soft skills. Think of soft skills as the techie version of a doctor’s “bedside manner”.
Soft skills cover a wide range of things, but they all revolve around skills you need BEYOND the technical skills … working well with others, collaborating with coworkers, reading and writing skills, communication skills, diplomacy skills.
It may seem strange to think soft skills are important in a technical profession such as software development, but it becomes clear why they’re important when you end up working with software engineers who DON’T possess soft skills.
Not always, but often, they can harm team morale. They stay huddled in their cubicle or office, unwilling to help out other teammates. They’re perfectly content, doing their own thing, in a vacuum.
Even worse, if they don’t possess effective communication and diplomatic skills, they can often cause friction with the customers.
The senior programmer realizes the value of soft skills.
LOOKING AT THE BIGGER PICTURE
When you’re down in the trenches, busy implementing your project’s tasks, it’s easy to lose the forest for the trees.
What I mean by this is looking above and beyond the scope of your project implementation.
For instance, could your project be useful to other teams? Oftentimes, we as programmers, can get so focused on our own tasks, we don’t realize nothing exists in a vacuum.
Understanding the overall topology and technical architecture of your company’s infrastructure can be key to making big and positive changes.
If you work at a more established company with lots of legacy systems, the only way you can improve the architecture is by analyzing and understanding how all the current sub-components of the architecture work together.
Senior programmers take the time and effort to analyze and understand the bigger picture.
HOW TO STEP UP
The junior programmer is satisfied with accomplishing her own immediate tasks and projects.
The senior programmer looks for opportunities for additional responsibility.
Assuming you want to get noticed and move up the corporate ladder (or government ladder, for that matter), there are usually plenty of opportunities around to help you get noticed.
Can you pitch in when a critical production system goes down? If you’re on an agile team, is there an opportunity for you to volunteer for the scrum master position?
CONCLUSION
As much as I wish there was some magic elixir that I could have taken, when I was younger, to instantly turn from a junior programmer to a senior programmer, it’s better taking the journey through the normal course of time.
Head knowledge, at least for me, wouldn’t have cut it. That old saying, “live and learn”, seems especially applicable here … it took a lot of “school of hard knocks” lessons (and being held back for a year or two at that school), before my noggin finally started taking in the nuggets of information we just covered.
My hard evidence came through direct and personal observation of coworkers over the years.
The coworkers who possessed the soft skills, looked for ways to improve existing business processes and increase revenue, and volunteered to take on more responsibilities, got recognized for their efforts.
The coworkers who were content coding, not looking for ways to step up, inevitably stayed still. Whether this was out of choice or not, was not for me to stay.
But it became clear to me coding skills are only the FIRST building block on the path from junior to senior programmer.
