There is a lot of content out there discussing what you need to do to become a good programmer. What concepts you need to understand, what technologies you need to learn, what tools you have to know, etc. When I joined the tech industry 2 years ago with dreams of being a great programmer who will change the world with code one semi-colon at a time, I had a mental list of what I need to learn in order to be an awesome dev. Over time I have learned that there should've been a list of what not to do as a programmer, dev, software engineer/ninja or whatever you call yourself.
I'm trying to put together a list here to keep reminding myself and for those who have just started their careers or are going to, soon!
1. Do Not Fall In Love ❤️ With Your Code
The number 1 mistake a lot of devs make at the start of their careers is treating their code like their babies or pets.
Sure, we all love our work but always remember what your end goal is, to write good code and collectively contribute to making the product/project you are working on better every day.
When you don't attach your feelings with the code you write, there is a better chance you'll always try to make it better and not let your feelings come in way of improving it.
2. Do Not Try to Learn Everything 📖
The kind of business we are involved in, there is always something new around, that new JS framework, a new library or another new productivity tool.
Do not lose your focus by thinking that you need to be expert in every tool and technology that is around. Keep exploring and trying out new technologies and stacks but always keep your focus on something particular.
3. Do Not Worship Frameworks & Languages💎
Sure keep your focus on something particular but at the start of your career do not try to put a label on yourself. Do not call yourself a ROR Engineer or a React Developer. Sure you work on React but do not let that define you. Frameworks and languages will come & go, you are here to stay!
4. Do Not Feel Proud if your Team Depends Heavily on You 👦
One thing I always thought of something to be proud of was doing a lot of heavy lifting in a team. I always thought the best programmer would be the one without whom the team will not be able to function. Do not try to be that guy! Teams that have a uniform distribution of responsibility and workload are less prone to failures and crisis. Always try to enable other members of your team and not keep the knowledge and expertise to yourself. Do not try to be that hero who's always there to save the day!
5. Do Not Mind 😠 Negative Feedback
Always assume that other people who work with you want to see a better self of yours. Do not take criticism or negative feedback from your coworkers as a personal attack on you. Listen to the feedback, contemplate and try to improve.
6. Do Not Keep Complaining ⁉️
Always try to take initiative rather than complaining. Realize the fact that even as a young or junior dev you are now part of the team. Do not act as an outsider who keeps complaining rather take initiative and suggest options to make things better.
Note: This does not apply at all in case of abusive, threatening, discriminating or harassing behavior. Do not wait a moment to report any such behaviors.
7. Do Not Point Fingers 👉
If something goes wrong e.g a deployment fails, bad code gets into master or a server breaks down, do not start pointing fingers at individuals. Teams operate as collective entities and take responsibilities as groups. Sure, you want to find out what went wrong but that does not mean you single out individuals and blame them.
8. Do Not Remove Your Work-Life 👪 Boundaries
Keep in mind that you have a life outside of your profession. Do not let being a programmer come in way of having quality time with your family, quietly reading a book or going on a vacation.
All of my observations come as a junior engineer with 2 years of experience only. My opinions could also be biased only by the kind of teams and people I have worked with.
Junior devs working in teams early in their careers, what do you guys think of this? Senior, more seasoned guys correct me if I'm wrong or want to add something!
Edit: There are some brilliant new points and discussion on these in the comments section. Please go through those as well, happy coding :)
Latest comments (63)
Great article! For me, number 4 is the most important point on that list. Well-written article, congratulations!
Great list!
There is some great universal advise. But 1. is definetly worth mentioning. Learn to love throwing away code. Especially it it is your own.
Always blame the code, never blame the developer.
I agree with everything, thanks for remember these very important rules
For some of the points, I would add - be that way, but don't automatically assume others will as well.
Yes, you shouldn't "take criticism or negative feedback as a personal attack". But the robustness principle applies here: be conservative in what you do, and be liberal in what you accept from others.
Other co-workers are only humans, and they may not be able to accept dry criticism. Yes they shouldn't be attached to their code, but they always will. We naturally are kind of attached to something into which we've invested hours of work, even if we know it's better not to. And you're particularly likely to be perceived as aggressive or confrontational if you criticize in writing (as in in code review). It's easy to fall into the Sheldon Cooper syndrome, whereby in your mind you're only pointing out facts, while you come across as a douche to the people around you.
For that reason I would recommend some extent of cautiousness in critizing others.
Never assume bad intentions or incompetence by default. My key phrase in code review, whenever I suggest what seems to be a clearly superior alternative, is: "what am I missing?". By stressing that I understood they could have had some valid reasons for what they did, I make the criticism much easier to swallow. And guess what - once in a while I am indeed missing something :) And then I'm quite glad I spoke out with some reserve.
Sweeten your criticism up with a bit of praise. For every 10 critical remarks I leave in a code review, I try to find something that I like and point it out. It costs nothing, and it creates a more friendly atmosphere.
Another keyword that I like is "we". "I'm afraid you're making this function too complex, you really shouldn't be mixing async logic with business logic here". No: "Aren't we making this function too complex? We shouldn't be mixing..." - and so on, you get the idea. It costs absolutely nothing, and it communicates a totally different approach. Collaborative, non-confrontational, goal-oriented and helping to detach everyone from the code they wrote through positive, constructive mindset.
Just my two pennies.
Thank you for writing these down Konrad. All of these make absolute sense and are very vital traits to learn to promote an environment where nobody feels attacked, questioned, or not trusted enough!
Students coming from cut throat academia competition environment should understand these as soon as they can!
9 - Stop trying to change the things you cannot change (eventually). It is positive and useful to argue that a particular framework should not have been used, architectural decision should not have been made, vendor should not have been overlooked and so on... but, sometimes you are just stuck with the results of decisions made long ago, that will not be unmade anytime soon. Sure, I'd much prefer that the heavyweight Java services in my current project were actually lightweight Node endpoints or even written in Golang, but the client has spent thousands of hours and many, many dollars building on that stack, so it's not going anywhere right now. Roll up your sleeves, and learn to work within that limitation.
Great list. As a senior I have to remember (4) in particular. It's always my goal to make myself dispensable.
This is a great point Daragh!
I had something similar in mind when writing #6 (Do Not Keep Complaining). Teams which know their limitations and find solutions within those rather than spending hours of discussion on 'what should have been done' are happier I guess and more productive.
Yes I was originally thinking of it as 6(a)!
Awesome list, so very much resonates with me.
Awesome list Hasseb!
For so long I thought that programming was my life and if I didn't write code I had nothing. Almost all the time I was sick and tired but when I realize I had to have a life outside of the code and I had to recover those boundaries everything improves in my life.
So, to every person in the coding work be careful and do not remove your Work-Life boundaries.
That's an awesome list.
Fantastic!