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.
Top comments (14)
Very good article! As a Junior developer, coding is a bigger part of the job, because you're usually not aware of all the other important aspects that you've mentioned here. As you gain experience, coding becomes a less prominent part of the job :)
BTW, in your example about communication and understanding the requirements, I believe you meant to say that the former developer will do better, because they understand what needs to be done, right?
Thanks for the kind words. I completely agree with both things you said (that more senior positions require less code than junior ones and that juniors will not be as good at understanding requirements). I think what I meant was more along the lines that before getting job experience, you don't realize how much the team aspect and communication impacts your work when compared to doing solo projects.
He means that you wrote in the article that a developer who does NOT understand the clients requirements will almost always have the better solution. So you probably meant "former", not "latter"
Yeah, it is probably 'former'.
@marc if possible, change the article :)
propietary service -> proprietary service
costum solution -> custom solution
Okay, thanks for the feedback. Changes have been made!
I agree with this 100%. It’s something we don’t think about often. Development gets so complicated. Great developers are not just responsible for writing hopefully great code, but also participating in many decision points. This is something that does not get taught in school, and really comes from on the job experience.
Beautifully written!
Great write up Marc!
your podcast isn't more available in Spotify
Yeah, I decided to remove it for the time being - was not happy with the quality and how it was going, so felt I needed to retry with a more structured/prepared approach.
still available on Apple Podcasts :P
Haha yeah Apple Podcast doesn't have the same frequency of updating the RSS information as Spotify (I don't know if I need to ask them to remove it or what)
Maybe even less...
Nice one, unfortunately only experience helps you get better at this because you always have time constraints