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 :)
Top comments (63)
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.
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."
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.
Hmm... Word! @Newton's quote.
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.
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.
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!
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.
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.
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.
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.
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.
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
Thow shalt not over engineer. (That's something I just can't shake)
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
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 ⚡
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!
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."
I see #4 all the time. There's always the expert guy who is the expert because he gets all the work and continues to get all the work because he is the expert.
And then management is like: "yeah we know but we gotta get this done"
.... management is getting pushed around lol... No offense but they got to do better than that. It's a hard job to be unwavering when they start pushing hard, but your leads/manager/whomever gotta help out to negotiate. They are going to cripple their team....
It goes faster long term to include everyone but someone has got their short sighted glasses on as well.
This can come from many sources, from what I've noticed.
Totally agree. It was both management being short sighted and Devs not stepping in.
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)!