DEV Community

Cover image for Personal and Professional Growth Through Constructive Feedback
Ilona Codes
Ilona Codes

Posted on • Originally published at ilonacodes.com

Personal and Professional Growth Through Constructive Feedback

If you are constantly questioning yourself about your personal and professional growth that means you are already off to a great start!

We all have concerns about ourselves. Sometimes, we cannot evaluate our current state of personal and professional development. Either we overestimate or underestimate our progress. And it's normal because we are always seeking balance in life.

A great software engineer is a good problem-solver and a good team-player, who will generously share their knowledge and help other software developers improve themselves. They value team achievement over personal achievement which means they help teammates when they stuck and take criticism as well. There are a lot of ways to improve your personal and professional growth as a software engineer.

And the most important one is an opportunity to receive constructive feedback.

Feedback from Team

I have been working in a cross-functional team by following scrum methodology. Every two weeks we run a sprint retrospective in "Start-Stop-Continue" format.

The idea behind this format is that the team will have the chance to recognize the achievements and mistakes we made during the sprint.

Usually, we collectively answer the questions: What should we start/continue/stop doing in the next sprints?

In these cases, first, it is about bad habits that should be just broken (STOP) or good ideas that we didn't follow up to, whereas we should have (START). This format is also about reaching success, confirming patterns and behaviors that led to good results (CONTINUE).

Feedback from Dev Team

Despite that software engineers write code, read the code of others, they also get constructive feedback on their code from a team. It's impossible to know everything and predict all the crucial consequences of the code contribution for the product. Each time it may be missed something.

Moreover, code contributors can learn from a provided code review, because it's more about catching and fixing errors if it does right, then it strengthens the skills and increases the knowledge of the development team.

There is absolutely no shame in accepting suggestions from other team members to improve code quality. And of course, offering the same when you are acting as a reviewer. Because together we make things better than we could do it on our own.

Feedback from Manager

Good team leaders/managers should understand and know the current mental state, priorities, and concerns of team members. The best opportunity for that is a biweekly one-on-one feedback session with everyone from a team. During this meeting, a team leader/manager can not only understand the problems of the person but also identify the problems in a team and help a team to overcome them.

Indeed, gathering feedback about team performance, encouraging openness and honesty, building trust is these things that will pay off later as a result. Instead of protecting themselves and their interests, a team will focus on improving team collaboration, solving causing problems together, productivity and attaining common goals.

I am lucky to work at Zenjob where I can grow personally and professionally through teamwork, ongoing feedbacks, the flat hierarchy between employees and managers, also have flexible hours and a lot of learning opportunities.

Do you want to supercharge your career and become a part of the supportive and ambitious team at the fast-growing and innovative startup in Berlin - the heart of Europe? Check out our job openings: we are hiring!


Originally published on ilonacodes.com
Photo by Adam Jang on Unsplash

Top comments (6)

Collapse
 
ssimontis profile image
Scott Simontis

I've realized that giving feedback to others has traditionally been a weakness for me, because I was too afraid of offending other people. I see a lot of people in consulting who are afraid to rock the boat...they will come into a project and instantly start nodding along to whatever the client says and praising their organizational processes. It's really easy; everyone likes to be praised and you can get through an engagement without solving anything significant.

In the long-term, it's an awful strategy. If a company has a terrible business model or development practices that don't scale, they need to know ASAP. These things can be said with tact, but that still doesn't guarantee that they will be received well. I'd rather have someone be pissed off at me than worry about whether it is partially my fault when their business collapses two years later.

The opposite also applies: when someone else criticizes me, even if they do so rudely, it could be the piece of guidance that saves me from making a major mistake.

Collapse
 
ilonacodes profile image
Ilona Codes

Thank you for your comment! πŸ™
Because of the listed reasons above it's important to provide constructive feedback with explanations and an action plan on how to solve occurring problems.

Collapse
 
ashleemboyer profile image
Ashlee (she/her)

This sounds like an absolute dream πŸ’•

Collapse
 
ilonacodes profile image
Ilona Codes

Reality πŸ™ˆ

Collapse
 
peterwitham profile image
Peter Witham

I think you have summed up the idea of feedback perfectly.

One thing we do with my teams that is slightly different in the sprint retro is to not include management. So I do not attend the meeting, I receive the feedback from my Scrum master afterward. This gives everyone a chance to speak freely without any perceived pressure. We have found it works well, I do of course always read the feedback and take it into account.

Collapse
 
blaisep profile image
Blaise Pabon • Edited

@ilonacodes , Have you read Radical Candor by Patty McCord ? She elaborates on this theme in great detail and describes her experience implementing it at Netflix.