Adaptability in Software Development

Being a developer in a modern world is filled with challenges. Keeping up with such a varied and rapidly growing industry can be difficult. In the end, excelling as a developer relies on being adaptable to the constantly changing situations. Adaptability is a matter of choice or preference based on our individual personality and molded by the experiences we gather over time and the way we react to them.

Some developers choose to specialize on a particular language or framework, or other aspect of the development career. Whatever their chosen specialty, they will become experts on what they have chosen to pursue, which makes them the perfect people to handle focused tasks on their respective areas.

Unfortunately, the diversity of technology has become so widespread that being a specialist in one particular technology is not necessarily a guaranteed success track.

I, personally, have never been a big fan of over-specializing on a particular technology or framework. There are a few reasons for that:

• Mature frameworks tend to be very stable, but they usually evolve slowly and cannot keep up. This will render your skill-set out of date very quickly. It will also slow down your technical evolution when it comes to web and mobile.
• Novel frameworks address modern problems with novel approaches most of the time, nut they lack both stability and backward compatibility, and also tend to have quirks. If you invest too much time and love into novel frameworks, you may be shocked to discover one day that they do not love you back. One such framework is Angular, which is notorious for excessively complicated backward compatibility and quirks.

In order to keep up with today’s technologies, I follow a few basic rules:

1. Trust your gut feeling. If you have been a developer for a while, you’ve seen a lot and should know not to take anything for granted. When choosing something new, take it out for a spin. You know what you want to accomplish and you know where things can get funky, so go straight to the potential pain points and check it. If it feels wrong, drop it and move to something else.
2. Always go back to the basics. Don’t reinvent the wheel, but also remember: the wheel is just a concept. The implementation can always be improved upon. Always remember the concepts. Most of the time, technology tries to find a new spin to address the same problem. However, while the problems are the same, the solutions are diverse. Also remember to ask around. There is always someone out there who has already run into the issues you are seeing, and you may be able to benefit from the experience. This effort will teach you more and make you wiser.
3. Beware of the silver bullet. Recently, the decision to use a certain technology is partially rooted in marketing. Companies will choose some technologies based on hype more than anything, meaning that you may never truly know if the technology fits your product completely, or if you will spend half of the development investigating edge cases and framework quirks. Becoming familiar with quirks has no real long-term benefit; it simply points out when technology is not mature or stable.
4. Learn to debug. The most valuable skill you can have is debugging, which usually means breaking a solution into parts until you find the problem. Getting to the core of a problem and understanding a system can be a lot faster once you start debugging. However, this can be harder than it sounds. Most of the time, finding the cause of a bug is fairly easy, and the solution usually involves simple development procedures. But this doesn’t even scratch the surface of hardcore debugging, which is usually tracking down bugs in love production systems with limited tools. This requires breaking down issues and getting very creative with test scenarios. Debugging will sometimes take you to the root of things, so having a diverse technology skill set will take you in the right direction faster. You will find that knowledge about networks—such as TCP/IP, DNS, and NAT—will reveal problems you never knew had to be solved.
5. Learn to script. There are times when scripting comes at an infinite advantage, especially when tracking down complex issues in complex systems, implementing short workaround for deployment, and building and testing things out. Never forget though: they are tools, not a way of life. Modern IDEs will do a superior job writing code when you need it. Scripts are a fast, “hackish” way to get a job done quickly and effectively.
6. Nobody cares about how your code looks. At the end of the day, all of the discussions about how the code looks, if we want to use spaces or tabs, and all of the other nit-picking discussions are a waste of time. There will always be people who care deeply about these sorts of issues, but customers will really only ask the same questions: Is it ready? Does it work? Does it do all that I need it to do? Of course, if you don’t look at code quality, unit tests, and other things, the project will eventually buckle under its own weight. However, if you don’t look at what the customer asks, the project will never even make it out of the gate. It’s good to end up having technical debt. It means that you produced something that is worth maintaining and enhancing.
7. Go with the crowd. This may seem kind of counter-intuitive, but it helps with efficiency and overall production. I would rather submit and follow a team trend to become productive than try to fight for a unique production, which will waste energy, cause frustration, and lower productivity. Instead, put that energy into increasing the overall experience. Bad code is in bad shape for a reason. If you don’t understand the history behind it, you will repeat the same mistakes. Strive to have everyone on the team come from similar work environments and have similar practices. When you have too many variables on the team—different IDEs, different build methodologies, different environments, custom scripts—a chunk of time will be spent debugging unique issues unrelated to anything.

In the end, being adaptable is a matter of choice. It may bring you ease of mind the workplace and increase productivity of the team, or it may slow down a project. There is no right choice when it comes to adaptability, but it can always serve as a useful skill within this industry.