At Sparkbox, we pride ourselves on doing the best work we can for our clients. As Drew Clemens wrote in his post Working With You, we like to work “with, not for” our clients. This means constantly thinking and talking about how we can make our clients’ code better and, when we see something that needs to be improved, advocating for it. Sometimes adjustments to the code are easy. Maybe it’s a small performance improvement, a tweak to some styles, or a quick simplification of a JavaScript function. In these cases, you bring it up with your team, project manager, or client, they say “great”, and you take care of it. Yay!
Other times it’s more complicated. Maybe the changes to the code are going to take a lot of time, it’s something that would require a team effort, or it’s something that your client hasn’t prioritized in the past. Maybe you want to upgrade one of your project’s main Node dependencies to a new major version or you want to refactor a large piece of code. Maybe you work on a project with multiple teams and the thing you want to improve will affect them too. As nerve-wracking as these situations can be, as contractors who care about code quality and the longevity of our clients’ projects, we should always try to improve where we can.
The strategies listed below are designed to make this process less panic-inducing both for you and your client. As always, the idea is to work together toward the common goal of building a web that works for everyone.
Always Mention Your Suggestions but Accept That Sometimes the Work Won’t Happen Right Away
Smaller projects with smaller budgets usually don’t have room for major improvements. Even on larger projects, other tasks often need to be finished first. This doesn’t mean that you shouldn’t mention your idea, but be prepared for your client or project manager to say that this particular improvement can’t be a priority right now. Bringing it up means that your client or project manager now knows about it and may make it a priority in the future.
Your idea may have been documented somewhere already, maybe in Jira or Trello or some other project management system. Mentioning it again can remind everyone about it and maybe get it prioritized sooner. If it isn’t documented, you may be asked to capture it somewhere so that it can be prioritized in the future. In this case, it’s a good idea to record as much detail as you can.
Be Considerate of Your Client’s Situation
While you should always mention your project improvement ideas, you should also be conscious of your client’s needs in the moment. Maybe you are working on a small, fast-paced project or you have already had to cut features in order to meet a project deadline. In cases like these, it’s probably better to document what you’d like to do, mention it once, and then, if it’s not something urgent that is going to cause the project to fail, leave it alone. This goes for larger projects, too, where maybe you are working on a tight deadline or your scrum master is trying to keep everyone focused on delivering a new feature. It’s important to be able to read the room and let your client and your team decide how to prioritize the work that needs to be done.
If Possible, Find Small Ways to Start Implementing Your Idea
This one won’t always work. There are no small ways to update a primary Node dependency, for example. But for things like improvements in documentation or encouraging the use of a different design pattern or testing strategy, changes can start small. Take documentation, for example. Instead of pushing to overhaul everything all at once, start with doing a better job of documenting the code you’re working on or writing a bit of documentation every time you learn something new about the codebase you’re working in. Find small ways of bringing attention to what you’re doing—mention it casually in meetings or ask for feedback—so that other people will see what you’re doing and, if they like it, will (hopefully!) start copying it. Slowly but surely, your idea will be implemented in small ways, and those small changes can grow into something much larger.
Be Open to Suggestions and Improvements
This last thing is the most important, but it’s probably also the hardest. Sure, you have a great idea and you believe in it so much you’ve been bringing it up with everyone who will listen. Fantastic! But maybe one of your team members has a similar idea that she thinks would work really well when combined with yours. Or maybe your client likes your idea but wants to implement it in a slightly different way. Or a completely different way. It’s okay. Once you put your idea out there, it doesn’t belong to you anymore. It belongs to the project and the team, and it’s important to let other people play with it, add things, subtract things, mix it up with other ideas. In the end, it may not be exactly what you were initially thinking, but it will most likely be something that is more integrated into the project and works better for more people. And working together, collaborating on solutions, is really what building a better web is all about.
