Confusion is an old friend of every developer. Sometimes she comes as an emissary of programming languages, be it because of the way they read or the way they function, and sometimes she visits via the human element, particularly when you’re interacting with colleagues or clients who do not understand programming very well.
Whatever the case, knowing how to tackle confusion is a skill so important for every developer, that entire books have been written on the subject. While we will not go to a similar level of depth in this article, we would like to provide a few general pointers that will help you keep your mind unclouded, particularly if you are new (or relatively new) to this undeniably complex industry.
Source of Confusion #1: Poorly-written specifications
One of the most common of all problems that developers face. Your client will commission a product, but will not properly explain what that product needs to do, or what features it should include.
Solution: This is largely about attitude. Yes, your clients may sometimes be bad at explaining what they want, but you would do well to remember that those clients are the reason you have a job. So, put on your most serviceable hat, and insist on a gentle but in-depth conversation with your client about what their product should do and how they expect it to serve their business. Ask basic questions and mine out the information they did not provide. Be patient if the clients’ answers demonstrate their lack of technical understanding – if they had that understanding, they would not be paying you to provide it.
Source of Confusion #2. Conflicting orders
Nowadays, many companies seem to want to emulate the model of a hip, trendy startup, and so they’ll talk of operating under a ‘flat’ or ‘flexible’ hierarchy. This has the potential to backfire if two different heads of department hand over directives which are in conflict with each other, and which you have no idea how to resolve without engaging in deft office politics.
Solution: You’ll normally have at least one boss, lead or supervisor who knows how to code and who understands the technical aspects of your current project. Make sure that any project directives first go through him/her before they are sent to you. If this causes friction with the person who sent the directive to you, politely ask them to be patient and explain that the purpose of your referral is precisely to avoid this sort of friction in the future.
Source of Confusion #3: Bad variable, class or function names
Reading code is not the same as reading a natural language, and one of the reasons is that writing code involves making up ‘words’ on a regular basis, in the form of the names you give to some of your items – typically variables, functions and classes. If these names are not intuitive or self-explanatory, this can lead to a great deal of head-scratching as you try to figure out what “analysis_variable” is supposed to do exactly.
Solution: For inherited code, there is unfortunately little you can do other than lots of patient unit testing. For internal code, the best cure is prevention, and the best practice for prevention is to carefully and consistently supervise the junior developers in your team. Poorly-named items most frequently come from those team-members who are new to the team or not used to working as part of one, so look at the work they’re doing, and make sure they understand why they should name their variables clearly.
Needless to say, you should be leading by example here, for your colleagues’ benefit but for yours too – don’t rule out the possibility of being confused by your own old code, one day when you have to return to it.
Source of Confusion #4: What tech to use
In code, there are always many different solutions to any given problem. Yet this variety of options can lead to uncertainty if you aren’t sure what framework or even what programming language is best for the job you are given.
Solution: While the community is far from unanimous, there is a certain consensus that it’s better to be a specialist in a few languages than to have basic skills in many different ones. The above problem shows one of the reasons why that is so. Being very skilled in a language, and knowing what its many libraries can do, will give you a much better sense of which problems you can and most importantly can’t take on. It is better to turn down a project altogether than to commit to it and realise halfway through you should have gone for a different programming language.
Another way around this problem may be to let the client or management decide on which technology to use, but we would advise against that emphatically. Nobody will ever be more qualified than you to decide how you work best, and problems are rarely solved by shirking responsibilities that should be yours.
Final Source of Confusion: Code that does not work
And here we come to the universal problem that will forever baffle all developers until the end of time: code that simply does not do what you tell it to do.
We shall not write a ‘solution’ this time because the only solution, really, is to be a better developer: keep your logic clean, do plenty of unit tests, and practice catching bugs. You can learn by following the blogs of experienced devs, take some free Codecademy courses to expand your abilities, or fully upskill with one of our bootcamps.
Whatever you do, there will always be some part of your code that behaves so as to confuse you. Don’t be scared by this. Computers are logical things, and what they do can always be understood by old-fashioned hard work, or in your case, by patiently, diligently and intelligently applying what as a software developer you already know.
