"PHP Bad…Python Good"
The most important things that every new programmer must know before learning anything are usually the ones that are overlooked or ignored completely. Mainly because we don't want to admit that they are correct, either it's not the norm and we should always be "following trends" or because of other reasons related to cough ego cough. People like to dive straight into the learning part and create new and amazing things, which is not wrong by the way, I've done that too. But, I wish I knew some of these tips and facts about the tech industry, learning when you're working, and the shifting technology trends before starting that might have been a big help in my personal learning journey. These tips might prove useful for new and budding programmers who have never worked in a professional environment as I've mentioned below. I'm sure it's going to be a huge help in their learning path and change the traditional thought process while working in development that many people blindly follow. So let's get into it…
1. There are NO bad programming languages.
"There are only two kinds of programming languages, the ones people complain about and the ones nobody uses" - Bjarne Stroustrup
Yup. I get a little annoyed every time someone makes fun of C, PHP, or Java and says that they are not good programming languages. Well, they are, you just either don't need them in your current situation right now or you need to spend more time on them if you're struggling. All these different languages are there for a reason and if over 3 billion devices are using Java or 80% of the internet runs on PHP, then the problem is not the language. The only thing required is practice and yes, sometimes it is tempting to see your friends playing around with Python or JavaScript, creating that cool game and that awesome-looking website with smooth animations but that's okay, you can use them too. Just make sure your goals align with the tools you are using.
Until and unless you are using some esoteric languages like BrainF***, Befunge, or Malbolge, (which is highly unlikely) you don't need to switch the language you are learning just out of peer pressure. I saw this great informative post while scrolling through Reddit and thought it might be of some use here as a guide.
2. Your goal should be efficiency at work.
While working a job, more often than not you will come across multiple ways of solving a problem. And more often than not, there will be an established "traditional" way of solving that according to your colleagues. But you should have the ability to know which solution will be more efficient in terms of your ability and learning speed. For example, it helps to know terminal commands of course in version control and that feeling of power is great when you push your code using Git via the terminal but if you feel more efficient using a GUI like GitKraken or GitHub Desktop then why not use that? You are here to do the job faster and make things more convenient for yourself.
Don't let ego get in the way of being more efficient. The same is the case for languages, practice what you feel makes your job easier because the core principles are the same for every one of them.
3. Those "green squares" on GitHub.
Let's face it, you as a beginner in programming should be focused on learning and building things first as a priority. Creating your portfolio or jazzing up your GitHub profile part comes later. But one thing I usually have noticed is that many developers get stressed out if they don't push their code daily and don't see that "green" square of contribution on GitHub. Guys, chillax. You're not going to lose a job opportunity because a recruiter noticed you did not push anything for 10 days. If you did, you dodged a bullet there because that company has some bad hiring practices. What good recruiters want to see is whether you have the necessary problem-solving skills or not. And if not, then provided the time whether you can learn them or not. That's it.
My point here is, if you do somehow manage to push something every day to GitHub for a whole year, it's an impressive feat but that should not be your ultimate goal. At the end of the day, it's just a vanity metric equivalent to reading 50 books in a year i.e it's nice if you can achieve it but don't worry even if you miss it a few times.
Once you reach that level of experience, you're going to notice that it's going to start happening by itself when you're working on various projects at once. I'm going to write another article in the coming weeks about how to keep your GitHub "busy" as a newbie developer. Meanwhile, here is a very interesting read I came across by Andrea Giammarchi who clearly explains why the amount of your GitHub commits mean nothing.
4. There is no fixed time for daily learning.
Too much of anything is a bad thing, but too much good whiskey is barely enough. - Mark Twain
As the title says, we all have lives apart from just sitting in front of a screen and it's important to hang out with friends, go out and do something fun, and just take a break for a while. I don't mean to say that you should break your #100DaysOfCode streak or daily 3-hour Leetcoding sessions but daily 30–60 minutes of practice also counts as actual work done. So, if you give a whole day to yourself after studying for 1 hour in the morning then don't feel guilty about it. Some days we can work 4–6 hours straight and still have enough energy left to accomplish other things but then there are days when the mind just goes BrainF***.
It is our developer's passion to learn new stuff and create amazing things out of them, be it just another hobby project or something that contributes towards helping the communities out there but when it starts to interfere with our peace of mind and we are feeling overwhelmed rather than relaxed after finishing a project or solving a problem, then that's a signal from your brain that you need to slow things down.
That was it for the "hard to swallow" pills that every new developer should take. There are always more useful tips for newbies that help a lot while learning to code but the ones mentioned above were what I observed from my experience working as a developer and also across multiple social media platforms. I noticed many people were asking these questions on a daily basis so that's why I decided to write this nifty little article. Hope you guys found it helpful. Let me know if I can make some additions or changes to this article or if I missed some other important "pills". My objective for writing these articles is always to give back to the community which has aided me tremendously to become a good programmer.
Connect with me on GitHub, Twitter or LinkedIn. And stay tuned for more stuff ahead! Ciao Guys!
Top comments (2)
Mostly agree, except for the first point. There are bad languages. Java is a bad language, javascript is a bad language, php has been and to some extent still is a bad language. The point is that we some times have to use bad languages and a language being bad doesn't mean one shouldn't learn it. In fact, I'd say learning bad languages is a good thing, because then you learn why they are bad.
Go program in Java for a few months and learn why rampant boilerplate code, rejection of operator overloading, and overuse of wrapping classes make for a bad language. Go program in javascript for a few months and learn why the need for
===is a sign of a bad language. Go program in php for a few months and learn why lack of consistent naming conventions, over proliferation of similar yet different solutions to problems, and general lack of language design direction makes a bad language.I understand your point, new coders shouldn't avoid learning important and popular languages just because they are bad, but we also shouldn't blow smoke up people's behinds and pretend that all languages are good when that simply isn't the case.
When I say, there are no bad languages, I do not mean it in a technical or syntactical way. Nor am I advising anyone to commit themselves to learning PHP, JavaScript or Java even when they don't want to. The only thing that I want to convey from my first point is that no language is without its pros and cons. If we dig deep enough, every single tool out there will have its own disadvantages but that does not mean that we should stop using them out of minor inconvenience. We just need to align our goals and what we want to achieve and then choose the tool accordingly.