Be A Python Dev

It’s not a trend that rings a bell for a newbie in the programming world to be found to suck at coding. It’s a stage of amateurism that you can conquer with patience and tenacity that you might not even know you’re in. You may notice lots or few of these mistakes and bad practices that need tidying up to attain the level of professionalism at the job worthy to be considered a decent programmer much less jump to the next level. A lot of reasons could be responsible for this, and here, they will be examined and the possible solutions lay bare.

Taking on too many programming languages at once

Trying to get many programming languages into the brain, at once, can easily make the learner end up as a bundle of confusion. It will make you a jack of all trades and master of none, a quite terrible position to be in the coding world. Many try to do this in an attempt to show-off, but it’s a very unhealthy practice. Don’t jump to PHP while you’re still trying to grab the basics of JavaScript. Not a wise move. Sure, it’s a good thing to have little knowledge of all the areas, but focus on one language at the beginning. Mastering one language, such as python, makes switching to others easier as you learn advanced concepts like using functions as objects and list comprehensions. The experienced already gathered in one area of expertise will help a lot.

Coding Without Planning

Writing code without much thinking, research, and planning is a mistake many beginners make in programming. It can get you, as the programmer, to code something regrettable. Designing before coding is a practice that should be done to set yourself up for success.

It allows for ease of change, learning, and maintainability. During planning, an achievable goal will be set and the main plan execution will work towards that. Without a well-set goal, it’s easy to veer off course, chasing the wind and only a slight change in your initial heading can leave you thousand of miles of where you should be after you take off.

To a great extent, planning is to coding, what architectural design is to building. Yes, planning needs to be moderately done and not-overdone or optimized too early. Some overdo it in a bid to get a totally perfect plan. Actually, no such plans exist in the coding arena as even senior developers are constantly learning and finding new patterns to use. The best plan to have is one good enough to get you started in an organized way. The plan may change as it goes on when it forces you into some light bulb moments that may lead to more clarity in the code.

Failure to learn and properly use an IDE

Known as the Integrated Development Environment, an IDE enables programmers to consolidate the different aspects of writing a computer program. Some IDEs, such as NetBeans and Eclipse, contain the necessary compiler, interpreter, or both; others, such as SharpDevelop and Lazarus, do not. IDE’s familiarity with the syntax of your language can provide visual cues. Keywords, words that have special meaning like ‘class’ in Java, are highlighted with different colors and therefore, made easier to read. They also offer the auto-complete advantage when writing code, as it can predict/suggest what you are going to type next. Debugging tools also come with IDEs. This gives a lot of help whenever a code doesn’t run correctly by being able to step through your code line for line to see the contents of variables and more clues on why something might be going unexpectedly. It would be a very great mistake on the part of a beginner to ignore the learning and the usage of IDE, with all the speedy and effective coding advantages it offers.

Bad syntax and dirty coding

Computer programs need to follow strict syntax to properly compile or be ran by an interpreter. Any aspects of the code that doesn’t correctly use the syntax of the programming language can turn out to be a costly programming error as it means spending time to chase it down.

Poor syntax and unclean coding can take many forms. They include:

• lack of proper indentation
• putting everything in a single line or the inconsistent use of new lines and whitespace
• under-commenting or over-commenting
• bad variable names or assignments
• functions that are too big and hard to test
• objects that don’t properly abstract the thing they represent

Code should be written in such a way it is clean, readable, maintainable, and extensible. To achieve this, the points highlighted are to be well noted.

Choice of data structures

Data structures in your code organize your data for effective and efficient use. Examples are array, linked list, queue, stack, binary tree, binary heap hashing, graph, matrix, etc. Factors that determine the choice of a particular data structure for a code are: the size of the data, size of the storage, and the data dynamics such as are you limited by memory on your system or optimizing for CPU time. Do you need to lookup data instantaneously or will you need to do frequent inserts and updates to the date your are working with that a binary search tree would be more useful than a hash table. It is important these are well considered in order for the right choice to be made.

Ignoring unit testing and edge cases

• Unit testing

Even though unit testing is the most important level of testing, it is often neglected. A unit is the smallest testable part of the software system. Unit testing has to do with the testing of the components of software to validate each unit of the software performs as designed. With unit tests, code is more reusable as it makes it safer to edit covered code. Overall development is faster in the long run as the effort required to find and fix defects found during unit testing on modified code is reduced compared to the trouble needed to repair defects found in later stages of testing or ::gasp:: prod. Also, debugging a failed unit test is easy because when a test fails, only the latest changes need to be debugged.

• Edge cases

James Lewis Nance, MS Electrical Engineering, North Carolina (1991) describes an edge case as an exception to a rule, or a situation that requires additional or special handling. That is, “do this, unless this condition or context exists, then do something else”. Some may refer to edge cases as ‘boundary conditions’, but the truth is there is a slight difference between the two. Non-trivial edge cases can result in the failure of an object that is being engineered. A Unit test is a good solution to edge case issues and should be carefully considered when writing efficient tests.

Lack of research!

Curiosity is a great knowledge tool for a programmer. It’s good to dive deep into problems and ask questions, seek to gather knowing assets from those who know better when you get hung up. However not doing your own research before hand will make a bad programmer out of you and potentially even a weak one, to be candid. Since this doesn’t enable you to learn in the future and enables you to be that kid in the college class that asks for all the answers to yesterdays homework right before class. Do your own research. Put your brain to work. Remember, a good programmer is a problem solver. The more you do this; the easier it gets for you to break down problems and come up with working efficient solutions.

Finally, whichever area of coding you chose to explore, patience is key. Challenges will come up in programming and running from them won’t help a bit. Also, not keeping calm during such challenges will weaken the brain’s reasoning power instead of helping with the problem. A break might be needed and it’s fine to take it by taking a walk to the water cooler. That is not to say you should abandon the project and go to other things that aren’t related. You should stick to it until it gets solved . Every challenge solved teaches something important. Be ready to give it all the time it takes. You’d emerge stronger and better equipped. Being able to show examples of times you encountered a challenging set back and were able to come up with a good solution to bring yourself back on track is usually good to bring up during interviews.

Now that you know why you likely suck it’s time to turn it around!

With all these well-noted and put to good use, you can avoid being a sucker at programming. Welcome to the coding world. Be sure to have a good time and don’t be the guy that everyone has to clean up after.