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 :)
Oldest comments (63)
Nice article. Many juniors should internalise this, including my younger self ...
Agree, and many companies should print and display this list in every IT department! Mostly the job/personal life balance...
Thow shalt not over engineer. (That's something I just can't shake)
Haha 😆
This is something to stick to forever, should add this one to the list.
Do it, but simply wrote, not to many thrills just the MVP ⚡
Or the KISS principle. Keep It Simple Stupid
Mini! I'd flash you if I still had mine 😟
The picture isn't mine, I have one, but no where near as good condition
Awesome list Haseeb 👏👏👏
I am guilty of some of the points that you included here especially no. 1, 2 and 3 but I'm working on that 😌
If I may add one thing, it will be:
Do not be limited by your role or job title.
Just because your title says you're a frontend engineer, backend, etc, it does not mean that you should limit your team or project involvement in that specific area only.
Participate in the team discussion when there's a new feature, an issue occured and you're all coming up with the best solution.
Trust me, you will gain a deeper knowledge on the project, it's overall architecture like how the API is structured. Because even though you don't have a lot of experience on that area, you can provide a different perspective on how to approach the problem.
What you suggested may not be the solution but your insight can help your team members look at the problem in a different way, they can build upon it to come up with a better solution.
In my personal experience, there were times where the answer came from a different source. For example, there was a time where we experienced several server downtime in a day, our backend engineers initially thought it was caused by an unoptimized code and so they optimized it but still the problem keep occuring. It was not until I suggested that maybe it is a DDOS attack and it was actually a DDOS attack.
Another time was when I was the one facing a problem on the frontend, our iOS engineer came up to me and suggested me "why don't you do this instead". He came up and suggested me a brilliant idea which we used to come with the solution. I was really grateful to him for that, it saved me a lot of time.
Build on each others ideas.
And speaking of that, here's a quote from Isaac Newton which I believe is relevant to that idea.
"If I have seen further than others, it is by standing upon the shoulders of giants."
Hmm... Word! @Newton's quote.
Yep, this is a very good example. I am sure your confidence and the feeling of belonging to the team went high after participating in something that was out of your job description. It's these little things that help us stay motivated and move forward!
You're totally right, participating in those kind of discussions also add some sense of camaraderie among our team since I know that I can always rely on them and they can rely on me during challenging situations.
Thank you for the kind words, Ana! We all have been guilty of these at some point in our careers, but hey this is how we all learn.
This is a great point I think, this is how you grow as an engineer/dev/programmer. If you want to be a leader in the team this is the right way to go. Having a 360 view of things also helps you put your work into perspective and understand how everything fits together.
True. However, depending on the culture or individual sense, even if you feel that you are not tied down to a title but you have a decent idea and it's not your area, you can have pushback... do not worry. I ended up speaking directly to others to gain more understanding and it made it easier moving forward for my ideas and troubleshooting.
Being seen as just x or just y is not encompassing of all our abilities and it sucks when people push it on... when you have also their education as well or other experiences they may not know about.
Have respect and listen to your teammates, please. Good ideas come from everywhere and better ones come from more than one person as its worked on, vetted and applied. There is not just one single person.
The mistake is not one limiting people to title, it is also assuming things, and thinking only one person has "the idea" and that's it. It takes the team.
Great list and absolutely true. I saw most of these points especially on seniors and I say that considering myself a senior as well. 😉
Also, I cannot stress 8 and 4 enough! I'm trying to work with a "make yourself replaceable" attitude: document stuff, engage and empower the team members, communicate. There's nothing worse to be called up when on vacation.
Making yourself replaceable makes you irreplaceable because no one else will be that type of developer.
Hm? What do you mean?
By being the member that is fully communicative, documents impeccably write code for everyone else, you are much harder to replace. :)
Ha! That's why it's working so good. 😂
The team I'm on is about to lose someone who manages to be both. He's an amazing developer who can do stuff twice as fast as the rest of us but also documents and shares everything and doesn't hesitate to help anyone.
We hate to lose him but the plus is that he's the kind of guy who is leaving everything we need to get up to speed.
I think he's probably doing the best both for you and himself, you'll be able to function effectively even without him and he'll always be remembered as a good guy in the company who laid foundations for everyone.
Mr Haseeb... Please, can you help make a list of this ?
"What one 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..."
These are all very open-ended questions which a lot of people have tried to answer over the years. I'll surely share my opinions when I think I have something solid and productive to add.
I agree with all of your points, but regarding nr 7 (don't point fingers):
We don't blame people externally, so we take responsibility as a team, but we do find out who did it internally and explain what went wrong to them, so that they don't do make the mistake again. If you can always do this in a playful/constructive way, you're an excellent team.
This is excellent. I wish I could apply this approach in every company where I work. It doesn't help if we don't investigate the mistake and don't try to learn from it.
Totally agree with your point. Understanding your mistakes and not making those again is how you grow as a professional.
I think what I wanted to say is that in time of crisis or failure it is not nice to have a culture of throwing the blame off your shoulders and on others. Definitely, a good practice to have a calm and cool discussion later to find out what went wrong and who was at the heart of it.
Fair, but usually the person has to accept the responsibility of their part. I'm responsible for my code. If you are honest with yourself, it's easy to say "Sorry guys, I screwed up", but I have felt in some places that it was unsafe to do so, which is unfortunate because it prevents people from taking responsibility, because they are shamed or judged upon it.
Currently I feel safe saying I screwed up and it really helps. You also have more mental room to catch things before they become bigger issues down the line.... I consider it a very important part of culture.
I've found making it safe for people to report issues or safe for saying "I screwed up" helps the team. :)
Great points Kat!
Nice one
"1. Do Not Fall In Love ❤️ With Your Code" - so true, yet I fail to avoid this every time!
I would add
Don't reinvent the wheel
Many developers I've come across are disappointed in a particular CMS or framework, then struggle for long periods of time to build it themselves, and then realise that what they've built is hard to maintain and definitely not an improvement on what they were trying to reinvent in the first place.
I had this exact problem in my last job. The lead dev did not like Redux, so he decided to build his own state management library, which the rest of us had to learn to use with minimal docs. Suffice to say this also caused all sort of problems with other libraries and of course there was the issue of him creating newer versions that were not backwards compatible.
I know this comment goes against rule 7, but I had to vent :D
Hi haseeb, lovely write up. Pls can ubhelp with some remote gigs. I work with JS and PHP. Majorly back end. Thanks
Hi haseeb, lovely write up. Pls can u help with some remote gigs. I work with JS and PHP. Majorly back end. Thanks