A clever person solves a problem. A wise person avoids it – Albert Einstein.

I am a firm believer that picking from the experience of others is better than depending just on your own experience.

In My seven years of being a Software Engineer, from writing my first code on paper (I couldn't afford a Laptop) to building software for companies with millions of customers. One thing that has helped me a lot is learning from others.

And in this post, I want to share seven useful articles that have made a big impact on my coding journey. I still go back to them even today. I have bookmarked and have read some of them more than 10 times.

I believe by going through them and taking them seriously, they might make a big impact on your own journey.

1. Teach Yourself Programming in 10 Years

Why is everyone in such a rush? - Peter Norvig

I began my programming journey after seeing an ad "Learn Web Development In 8 Weeks". But 7 years now, I am still learning. If we divide that into weeks that's 365 weeks in progress.

This is a post written by Peter Norvig. It contained very realistic advice every new programmer needs to know. Despite the year it was published, nearly every single piece of advice still holds true for beginners.

When learning a new language it is easy to think you can just pick a book or watch a 1-hour video on Youtube and Boom! You are now a master coder.

Far from reality. Research has shown that it takes about 10 years of deliberate day-to-day practice to develop expertise in a wide variety of areas, including chess playing, music composition, telegraph operation, painting, and piano playing.

In the article, Peter mentioned how if you walk to any bookstore you'll see how to Teach Yourself Java in 24 Hours alongside endless variations offering to teach C, SQL, Ruby, Algorithms, and so on in a few days or hours.

But teaching yourself Javascript in 24 hours means you won't have time to write several significant applications and learn from your successes and failures with them. You won't have time to work with an experienced programmer and understand what it is like to live in a JavaScript environment. No deep understanding. You might be able to learn some of the syntax of JavaScript (if you already know another language), but you couldn't learn much about how to use the language.

The conclusion is, to be a programmer: You must be **passionate about programming; you must program; talk to other engineers; read their code and collaborate; Learn multiple languages with different styles, not just OOP languages. And that will take some time.

It's a timeless article. And it is worth bookmarking.

2. Don't Call Yourself A Programmer

This is one article that made a quantum leap change in my journey. It was written by Patrick McKenzie. I have read it many times.

How do you write your Twitter bio? how do you tell others what you do in a few words? For many of us, we usually go according to the common flow:

• Software Engineer.
• I code in Javascript, React, Nodejs, and Python
• React developer at X Company

But the problem with calling yourself just a software engineer is agreeing to the fact that someone is already working on a way to get you fired. If you have 5 years of experience and you call yourself a software engineer. There are at least one million engineers with 3+ years of experience who will also call themselves software engineers. What then is really your difference? first impression counts. To people who sign checks, both of you are the same.

How do you tell everyone you are different without them digging into your experience? you don't have a second chance. I recommend you bookmark this article, it is full of other career insights.

3. Always Be Shipping, Always Be Writing

This is another career advice from Jeff Atwood, the cofounder of StackOverflow. Old article, but his advice is still valid. His advice made me begin writing online in late 2018.

I must confess, that I haven't taken this advice aggressively. I have written very little content. The reason is that those few contents brought me multiple gigs that ate the time I have to write. I remember vividly how the CEO of a local startup sat with me in a Domino Pizza store with an offer to lead his technical team. I asked him how he knew me and he replied that he read one of my articles online.

My Dad usually says "your signpost is your work". Jeff, in one of his older posts, mentioned there is no use in being a programmer without sharing or communicating. An experienced programmer who has something to say should spend less time coding and more time communicating.

And think of it, that is how you put your name out there. I highly recommend you add it to your bookmark. Also, you may want to scan through some of his 2007/2006 posts for a better understanding of this.

4. The Pragmatic Programmer

I read the actual book, during the Pandemic. It is packed full of quality career advice. You can get the full book for yourself. However, this Github post did a great job of summarizing the most important concepts.

Is there something broken in your company you want to fix? is there a project idea you want your manager to approve? Rather than making a big request of what you want, why not try to understand the situation at hand and then make a move that generates curiosity?

A Pragmatic programmer is proactive. Fix problems before they get bigger. Open to new technology. He or she is willing to drop an existing knowledge in their portfolio and move to another.

You may not have considered - not all programmers are the same. There is a big difference between a pragmatic programmer and a normal one. The concept in this book can get anyone ahead. I highly recommend you check it out.

5. To get rich, make something people want

This is not your typical programming advice, but if you want to get rich, one way you can do it as a programmer is to make things people want. This advice is from Paul Graham, a famous Lisp programmer and founder of YCombinator.

You may not necessarily want to get rich and just reading his post alone won't increase your bank account - it may even reduce it. But it encourages you to create things people want - even for your fellow programmers.

How do you make a shirt and sell it to 3 million people? You have to go work for Nike or Dior Clothing. But Josh Wardle a single developer created a game and sold it for over one million grand - very unlikely in other industries that have been over-industrialized.

According to PG, to get rich you need measurement and leverage. Shipping a game to Playstore automatically puts your app in the reach of more than 3 billion people. That's leverage and you can cheaply measure the amounts of downloads and active users.

I have read this post twice in a year since 2017 just so I keep making things. I highly recommend you also bookmark it and read it anytime you noticed you stop making things. Many side projects have become unicorns, including the popular Replit.

6. Have a Maker's Schedule without ignoring the necessary

This article is geared toward technical founders or programmers working on a side project with a full-time job. Managing your time is very important. The more you grow as a programmer, the more important it is you have to allocate your time for things properly.

As a technical founder, you have to learn to manage your coding time and the time you spend talking to customers or doing other boring things like partnerships. If you are a programmer with a full-time job, how do you manage your time at work and also allocate time to work on your side project?

This article may not be for every programmer, but I recommend you give it a read. It's on my bookmark. Written by Paul Graham, it provides valuable tips on managing your schedule as a programmer.

7. Learn to explain your simple projects to any employer

This is an amazing article (written just a week ago by Julia) which already gained some attention. And I must admit, it's full of examples. It's something I wish I had when I started coding.

Jeff Atwood in a tweet mentioned how naming things is among the two hardest things in programming.

To a programmer, explaining things is like throwing an exception, not something usual. We expect people to understand us. Less code documentation; fewer comments; single variable names.

But, if you want to win, you must learn to explain yourself and value your experience. How do you do that? how do you demonstrate knowledge to an employer with simple projects you have done in the past? That's something you won't bother about after you give this article a read.

That's all for this post. I hope you found them useful.

Thank you for taking the time to read - I highly appreciate it.