While sitting in the deep nights behind the screen, practicing your craft, building projects, and learning new libraries, you were putting your best into mastering technical skills.
For sure, those skills are the primary pillar of the developer. The pillar that makes you a great engineer.
It didn't make you a great team player though.
To be a great team player means a lot of things. But probably the first one is to be reliable.
Unfortunately, I've seen many engineers misunderstanding the idea of being "reliable" as being able to solve any technical problem alone.
And that is exactly the opposite.
Let me share two principles, that I've been advising junior developers to stick with during my mentoring practice.
You may find many other principles, but these are a good starting point to make you a little bit better team player.
Which is what will help you to succeed in your first (and all next) developer job.
Principle #1: don't listen to your ego — talk to your team
Let's say, you got through the onboarding process in your first tech company, started your first task. You created a PR and got approved by your colleagues.
Enjoyed your first lunch with the team. Maybe got in love with a cool QA girl (or a boy) along the line. 😉
In the next few weeks, you were successfully closing tickets, finishing tasks with confidence. Had a few One-on-Ones with your manager or team lead.
Team lead
— The team likes you. We believe you are really competent - you solved all the problems without much intervention from your mentor. On top of that, you have a great personality, I believe you are a great match for the team.
You
— I'm glad to hear that! Thanks!
Finally, feeling proud, you start taking on more challenging tasks. And here you stumbled upon a hidden issue.
During the ticket, you discovered a problem you can't figure out how to solve. You going through it that day. The next day at the morning meeting, you say that "I encountered an issue, but I should be able to solve it today and continue with the rest of the task". Well, how could you not?
You tried again but couldn't crack it.
Maybe you found a probable solution, maybe you didn't. But the second day is getting to the end and there's still no clear progress on the task.
Let's stop here for now, as tomorrow you can just as easily say "I'm almost finished" again.
The problem in the exaggerated example above lies in your ego. Don't get offended, we all have that.
Well, it is your first developer job after all. You've finally got appreciated for the efforts you've put so far! For sure, you want to meet the expectations of your teammates.
At the same time, you likely want to have a successful career with rapid professional growth that shatters the assumptions about career advancement.
There's nothing wrong with those thoughts. But let them overrule you and you end up losing the ability to think critically in that situation. And we've seen what happens if you lose that ability: you won't ask for advice and instead, you will deal with the problem on your own.
But the thing is, if you care about not losing the credibility and actually proving that you are exactly who the team believes you are, you need to do exactly the opposite — you need to solve the problem together with your team.
Speaking from a business perspective, when you do not have a huge piece of responsibility for a product, if you take 3 days to build a feature instead of 1, you will not cause any harm — or at least any unsustainable harm that may make people think you are not right for the job.
Instead, you will show that in front of a challenge, you don't speak - you wait, hide, and play solo. Not a kind of team player anyone wants.
Notice, that we do not talk where is the team lead or your senior colleagues and why they do not intervene. We talk about your responsibility here as a team member.
You have to be reliable.
Being reliable means that you address any problem head-on, transparently discussing an issue and sharing your thoughts, especially if you are not sure how to solve the issue.
The takeaway: try as hard as you can to ignore the ego and always go and talk to your team. Tell about a problem, ask advice or start a discussion — anything to make it clear that you encountered some issue and not sure how to deal with it efficiently.
Don't get yourself to be blindsided by the feeling that asking for help will belittle your professionalism in the eyes of others. It won't.
Principle #2: Be braver — say (nonsense) aloud
The second principle is closely related to the first one.
Being part of the team also means taking a part in team meetings. Those may be brainstorm sessions, tech discussion, product meetings — as they say, meetings for everyone on the house!
Those meetings may be barely 3 people in one place or a room full of different specialists. No matter where you are, you might get afraid of sharing something as you don't want to end up saying a silly thing instead of the next brilliant idea.
Unfortunately for you, I'm about to say something you might not like: when you have an idea, a thought, or a feeling — even if it seems bold or unusual — say it aloud.
Yes, you may find yourself saying something obvious, inaccurate or even ignorant. If that's the case, people will say what's the issue with your suggestion and will move to the next thought.
They may do it roughly or more professionally, explaining what's the issue with the suggestion, but they will.
No matter how they do it, you end up learning about your product or technology a little bit more. And what's even more important, the chances of you bringing a meaningful and valuable opinion to this and future discussions have increased. That's super great!
Moreover, your thoughts do not have to miss the target all the time — and they actually will not.
First of all, you have fresh, bold, and full of raw potential mind of a junior engineer — this something companies are stacking on. This mind enables you to see the problem, without being restricted by knowledge of subtle nuances and tangled technical details of the product or technology.
You are looking at the "naked" problem, so to speak. It doesn't only mean that you are unaware of edge cases — it also means you are not limited by them.
And finally, you are closer to the user of the product so far than any more experienced engineer: they have been working in the tech field for quite a while and are super biased. Yes, you're biased too. But immensely less than anybody else. 😉
So my takeaway here: Don't hold on yourself back - speak up your mind, even if you think your idea might be nonsense. The more you do that, the more valuable ideas you bring to your team and your company.
Final thoughts
To shine in the workplace, especially in your first tech team, don't just bury your head in the code.
1. Look out for your team, talk with your colleagues and, when in trouble, ask for help — it does not make you unworthy of your job, it makes you a more mature and reliable engineer which knows how to control his or her ego (which we all have after all, but not all know how to control).
2. When participating in discussions and meetings (product and technical ones) be brave enough to share your thoughts, no matter how silly they seem. Firstly, you may find yourself sharing an idea which another team member may iterate on and improve it. And secondly, with each thought you share, you are making yourself better through feedback, by learning the product and tools behind it.
What's next?
There's one more primary principle that I usually explain and advise to stick with — take on responsibility proactively. But I'm intending to share it in a separate article.
In the meanwhile, I invite you to share your own principles, rules, or advice that a junior developer should keep in mind to become a great engineer and a reliable team member.
I also want to share a project that I and my partner have been working on for a while.
We came up with a challenging project to help junior frontend developers that need to showcase their skills and want to build a portfolio to ease the problem of getting a job in the industry.
You can check out it at https://banda.works/housework-undoer.
Houseworkd Undoer is a project organized into separate tasks through which you will build a frontend app to help our (imaginary) friend Jack.
We prepared a nice-looking design and a background story so we hope it should be enjoyable and interesting for you to build, while still providing enough challenges to display your skills to possible employers.
See this in full size for more details 😉
To finish the project, you need some skills in one of the major frameworks/libraries (React, Vue, Svelte, Angular, etc.), though the project can be completed without any of those, just with plain JS (but keep in mind, employers usually expecting you to have knowledge and experience in one of those mainstream technologies).
In the upcoming future, we want to create a few more projects, including backend and mobile related ones. But we could really use your help as well: if you try on the project, send us feedback, your thoughts, and questions. The project is completely free and we will really appreciate you spending a little bit of time to share with us your thoughts over team@banda.works.
See you next time! 😉
Top comments (0)