Tapptitude Presents: A Developer’s Guide to Everyday Feedback

Communication is key to any successful and healthy relationship, whether we’re talking about our personal relationships, or the relationships we have with coworkers or clients. But effective communication can be tricky to achieve, especially when working with remote teams or when you’re navigating language or culture differences.

Why feedback matters in our day-to-day work

A significant part of the communication that takes place within a product studio like Tapptitude constitutes feedback, from one developer to another, from a manager to a specialist, from a programmer to a designer, or vice versa.

We believe good feedback is the secret ingredient to building mobile products with an impact, and a key element that helps us build long-standing relationships, both with the people on the team and with our clients.

Our partners and clients appreciate us for walking the talk, and for telling it to them straight when something is not working or headed towards becoming a problem. We try to maintain that transparency and the high standards among each other, as well – that’s the only way we can build quality products together. But any way you look at it, giving good feedback can be tricky business.

What this article is about (and what it isn’t)

Can you think back to a time in your career when you received brutal feedback from a manager, or a colleague? Or can you recall a time when you had to review someone else’s work, and was stressing out about how to do it without hurting their feelings?

If you’ve done your job for a while, you’ve probably had to face this beast called feedback, one way or another. We’ve all had to do it. Oftentimes, the way feedback is delivered can have a bigger impact than the message itself, because we all want to perform at our jobs and get praise for what we do. The delivery is all the more important when feedback is not all positive, because you might hurt people’s feelings, their egos, which might lead them to feel discouraged and unmotivated. That’s why we all strive to deliver what’s called ‘constructive criticism’, but where do we start?

This article aims to be a mini-guide to help people in the mobile app development industry get better at giving – and receiving – feedback. Still, these tips and situations apply to pretty much everyone who may be working with and around products, so we hope it’s going to be helpful in your day-to-day job, whatever that may be. But let’s get a bit more specific about what this article covers.

This article is:

A hands-on guide on how to give feedback to colleagues
A go-to resource with examples that you can apply in your life
A guide to giving very specific, pointed feedback, but also
A set of tips on how to communicate more effectively with coworkers and clients in general

This article is not:

A list of bad examples or habits
A guide on how to communicate in 1-on-1 meetings or performance reviews
A guide on how to ‘sugarcoat things’ when talking to colleagues
A set of ‘rules’ that everyone has to follow

Whether you work at a mobile app development company, a product studio, or a startup, we hope this mini-guide will be useful. It doesn’t matter if you work as a developer, a UX/UI designer, a QA specialist, or a marketing specialist – at some point, you will be given feedback, and you will have to offer it to someone else, be it an intern, a new colleague, or someone in a team that you manage. We hope this article, and the countless resources out there, will give you confidence that giving and receiving feedback is a skill you can get better at (just like riding a bike), and it’s not some intrinsic, immutable feature you get born with.

Something to reflect on

Before we get into more specific tips on how to provide helpful feedback, take a minute to consider what that means for you.

People can provide feedback to instruct you on how to do something, to evaluate a task that you worked on, or to validate the good work that you’ve completed. Think about which kind of feedback helps you the most, if at all, and when? Some people find motivation and professional satisfaction in receiving positive reviews, while others might not need it at all. Some people like figuring things out for themselves, others appreciate some guidance. Some feel they’re getting direction when they have a baseline of how they’re doing and how they’re supposed to do, others are sensitive to being evaluated. Where do you find yourself?
Is there a particular medium or context in which you prefer to get feedback? Would you rather get it in an email, or face-to-face in a private meeting? Do you prefer it to be timely and pointed, following each project or task, or would you rather receive a more comprehensive review during performance reviews or 1-on-1s?
Are there any particular moments or places where you do not want to get feedback? Like, during a team meeting, or on Slack, or outside work hours?

It’s very likely there have been times you’ve gotten or given very good feedback, as well as had bad experiences. Getting good feedback right isn’t just about knowing how to deliver it, it’s also about knowing what your conversation partner is more comfortable with. And being self-aware gives you that extra ability to be attentive to what people around you respond to.

Now let’s get into the hands-on stuff.

Our take on how to give constructive feedback

Feedback is a universal thing, no matter what position you’re in or what company you work for – or, at least, it should be. But reviewing the work of a technical person can be different than doing it for someone working in content marketing, or design, or human resources. It’s important to adjust feedback and its delivery depending on who you’re talking to, so we’ve come up with a few specific examples from our own experience, to give you an idea of how feedback can be approached.

How to give feedback to another developer

Assessing another developer’s work can be tricky sometimes, because ‘good code’ is very subjective. What’s more, developers tend to see things as black or white/true or false, but that’s not really the case in real life. Feedback is the one thing that isn’t black or white, so there’s a natural struggle for technical people to provide and receive it, at least early on.

When giving feedback, we sometimes unconsciously try to insert our own preferences into the matter, but it’s worth keeping in mind that everyone works differently and has a different style or process.

Of course, when it comes to code, it’s good to have a previously agreed-on style guide that makes it easier for everyone to get on the same page, and for newcomers to onboard the team. But it’s also good to let everyone approach things in their own way.

Everyone should do code review, even experienced or senior developers. Even if the code is flawless (which is pretty rare), the feedback process becomes a mentorship opportunity and a learning experience for the person reviewing the code. For junior developers, it’s even more important, as it can be a positive growth experience that helps them expand their skill set and get over that dreaded ‘code review fright’ early on in their careers.

Why should you even do code review, you might ask? Here are our top reasons behind it:

Knowledge sharing and professional development
Ensuring that the code is consistent throughout the code base
Preventing accidental errors, like typos, and structural errors, like dead code/logic
Increased motivation and satisfaction resulting from peer-recognized coding expertise

Basically, code review is more than just a way of ensuring code is correct and consistent; it’s an opportunity for professional growth (you get to see how other developers work), giving feedback to another developer can also boost your soft skills, and you get to give positive feedback for a job well done. Those are important if you’re ever in the position of managing a team of developers or becoming a team leader – you’ll have to give feedback a lot, so having good communication and people skills will come in handy.

Some tips on giving feedback to another developer

Don’t give orders – instead, make suggestions and provide direction
Don’t just offer someone the solution or try to fix it yourself; instead, provide guidance and let them find the solution on their own; this will help them grow as a developer and learn to problem-solve
Think about how your message will be received; instead of saying ‘this method is way too long!’ try saying ‘this method might be too long, maybe we could try breaking it down’
Don’t just tell someone to do something, but justify why you choose that particular fix and why your proposed solution is a better fit;
Make it about the code, not the human (“This code is…” instead of “You wrote code that…”).
Make it about your perspective, not a generalisation (Say “It’s hard for me to understand this code.” instead of “This code is hard to understand.”; you’re leaving room for your colleague to explain why that code was written like that in the first place, instead of them following your lead because they think they have to)
Remember we’re all humans; if you find yourself writing angry, impatient or disappointed comments, step back and come back with a different mindframe. Your aim is to create a learning environment, how can you do that?
Try to limit your use of emojis, as sometimes they can betray passive aggressiveness or be misinterpreted 🙂
Don’t be afraid to leave comments; you’ll either learn something new, or you’ll surface a problem or something you were all confused about – either way, everybody wins.
Encourage things that you like; praise parts of the code that you’ve liked, smart solutions, new things you’ve learned, things you’ve noticed your colleague got better at. Most people feel good about themselves if their hard work is seen and appreciated.
If you’re on the receiving end, remember that the feedback is about the code, not about you; try to detach yourself from the code you write and think of it as an opportunity to look at it from different perspectives, and further develop your skills and get better at your job.

Finally, keep in mind these simple best practices that should help every code review session:

Start from the big things and go small: from architecture, code style and conventions, to specific solutions and code consistencies;
Work in batches; don’t go through more than 400 lines at a time, and take a break after 60 minutes (or skipping lines will start to seem like a great idea)
Help your colleagues review your code more easily: try to use a pull request template including link to the ticket describing the functionality implemented, maybe an explanation of your solution if it’s not too obvious,
Leave comments in your own PR on changes you would like to highlight but not leave a comment in the source code, commit as often as possible with an explicit message of what is in that commit

How to establish a healthy workflow with your QA

Discussions with people in the same role might be tricky sometimes, but at least both parties are already familiar with the jargon, the tools, the technology, and the basics of the job. It gets a little trickier when you have to give feedback to someone who doesn’t have the same job title or description, for instance, a QA specialist. Here are some tips to make communication smoother between a developer and a QA:

Provide clear and concise reproduction steps, together with a video that also has a tap indicator visible and/or screenshots, where necessary
Figure out a process along with the other coworker: find out how they prefer to get builds; figure out how you prefer getting crash/bug info, besides board tickets, to ensure seamless communication
Try to find common ground and understand each other, and take the time to talk issues through; remember that everyone works differently on different projects
Avoid intention misinterpretation by not taking things personally; for instance, a developer marks a tasks as ‘ready for QA’ and receives 10 bug alerts, at which point they take it personally and start to resent the QA specialist; remember that you’re both on the same side (building a good product for the end user to enjoy), and don’t take the feedback as an attack on you or your work
Remember that a lot of QA specialists work on multiple projects at a time, so try to set up calls and discussions in advance; also, whenever you can, try to solve things using async communication first
If you simply can’t reach an agreement on how to proceed, don’t waste time and call in a third party (a product manager, project manager, designer, or another developer, depending on the issue) to be a third pair of eyes, help mediate the conversation and come to an acceptable solution.

Some tips on working with your project’s designer

UX/UI designers play a major role in mobile app development, any no project can be completed without their expertise. You can expect to have some back and forth when it comes to design, or how to intertwine design and functionality, so these tips will help you establish a good rapport with your designer:

As a developer, it’s ok to stand up for your platform; if a design has an iOS-centric UI, you can – and should – provide feedback on what the equivalent expectations are on Android. In the end, it will be a better product for the user if you work together and see what can be changed in the given timeframe, so don’t hesitate to establish expectations.
Sometimes the assets you need aren’t available in the correct format. You should provide an explanation of what goes wrong, and why, when importing those assets, and be clear on how you need them to work. Of course, don’t just go ‘well this is all wrong, nothing works!’ – instead, explain to your designer that you need a different format to be able to work with the assets, and provide similar examples, if possible.
Most often than not, you shouldn’t run into any major obstacles or have to do a complete overhaul of a product’s design. However, when it comes to more complex issues or changes, you should talk to your product/project manager first to see how the matter should be approached, before assigning tasks to the designer.
When a UI/UX component is difficult or time-consuming, talk it over with the designer and the project manager. Prepare a demo with the closest solutions and an overview of the technical challenges, the required time and effort, together with alternatives and workarounds. Remember that the best products make tech capabilities and UX/UI come together like magic. Sometimes, the role of a developer is to clarify the sandbox in which a product designer can do their best work. Figure out together what can be compromised or changed to try to build the best possible app in the available development time and budget.

Some tips on working with your product manager

Your communication with your product manager is probably one of the most important aspects of the development process, as any breaks in communication at this level could compromise the entire project.

You should always strive for transparency and keep an open line of communication with the product manager. Whenever in doubt, go to them first, and they’ll be able to provide guidance or point you in the right direction or to the right person to help you solve the problem.
Don’t wait for a problem to get worse, and speak up to your product manager as soon as it appears; otherwise, problems that are not dealt with early can become huge down the road and might reach a point where they’re very complex and costly to solve;
Be prepared to explain technical things in plain English, and to drop the developer jargon. The product manager has the direct line of communication with the client, and they are the ones who will work with them on planning roadmaps or bring certain issues to the client who may or may not be a technical person. As experts, you’ll need to work together to give the context where the client can confidently make decisions that will put the product on the right track.
Establish a process before you even start collaborating on the project: agree on working hours, blocked time intervals for other projects, meetings and their frequency, how updates should be delivered and through which channels
Last but not least, let your product manager know if you are okay being contacted outside working hours; perhaps you’re open to responding when there is an emergency or critical bug, or perhaps you don’t want to be bothered at all outside of work and they need to find another contact.

Key takeaways

Feedback is an integral part of a developer’s day-to-day work, and it’s the fuel that keeps the moving parts of a project running smoothly. What’s more, it’s crucial for personal and professional development, and for establishing long-lasting relationships with coworkers, managers, and clients.

At Tapptitude, constant feedback is something that helps us deliver good work as a product studio. Transparency and open communication are key elements that have helped us forge long-term partnerships with our clients, and build products that are trending and that people love to use.

It’s also why people in the #TappSquad tend to stick around for many years – constructive and effective feedback helps us keep evolving, keep learning, and expanding our skills. It also strengthens the relationship we have with the other people in the team.

Good feedback is helpful, constructive, and positive; it’s not about telling people off or pinpointing their mistakes; it’s about guidance, and about pointing them in the right direction to be able to solve problems. The ultimate goal is not to find errors in someone else’s work; it’s about creating a space where you’re confident to ask for help if you’re stuck, and confident to ask ‘how can I make this better?’. With useful guidance and tips, we help each become skillful experts, and we build better products for the end users. A win-win situation.

So, the next time you’re asked to give feedback to another colleague, or the next time you receive it from someone else, think of it as an opportunity to grow, learn, to become a mentor, and build a good rapport with your coworkers.

Want to join the TappSquad? Check out our careers page and see if there’s anything that catches your eye!

A short note on credits: The writing of this article was a collaborative effort. Cătălin Dârjan, Android Developer and Laurențiu Onac, Head of Android, provided their valuable expertise and feedback. Ioana Neamț, contributing writer, wrote the bulk of this article. Erika Kramarik was the editor behind the scenes. We hope you enjoy this long read!