Software developers face a lot of challenges on a daily basis.
These are both technical and non-technical. Also, they are very common.
In this post, I will tackle seven of the most common of these challenges that I have come across throughout my career - in my own work, and also while career-coaching others.
Here they are - the seven most common challenges of a software engineer and how to resolve them.
Let's go!
👇👇👇
Too Many Meetings
Here's why you have so many meetings in your calendar.
For many, the most intuitive thing when they need information, action, or anything from anyone else, is to schedule a meeting.
At other times, meetings will be scheduled because there are many roles within your company whose main job is…well…to hold meetings.
This is a reality of many corporate (and non-corporate) environments. For some roles, scheduling meetings is something that is central to what they do.
So how does all this help you manage and minimize the meetings that are set upon you?
Well, read on…
Meetings are expensive to the organization. The more people are invited, the more expensive it becomes. So, meetings need to be justified.
Every meeting must have a reason and a clear agenda. If there is not a clearly communicated goal and agenda - that is the first cue that this meeting is unnecessary.
For every meeting invite you receive, if the agenda/goal isn't clear, ask for clarification.
Ask - "what is the goal, agenda, and expected outcome of this meeting?"
50% of the time, there won't be a good answer. If that is the case, call it out to the organizer and ask if this meeting is needed at all.
Also, if it isn't obvious, ask why you, specifically, are in that meeting. Often, the meeting organizer does not know who to invite, so they just invite everyone.
💡 For every meeting request, ask if this is something that can be resolved asynchronously. It's a common saying nowadays that most meetings could have been an email and most emails could have been a Slack message.
There's a lot of truth to it. Remember what we said above, often, scheduling a meeting is a knee-jerk reaction. It may not occur to the meeting organizer that whatever it is they require, can be tackled with a simple email.
I turned countless meeting requests into emails (and emails to Slack messages).
You can too. It works.
💡 Lastly, take control of your schedule. As a software developer, you have certain times of day when you are most productive. It may be in the mornings, after lunch - doesn't matter. Whatever those most hours are - you can block them off in your calendar.
People will not always honor that and may book over these time-slots, but at the very least they will give it a second thought and will likely contact you to check whether you are available. At which point, you can inquire whether the meeting is required at all.
Lack of Requirements
One of the most frustrating things I've experienced as a software developer is the expectation to deliver results when requirements are not clear or continue changing.
I know that many will jump on this with "but that's the whole point of Agile!"
But that's not entirely true.
True Agile means that you continue evolving and adapting as requirements come in.
That doesn't mean that you can somehow, magically, guess the right solution when you don't know what you are solutioning for!
Here's what has helped me in those situations:
👉 Document the assumptions you are making in lieu of concrete requirements.
Whatever gaps you have identified, document them as well.
Be clear about basing your architecture/design/solution in part or in whole on these assumptions.
Then, make sure to communicate these assumptions to your stakeholders.
👉 Write an email and summarize these assumptions.
👉 Ask the stakeholder(s) to state their agreement.
This does 2 important things:
💡It surfaces assumptions that would have otherwise been implicit. Often, that is an indication to your stakeholders that they need to do a better job at procuring these requirements or that the project is not yet ready for implementation.
💡It removes uncertainty and creates clarity and transparency around why decisions have been made this or that way.
Work is Underestimated
There is a common understanding among software developers that correctly estimating development work is nearly impossible.
Now, that doesn't mean that you will fail at estimating all the time.
Obviously, we've come a long way and the software development industry has matured to a point where we can have some confidence in the estimations of projects.
Makes sense, right? Otherwise, every single project we're on would be late!
Wouldn't it?... 🤔
I mean, if I ask you to estimate how long it would take to write a CRUD API with your
language of choice (and provided some rudimentary requirements) - you would indeed be able to provide a fairly accurate estimate.
☝️But here's the thing…
Often, the task that we need to estimate involves a number of unknown parameters. You might need to use a library or framework that you haven't used before.
Or a new technology.
Or you need a whole new database...
or cloud service.
And maybe….just maybe…those requirements that I gave you weren't really 100% correct or complete....know what I mean?
Now that we're mid-implementation, it turns out that the requirements changed 180 degrees and so all of your estimates are thrown off.
Here's the problem. Often, there are still expectations on you to deliver.
Some projects and teams will adjust accordingly.
Many projects though, in my experience, will have difficulty doing so.
So what do you do?
How can you solve the problem of consistently underestimated work?
More specifically - how do you manage expectations for underdelivering due to work being underestimated?
Well, here's what worked for me.
👉 Keep tight documentation. Keep track of your progress and any roadblocks. Put comments in your JIRA tickets (or whatever your project is using) reflecting the roadblock. Be clear about -why- it is a roadblock.
👉 Raise the roadblock/cause of delay. Whether during your daily standup, to your manager, or otherwise - communicate the challenge to the team. Communicate often. The worst thing you can do in this case is make it seem as if everything is going great, and then not deliver when the time comes.
Blocked By Code Reviews
Unless you are an indie hacker, chances are that you work in a team. Also, chances are that your team has a code review process that one must go through before pushing changes.
Now, there are different ways to do code reviews, and different philosophies.
Most teams that I have been part of used a popular merge/pull request process.
Your team likely has the same thing.
Now, one frustrating point that I, and many around me, have experienced is this 👇
You do your work. It's almost the end of the sprint (or whatever code delivery structure you have). You now push your changes, but before these make it to the main line/branch of your code, other developers have to review your changed code.
Moreover, you also have to take into account that you may need to make changes based on feedback. The process will then repeat itself until your code is approved.
This process takes time. It takes time from other developers. It takes time from you.
Most importantly, it creates unnecessary churn because you are never entirely in control of when you are done. In a way, you are at the mercy of others.
How often have you checked in/committed your changes silently hoping that they just go through without anyone commenting?
I bet that a lot.
So what can you do?
Well, here's what worked for me.
👉 Commit frequently and incrementally. Small changes make it easier for people to review. Instead of pushing all of your changes at once towards the end of your sprint, push them as you go throughout the sprint.
Now, understandably, not all of the functionality will be there, and that's ok. It will add up as you continue committing.
👉 Raise the overall issue with your team. Code reviews and subsequent changes are factors of uncertainty within your sprint, estimates, and pointing. Everyone needs to account for that.
Your scrum master, your product owner, whoever is part of the team need to know this and be aligned.
If you encounter resistance, show a concrete example where a ticket/task was estimated as one thing but then took longer than expected or spilled into the next sprint because of code reviews.
This will adjust expectations and will alleviate much of the stress around code reviews.
👉 Ask your team to divide code review comments into "blocking" and "non-blocking". Blocking comments are ones that need to be resolved before you are allowed to merge/push.
Non-blocking comments are those that can be postponed and resolved after that.
This ensures that what you have to address right away are only the most critical of comments.
Everything else can wait.
Too Much Non-Coding Work
As an individual contributor you have your individual tasks. These may be purely around writing code, but can also be around delivering a design/architecture, documenting a solution, or something else that has a concrete deliverable.
These are all the things that can be put on the scrum board (if your team follows Scrum) or otherwise reflected in whichever method of project delivery your team is subscribing to.
However, your job is not limited to those things, now is it?
In fact, I would go so far as to say that anywhere between %40 and %60 of your work has nothing to do with individual deliverables.
Though, it does have to do a lot with
👉 Investigating issues
👉 Helping other developers
👉 Babysitting CI/CD pipelines
👉 Meetings, meetings, and more meetings
👉 Production (or other environment) support
👉 Going down rabbit holes of malfunctioning technology
These are only some of the examples of what you do on a daily and weekly basis that have little to do with your development work.
In my experience, very few teams actually account for this.
What happens is that you scramble to meet deadlines.
That 3-pointer (if using the pointing system) took 2 weeks to deliver instead of the expected 3-4 days.
Now you have to justify why.
The result is unmet expectations, poor planning, missed targets, and let's face it - frustration and decreased morale all around.
Day after day. Week after week. Month after month…
So what can you do?
Well, here's what has worked for many teams that I was part of.
👉 List all of the activities you can think of that take up your (and others) time outside of your main software development tasks.
👉 Quantify these in hours and assign rough % of of your total time. So if you have 100% time in a sprint, for example, ~50% of that will be spent on software development, 20% on investigating environment problems, and 30% on helping less experienced developers troubleshoot issues.
👉 When you have the numbers, bring it up with your team. What you can do now is assign "buckets" or placeholder tickets within your sprint to these activities. All developers can now track their time against these.
👉 Alternatively, if an activity takes more than, say 1-hour, you can open your own ticket within the sprint, without having a predefined "bucket" to account for each specific activity.
The crucial thing here is to make the whole team aware of the situation and align on an approach.
As long as all stakeholders know what consumes a developer's time and are aware of the implications to project delivery - we are all good.
No Design Before Implementation
Can you jump into development without designing the solution first?
It's one of those common challenges in software development that hurt software delivery teams and that often go unnoticed or unaddressed.
Someone comes to you with requirements that aren't trivial.
You now need to to
🔹 Analyze, process, and come up with a way to tackle these requirements.
🔹 Think through the architecture and design of the solution.
🔹 You likely also need to discuss it with others.
☝ The challenge is that when you communicate this to stakeholders, they don't quite get why this activity should "take so much time!"
❓ Why can't we "just go ahead with working on this?"
The challenge here has actually nothing to do with software development as such.
The problem, typically, is that the person that gives the requirement does not have the understanding of the effort required for these requirements to be implemented.
However, you do.
At the very least, you understand what's involved.
This is the disconnect that needs to be bridged.
Here are the 2 methods that have helped me in the past. One tactical and one more strategic.
Tactical Method
👉 Summarize exactly what needs to happen before the implementation of the requirement/feature/project commences.
For example:
- Figure out the API specification
- Create data model
- Identify technology stack
👉 Communicate it to your manager and the rest of the stakeholders.
👉 For each item above, work with your manager/scrum master/product owner to create separate design/solutioning tasks for each of these.
👉 Ask your manager to prioritize your current tasks in relation to this new task. This is key as it creates awareness and stakeholder accountability.
Strategic Method
Typically, lack of design before starting development is a reflection of the team's inexperience or lack of maturity.
Specifically, when it comes to product delivery.
Now, when I say "team", I don't mean software developers specifically, but the wider delivery team instead. This is the team that includes Development, Product, Business, Management, etc.
💡 The solution, then, is to bring the team together and to establish a smoother process for thinking through a deliverable before starting actual work on it.
The key to this is to make this process transparent and a fit with your overall delivery structure.
For example -
If following the Scrum or Kanban methodology, account for design/architecture work as part of the sprint in the same way that you account for development tasks - through individual tickets.
Unclear Performance Goals and Reviews
Why do performance reviews so often go nowhere for software engineers?
All too often, the performance review and evaluation is a frustrating process to both the person being reviewed and the person doing the review.
In theory, it is where you and your manager align on expectations and go through your personal achievements and how they align with the team and organizational OKRs.
In practice, there is one problem that I've noticed in many organizations and which so many software engineers raised to me during career-coaching sessions.
☝ Performance targets, goals, and expectations often lack clarity and structure. As such, they are nearly impossible to fulfill in any objective way.
Often, performance targets feel completely made up and totally irrelevant to you as a software engineer.
It's no wonder that you struggle to move forward in your career.
Fortunately, there are concrete steps you can take to help yourself in a very significant way.
👉 Don't wait for the yearly review or goal setting session with your manager. Have frequent 1:1's to align on your goals. This helps you stay on track and resolve any issues as they come up.
👉 Ask questions and get details. If anything is unclear about a specific goal - raise it with your manager. Get them to explain to you. Get them to provide details. If they can't, it's a sign to the both of you that this goal needs to be replaced with something else.
👉 Set backup goals. Things happen. Not all of your performance goals depend entirely on you. Talk with your manager about what happens if s goal is not met and what "backup" goals you can put in its place.
👉 Keep track (document) of your achievements throughout the year. Regardless of whether your achievements align to some goal, keep track of them for yourself.
🔵 Helped a new developer onboard?
🔵 Delivered a feature well ahead of time?
🔵 Added unit tests to functionality no-one wanted to touch?
Document all of that!
What happens is that come performance reviews, you will have a secondary list of things that you can use to support your career goals.
Many of the items you document have a high chance of supporting your goals in one way or another.
That's a wrap. Hopefully, these 7 challenges will now be something that you are well equipped to resolve.