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.
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.
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:
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:
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.
Manyata Goyal
Couple of things I have noticed: