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!
Awesome insights... I only deffer from the Pointing Fingers part. I think that everytime something goes wrong there should be someone representing that process that everyone should keep an eye, not specifically to tell them "this is all your fault" but to try to avoid these mistakes in the future, in special when you are part of a team where everyone is rotating from a roll to another. This is where team work should come in hand and someone that has any knowledge related to the topic should say "hey man, got your back let's do this together". Let people do mistakes, take responsability, and rel on the team for a solution.
Great article!
For 7 - currently the atmosphere is not judgmental, but because on several occasions different devs(including me) stood up and said in front of everyone "Sorry guys, it's my fault. I'll fix it." everybody started to take responsibility(at least for most of the time).
For 6 - unfortunately recently on several occasions I see no desire to even discuss problems or take actions, that affect all of the teams, even when ideas to fix them are presented. It is really frustrating and sometimes ruins my mood.
React engineer, really? Wow that's a bit ... Okay that leads me to a problem I have with the industry, I have been in the JavaScript (and more) game for quite a few years. All the jobs today look for experience in React or Angular or Vue. But do you know what SHOULD superspeed this, being damn good at JavaScript and an excellent developer, but noooo we want React engineers 🤦♂️, it's like saying I want a Bagel mechanic instead of a Baker.
I would take it one step further. You want people who can code. How to think through a problem logically and then execute in the language/framework of choice. What happens to those JavaScript Devs when we all switch to web assembly and blazor
Like me, I would hope that they would have spent some time working with WASM, which is still very much a symotic relationship with JavaScript, which is still required, I know because I wrote a Lua to JavaScript interop framework.
Besides WASM at the moment is very much an MVP, I highly doubt there will be a mass extinction event for JavaScript for atleast another 10+ years.
I do agree however, "I am developer" is a very positive mindset and desirable.
Out of interest why did you pick Blazor for an example?
Well, that's what the point is. Don't define yourself with a language/framework. If we switch to web assembly and blazor today all good devs would switch to it eventually without advocating for 'React' only
Enter react C# equivalent. If only WASM had true direct access to the DOM, but it must go through JavaScript.
They are hiring wrong and it's unfortunate that people get impacted by the practice of the current trend, IMHO....
If you are a capable dev, you can always learn. May take a little longer but if they are good at running their team, department or company.... they should understand this.
Pick up traits of devs, not a particular framework sometimes. By traits, I mean different degrees of traits to get the fit correct. I can be risky at times at initial phases but near prod I have a good sense of risk. That is a good thing.
Some places just want the latest thing so they seem cutting edge or whatever. It seems pretentious and not necessarily the better solution for the need of the company or the problems at hand.
Unfortunately, when most of the people starting their careers look around and see that almost everyone is working on the same thing, every company is demanding engineers with experience on that technology, the impression they get is that this is the only thing they need to learn to do great in their careers.
Great summary. Espacially point 3 is so true. I work as Software Engineer for over 6 years now and I started with PHP and still write PHP. But as you might know, PHP is not the most loved language out there ;)
But still, I like it. Not because it is PHP but I discovered that I can do many things with programming and I learned that it is not the language. I have been part of so many discussions about "The best language" or "PHP sucks". But nowadays I simply ignore those and keep going. The language (or framework) don't define me as a programmer.
The same is true for so many things: Mac vs. Windows, Nikon vs. Canon, etc. People seem to like to identify themselves by their products. But in the end they use "just" a computer, or taking photos. The photography community like to say: "It's not the camera, that takes the photo, but the photographer."
Great list and agree with all of them thanks for the insight