"Coding is 30% of the Job"

These were the words uttered by one of the more senior developers during my first week at the job. It struck me - wasn't coding the reason I got paid? Well, it turns out that this is true, but not to the degree that you might think. Brian Tracy once said something along these lines to a large audience at a business conference: "I can tell each and everyone of you exactly what your job title is - you are a problem solver". No doubt that coding is problem solving in one of its purest forms, but when you think of it this way, there is a lot more to it than just programming, right? Right now you might be wondering: what really matters then? In this article, I want to discuss some of the things I realized have been much more impactful on my productivity at work than some of the code that I have been writing.

Business Knowledge and Awareness

Having a deeper understanding of the business you are working for is quite a big deal. For example: the problems and focal points of a lean startup are going to be really different to those of an enterprise company that has been around for several decades. This is not only going to reflect the choice of technologies for the given company, but also the solutions that its developers propose and implement. Having an awareness of the business goals for the given project that you are working on will allow you to understand the customers that it is built for and their needs, which in turn will make your contributions, suggestions and solutions more valuable. Depending on the goals of the business, certain features will require more or less depth and different levels of technical depth will be tolerated or disallowed.

Often, it is simple to get an idea of how the goals of a business are aligned by going onto their website and finding out its history. Are they are huge company that has been around for a while? They probably focus on long term growth and sustainable engineering practices. Are they a VC funded startup trying to test a new product? Prepare for short sprints and rapid iterations of different features.

Domain Knowledge

When I first started out as a junior developer in telecommunications enterprise consulting, my team members might have just as well been speaking mandarin at our first standup: I understood nothing.

Fortunately, as I became more familiar with the material surrounding my project, the pieces were starting to fit into place. You will probably be experiencing the exact same thing for whatever domain you are entering for your job. Every industry uses software these days, that means that every industry is hiring developers. Most industries also have their set of tools and terms that are not going to be familiar to most people outside of that industry.

It could well be that you end up taking the leap and working in a field that you have no idea about - and that's okay! While you will probably get to learn all these things over time, I think it is a great idea to start studying your domain before you start your job, so that you can get an edge.

Communication

Most knew this was coming - good communication is the key to a higher plain of productivity. No matter how often you hear about it, its still hard for a junior developer to truly grasp the importance of communication when starting on a new job. The simple fact is that if you take the work of two developers, one who did and one who did NOT understand the exact requirements set by their client, the former will almost always have a better product, no matter the disparity in technical skill.

Communication also goes beyond understanding and meeting requirements or customers demands. It is also about respect and empathy, important traits in software development, a discipline that is driven by team work. Developers are passionate and proud when it comes to their trade, so voicing disagreement or making improvement suggestions needs to be done with care. Likewise, it is important not to take feedback too personal and see it as a learning opportunity. Being someone that other people like to work with will be a huge advantage in your career and most of that is based on having great communication skills.

Decision Making

Its not long in your career as a developer, that you will run into having to make decisions - whether you are an experienced software architect or just learning to code. The term "there is no free lunch" might come to mind. Great developers know how to make decisions better than others, usually with consideration of some of the aforementioned elements (especially business and domain knowledge). This does not just boil down to the code that we write, but also other areas, for example moments where it might be better to decide not to write code at all.

Developers with a keen sense of business and domain knowledge are able to make the right decisions in moments where it could save the company a considerable amount of money. This includes deciding when it's best to use a proprietary service instead of creating a costum solution or using a specific architecture over another. Making informed decisions confidently is key to becoming a great developer.

Conclusion

From my (still quite minimal) experience, I have to agree with my more experienced colleague. Most solutions require the developer to go beyond the code, so its no surprise that the most highest roles for a given company in software development rarely require any coding. I hope that this article helped underline and prepare you for some of the commonly overlooked, yet still very important, aspects of a software developer job.