From Good to Great: Five Essential Developer Skills to Master

In my almost three years working at Gorilla Logic, I’ve had the opportunity to hold several different roles (senior developer, technical leader, and technical screener) for a multitude of diverse projects. This experience has helped shape my mindset as a developer and opened my eyes to a specific set of developer skills that I believe to be vital to the success of any developer. 

In this blog post, I am going to share the top five golden rules that, when followed, may help you to improve your code quality, collaboration with your team, and communication with your clients.

Whether you’re a more junior- or senior-level developer, the sooner you realize the importance of these developer skills, the better! Let’s dive in, shall we?

Rule #1: Channel your inner QA and great results will follow

As developers, we need to start thinking a bit more like QA testers do. It’s no secret that the majority of us consciously (or subconsciously) only test the happy path, usually because we need to deliver fast. 

We tend to think that we are saving time by doing quick testing before promoting our code. However, I came to the conclusion that this way of thinking is actually counterproductive, as bugs were found and I had to fix them, re-deploy the code, and much more. The time that I had initially intended to put towards other tasks was actually time that I had to use to correct mistakes I had missed by going too fast.

One thing I started doing during a previous project was being more involved with the QA team by looking at their test cases and shadowing them in order to train my brain to think more about edge cases, improve my test coverage, and even test scenarios that unit tests would likely overlook. 

By doing this, not only was the quality of my code improved but so too was our team delivery time. 

A win-win situation, don’t you think?

Rule 2: Don’t be a blind copycat. Analyze and ask yourself questions

There’s no denying that the internet can be a lifesaver when it comes to finding a solution to a problem that made us scratch our heads for hours. 

It can be tempting to copy/paste a solution from a blog post, compile your code, and, if it works, your job is done; everybody is happy.

But what happens when a bug arises in production? 

Not every plug-and-play solution will work correctly in every codebase (even if it looks like it would on the surface). Instead, we need to understand how something would work in the grand scheme of things, how it would play along with the rest of the code, and whether or not it would meet all of your application needs.

Understanding the code before copying it, questioning the solution, researching unfamiliar code, and reading the comments from that particular solution are developer skills that can ultimately make a huge difference.

Rule 3: Avoid refactor obsession

Who hasn’t worked with legacy code for which the “Marie Kondo” technique could do wonders for? Oftentimes, because we need to deliver fast, the first solution that comes to our minds isn’t always the prettiest or fanciest. 

I’m pretty sure we all have experienced this at some point in our careers, and maybe you’re waiting for the perfect opportunity to redeem yourself.

Even though you have the best intentions, it may be best to think twice before heading down that path. Refactoring can be a double-edged sword, and you need to be extra careful when refactoring functionality that is already in production.

Here are three musts to consider when it comes to refactoring: 

1. Identify dependent workflows
2. Validate that all the parts involved are unit tested
3. Always create a new version of the code and never overwrite existing code if it’s already in production

Rule 4: Simpler is always better

It’s not a secret that applying principles and patterns makes the code cleaner, more maintainable, and extensible, but what if trying to apply a particular pattern to your code could actually do the exact opposite? 

Forcing a solution to fit a particular pattern is often not the way to go, as your code might end up being difficult to understand and/or maintain.

Solutions are best when kept simple; patterns should come naturally. Remember that each project is an entirely new ecosystem. What once worked in the past might not work in the present.

Rule 5: Become a polymorphic communicator

As developers, we tend to talk only in technical terms, which is fine if you’re in a technical discussion with your colleagues. But what about when you have to explain your solution to a non-technical audience? At this point, challenges may arise. 

Mastering the art of adapting your message to different audiences is not a trivial task and often requires practice. Recently, I discovered something called the Feynman Technique, which basically is a set of steps you must follow in order to learn a particular subject, wherein the last step is about transmitting the message in layman’s terms.

I strongly believe that we can apply this technique when having conversations with people at work. It can be easily achieved by using real-life examples, analogies, or even by adapting your vocabulary to use words the audience is more familiar with.

In the end, the goal here is to deliver a clear message and engage the audience.

I hope this post helps you continue the exciting journey of growing your developer skills and becoming a better developer each day. I know it’s not always easy to adhere to these rules but, as with all things in life, the more you practice, the better you become.