How to Resolve These Five Problems of Struggling Software Engineers

Put Them On The Right Path

George Marklow

Published in

Geek Culture

8 min readJul 14, 2022

Introduction

First of all, a caveat — I’ve never been a line manager to a software engineer but have coached developers in previous roles in an informal way.

I put together this article to identify five common problems that might be causing a developer to struggle in his/her performance, along with suggestions for how to help the engineer back on the right track.

Understand that this problem requires coaching and monitoring on a regular basis until gradually the developer’s performance and confidence are brought up to where they should be.

Also, remember, that a struggling developer could be a sign that there’s a lack of support, structure, or organization within the team. I’ve alluded to some of these things in the article and offered potential solutions.

1. Slow Progress of Work

Some developers may take a long time to create features that to us seem relatively straightforward. But it's important to remember that everybody is working and learning at his/her own pace.

I believe that half the battle for less experienced developers is knowing where to quickly find a technical solution to progress their user story. For example, if a developer is taking a long time to set up unit tests for a new Angular route, wouldn’t it be better to have a page on the team’s wiki with links to previous pull requests that they could reference? I think so — having a blueprint allows them to more quickly identify all unit tests (of course, including edge cases) needed and the refactoring required. For this to work, the team would need to remember to add these links after their pull requests are approved.

But what if the problem is more fundamental than that? Let’s say, for example, that they’re struggling (or nervous) to review other people’s PRs because of a lack of understanding of a particular framework, such as working with the Angular NgRx library having come from a standard Angular background. The line manager could ask the developer to complete the relevant Pluralsight course(s) or read particular articles, either as individual tasks under a miscellaneous section of the Sprint or as a measured objective for a mid-year review. There are also quick cheatsheets and ‘drills’ out there that can be helpful:

If confidence is a problem, long-term strategies include things like getting them to present work regularly in tech showcases, because presenting anything means they have to have a good understanding of it and have read around the subject. It could be anything from a library that’s helped them or something more general like discussing a design pattern or perhaps a useful refactoring tip to be aware of.

Finally, you could also encourage them to become more immersed in the development community. For example, ask them to join meetup groups in their area e.g. London Angular Developers. This could (creatively) be set as an annual/mid-year review objective.

2. User Story Understanding Issues

If the engineer is unclear on the user story requirements, this problem will manifest itself all the way down to TDD, where the developer will be unable to write tests before providing implementation, since the goal is unclear or misunderstood. This often results in the struggling developer trying to write code first, then attempting to figure out how everything works along the way — disaster!

Before the developer begins the user story, ask them to start writing the technical documentation earlier rather than leaving this to the end, as it genuinely forces the developer to think about what the objective is. Make sure they review the QA’s test cases against the user story and raise anything that doesn’t look right. Make sure also that in cases where there’s a front/back-end interface, the contract is agreed upon and documented against the user story.

It will help to break down larger user story tasks into smaller ones, so the developer moves piece by piece through a problem, and there’s at least some indication to the rest of the team of how things are progressing. The PRs from these tasks will be smaller and easier for others to review and approve.

3. Lack of Core Business/Database/Workflow Understanding

An understanding of the business, and underlying database(s) and workflows, should be a priority for new developers joining a team and part of their onboarding strategy. If this is not got right, a struggling engineer will have problems down the line when it comes to estimating user story points during sprint planning sessions, among many other things.

So what do you do if there are fundamental understanding problems surfacing many months later?

If the developer feels their understanding of a particular platform is lacking, encourage them to approach the Product Owner or QAs with a meeting request to give them a refresher. The developer should be given the confidence to take control of their own learning, rather than assume that somebody else will automatically give it to them.

In an ideal world, the developer should have the confidence to raise any questions or doubts they have. But if the developer still feels frightened or embarrassed to ask questions for things they feel are quite basic in front of others, they could take the discussion away from the main development desks in a 1–1 session with an experienced developer in a meeting room. This is less of a problem if everybody is working from home on a particular day and the developer can open a private discussion quite freely.

Get an experienced developer (perhaps yourself) to generate a database diagram, or reference the top ten most used tables to tackle first if the database is large. Encourage the developer grappling with their understanding to ask questions like:

What does the data look like?
How is the data used in different parts of the application?
What tables are connected and how?
What business function does each table serve?

And for workflows, take one simple record and go through how this gets processed. For example:

Which message queue is a message pulled from?
Where does it get staged in the database?
How is the data validated and loaded into the system?
What does the confirmation message look like that tells the other end of the queue that everything was processed successfully?
What happens if the message is badly formatted — how does the error message look that goes onto the queue?
Are there specific times when we expect messages like this to come down the queue for processing?
Can messages be reprocessed in a queue and how?

4. Pull Request Problems

There are three bits where developers might struggle when it comes to pull requests:

They lack the confidence to review, comment and approve other people’s PRs, perhaps waiting for other more experienced developers to approve first.
They raise a PR that doesn’t meet a common set of coding standards used by the team.
They create PRs with lots of faulty code.

If a lack of understanding is the problem, the developer should reach out for a five-minute chat with the person who raised the PR. It’s much quicker for the PR author to explain what’s happening, rather than have the PR reviewers taking a long time to piece everything together in their heads from reading the code. This is perfectly normal — we’re all at times in our own bubble!

Some of these PR problems can also be resolved by using a checklist that should be followed when raising a PR in order to minimize:

Wasting other developers’ time reviewing/commenting on the code i.e. writing code that falls outside the agreed coding standards (which should be documented somewhere on the wiki!).
Dealing with bugs found in QA that could easily have been picked up if the developer smoke-tested their work, requiring a subsequent PR to fix the problem.

This PR checklist will have some things in common, such as ensuring it has:

A description with a link to supporting documentation.
Tags with the correct work item IDs.

But there will also be some differences depending on what code is being merged. For example, if the PR includes front-end changes, the developer should:

Smoke test their own work before raising a PR for it.
Eyeball that their work is deployed and functioning before informing the QA that the feature is ready for more extensive testing (believe me — I’ve caught problems in my own deployed work before wasting a QA’s time).

Obviously, in the real world, these checks won’t eliminate faulty PRs entirely but will help to reduce them. I wrote an article about this you should check out.

5. Anxiety Dealing with Production Issues

Every developer has experienced ‘stage fright’ at some point in their early career. I remember getting anxious when production issues landed on my lap and I couldn’t find what I was looking for to resolve the situation.

To reduce this stress in struggling developers, preparation is key. Bookmarks need to be properly set up so that they don’t need to spend time looking up names of servers or where release artifacts land. It also reduces their anxiety trying to look things up in a hurry:

Links to the application website(s) (including current and previous versions), API Swagger pages, CI/CD portals, as well as links to important technical and helpdesk documentation must be properly organized.

When helpdesk issues land in your team, encourage the struggling developer to jump straight into dealing with these problems head-first. Get them to see who to contact in certain situations and ensure that it is properly documented for themselves and others in a Knowledge Base. Failing that, it's quite easy to search previous email/chat communications of similar issues to find out which parties are involved. Again, if they have adequately studied the workflow they should have a rough idea of where a fault is and hence who to reach out to.

Documenting commonly used SQL queries or API calls can also save time. Remember, it might be a helpdesk issue coming from an area of the platform that the developer hasn’t been working on for a while, and these queries will help take away thinking time. Maybe investigate having a shared Postman (or whatever API software you’re using) workspace and making sure that if a developer changes a URL or payload for an API that the configuration file is updated as part of the PR checklist.

Finally, and most importantly, the developer should be encouraged not to panic. This is especially true for post-release production issues, where every release goes through change-control and has documentation with clear backout steps. A release can be reversed if a major helpdesk issue occurs and the developer should bear this in mind!

Thanks for reading! Let me know what you think in the comments section below, and don’t forget to subscribe 👍