When I was starting out as a coder, I didn't quite have the right mentality. I know that I could have used this information when I was starting out.
The structure of the post is made so that I will first cover a general topic, and then focus on the relevancy to software development and the coder community.
Dealing with motivation issues
First of all, you should be generally motivated in achieving the goals you set for yourself, but it is even more important that you generally enjoy the process, not only the achieving itself. I can't stress this enough, because over longer and more advanced projects you might not get any real achievements for a long period. I used "generally" because this may not always be the case. Life is not all happiness and lollipops, yet a good life strategy may be to optimize the amount of lollipops you can squeeze out of life. Like it or not: when setting goals, there may be topics that need to be covered that you don't like at all. In fact you might really hate them. There will be times when you get really demotivated. How should you deal with them?
If you find yourself hating on a lot of the things you need to do in order to achieve those goals, it may not be a good idea to continue with it, as just being happy with "the process" is a lot more important than achieving goals. But you shouldn't quit that easily either. Why? Because in the end, it might be worth it. Achieving your goals will feel good, and if you get through this mess, you can start doing things you like again.
Here are several methods I use to overcome those "depressions":
- Even though you might hate it, try your best to like it. It's a lot better than constantly convincing yourself that you hate it, you would only make it worse
- Get some fresh air, take a break, do something else for a while and come back to it later. Get some happiness going on.
- Remind yourself why you're doing it.
- Pride and stubbornness: don't accept defeat.
- "Just do it". Hate it as much as you want, be demotivated as much as you want. No matter how you feel just do your job, like a machine would do his.
The last technique I mentioned seems to work best for me. These are just my techniques, they may work for you or they may not. You should find out for yourself what works best for you.
Relevancy to software development:
- In longer projects you might have to code some things that you hate, and there will be times when you get demotivated for various reasons. When you do, it is important to analyze the situation and decide if it's worth going through with. Sometimes you may think you don't have a choice, but there always is a choice. Sometimes it's just difficult to deal with the choices you have. In group projects where other people depend on you, the choice is a lot harder and needs a thorough analysis before you make a decision. It is best that you make this analysis before you begin working on a project, but it is not always that evidential from the start. As you get more experience, you will be able to judge those projects better from before you start working on them. But there may always be cases where you are mistaken.
Dealing with competition
A lot of people have issues dealing with competition. This includes myself. I come from a competitive online gaming environment. This environment is filled with flaming and jealousy, because they all want to be the best. They all work hard for their skills and want to be noticed for it. Not only that, they need to feel and get accepted as being superior to others as well. Yet not everyone is talented enough to be among the best. There can only be so many. This does not apply to all competitive game communities, and certainly not all competitive gamers, but it does to most.
I am not saying that competition is a bad thing per se, but it can be. Competition can lead to a huge motivation and productivity boost, but it can also have quite the opposite effect. How competition affects you is personal, thus it is important that you find out for yourself how it affects you. Because of experience, I know that I generally work better when focusing on my own performance instead of that of others. When actively competing, I focus too much on the performance of others, so I stopped doing it. I do however have a natural urge to compete, and I do so passively by comparing myself to others once every so often. Sometimes it stimulates me and sometimes it doesn't, it's just something that is in my nature to do.
If you choose to be competitive and you think you are good at something, one common mistake is bragging. People will dislike you for it, and it will only lead towards your own dismay. You do however might want others to respect you for your hard work, but doing so forcefully and calling others amateurs is just not going to work. A good approach may be to use your skills in a positive way, for example: use it to help others, and others might respect you for it. Really, being modest goes a long way. Another advantage of being modest is that you understand that you have flaws, and only by recognizing them are you able to work on improving your flaws.
Try not to be too judgmental on others. This has a lot of good reasons: for starters, you never have complete information. Secondly, if you judge others, you often do so starting from your own moral framework/perspective, but they most likely have different goals and standards in life, and there is really no objective way to deal with morality.
Anyway, in general, people may respect you or they may not. It may feel good if they do, but the most important thing is that you do what you enjoy, and not what others think you should do.
Relevancy to software development:
- You can always learn from others. By helping other coders, they will also be more willing to share their knowledge with you, on condition that you stay modest and keep a healthy relation with them.
- If you find that being competitive has a good effect on you, then try to compete with others who want to do so too. However, always keep it healthy, and don't do so if you notice it has the opposite effect on you. I can tell you that most serious coders don't like actively competing though, so take care in doing so.
- Don't judge other coders too much, because people won't like it.
Dealing with pride
Some people say pride is a blessing, others say it is a curse. My opinion is that pride is a curse until you know how to use it to your advantage.
Pride leads to two things:
- you will persevere through hard times, and you will not easily accept defeat. Side effect: If you do experience defeat (and sooner or later everyone does), it will be hard for you to accept it and you will either frantically want to keep trying to the point where you hate everything about it, or you will just get extremely demotivated.
- you will generally put a lot of hard work into your goals. Side effect: you might force people into respecting you for it, and as I mentioned earlier, that will only lead towards your own dismay.
Therefore, I believe that pride is only good when not taken to extremes and when you found a way for yourself to handle the side effects.
Setting the bar too low will just lead to sloppiness. Setting the bar too high will lead to frustrations. As with so many things in life, it is important to achieve balance here.
Relevancy to software development:
- Don't act like you're the biggest and brightest coder in the world, because first of all you are not, and secondly it will only lead towards your own dismay. Contrary to what most believe, coders who make a lot of noise are usually the 'lower rank' coders with an irrational idea that they are somehow a lot better than others at what they are doing while only having little experience. (this applies to people in general)
- Use pride to overcome tough project situations, but use it with care.
- Set coding standards for yourself, but don't bite off more than you can chew.
Dealing with the hammer of experience
You have the urge to be good at what you do. Thus, once every so often, you want to try something more challenging. This is a good thing. But sometimes you will want to jump so far ahead that you won't make it, or only make it with one leg. The moment that happens, you have hit the hammer of experience. The hammer of experience is a bit like Chuck Norris: it will always win. Don't try to jump too far ahead, as you will miss out on important knowledge/skills. You will get holes in your skillset and eventually, it will crumble. Therefore I think it is a lot better to advance at a pace you can handle.
It is very important to completely grasp the basics first and all the skills leading up to a certain more advanced skill, because if you don't have a good base then you won't be able to build well upon it. This is a lot harder than it sounds. Also, it may be a good idea to refresh your base knowledge once every so often, to prevent forgetting it partially or completely and having to start all over again. Always keep a strong base, because the stronger it is, the easier you will deal with tougher situations.
You should occasionally challenge yourself too, because that is the key to improvement. Just don't jump too far ahead, because you will end up crying for your mommy like a little child. Eventually, you will be able to beat your previous 'hammer of experience' and set a new one.
Relevancy to software development:
A lot of beginning programmers have huge issues with the hammer of experience. They tend to bite off more than they can chew.
- Try to work on basic skills first: learn a language, learn it well, then learn the basics about algorithms.
- Don't optimize prematurely, optimize smart. In fact, don't optimize at all until you know it is necessary, but don't pessimize prematurely either.
- Don't learn assembly for optimizations or to be cool, learn it to understand how a computer works.
- It may be good to focus on doing more smaller projects instead of doing one huge project, especially when learning. In huge projects a lot of beginning coders have the tendency to hit the hammer of experience. Also, if you think you have enough experience to handle your first big project, then focus on getting the task done first and keep it simple before you try to implement impressive algorithms or something similar. Because if you do those harder things first, you will endanger the project.
