Developer Job Description
There's been a bit of talk about job descriptions around Wiliam lately, and it got me into thinking about what exactly it is I do, what I should be doing, and what I want to do. Today I will discuss what it is I think developers should do.
Translator
When we think translation, we think of a transformation between two languages, matching the words of one language to the other. But there's more to translation than this. What is the difference between an online French translation service and your best friend who moved to France 5 years ago? The online service will do a dictionary look up of the words, matching common phrases. A great translator will transform more than just the words, they will transform emotion, sound, symbols, cultural context and (most importantly) the intended meaning.
Developers are translators. We translate business requirements to technical solutions. Like a great translator would, a great developer will take into account the business context when creating a solution. Its not just translating the requirements document into lines of code! A client generally does not know what is technically available or achievable, its our job to make sure they understand the solutions (translation) we are proposing. For example, say you've built a site that shows off your client's recipes. If you find yourself explaining that the system cannot accept 'a pinch of salt' because 'a pinch' is not a number, change it to '1 pinch salt' or '1/8 tsp salt', then you have not understood the business. Its not enough to say "I don't know how run a bank" or "Do I look like a cook to you?". Be a great translator, teach them a bit of your technical language, and learn a bit of their business language.
Architects
When I'm out and about and want to say something secret to my wife, I usually speak Khmer. Usually it's insulting or crude about someone or something around me at the time. It's fine as no one will understand, unless they happen to be Cambodian as well. In the same manner, I've seen a lot of developers slap code together like 2 year old finger paints, expecting that no one will see the code once its gone live. Put together without regard for maintenance work, or future extensions to the solution, without regard for the next developer. The client will not understand, they will see the code works, it does what its supposed to do. But if there happens to be another developer that needs to make changes, they will want to do terrible things to the author of that code.
Developers are architects. A building architect would not throw bits of wood around and call it a house. In the same way, developers should be designing and creating extensible, scalable, testable solutions. Layout your code in a logical manner. Learn and apply the latest techniques in the industry. Keep it standard. "Standard" is known. The next developer will know "standard" code. It will reduce
Integrators
Its not often that a client will come in and say "I've got nothing else, this website is the beginning". They will usually have established accounting, inventory management, CRM, shipping systems. We need to understand these systems so we can interact with them to supplement the client's existing business processes. Yes, integrating with other systems is a pain, but don't go replacing everything the client currently has. Definitely examine the client's existing systems and see if they will work well with your proposed system or if they will need replacement. If the client is using an Excel spreadsheet to manage inventory of 50 products, then propose that the website development will include inventory management. If the client is using Microsoft Dynamics with hundreds of thousands of products and customer details, then it's probably best to go dig up the API documentation.
Developers are integrators. Developers work with the client to improve their business using technology, and that might mean making different technologies work together. A developer should remember that their objective is not to make the coding task easier, but to create a solution that optimises, streamlines, is synergistic with the existing business processes. Any replacements or changes to the business should work for the clients business, not to shorten development time. If a system does not do what the client wants, why would they use it? And what good is a system that does not get used?
In summary, a developer is more than just a code monkey. As one of the most time intensive and expensive resource in the development cycle, we need to offer more than the code we write. We should be (need to be) translators, architects, integrators.
