One mistake that used to affect my productivity was the "I will fix this myself" mentality. I always stayed with blockers and tried to fix them myself in the false intention of trying to achieve. Now I know better. Ask for help early enough and move on. We work in teams and communities for this reason of complementing each other when we get blockers.

Also, I underestimated communication. I remember implementing dependency injection on some .NET codebase and merged the biz logic. When guys asked what I had done, I did not explain myself so much. I felt that they had to do some homework themselves and didn't want to labor. We reverted and when they got to read and understand, we went back to that implementation later. If I had communicated clearly what I had done, we wouldn't have gone through that much much time reverting and then pushing back the dependency injection changes.

Not unit testing. It’s not that noticeable when you have a small project, but as things get bigger and more complicated, the work required for end-to-end testing increases exponentially.

Not setting a clear end goal before you start. I’ve completed many projects, but the one I didn’t had a fuzzy end goal that I told myself I would eventually define. I never did. If the goal is crystal clear, it will motivate you to keep going.

It took some experience for me to get rid of my prejudices about programming language A always being far worse than language B, and tech stack A being worse than tech stack B.

Sneering at--for example--Visual Basic or PERL or PCs or whatever is not just a waste of time, it's a barrier to really learning the trade of programming.

1. Perpetuated the quick-fix mentality. This is really quite terrible, and a cycle that is hard to break from. Start with tests, code reviews, and continuous improvement on day one, and don't break away from that.

2. Believing technology was inherently valuable on its own. (It is not.) The people you encounter in your career who are not developers (read: project management, executive teams, clients) will likely not understand the value of testing, or the value of new technology for that matter. The more you understand how to translate value into terms that others can understand, the further in your career you will go.

3. Not automating repetitive tasks. I don't know how much time I've lost, but every task you repeat that isn't made more efficient is time lost. See:

4. Understanding my own values, goals, and clear path earlier. If you don't set yourself up for longer-term career fulfillment, eventually you will hate your job, no matter how cool it is or how high-paying it is. Find what you care about. Find your underlying values and career purpose. It is the fuel you need.

Probably every single one you can imagine.

But it doesnʼt really matter. I donʼt even remember most of them, just the fact that I failed badly a lot of times. What matters is you donʼt do the same mistake twice unknowingly. Or thrice, tops.

For the first time, especially if you donʼt have a mentor, you will realise the mistake too late (like, after release.) If the second time happens, you will realise it early enough the thing doesnʼt go to production. And the third time should never happen. Well, unless…

Thereʼs an old saying, “I can do it well, fast, or cheap. Choose two.” You simply canʼt do all of them, and most of the time it will be “fast and cheap”. In those cases you will knowingly do mistakes on the altar of fastness. But this time you can add a comment like:

# FIXME: I know this is wrong, but I had to do it fast.

Learn from your mistakes, and donʼt repeat them unless really necessary. Do so, and your mistakes wonʼt even be remembered.

1. I tried to code before thinking about the problem. It's a dead end really. Your mind can't be but deadpan and dejected if you try this, at least most of the times, because it doesn't make sense.

2. I kept learning more about the language, and kept forgetting all of it because I never really used all of it anywhere — I didn't really have any hands on properly. This was tempting to me, at the start of my career because I wanted to catch up. I wanted to learn as much as possible. But that's not how it works. I wrote about about in this hashnode answer

3. I'd not understand a concept / a problem properly (but thought that I have) and then tried to propagate and stand by my falsified opinion (which turned out to be very embarrassing more than one time). For example when Google first released its Material guidelines (I was in my first week of training in my first job then, with no prior programming experience whatsoever), I thought Google had devised a physical way to provide depth in devices because of the "physical width of the display/screen". 🤦‍♂️

4. I didn't work on side projects. First 1.5 years into my first job, I'd have a seemingly stunning idea, I'll work on it in a weekend, setup a boiler plate, then I won't work on it ever. Last year this changed. I started up with a couple of projects — 1. to set up an alumni system for my alma mater (it doesn't have one) 2. make a small poetry editor. I have failed 3 times trying to build a solid alumni network. My most successful (least terrible) attempt. I've started working on it again. Poetry Editor I had been constantly working on, then paused for a couple of months then I've started again now.

   One astounding thing that I got to learn while working on the editor

5. When I didn't know Javascript Coercion 😅

6. Git Hard Reset Blunder which Tyler McGinnis fell prey for as well — twitter.com/tylermcginnis/status/9647516134192865…

7. Not writing. I come under the people category who have terrible retention power. I'd keep visiting already visited links again and again. Then I gave writing a try , and especially after Preethi Kasireddy started writing. As soon as I stumble upon something unique / needed I write about it either on my blog or on [medium: Web Bos's Learn Node Course Review] (medium.com/@arihantverma/review-experience-wes-bo…).

8. I didn't read enough code. There will come a time, where you'll hit a straight wall. You'll think hard where you should go next. You'd have read every blogpost every advanced coverage of API and features in the docs itself, but you'll struggle to go to the next level to make something real. You'll get tremendous help from very detailed courses like Web bos's Learn Node and Pluralsight's Advanced Nodejs. But even then you'll somehow feel stagnated and not be able to understand why.

   At one point of time or the other, you'll realise that the only way to get on the next level is to read code, contribute to open source. Also really detailed courses like on FrontEndMasters will help, A LOT.

9. I didn't bug enough people to collaborate / generally ask questions. Thankfully (Thank the Lord, Stackoverflow question restrictions were making me CRAZY!) sites like hashnode.com and spectrum.chat came to be.

10. There are a lot of things that I'm still at the level of a rookie . I realised this from this Alex Russell 's answer.

1) I agree with Ujjwal Kanth. That was one of the most stupid mistakes in regards to programming that I have done. However, it's good till an extent when you are ready to check on the other ways to solve the same problem and make it and yourself better.

For example, if you are trying to solve a computationally expensive prime number generation problem, you'll come up with a simple solution with your plain brain. That would be great, implement it and then you'll see that it can be improved. If you miss this step then you'll be extinct soon.

2) Other would be trying to make it look modular, performant, premature optimization and following all standards. Because, as said earlier, the process of learning is lost and many edge cases will be lost when we try to make it very standardized code and fixing those it becomes dirty which is too bad.

3) Also, learning a new language without considering it's reason for creation. Anyone would learn by starting to code, but there's a small issue here.

For example, I know java and I am learning python by solving a problem. In java I need to store data in a format to reverse it and all. If I'm writing the same solution in python replacing the syntax, it's as good as not learning python. Because, I am trying to port a program here. I might even miss simple ways of string manipulation in python which could be much faster ( It may look funny, but it matters when you solve computationally heavy problems like in projecteuler.net). Because, for some problems some languages offer better solutions than others (just my personal opinion though. I am not starting any language wars :J) 4) Considering too much about design patterns, data structures when you're learning a programming language. This might even make you loose the motivation.

Looks like I have given points which even contradict within themselves. Let me know if you find any mistakes. Cheers :)

Thinking too much in terms of design patterns. Sometimes, it leads to over-engineering. The simplest solution should always be preferred, not one that looks enterprisy and following an established design pattern.

Not that design patterns don't have a place or that rookies should not be learning and using them. As a beginer, I concentrated too much on design patterns instead of letting the solution evolve towards one.

The biggest mistake I used to do, which I rectified later, was not thinking enough about the problem and jumping into coding it.

You learn to think more and more as you get more and more experience.