You can't grow in your career without feedback. 🗣️ Here's 5 ways for you to find some 📝

"This guy has 10 years of experience, but he works like a 4YOE one?"
"How do I talk to my manager about how I'm doing?"
"I don't know if I'm growing sufficiently in my career!"

Ever said or wondered these things? Then you're in the right place.

There are tons of people out there who have worked since so long... Yet somehow there's not much of a difference between how they work and what they ship, compared to someone with much lower years of experience.

It's because it's not the number of years you've worked that shows how far you've come. But the distance you've covered.

"Ooh that's deep."
Yes, I know. Thanks. 😂

Devs find it easy to write code. To zone into a problem and focus on fixing that to the best of their ability.
Best of their ability.
THEIR ABILITY.

Where does "their ability" even come from?

It comes from the learnings and growth they've acquired over the years. It comes from working with others to see what they do better, or do differently and why. It comes from receiving feedback on the work they do themselves, learning what they did well, what they could do better, why, and how.

You could totally work in a silo, but unless you're an exception genius of some sort (or even if you are), you'll benefit a lot from obtaining feedback from those you work with.

"Ah. I see. I'm ready for some feedback. But... how?"

Well, that's why you're here, aren't you?
Let's go.

1. Not all feedback is useful feedback.

Funny how before I'm sharing how to get feedback, I'm sharing how NOT to get feedback. Or more like, how to ensure you have good feedback.

Everyone loves sharing their experiences and opinions as solid fact. They love to act like their way is the best way, and sometimes the only way of doing things.
If you ask around, you'll find people passionately defending their stance on whether a Pull Request should be merged via Merge Commits, Squashing, or Rebasing or something else. But these opinions are often not backed by sufficient or sound reasoning.

Some examples of such feedback might be:

• Don't use this library, write a util function instead.
• All your changes must have tests.
• Don't use list-comprehension. Use lambda functions instead.
• Write your commits in this following structure.

I'm not saying this is BAD feedback. Maybe it isn't. But without elaborating further you wouldn't know. And it is common for especially new devs or introverts to NOT ask further questions.

When you request or are provided with feedback, whether it is on your code reviews, task completion, planning, collaboration, etc. Always ask, "why?" (in an appropriate tone and politely of course).

For each of the above pieces of feedback, here are some questions you might ask:

• What risks do we face by using this library? It's open source, actively maintained, has a lot of stars. All good signs right?
• ALL my changes need to have tests? Why? That feels overkill and might cause my tasks to be delayed.
• But list-comprehension feels like a perfectly understandable way to write this code. I feel it's not really compromising readability either. Could you explain why I should be using lambda functions instead?
• Could you help me understand why I need to write my commits in this specific way? What problems might we face if I do XYZ instead?

When offered with some feedback, you absolutely need to understand why that feedback is valuable and applicable to you.

Either convince, or get convinced.

2. Don't wait for it. Ask for it.

Everyone has their own jobs to do, and sharing feedback often feels like something you have to go out of your way to do.

Well, you can't wait for it forever. Every month that passes by without feedback, you might be ingraining the "bad practices" harder. Doing things in a worse way without knowing. Not doing something that might benefit you significantly for low effort.

You'll figure most of it out eventually, often the hard way. But that's also a slower growth path.

Ask your managers and some of your peers for feedback, between once a month and once a quarter. Learn how they feel about working with you. What can you do better as a teammate? As a dev? As an employee of the org?

If your org already does regular review cycles, then you might not need to do this manually. But in most orgs, the review cycles are either insufficient, or non-existent.

1:1s are a great way to get some regular feedback from your managers, and they are more commonly done between 1-2 times a month. But again, 1:1s aren't done very constructively in way too many places. If you've ever felt like skipping a 1:1, then you're a victim of poorly structured 1:1s. Maybe I'll write about that too soon.

3. Know where you want to go.

Most people have ambition. They want to be someone big, build big things, make big money, etc. And that's cool, obviously there's nothing wrong with that.

But whatever your goals are, have some level of clarity about them.
You don't need to have your whole life planned down to the moment. But you should know who you want to be and what you want to be doing in 5 years, and then 10.

Why is this important?
Because you'll receive all kinds of feedback, and people share feedback based on the things that are important to THEM.

Someone who intends to be a staff engineer someday might be highly focused on code/architecture/performance related feedback of your work. But if you intend to be a manager 5 years down the line, the more relevant feedback for you would be related to planning, collaboration, and high level design to some degree.

My last blog post might be relevant for SDE1/2's looking to grow in their careers:

Going from SDE1 to SDE2, and beyond! 🚀 What it actually takes.

Jayant Bhawal for Middleware ・ Jun 10

#career #promotion #webdev #beginners

4. If you can't act on feedback, you might as well never have received it.

This means two things.

1. There's simply nothing you can or want to do about the feedback you received.
2. It isn't obvious, or you don't know how to can act on the feedback.
3. You straight-up forgot past feedback, or didn't make a plan of action.

If any of this is true, you need to do something about it.

Let's start with feedback that is clear to you.

If you know where you need to go, you know which feedback is going to be relevant, and if you don't actively act on such feedback then you're not really going to go anywhere.

Track the feedback somewhere.
It can be a spreadsheet, a document, some To-do app, or just a notes app. Log it down.

For each feedback item that you choose to track, you want to log the the following along with it:

• When was this shared
• What personal goal does it relate to
• When do you want to see the results of this

For example, if someone shared feedback with me stating that I should be more involved in the planning phase of new features, then I might log it down like:

Coming to feedback that isn't obvious to you, either in terms of how you can act on it, or what the feedback actually means.

Well, your only course of action here is to ask.
Ask for clarification on that feedback.
Ask for help with how you can work on it.

I understand depending on your work environment and culture, asking questions isn't always easy.
It's cool that you can often ask Google, or GPT about these things now, to some degree of success.

But... this highlights the last part, and a hard decision to make when it comes to feedback (or your career generally).

5. My work environment is straight-up not conducive for feedback.

I'm not going to pretend the whole world is utopian. There are places where your peers suck, your bosses suck, and everyone is too occupied in their own lives to care about you. After all, for someone to share meaningful feedback with you, they have to care about you in at least a professional capacity.

In such a scenario, maybe an option is to just... leave?

You should be at a job if you're getting at least 1 of the following:

1. Growth (personal/professional)
2. Money
3. Recognition

There isn't a "right answer" here. The right answer is whatever you deem to be right.
Feedback can play a crucial role in any, or even all of these, if acted upon properly.

But if there's no feedback, and you see no other reasonably fast path to any of this, then don't remain stuck. Keep moving. Keep growing. This post was basically about growing in your career. Feedback is one of the most useful tools as your disposal.
Seek it out. Use it.

⛳️ Some background on this post:
At this point I've worked at all kinds of places that have dealt with feedback in their own ways. Some made feedback a structured and regular thing, some others made it a more ad-hoc and casual thing, and sometimes there was hardly any feedback till it's been late.

Having deeply learnt the importance of feedback for myself and my peers the hard way, I decided to make sure there was a process and cadence to this chaos. I wouldn't say I practice this perfectly, else my team will have something to say about that. 🤣 But I'm sure they'll agree that we do a bunch of things right when it comes to feedback, and making sure they have a direction in which they can act in.

We at Middleware leverage feedback culture heavily! Make sure we have clearly set expectations from our roles, and are actively communicating differences and feedback clearly.

If this was interesting to you, you could check this post out, which was also linked above:

Going from SDE1 to SDE2, and beyond! 🚀 What it actually takes.

Jayant Bhawal for Middleware ・ Jun 10

#career #promotion #webdev #beginners