“Mistakes are always forgivable, if one has the courage to admit them.” – Bruce Lee
1. Attempting to learn too many programming languages at once
It’s intuitive to assume that knowing every programming language out there is beneficial. Isn’t that what employers are looking for, right?
Well, not exactly. Spreading yourself too thin too early is never a good thing. By diverting your focus into multiple directions, you are cutting yourself short from the deeper layers of understanding. Every programming language has its own unique slither of intricacies.
Java, for instance, is one of the most robust languages out there, commonly used for Android smartphone apps and large scale software. It is platform-independent which allows it to run anywhere.
The point I am trying to make is that you cannot merely skim over every programming language at the same speed Usain Bolt covers the Olympic track. Unless your goal is to become good at learning programming languages. But who really wants that?
A more effective move is to learn just one programming language, go very deep into it, fill in any gaps of knowledge you might have and tackle a few projects. Doing so, you will develop core programming concepts which will then translate and cross-over into other areas more easily. You’ll be able to pick up and learn new tools, frameworks and languages much more quickly.
It also depends on the employer and the requirements he or she demands from you.
It is ok to experiment initially by trying out many different ones to see if you resonate more with one or the other. Picking the “right” language to learn is a whole topic in itself because some are more popular than others depending on the demand and where technology is currently.
Learning new languages should about opening up your mind and helping you to understand them all more deeply. Given that view, you should picky about which ones to tackle. You don’t want to pick very similar ones as they will not broaden your understanding.
2. Not knowing when to ask for help
If you’re a programmer, you know how easy it is to fall into the endless battle of trying to solve a problem. The caffeine crash has hit you; it is getting dark outside and still, you can’t wrap your mind around this issue. Your thinking “this is impossible; how is this not working?”
We’ve all been there. Eight hours in and still no progress. What next?
Simple. Ask for help!
We like to think of ourselves as very smart and intelligent. Asking for help undermines our ego a bit. Our current culture views this as a weakness. Being the introverts that we are, approaching someone can add an extra layer of challenge.
Enter the middle path!
We should choose the right balance between trying to do everything ourselves and knowing when and how to ask for help. Not only will this enhance our productivity as individuals but also help propel the team forward.
Here is a simple hack I like to use to know exactly when to ask for help:
Its called Timeboxing. A process by which you allocate a limited amount of time to solving a particular problem.
Do the following:
- Assess each item on your To-Do and give them a time limit.
- Set a timer for moving onto the next task.
- Timer rings. Still have not finished your task?
- Re-assess your primary goals and objectives, ask yourself why you didn’t make the time, could it be delegated to another team member? What do I need help with the most to get this finished?
Can you see how this approach is more productive than the stubborn approach we all like to revert to by default, which is to work hard on it until it’s finished? Timeboxing helps us to:
- Improve our focus and enhance creativity
- Keeps perfectionistic tendencies in check
- Eliminated distractions
- Allows you to measure your productivity levels
It’s much better to think strategically and figure out ways of doing things faster than getting caught up in a mental loop of confusion. Time is a valuable resource and employers are looking for engineers who can solve problems quickly. Your time is also the most precious thing there is!
This approach helps to prevent over-engineering your code which I will talk about in a few moments.
There are some drawbacks. One of them is that it can cause you to feel rushed, and it may be harder to enter the flow state. Moreover, some jobs have to be completed to a very high quality regardless of the time taken; in that case, Timeboxing may not be the right approach.
The main point here is to work smart, not hard. Be like the General of the Army and figure out new ways of doing things better and faster. That’s how you become a leader. That’s how you help your team and make the environment less stressful.
3. Trying to be perfect and over-engineering your code
Over-engineering means writing code that uses every available tool in the toolbox when it’s not necessary.
Despite what people say, I believe that programming is an art. There are countless ways of writing methods, classes and the logic behind the functionality of our software.
Just like any creative pursuit, programming allows us to play the role of “God” and design just about anything we desire. It’s the same as playing lego when you were a child. Do you remember the joy you felt while doing that?
There are times, however, when our creativity runs wild, and our seemingly good intentions start to backfire on us and the team.
Common signs to look out for:
- It becomes harder to find a piece of code that implements some concrete, domain-level part of the functionality.
- You are reinventing the wheel: Creating and writing your frameworks rather than using the ones which already exist and proven to work well.
- Wrappers for “everything”. You even make a wrapper have it’s own wrapper! 😀
In general, If you feel like there’s a gap between the complexity of the problem and the complexity of the solution, then you have a clear case of overengineering.
The same is true for UI.
You could end up spending weeks designing a simple log-in form which makes entirely no difference to the user experience.
But you might be thinking, “isn’t good design beneficial to every application?”.
It is to the extent that it serves a simple way for the user to interact with your application. You need to ask yourself if animating these text views are worth it, and perhaps it could deter people from using the app. I remember downloading a goal tracking app a while back. The user interface was overly engineered with all sorts of animations, annoying button click sounds, and it was just too much. All I wanted was a simple app to track my goals. I got rid of it straight away.
Over-engineering your code can also be a problem for your team. Not because they are not capable of reading it but because you’ve put in so much effort to make the code elegant or “infinitely extensible”, you’ve just made it more complex to understand and maintain.
If people can’t intuitively understand you abstractions, then you have already gone too far.
I think that it’s impossible to foresee all possible limitations and integration problems while architecting and writing your code. Even when you think the system is perfect, newer and better designs are catching up and changing real-world requirements. Despite finding your ideal abstraction, in the end, it comes with an expiry tag attached to it anyway.
The main message here is to stop trying to be perfect. Paralysis over-analysis is the real devil preventing you and your team from moving forward.
Look at it from a business perspective. By over-engineering, you have delayed the ability to sell your software yesterday.
3. Abusing online tutorials
We like to think that watching tutorials and taking notes is going to help us learn to code. It feels like a productive use of time, doesn’t it? Honestly, what can be wrong with it, that Data Structures & Algorithms course has dropped from £13.99 to £149.99, don’t you just feel tempted to buy it?
So you buy it and spend 50 hours consuming all the content. Everything is going well. But then you start to tackle some personal projects, and then you are shocked to discover that you don’t know anything!
You find yourself saying something like “Oops. What happened? Did I miss something from the tutorial? Let me go back and watch it again!”
So you do it again, watch a bunch of tutorials and come back to your project. Still, you just cannot grasp the essence of how this SQL database thing works. You start to doubt yourself and wonder if coding is even for you.
Welcome to the world of tutorial purgatory – the deadly loop of unproductive coding.
It’s intuitive to assume that by watching videos and reading books all day, you are going to learn. This is simply not true. You’re just going through the motions, copying code and never really going deep into the problem.
I am talking to absolute beginners and more experienced developers out there.
Adopt an active learning strategy – This means to figure out unique solutions to complex problems yourself on the fly, without relying on external things to spoon-feed you. It’s about developing a deeper level of understanding through intense observation at the problem and the “course correction” along the way to make it work.
True learning is also about finding that 20% you need to solve 80% of the problems you are facing.
Think about it this way: you could read all the books you want about the proper way to swim. You could even watch videos of people swimming. You might know all about the mechanics and techniques of what makes a good swimmer. However, you won’t learn how to swim until you put your learning into practice.
If you want to learn something quickly, what should you do then? Ultimately, you will learn best by taking action and then reinforce that learning by taking on the role of teaching what you’ve learned to someone else.
The best way to learn is to jump right in and start before feeling that you are ready. There is something special about this approach I can’t explain. It feels like tapping into a well of creative genius which helps you absorb more information quickly and in a meaningful way.
Teaching is like a cherry on the pie. It cements everything into place. Something as simple as having a conversation with yourself in front of a mirror or by writing a simple blog post is enough. The key is to regurgitate and process the information you’ve gathered somewhere outside your head.
I am not discounting tutorials or books in any way. You should use them, and I use them all the time. However, they should only be used after you have attempted to solve the problems yourself. When you come back and look at your notes, you’ll approach it with a greater desire to devour and absorb the contents.
4. Ignoring test-driven development
Testing isn’t something we like to spend a heaping amount of time on. We want to get to the “good stuff” and make the software do its thing.
An all-too-common scenario is that Software testers are given orders to check new application functionality after a group of developers have deemed it done. The primary goal here is entering X and checking that the outcome is Y and not Z. These people rarely interact with the business side of things and even the developers themselves.
Most testers are quite enthusiastic at the beginning of their careers but with more and more writing of the same bug reports and test cases, its easy to begin feeling bored and frustrated at your job. The creativity element is gone. It doesn’t feel like your contributing the overall feel and design of the application.
You can probably already see why testing isn’t the most sought out for position or pursuit. However, I believe that testing is one of the essential elements of any software, and neglecting this part can cost you big time. Here are three main reasons why you should take testing seriously:
It saves money – By investing the time now to integrate testing procedures, we can save a significant amount of time and money in the long run because we can quickly identify any issues and fix them right away before upsetting any customers. The maintenance cost will also be significantly lower.
Provide an extra layer of security – Test-driven development will allow users to gain trust in your product because they can see that it’s working well without any issues. There have been many cases where hackers have exploited the software’s weak spots, allowing them to steal personal information of the user. Testing will provide you with the confidence that your product is safe and vulnerability free.
Helping to deliver a high-quality product – You probably know how vital a great UX and UI is for any software to succeed and stand out from competitors. In today’s technological market, customers are expecting higher quality applications with slick design features and lightning speed responses. Its is therefore essential to provide your customers with the value that the application promises. Testing allows us to identify any bugs or glitches by checking if the graphics are correctly aligned. It can help us check for any compatibility issues by running the application from multiple devices.
Despite the above, most companies are still reluctant to invest money into testing. But why?
The answer is simple.
The results seem invisible. People want to get to the juicy stuff. Customers don’t care or understand about testing; they are too busy to think about “does this app have amazing security features inside it, where is the proof”. Everyone just expects the applications to work like everything else.
That’s until something eventually goes wrong. And the consequences are often catastrophic. Take a look at these historical cases of the most costly software errors:
- NHS IT Catastorpic IT failure: In 2016 the National Health Service (NHS) suffered from a devastating IT failure causing up to 300k heart patients to receive the wrong drugs and advice for treating their problem. The system’s algorithm which use to calculate the risk of heart attacks had failed. Sadly, people at low risk ended up having strokes and heart attacks directly due to the misinformation.
- The Northeast Blackout: A programming error which occurred in 2003, caused a significant power cut throughout ports of the Northeastern and Midwestern US. The reasons were due to a software bug which stalled the alarm systems and prevented software operators from knowing either visually or audibly that a fault in the system had occurred. A hefty price tag of $7-10 billion ensued.
There are many other cases of flimsy software breaking down, resulting in enormous consequences, but I think you get the point. Test-driven development should be your top priority, especially if the number of people using it is significant.
5.comparing yourself to others
This can be applied to any field of work, but I think in software development the effects are much more pronounced because you are almost always working in a team. You hear about how Bob can write complex algorithms with his eyes closed and how Tim built his operating system while he was only 12 years old. These guys are getting promoted almost every single week, and that shiny new BMW parked outside, you probably know who owns that.
Can you see how easy it is to start comparing your self worth to that of others? It’s addictive, and we do it all the time without realising.
The effects of comparing yourself to others can be crippling to your psyche and affect your motivation to work and produce quality work. How will you keep focused if you are always thinking about how other people are better than you? Most likely, you will put enormous pressure on yourself to try and get to their level.
The people around you will notice, either consciously or subconsciously, that you are working hard just to get that promotion. It’s unlikely that they will be willing to support you and in some cases, they might try to bring you down.
As you can see, comparing yourself to others is a deadly parasite which will slowly eat away your very sense of self-worth and ability to thrive in that environment.
Here are four things you can do:
Try not to chase rewards that other people value
For some people, it’s easy to get tangled up in other peoples wants and desires. What may happen is that you start to crave having that same car, you may begin to want the same position or perks that somebody else is having. What you need to ask yourself is, “Am I craving these things because I genuinely want to have them, or is it because other people are chasing them?
If you stop for a minute and think, you will discover that you don’t want these things. You only started to want them because somebody else did. With enough self-reflection and observation, you will simply stop caring and instead pursue more meaningful and intrinsically valuable goals.
Adopt a leadership mindset
Instead of seeing the environment as competition to succeed and how you deserve to get more than everybody else, do the opposite.
Try to provide value to everyone and help them to get promoted. Think about lasting solutions to existing problems and present them to your coworkers and your boss. Doing so will make you look more of a valuable employee. People will notice that you don’t care about yourself succeeding as much as they do. They won’t view you as competition anymore, and you will get along with everyone better.
Realise that everyone is on a unique journey
What makes you different is your genetics, your upbringing and the many different choices you made along the way. You had very little if any, control over those choices. I’m talking about the school you went to, your parents and the kind of friends you got along with. Having said that, comparing yourself to others is like comparing an apple to a banana. Those are two completely different things with a unique texture and taste.
Instead, try to think about your unique strengths and how they can be utilised to your advantage.
Realise that self-worth does not exist in the first place
This one goes quite deep because It forces you to re-wire and think about your core beliefs about self-worth. But I encourage you to stay with me and do the following practice:
In a quiet area when you are free, sit down and contemplate what is self-worth and where does it come from? Who is determining what is worth what? Do that for 10-15 minutes every day for one week, preferably in the morning.
With enough practice, you will discover that self-worth is merely a label that the mind constructs and attaches onto things. That “beautiful” car or big house doesn’t have any worth. None of us as social beings have any worth. Every object out there that exists doesn’t have any worth. The only worth it has is the worth you attach to it and that label is relative to every individual. There is no “absolute” governing rule or entity to say what’s valuable and what’s not. It’s all relative.
You can choose to stop playing this social game because you realise that it’s a losing battle. Remember that no matter how many external things you acquire, you will never feel happy and fulfilled on the inside.
I sincerely hope that the above points have given you some food for thought and I invite you to re-examine your current working habits and come up with better ways of doing things. Acknowledging your errors is a brave thing to do.
I would like to leave you with a simple but powerful homework assignment.
As you go about your day ask yourself the following question: “How will the decisions I am making now affect me or the people around me in the upcoming future?”