What is the greatest flaw you see in junior developers?

Those of you who have worked in an office or other situation with new hires coming on... What about a bad hire made him or her bad in your experience? Juanita Sutton recently asked the question of whether or not you would hire a candid whose approach is correct but who is having trouble coding. This got me to thinking and I arrived at this question because I feel it could help newbies. We often focus on what makes people a good hire, but let's answer: What are common problem areas? If the answer is very general such as "bad performance," please try to go into more detail or hypothesize what was making this performance poor... Attitude, aptitude, distractions (cell phone, family, life), lack of knowledge, lack of care, not enough persistence, self-doubt, etc... Obviously, we're not all psychologists, but do your best, I think this'll be interesting.

Couple of things I have noticed:

Almost all focus on code and not enough on monitoring it once it reaches production.
Lack of coding consistency and conventions and not enough emphasis on readability. Treating conventions as second class citizens in a distributed codebase where more than one person is going to contribute and maintain leads to a lot of confusion and hard to read code.
Not able to understand the value add of good formatting, understandable variable names, class names which say what they are, method names which say what they do and do what they say.
Over estimating or under estimating the amount of time it might take to finish something.
Accruing tech debt while trying to finish work fast and never going back to fix it.
Hardcoding of DB urls, passwords, thread counts, message strings (in case of UI).

Do you think the variable and type naming issues come from laziness or could it be inherited from the algorithms and data structures college classes which use mathematics-inspired notation often in the form of single letter variable names? I never understood that and found it to be extrenely cryptic to say the least but for some reason they seem to stick with it in a lot of college classes since they are more theoretical in nature. A good example of this is the book Algorithms + Data Structures = Programs

The thing is, I have had both kinds of college courses. Algorithm and DS classes would never place any emphasis on variable names, but software engineering courses would tell you how important all of that really is and the advantages.

So in my opinion, its a little bit of both. Maybe they just don't know better and no one else has taken the time to explain to them the importance of this and it has been accepted by others. I have noticed that in senior engineers also. They would very rarely take the time and explain the importance of coding conventions and naming paradigms to juniors.

Not trying to understand a problem. When something goes wrong with the software you're developing or the tools you're using, your first instinct should be to figure out what went wrong and why it went wrong.

Some junior developers have a tendency to jump to possible solutions without trying to understand the problem. This is a common tendency when the problem is too complicated to be understand -- it's why we tell people having trouble with a computer or electronics to power it off and on, or reinstall -- because these are solutions that fix lots of problems, and they can be a cost-effective use of time. But what they don't do is tell you what the problem is. And when your job is the creation and maintenance of software and there's a problem with the software or a problem with the tooling, it's valuable to you to understand the problem with the software or the tools, and jumping to solutions won't tell you that.

Of course, sometimes it's hard, extremely hard to find the problem, and I understand that sometimes you need to make decisions about whether it's cost-effective to continue to diagnose the problem. It's ok to make those decisions, but they should be conscious decisions.

Not asking enough questions.

I've seen this in various people at various places — peers, managees, and students. I think this flaw stems from one of the two reasons:

One, the person believes that s/he would get the most satisfaction if they figure out everything by themselves, without relying on anybody's help. While they may be right in their own perspective, they miss to see that everyone involved is on a clock, and their work is expected to get done in a set amount of time.
Two, ego problems. A belief that one is way above the phase of asking questions; and doing so would probably make him/her look a little less smart; while the truth is much closer to the opposite.

I've been reading all of the comments over and over again. To me you made the most valid point. The others mainly answer about a lack of experience. The second point to me is the most important lesson to learn.

As someone who doesn't know how to ask questions, I feel that it mostly from lack of understanding. When I understand a subject I have more questions than when I don't.

When I was in University, I would sometimes, on breaks, stand by the teacher and hear questions of people, that would help me understand the material more because I would know to which questions I have an answer and to which I don't and thus to what I should review.

Today, I tend to lurk in stack overflow and hashnode and read q&a of people from the same reasons.

The Not-By-Me syndrome, NIH turned up to eleven. It's damaging when new hires want to do absolutely everything on their own, existing third-party or internal libraries and tools be damned.

Mind you, a hire that could do everything is valuable, but those often know already that most of what they could fix was probably already fixed somewhere. They know to ask for guidance or can discuss potential improvements without trying to impose them.

I frequently have to deal with source code written by students with basically no programming experience apart from the exercises they did during their studies. Unfortunately, I mostly have to finish and maintain projects which were not even discussed with me. Since the students do not have any experience, they do stupid things, so I end up rewriting most parts of the applications. While a lot of things are annoying, I hate the lack of documentation or bad documentation the most. However, other than that, here are a few things I have encountered:

Use of an overload of libraries instead of simple Vanilla
Hardcoded configuration and passwords
Global variables which are exported to the whole application and changed in nontransparent ways (plus arbitrary structures, but without any documentation)
Lazy solutions (I once saw a C# application print a screenshot of a window instead of writing to a pixel buffer, which resulted in lots of problems, like aliasing, pixelation and miss-alignments due to different system font-sizes)
Bad variable names, which require a deep understanding of several pieces of the code
No error handling at all (stuff like accessing an object in an array on an object in an array, with constant indices, without checking if one of them even exists)

The first on your list is probably my biggest pet peeve, but the error handling and lazy solutions is pretty awful too, as is hardcoded passwords!

According to me, the biggest problem with most junior developers is that they fail to understand that they are solving a specific problem with the help of technology. Some of them believe that it is the features that matter the most. They fail to think about various scenarios (beyond code) and usually just do whatever they are asked to perform. However, one should keep in mind that this is not always true. I have worked with freshers who are extremely focussed, sharp and have clarity of thought.

The next problem I see is that most juniors don't do enough due diligence while picking up a tech stack. Worse is when they want to rewrite a particular part of the project in a newer shinier technology without fully understanding the product roadmap, priorities etc.. Imho, every developer should act like a problem solver rather than a feature builder.

The third and a crucial point is that some junior devs have a tendency to think that it is ok to ship bad code now and fix them later (which never happens and as a result technical debt increases). Regardless of expertise level, one should always try to take time and push well written code so that they themselves can understand the stuff while looking at the code after months.

Lastly, it is my personal opinion and varies from person to person. I have noticed the above flaws while working with different types of developers in different projects. Also as I said above, there are excellent developers who are junior, but give their 100% in every aspect.

A large problem I see often is some juniors not having a good attitude about solving problems. Web development is endlessly frustrating and there are so many conflicting opinions about what should be done or what is the best technology to use for the task or whatever. However, many juniors will complain often and loudly about how confusing everything is and that they wish it would just work more simply. Or they complain about how someone should have already made the codebase easier to consume or jump into, and are unwilling to be the change they want to see. I don't mind helping other devs, in fact I'm very passionate about teaching others and helping them grasp concepts that are difficult and I want to always be learning from those better than myself as well. However, when you have an attitude where you're always blaming everything on being chaotic or because it's not following best practices already, I just want to say "I know... it's complicated and hard, that's why we're valuable". Work towards being a developer that is willing to take on and solve very difficult/chaotic/messy problems with a positive attitude, and you'll be highly valued wherever you are.

+1 for mentioning problem solving. Completely agree.

Such a great point. This post alone was worth the thread! ^^ It's we want to whine but at the same time, that's what the paycheck is for, right? You have a point in that, if it were so simple, developers would be out of a job haha.

Thread

What is the greatest flaw you see in junior developers?

Responses(7)

Not asking enough questions.

Recent threads

Search Hashnode

What is the greatest flaw you see in junior developers?

Responses(7)

Not asking enough questions.

Recent threads