DEV Community

Cover image for My #1 tip for developers starting out

Posted on • Updated on • Originally published at

My #1 tip for developers starting out

Do you know what the most common internal development team failure is?

Communication issues

As a junior or brand new team member you will never be responsible for the team or its problems. However, you definitely can impact this disproportionately. My best advice is......


Raise your hand

If you can internalize this and constantly remind your self of it - I guarantee you will be so much more successful in your development career. It seems so simple and non-technical but it is absolutely crucial. I have observed people struggle in teams, organizations, and their careers not because of their technical skills but because of their communication skills.

Now I get for a lot of reasons it can be embarrassing or shame invoking to raise your hand and stop something saying: 'Hey! I don't get it.' However:

We all suffer more the further your understanding drifts from the existing teams.

It's similar to that saying of "Shifting software quality to the left". More information on that here. The basic idea is that: stopping bugs sooner is better and costs less. With misunderstandings we can say the same exact thing.

The sooner we stomp out misunderstandings the better everyone is.

That voice in your head is not your friend here. It's probably telling you awful things, telling you that you are stupid, dumb, calling you all kinds of names, how can you not get this? , why can't you solve this easy bug, why don't you understand feature: XYZ-4032 !?!? But guess what it's lying to you. Ignore it. Ask away and ensure you get to understand why. Once you think you get it then try to explain it back to the person that just explained it.

Everyone wastes time and spins their wheels. Over the most ridiculous and tedious stuff. Repeatedly. For sure I have lost hours to missing semi-colons, typos, and all sorts of other silly things. Failure and frustration are expected in this line of work there is no way around it. You learn from this stuff and gain knowledge and experience.

When you are starting out figuring out when to ask for help is very difficult.

Do you ask immediately?

Then you run the risk of burning people out with all your questions.

Do you try to cover up whatever is going on and give vague progress updates saying things are going well but really your fucking stuck and have no clue what to do?

As much as it might suck to admit you can't currently do something or need help it is way worse for the team to not be honest and seek help when needed.

graph of waiting time scale

Ultimately your goal should be to end up somewhere between asking everything immediately & waiting way too long.

I struggled with this early on and still do on occasion. I can vividly recall a really early performance review where I got dinged for asking too many questions and not trying to answer anything myself. I have also been guilty of not asking for help soon enough. Everyone struggles with these things. But, no one really gave me much advice on this or told me hey this is common and you are not unique - everyone struggles.

Here is my rule:

Set a timer for thirty minutes. Try different ideas. Take notes on what you did with the various approaches. Try some googling on the error message or digging in some wikis in your internal sites somewhere. Give it your best shot and if the timer goes off at thirty minutes - reassess where you are. If you think you are close reset the timer for thirty additional minutes. If you are still totally lost immediately reach out to your architect/team lead/fellow team members whoever can help. If you get to the end of the hour and any confusion or uncertainty reach out and discuss where you are at and check your assumptions and charted path.

These rules vary based on experience and the task at hand but my max absolute ceiling is half a day. If you have spent half a day spinning your wheels or not making the progress you should be then reach out, ensure the lead knows your status and that you are stuck, and get help.

As someone about to provide help - I would love to know:

  • What have you tried coding wise?
  • Where are you currently stuck?
  • Specific things you looked at to attempt to solve the problem

This allows me to tailor my feedback. I can then bridge any gaps in your knowledge or understanding of our software, product, etc. I can also offer any guidance on your methodology for solving issues on the project.

Coding and development are hard. First, there are all these technical things you need to learn to be able to get a job in the field. However, once you have landed that position you face another hurdle. You have to learn how to appropriately code within in a team, how to be a good project/team member, and how everything works (beyond the code).

Good managers and team leads know you will potentially need extra help to get going. Especially if you are at the start of your career or perhaps you are brand new to a project. But at the same time, an opposite issue exists for the lead in that they want to give you space. No one likes to be micro-managed. And finding the right balance for each team member takes time especially with juniors.

The worst six communication mistakes you should avoid:

1) Hiding your issues via false progress reports that things are going well.
2) Not communicating you need help on your task(s).
3) Wasting more than half a day being stuck.
4) Hiding the fact that you don't understand something.
5) Asking for help immediately every time all the time when something doesn't work.
6) Not understanding the solution to your problem when someone helps you.

If you liked this article, check out:

What do you think? Let me know on Twitter and follow me there for more development, programming, and general software engineering content.

Top comments (2)

jcsmileyjr profile image
JC Smiley

Great article and wonderful suggestions!!!

tccodez profile image
Tim Carey

Good article! Sometimes you need a different set of eyes to look at your project and there is no shame in that