How I Outperformed More Experienced Developers as a Junior Developer (and How You Can Too)

Zack Minott

How you think and approach programming problems is a better indicator of a skilled programmer than what “experience” provides

Photo by Morning Brew on Unsplash.

“I have hired far more experienced developers than you, and still you have accomplished more at a faster pace in the amount of time you’ve been here than anyone else I’ve hired.” — My CEO to me

It doesn’t matter if you have 20 years of hands-on work experience under your belt or you’re just entering the tech industry with no internships and nothing more than a college degree.

The latter was and still is the position I am in.

The amount of wisdom that you’ve accumulated over the years doesn’t matter when it comes down to efficiency, productivity, and raw programming talent, so stop using your seniority as a way to define how intelligent and reputable you are as a developer. That simply isn’t enough.

I came into the Salesforce developer consulting industry with basically no knowledge of how to implement solutions and integrations for the platform… at all.

Now, I’m setting company records, I’m being recognized as one of the most promising developers in the industry, I’m being contacted by recruiters and business owners on a very regular basis, I’m satisfying my clients and architecting solutions almost entirely on my own, and I’ve not once failed to deliver. The caveat: I recognize that I know absolutely nothing.

All it took was three months to accelerate beyond my peers after breaking down the doors into the industry. Those preliminary three months were almost entirely spent relentlessly training and learning.

  • I’m no genius or prodigy.
  • I’m not a gifted developer.
  • I don’t know everything about programming.
  • I can’t intuit a solution in a split second.
  • I still have much more to learn.

Given these traits, I’ll tell you exactly what it was that allowed me to distinguish myself as a developer and ultimately plow through programming tasks and projects at alarming rates — rates that other more experienced developers couldn’t keep up with.

I Made It A Priority to Establish Best Coding Practices Early on

Looking back at the entire time I spent studying for my computer science degree, I would have considered myself a subpar programmer who barely understood how to tackle real-world programming problems.

I struggled immensely trying to solve programming projects that were assigned to me — projects that I could now easily finish in a night. It was very hard for me to understand the logic that was required of me to implement a solution or to even understand the object-oriented principles that I needed to apply in order to accomplish a task.

If Google didn’t exist, I’m sure I wouldn’t have gotten very far and would have pursued a philosophy or business degree instead.

But there was a moment when I started seeing my skills begin to shift. Once I started to look at the way programming languages actually work, the way specific design principles are used and implemented, and the things to avoid along with the best practices to adopt when designing code, I started to see a shift in the way I approach problems.

I started designing and thinking about my solutions surrounded by the principles I learned, and it allowed me to formulate my thoughts in a more intentional and directed way.

Perhaps the most life-changing book that I’ve read in a programming sense that reinforced and embedded these principles deep inside my psyche was Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.

The way I named my functions, the way I simplified my code, and the way I structured my classes did me great justice in the way I developed. It allowed me to really take a step back and think about what I was writing and how I organized that code — keeping tabs on whether what I wrote made sense logically and if it was readable.

What I learned when I focused on readability, design, and simplicity more than anything in tackling a requirement is that it more often than not resulted in the production of code that was fast, future-proofed, reusable, and easily extendable.

That being said, as a programmer, you should make yourself aware of the best coding practices, the limits of the language or framework that you are using, SOLID principles, design patterns, and agile practices.

It’s not enough to write code that works but instead to write code that works, is easily understandable, modular, and can withstand the test of time. This requires a bit more thinking, but down the line, it’ll allow you to constantly build on top of and generate more value for the applications that you create.

I Saw Programming as Nothing More Than a Tool to Craft My Art

Programming is much too often seen as a mythological technology in and of itself — almost like a foreign language that is difficult to translate and only the well-trained can write elegantly with.

That couldn’t be further from the truth, and it would benefit you to detach yourself from programming, rewire your outlook on it, and start perceiving it as something more than just a technical craft.

I view code in the same way a painter views their brush, a mechanic views their wrench, or a carpenter views their hammer.

Code is a tool that you use to propel yourself to your ultimate goal and your architected solution.

What distinguishes a great artist from the crowd is their ability to use the tools that they have in unity with their mind and imagination. That artist starts in the same position as an artist with the same exact tools — a blank canvas, paint, and a paintbrush.

Remember that when you’re staring blankly at your empty IDE trying to write that first line of code.

What matters is how you use that tool, and what worked for me was not to simply understand the syntax and theoretical terminology of code but to do things that would allow me constantly refine my skills on the usage of that tool.

Thinking about what I could do, what I could accomplish, what routes I should take, and what I was trying to achieve is exactly what would inspire the way I would use code as a tool to tiptoe my way to the ultimate solution.

At that point, the only limit that I have is my own mind and my personal ability to figure out different ways code can be used to tackle and solve the particular solution that I have.

That’s why I don’t waste my time attempting to learn all the syntax of a language and endlessly reading documentation trying to memorize everything that a language or framework has to offer. What I found the most value in was understanding the different ways I could architect and design my code based on tested principles, design rules, and theory.

I May Not Know Everything, but I Can Learn Anything

This is another reason why I don’t waste my time scouring and trying to memorize documentation, watching comprehensive how-tos in learning a programming language, and spending endless amounts of time studying.

If there is any superpower that I do have, it’s the ability to learn fast and immediately apply what I learn to what I’m doing.

Yes, I do fail. A ton.

But failing regularly is part of the way that I learn and reinforce my learning to the point where I have a complete understanding of a topic.

I often don’t need to prime my brain with a bunch of technical and preliminary information because I drive my programming through the amount of research that I’m able to do and the experience I’ve accumulated dealing with similar problems and failures in the past.

I learn in accordance with what my requirements are. That way, I’m not wasting a bunch of my time filling my head with specific details and concrete ways to do things. Every task that you tackle is completely subjective to what you are trying to achieve.

If anything, I abuse the Google search engine with questions directed towards the problem that I’m immediately trying to solve. If I can’t find everything I need through a Google search, I barrage my CEO with questions trying to solve and work through some of the more complicated topics. I then take what I find and tweak that gained information in customized ways to fit my current needs.

I don’t give up because I don’t know a solution. Instead, I do everything in my power to figure out what I know to be possible.

This mode of thought and approach goes hand in hand with plugging that code into specific design principles that I understand and channeling that code as a tool to leverage the solution I’m trying to reach.

I don’t know everything and I’m by no means trying to know everything. Part of the excitement of programming is the journey of constantly learning and creative thinking, and when you try to learn the definitive way to do a certain thing and you only see that as the singular way or approach, I can see how that can drastically impede your imagination and potential as a programmer.

Final Takeaway

I’m a true believer that anybody — regardless of skill, talent, or experience — is capable of being recognized as a uniquely great programmer.

All it really takes is a shift in mindset and approach to the way that you build out your solutions and staying completely humble throughout your entire career.

People have built entire companies and apps without having any prior programming knowledge.

Your humility will allow you to adopt the mindset of a beginner with the thirst and drive to be curious and constantly learn and adapt to the rapidly changing environment that programming has to offer.

As programmers, we signed our lives over to embodying that of the constant learner and breaking down the barriers of what was previously thought to be impossible.

If you fail to embody that notion, then I’m afraid you’re running the risk of never being able to upgrade your skillset beyond that of where you are currently at.

Just remember: Anyone is capable of being great — whether you’ve been in the game for 20 years or you are just starting.

Comments / 0

Published by

Cloud Developer | Philosopher | Avid Reader | Intellectual Explorer and Lifelong Learner | Athlete | Top Writer @Medium

Santa Ana, CA

More from Zack Minott

Comments / 0