3 Mistakes New Developers Make

Communication

Instinctively, communication pops up first. But I also realize how challenging it is for new developers in the workplace.

We have a girl who completed our internship training and was offered an entry-level role. She’s assigned to a new “manager” (our front-end lead) and we’re always proactively asking for updates and offering help because:

  • She’s younger and still not used to communication 101, plus the generation gap
  • She has no work experience to date
  • Lack of “team work” experience as well, she’s self-taught through MOOCs
  • Her mentor was someone else (not her current manager)
  • She’s practically freaked out by the vast volume of information to go through

So while communication is her only way out, there are valid reasons why she’s feeling so uncomfortable and additional help should be explicitly offered on a regular basis.

Not Learning From Mistakes

But the thing I really, really can’t stand is not learning from mistakes.

Most aspects of the job are tolerable. Juniors tend to learn new platforms (or languages), get acquainted with business processes, adapted in a new environment, get used to communication and adhering to processes and deadlines.

It’s a lot to tackle at once, and that’s fine.

What isn’t fine is ignoring or taking feedback lightly.

Can’t Grasp The Basics Of Programming

We’ve had some interns who can’t grasp the basics of programming. They can’t access a hashmap or a multi-dimensional array. We take the time to explain the basics of how data structures work and how to use them accordingly (despite being really basic).

A couple days later, another few hours spent on the same problem. A different method used to train the person on solving that error.

Early next week, back to the very same issue. Without indicating a problem or asking for help – just committing a basic bug fix throwing a warning due to improperly accessing an array index.

That’s not fine.

The other common case is escaping input or verifying variables. In dynamic and typeless programming languages, a variable could be anything — and placing a basic check upfront is more than mandatory. Failing to grasp that after repeating that 5 times ranks acts demotivating to the mentor or the corresponding colleague.

It’s perfectly fine if you don’t know a lot of stuff. But unless you pay close attention to what your team is trying to teach you, there won’t be any notable progress. Here’s where communication comes into play, too — ask follow-up questions and indicate problems early on and you’ll be good to go.