There’s a world of difference between knowing bits and pieces of different programming languages, and being a qualified software programmer. We shall, in what follows, shed light on some traits and features that bad programmers tend to share.
According to a report published by the International Data Corporation (IDC), the total number of software development experts across the world is well in excess of 18,500,000. The Asia-Pacific region contributes over 37% of these programmers, while around 33% of the professionals are from either the United States or Canada. As you can very well imagine, not all software and mobile app developers are equally good at their jobs. If you are in this profession, you can find out that you are a bad programmer when:
You love to copy and paste
For a lousy software developer, the Ctrl-C and the Ctrl-V buttons are his/her best friends. If you spend too much time on looking for code snippets, or even complete programs, that have worked earlier – and simply try reusing them – it’s high time you changed your style. Open-source libraries are meant to be used, but lifting lines of program codes without understanding them is a big mistake.
You do not have a thorough knowledge about programming languages
The MAC address/IP address dilemma
If you do not know the difference between the two, hello and welcome to the ‘Bad Programmers’ Club.’ There are plenty of so called software wizards around, who take it that MAC addresses are invariably related to Apple iMACs. For them, there’s a whole lot wrong in the very basics!
You take pride in writing as much as you can
Great idea for a web content writer, and a horrible one for a professional programmer. Your focus should always be on judging each problem on a standalone basis, and solving it using as few coding lines as possible (without errors, of course). It is a hallmark of substandard programmers to hunt for common ‘patterns’ in all their coding assignments. Such patterns do not always exist, and you certainly won’t win any brownie points from writing line after line of redundant codes.
You are afraid of long programs
If you follow a rule of thumb of not trying to understand any program that has, say, 25 lines, you should probably start looking for another profession. There is no hard and fast rule as to what the ‘ideal length’ of a program should be – and for newbies in particular, studying a longer, detailed program is often a better option than simply mugging up an abridged, advanced version.
You are the most sincere worker at office
Nopes, I’m not advising you to be lazy. It’s just that, smart programmers tend to find ways in which they can tackle a coding assignment quickly and satisfactorily – and they generally face minimal troubles with code debugging. On the polar opposite, there are the ones who start to analyze their codes from 9AM, discovers about a hundred bugs by 12 noon, discover the solutions by 4PM, and by the time they are finished – it’s close to 10PM. The latter cannot be faulted for effort and hard work, but they simply do not have what it takes to be a good software developer.
You feel that programming is a black box
As has been already pointed out, coding has got nothing to do with either how much you copy and paste, or write on your own. There are procedural programming, object-oriented programming, imperative programming, functional programming and several other models – and if you do not know the difference between them, it won’t take long for you to land in a soup. Bad programmers rattle off fictitious phrases like ‘voodoo coding’ and ‘yo-yo coding’ – if you believe in them, you are one of them too!
You place blind faith on Java alone
This might be okay for amateur programmers – but for a professional web or Android developer, such a love-affair is the perfect recipe for disaster. Try to evaluate whether you are at all eager to look beyond Java – at languages like Python and Ruby – which might offer quicker and simpler solutions. For iOS developers, Objective-C is not the only language you need to be an expert in. Swift programming language is what the limelight is on now – and if do not learn it, you will fall behind soon.
You play the blame game with the compiler
The world is not fair – but if you can write a flawless program, there is no way the compiler can develop a mind of its own and mess it up. The most common symptom of this malady is the tendency to check the compiler switches, whenever your supposedly ‘correct’ program throws up a handful of errors. Look more closely, you will find that the fault lies in your codes.
You burn the midnight oil to learn new languages
A software or a mobile app company will hire you because you already know certain languages – and not because you promise to ‘learn them as soon as possible’. It is, of course, vital to stay updated with new languages – but you should not have to strain to learn the basics of coding AFTER you have successfully bragged, and bagged a job. Chances are high that a pink slip will come along soon!
You think program debugging is synonymous to error logging
Well, it’s not. Just because you are careful in entering every error/exception to the log, you should not think that you are handling them the right way. After logging the errors, you need to find out the causes behind them, and rectify the same. If you simply move on to the next project after recording the errors of the earlier one, you are basically shirking your responsibilities as a program debugger.
You cannot work with pointers and references
If the term ‘pointer’ means only the mouse cursor to you – you are not even a half-decent programmer. For mobile app development in particular, relatively complex APIs have to be developed – and if you won’t/can’t work with pointers, you’ll never be able to manage them. Simple tasks like array allocations and link-listing will forever remain a blur. If you are working with a managed language and do not have an idea about ‘references’, the situation will be similarly sticky.
You feel that a method/function MUST have a single return point
Lousy developers think so – and the excuse for it is laughably bad. According to them, such functions keep the overall program neat and easy-to-understand. The truth, in many cases, is just the opposite. Ask any proper programmer, and (s)he will tell you that functions with multiple return points are designed to simplify the coding structure, not to complicate it.
You get bogged down by the pressure of failures
Unless you are ready to take on the challenges that are associated with programming, you can never become good at it. There is no software or app developer in the world who has not made mistakes in his/her career. The trick lies in taking lessons from these mistakes, and becoming a more informed, efficient coder as a result. There is no point in feeling your program ‘should have been right’, when it isn’t so. Take failures in your stride, learn from other senior programmers, regularly follow coding-related case studies, and improvements will manifest themselves over time.
You cannot think beyond scalar data
Particularly if you are into SQL and relational database management (RDBMS)-related coding, such a shallow knowledge pool will not work. You can confidently classify yourself as a below-average programmer (at best!), if you cannot think and operate with ‘data sets’. From map-writing and data-fetching, to creating entity classes – ‘sets’ are the way in which most programming tasks should be managed.
A bad programmer would also have problems in understanding recursion, will tend to program everything in Unified Modeling Language (UML), and shall score poorly as a critical/analytical thinker. The general lack of confidence in coding skills tends to lead to the messy Collyer Brothers Syndrome in developers too. Every programmer feels that (s)he is the best in the world – although many of them still have plenty to learn!