Annoying grad behaviours

I have been working in software development for around 20 years. I have seen successful grads go on to do amazing things and other grads that have been fired within the first few weeks. These are the annoyances I have observed that seem to work against grads during the on-boarding process.

Say they understand what a senior dev has said when they don't.

Seniors know you don't understand if can't answer related questions.

Just admit that you don't know or ask for time to read up some concepts you don't yet understand.

I actually respect devs more if they admit what they don't know rather than fake it because it means I can better trust their judgement.

Say they are stupid when they do something wrong.

We all make mistakes. Be kind to yourself.

When you put yourself down, you are not focused on extracting maximum value from the learning experience.

It could also appear that you are fishing for compliments or sympathy.

Instead, try to demonstrate you understand what went wrong by reframing what you now understand that you didn't know when you made the mistake.

Doesn't read up on concepts that seniors tell them to read up on.

If a senior dev really wants you to understand a technical concept then you should prioritise this. It will save a lot of frustration later.

Make sure you follow up with a discussion about the concept with the senior dev at some point. It will expand your understanding and show you are motivated to learn.

Goes off on tangents thinking it shows independence.

Seniors just want you to stay on task for the first 6 months or so.

If you think some code could benefit from refactoring, discuss it with a senior first. Don't just re-write large swathes of code without understanding why it may have been written that way in the first place.

There will be plenty of time for the you to demonstrate the full range of your abilities once you better understand the technology, process, and the business.

Keeps apologising for asking questions.

Never apologise for asking questions. However if it obvious that the answer can be googled then try that first.

If you still don't understand, you can reframe what you have already researched and ask a better question.

Fails to read all the software quality management documents.

Most companies have quality management documents - read them! Read and understand the coding standards, the software development lifecycle, the security standards etc. It seems like such an easy task but many first-timers don't spend the time to fully understand the documented processes and wait for it to be explained to them. Pretend an auditor is going to ask you what the software development lifecycle used in the company is and make sure you know the answer!

Doesn't tell the seniors when when a task is complete.

If you are delaying submitting your code for review because you are worried it is not perfect, then stop it. Get it in for review and wait for the onslaught. Don't be upset if there are many things to change. It is inevitable and we have all been there.

Gets stuck and doesn't tell anyone.

If you have googled it, looked through other code to see how it can be done, and you still don't know what to do then you should ask for help.

There is a fine balance between asking too few questions and asking too many questions.

If you ask too many questions, you will disrupt the workflow of other devs. You can mitigate the risk of asking too many questions by doing your own research.

Mitigating the risk of asking too few questions is a bit tougher. You can batch up your questions so when a senior comes to check on you, you have a list of questions ready to go.

Ultimately I think if you have been allocated a task to complete with an estimate on how long it should take, you should ask questions if you fail to progress within some percentage of the estimated time.

Doesn't take ownership of their professional development.

If you are really struggling and you think you need some professional development, you should first try to bridge any technical deficits on your own first. Ask for time to do this during work hours if you can but agree to a learning plan with your senior dev first. Show that you are progressing with your learning plan by discussing your progress when your senior comes to check on you.

Ultimately in this industry though many devs work on professional development in their own time. Of course technology changes constantly and if you can discuss new development trends in general conversation in the lunch room, it will make you a more valuable member of the team.

So what do you think? Am I being too harsh? Do you have any other annoyances to share?