{"id":3904,"date":"2018-03-23T22:50:37","date_gmt":"2018-03-23T21:50:37","guid":{"rendered":"https:\/\/monodes.com\/predaelli\/?p=3904"},"modified":"2018-03-23T10:51:13","modified_gmt":"2018-03-23T09:51:13","slug":"the-mistakes-i-made-as-a-beginner-programmer-samer-buna-medium","status":"publish","type":"post","link":"https:\/\/monodes.com\/predaelli\/2018\/03\/23\/the-mistakes-i-made-as-a-beginner-programmer-samer-buna-medium\/","title":{"rendered":"The Mistakes I Made As a Beginner Programmer \u2013 Samer Buna \u2013 Medium"},"content":{"rendered":"

\"\"<\/a> Good reading: The Mistakes I Made As a Beginner Programmer by\u00a0 Samer Buna<\/a><\/em><\/p>\n

<\/p>\n

<\/p>\n

\n
\n

The Mistakes I Made As a Beginner Programmer<\/h1>\n

Learn to identify them, make habits to avoid\u00a0them<\/h2>\n<\/div>\n
<\/div>\n
\n
\n
\n
<\/div>\n<\/div>\n<\/figure>\n<\/div>\n
\n

Let me make one thing clear first. If you are a beginner programmer, this article is not meant to make you feel bad about the mistakes that you might be making but rather to make you aware of them, teach you to spot signs of them, and remind you to avoid them.<\/p>\n

I have made these mistakes in the past and learned from each and every one of them. I am happy to have formed coding habits to help me avoid them. You should do too.<\/p>\n

These mistakes are not presented here in any particular order.<\/p>\n

1) Writing Code Without\u00a0Planning<\/strong><\/h3>\n

High-quality written content, in general, cannot be created easily. It requires careful thinking and research. High-quality programs are no exception.<\/p>\n

Writing quality programs is a process with a flow:
\nThink<\/strong>. Research<\/strong>. Plan<\/strong>. Write<\/strong>. Validate<\/strong>. Modify<\/strong>.
\nUnfortunately, there is no good acronym for this. You need to create a habit to always go through the right<\/em> amount of these activities.<\/p>\n

One of the biggest mistakes I have made as a beginner programmer was to start writing code right away without much thinking and researching. While this might work for a small stand-alone application, it has a big, negative effect on larger applications.<\/p>\n

Just like you need to think before saying anything you might regret, you need to think before you code anything you might regret. Coding is also a way to communicate your thoughts.<\/p>\n

When angry, count to 10 before you speak. If very angry, a\u00a0hundred.<\/em><\/p><\/blockquote>\n

\u2014 Thomas Jefferson.<\/em><\/p><\/blockquote>\n

Here is my version of that quote:<\/p>\n

When reviewing code, count to 10 before you refactor a line. If the code does not have tests, a\u00a0hundred.<\/em><\/p><\/blockquote>\n<\/div>\n<\/blockquote>\n

\u2014 Samer\u00a0Buna<\/em><\/p><\/blockquote>\n

Programming is mostly about reading previous code, researching what is needed and how it fits within the current system, and planning the writing of features with small, testable increments. The actual writing of lines of code is probably only 10% of the whole process.\n<\/p>\n

Do not think about programming as writing lines of code. Programming is a logic-based creativity that needs nurturing.<\/p>\n

2) Planning Too Much Before Writing\u00a0Code<\/strong><\/h3>\n<\/p>\n

<<\/p>\n

p id=”fa12″ class=”graf graf–p graf-after–h3″>Yes. Planning before jumping into writing code is a good thing, but even good things can hurt you when you do too much of them. Too much water might poison you.<\/p>\n

Do not look for a perfect plan. That does not exist in the world of programming. Look for a good-enough plan, something that you can use to get started. The truth is, your plan will change, but what it was good for is to force you into some structure that leads to more clarity in your code. Too much planning is simply a waste of your time.<\/p>\n

I am only talking about planning small features. Planning all the features at once should simply be outlawed! It is what we call the Waterfall Approach<\/strong>, which is a system linear plan with distinct steps that are to be finished one by one. You can imagine how much planning that approach needs. This is not the kind of planning I am talking about here. The waterfall approach does not work. Anything complicated can only be implemented with agile adaptations to reality.<\/p>\n

Writing programs has to be a responsive activity. You will add features you would never have thought of in a waterfall plan. You will remove features because of reasons you would never have considered in a waterfall plan. You need to fix bugs and adapt to changes. You need to be agile.<\/p>\n

However, always plan your next few features. Do that very carefully because too little planning and too much planning can both hurt the quality of your code, and the quality of your code is not something you can risk.<\/p>\n

3) Underestimating the Importance of Code\u00a0Quality<\/strong><\/h3>\n

If you can only focus on one aspect of the code that you write, it should be its readability<\/strong>. Unclear code is trash. It is not even recyclable.<\/p>\n

Never underestimate the importance of code quality. Look at coding as a way to communicate implementations. Your main job as a coder is to clearly communicate the implementations of any solutions that you are working on.<\/p>\n

One of my favorite quotes about programming is:<\/p>\n

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you\u00a0live.<\/em><\/span><\/p><\/blockquote>\n

\u2014 John\u00a0Woods<\/em><\/p><\/blockquote>\n

Brilliant advice, John!<\/strong>\n<\/p>\n

Even the small things matter. For example, if you are not consistent with your indentation and capitalization, you should simply lose your license to code.<\/p>\n

tHIS is\n  WAY MORE important<\/pre>\n
than\n         you think<\/pre>\n<\/p>\n
Another simple thing is the use of long lines. Anything beyond 80 characters is much harder to read. You might be tempted to place some long condition on the same line to keep an if-statement block more visible. Do not do that. Just never go beyond the 80 character limit, ever.<\/p>\n
Many of the simple problems like these can be easily fixed with linting <\/strong>and formatting <\/strong>tools. In JavaScript, we have two excellent tools that work perfectly together: ESLint <\/strong>and Prettier<\/strong>. Do yourself a favor and always use them.<\/p>\n
Here are a few more mistakes related to code quality:<\/p>\n
\u2014 Using many lines in a function or a file. You should always break long code into smaller chunks that can be tested and managed separately.<\/p>\n
Any function that has more than 10 lines is just too\u00a0long<\/em><\/p><\/blockquote>\n
\u2014 Using double negatives. Please do not not not do that.<\/p>\n
Using double negatives is just very not not\u00a0wrong<\/em><\/p><\/blockquote>\n
\u2014 Using short, generic, or type-based variable names. Give your variables descriptive and non-ambiguous names.<\/p>\n
There are only two hard things in Computer Science: cache invalidation and naming things.<\/em><\/p>\n
\u2014\u200aPhil\u00a0Karlton<\/p><\/blockquote>\n
\u2014 Hard-coding primitive strings and numbers without descriptions. If you want to write logic that depends on a fixed primitive string or number value, put that value in a constant and give it a good name.<\/p>\n
const answerToLifeTheUniverseAndEverything<\/strong> = 42;<\/pre>\n<\/p>\n
\u2014 Using sloppy shortcuts and workarounds to avoid spending more time around simple problems. Do not dance around problems. Face your realities.<\/p>\n
\u2014 Thinking that longer code is better. Shorter code is better in most cases. Only write longer versions if they make the code more readable. For example, do not use clever one-liners and nested ternary expressions just to keep the code shorter, but also do not intentionally make the code longer when it does not need to be. Deleting unnecessary code is the best thing you can do in any program.<\/p>\n
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.<\/em><\/p>\n
\u2014\u200aBill\u00a0Gates<\/p><\/blockquote>\n
\u2014 The excessive use of conditional logic. Most of what you think needs conditional logic can be accomplished without it. Consider all the alternatives and pick exclusively based on readability. Do not optimize for performance unless you can measure. Related: avoid Yoda conditions<\/strong><\/a> and assignments within conditionals.<\/p>\n
4) Picking the First\u00a0Solution<\/strong><\/h3>\n<\/p>\n
When I was starting to program, I remember that when I got presented with a problem, I would find a solution and just immediately run with it. I would rush the implementation right away before thinking about the complexities and potential failures of my first identified solution.<\/p>\n
While the first solution might be tempting, the good solutions are usually discovered once you start questioning all the solutions that you find. If you cannot think of multiple solutions to a problem, that is probably a sign that you do not completely understand the problem.<\/p>\n
Your job as a professional programmer is not to find a solution <\/em>to the problem. It is to find the simplest <\/strong>solution to the problem. By \u201csimple\u201d I mean the solution has to work correctly and perform adequately but still be simple enough to read, understand, and maintain.<\/p>\n
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.<\/em><\/p><\/blockquote>\n
\u2014 C.A.R.\u00a0Hoare<\/em><\/p><\/blockquote>\n
5) Not\u00a0Quitting<\/strong><\/h3>\n
Another mistake that I have made more often than I cared to admit is sticking with the first solution even after I identify that it might not be the simplest approach. This is probably psychologically related to the \u201cnot-quitting<\/strong>\u201d mentality. This is a good mentality to have in most activities, but it should not apply to programming. In fact, when it comes to writing programs, the right mentality is fail early and fail often<\/strong>.\n<\/p>\n
The minute you begin doubting a solution, you should consider throwing it away and re-thinking the problem. This is true no matter how much you were invested in that solution. Source control tools like GIT can help you branch off and experiment with many different solutions. Leverage that.<\/p>\n
Do not be attached to code because of how much effort you put into it. Bad code needs to be discarded.<\/em><\/p><\/blockquote>\n
6) Not\u00a0Googling<\/strong><\/h3>\n
There has been many instances where I wasted precious time trying to solve a problem when I should have just researched it first.\n<\/p>\n
Unless you are using a bleeding-edge technology, when you run into a problem, chances are someone else ran into the same problem and found a solution for it. Save yourself some time and Google It First<\/strong>.<\/p>\n
Sometimes, Googling will reveal that what you think is a problem is really not, and what you need to do is not fix it but rather embrace it. Do not assume that you know everything needed to pick a solution to a problem. Google will surprise you.<\/p>\n
However, be careful what you Google for. Another sign of a newbie is copying and using others code as is without understanding it. While that code might correctly solve your problem, you should never use any line of code that you do not fully understand.<\/p>\n
If you want to be a creative coder, never think that you know what you\u2019re doing.<\/p>\n
The most dangerous thought that you can have as a creative person is to think that you know what you\u2019re\u00a0doing.<\/em><\/p><\/blockquote>\n
\u2014 Bret\u00a0Victor<\/em><\/p><\/blockquote>\n
7) Not Using Encapsulation<\/strong><\/h3>\n
This point is not about using the object-oriented paradigm. The use of the encapsulation concept is always useful. Not using encapsulation often leads to harder-to-maintain systems.\n<\/p>\n
In an application, a feature should have only one place that handles it. That is usually the responsibility of a single object. That object should only reveal what is absolutely necessary for other objects of the application to use it. This is not about secrecy but rather about the concept of reducing dependencies between the different parts of an application. Sticking with these rules allows you to safely make changes in the internals of your classes, objects, and functions without worrying about breaking things on a bigger scale.\n<\/p>\n
Conceptual units of logic and state should get their own classes<\/strong>. By class, I mean a blueprint template. This can be an actual Class <\/strong>object or a Function <\/strong>object. You might also identify it as a Module <\/strong>or a Package<\/strong>.<\/p>\n
Within a class of logic, self-contained pieces of tasks should get their own methods. Methods should do one thing and do that thing well. Similar classes should use the same method names.<\/p>\n
As a beginner programmer, I did not always have the instinct to start a new class for a conceptual unit and I often failed to identify what can be self-contained. If you see a \u201cUtil<\/code>\u201d class that has been used as a dumping ground for many things that do not belong together, that is a sign of newbie code. If you make a simple change and then discover that the change has a cascading effect and you need to do many changes elsewhere, that is another sign of newbie code.<\/p>\n
Before adding a method to a class or adding more responsibilities to a method, think and question your instincts. You need time here. Do not skip or think that you will refactor that later<\/strong>. Just do it right the first time.<\/p>\n
The big idea here is that you want your code to have High Cohesion <\/strong>and Low Coupling<\/strong>, which is just a fancy term that means keep related code together (in a class) and reduce the dependencies between different classes.<\/p>\n
8) Planning for the\u00a0Unknown<\/strong><\/h3>\n
It is often tempting to think beyond the solution that you are writing. All sort of what-ifs will pop into your head with every line of code that you write. This is a good thing for testing edge cases, but it is just wrong to use as a driver for potential needs<\/strong>.<\/p>\n
You need to identify which of these two main categories your what-ifs belong to. Do not write code that you do not need today. Do not plan for the unknown future.<\/p>\n
Writing a feature because you think that you might need it in the future is simply wrong. Do not do it.<\/p>\n
Always write the minimum amount of code that you need today for the solution that you are implementing. Handle edge-cases, sure, but do not add edge-features<\/em>.<\/p>\n
Growth for the sake of growth is the ideology of the cancer\u00a0cell.<\/em><\/p><\/blockquote>\n
\u2014 Edward\u00a0Abbey<\/em><\/p><\/blockquote>\n
9) Not Using the Right Data Structures<\/strong><\/h3>\n
When preparing for interviews, beginner programmers usually put too much focus on algorithms. It is good to identify good algorithms and use them when needed, but memorizing them will probably never attribute to your programming genius.\n<\/p>\n
However, memorizing the strengths and weaknesses of the various data structures that you can use in your language will certainly make you a better developer.\n<\/p>\n
Using the wrong data structure is a big and strongly-lit billboard sign that screams newbie code here.<\/p>\n
This article is not meant to teach you about data structures but let me mention a couple of quick examples:<\/p>\n
\u2014 Using lists (arrays) instead of maps (objects) to manage records<\/strong><\/p>\n
The most common data structure mistake is probably the use of lists instead of maps to manage a list of records. Yes, to manage a LIST of records you should use a MAP.<\/p>\n
Note that I am talking about a list of records here where each record has an identifier that\u2019s to be used to lookup that record. Using lists for scalar values is okay and often the better choice specially if the focus of the usage is \u201cpushing\u201d values to the list.<\/p>\n
In JavaScript, the most common list structure is an array and the most common map structure is an object (there is also a map structure in modern JavaScript).<\/p>\n
Using lists over maps for managing records is often wrong. While this point is really only true for large collections, I would say just stick with it all the time. The main reason this is important is because when looking up records using their identifiers, maps are a lot faster than lists.<\/p>\n
\u2014 Not Using Stacks<\/strong><\/p>\n
When writing any code that requires some form of recursion, it is always tempting to use simple recursive functions. However, it is usually hard to optimize recursive code, especially in single-threaded environments.<\/p>\n
Optimizing recursive code depends on what recursive functions return. For example, optimizing a recursive function that returns two or more calls to itself is a lot harder than optimizing a recursive function that simply returns a single call to itself.<\/p>\n
What we tend to overlook as beginners is that there is an alternative to using recursive functions. You can just use a Stack<\/em> structure. Push function calls to a Stack yourself and start popping them out when you are ready to traverse the calls back.<\/p>\n
10) Making Existing Code\u00a0Worse<\/strong><\/h3>\n
Imagine that you were given a messy room like this:<\/p>\n
\n
<\/div>\n<\/figure>\n
\n
\n
<\/div>\n<\/div>\n<\/figure>\n
You were then asked to add an item to that room. Since it is a big mess already, you might be tempted to put that item anywhere. You can be done with your task in a few seconds.<\/p>\n
Do not do that with messy code. Do not make it worse! Always leave the code a bit cleaner than when you started to work with it.<\/p>\n
The right thing to do to the room above is to clean what is needed in order to place the new item in the right place. For example, if the item is a piece of clothing that needs to be placed in a closet, you need to clear a path to that closet. That is part of doing your task correctly.<\/p>\n
Here are a few wrong practices that usually make the code a bigger mess than what it was (not a complete list):<\/p>\n