#you might be able to catch a glimpse of my imposter syndrome

[aidanchaser]

Read Confessions on Ao3 Rating: G for General Audiences Word Count: 1.4K

An Adrinette Post-Reveal fic, where someone brings up Catwalker

Her fingers slide through his hair like she’s untangling silk threads. She thinks she should have made the Adrien-is-Chat-Noir connection sooner, given how many times she’s slid her hands through his hair both in and out of costume. She’s never quite gotten over how smooth it is. She’d told herself that with Chat it was just the magic, and with Adrien, she’d imagined copious bottles of product—only come to find out, it was both.

His head rests in her lap, and his eyes hidden behind his forearm. His fingers fidget absentmindedly with one of her hair ties, and his lanky legs are propped up against her wall, jeans sliding off to show just a bit of bare ankle. She’s pressed back into her own mountain of pillows, and she thinks how nice it is to have afternoons like this together. No more chasing down villains, no more battles, no more secrets.

“Kim as the monkey was an inspired choice,” Adrien says. “He’s about as chaotic as Plagg.”

Marinette laughs softly. “I think that was Master Fu’s choice, not mine.”

“How do you decide who the right choice is?” Adrien pulls his arm from his face and looks up at her. Pensive curiosity flits through his determined green gaze. “Like, Nino’s really protective, so Carapace makes sense, but Alya’s all about truth and justice, right? Lies and illusion don’t make a lot of sense for her.”

Marinette tips her head back and stares at the trapdoor above her bed. “I didn’t think Ladybug made sense for me. She’s so brave and cunning and determined… I’ve always been a coward and pretty hapless and helpless.”

“I think you’re brave and determined.”

“You’ve only known me since becoming Ladybug. I’ve grown a lot.”

“Chat Noir made perfect sense for me.”

Marinette laughs, jostling Adrien, and when she looks back down at him he’s glaring up at her.

“You don’t think so?” he says flatly.

“It’s not that,” she laughs again. “I mean, it does make sense—now anyway. But not how you used to be, you know, around other people.”

“What are you trying to say?”

“Just that you’ve changed, too.”

“I was always like this,” he protests. “I just pretended to be someone else for a long time.”

“So you weren’t a handsome, charming, polite and kind friend all those years?”

“Chat Noir is all of those things.”

“Charming is stretching it.”

Adrien wrinkles his nose, and it only makes Marinette laugh more.

“Who was Scarabella, anyway?” Adrien asks, unsubtly changing the subject.

Marinette has to take a moment to compose her giggles. “That was Alya.”

“Ah, of course. She did a good job, but she certainly was no replacement for you.”

Marinette bites her cheek, hoping he can’t see her blush. The hardest thing about dating Adrien after the reveal has been listening to him praise her as Ladybug. She had never quite felt comfortable hearing him praise Ladybug before, and now that he knows the truth, it’s worse, as if knowing both of her identities has somehow doubled the intensity of the compliments.

She unsubtly reaches for a subject change of her own. “And what about Catwalker? You picked him, didn’t you? Or was that Plagg?”

Adrien glances away, tipping his head back for a better gaze of her pinboard that is no longer just Gabriel ads, but has grown to include photos with friends and pictures from several of their date nights, and a few even of Ladybug and Chat Noir.

“Catwalker was—well…” His brow furrows as he searches for the answer. She can’t fathom why it’s so hard for him to explain if he knows, but finally he says, “I was Catwalker.”

Marinette laughs again. “What do you mean you were Catwalker?”

“Well—you didn’t need Chat Noir around, and Plagg didn’t want another holder, so we… we figured something else out.”

Her hands go still in his hair. “You know I always need you, right, minou?”

His eyes are still on her corkboard. “You didn’t need Catwalker.”

“It was more like I couldn’t function with Catwalker. I… I liked you too much. You were so careful, so polite, so put together and charming… I couldn’t even think straight, just like all those times I couldn’t talk to you at school. You just made my brain stop working! I couldn’t be Ladybug if I was too busy thinking about kissing you.”

She hopes he’ll sit up for a kiss, but he still doesn’t move. His gaze remains distant.

“Catwalker was based on the person I would always pretend to be. The person my father wanted me to be.”

Marinette understands rather suddenly where she misstepped. She bites down on her tongue, holding back a stuttered apology. She can’t say she didn’t mean it, or it wasn’t true, because it all was and still is. She loves Adrien, and a lot of “Adrien” has been made to please his father. She understands now why he had pouted when she’d said he was so different from Chat Noir.

She runs her fingers through his hair again with a bit more intention to the contact between them than her lazy strokes earlier. “Shortly before we started dating, I got obsessed with dating Chat Noir.”

“Oh, I remember,” he says, and a small smirk flashes across his face. Despite how insulting it ought to feel, it relaxes her. She knows he’s still here, listening, and not lost in his own head.

“I love all of you, Adrien. You are still kind and polite, and not just to make others happy. You do it because you care. And you’re silly and sometimes charming, but maybe not as often as you’d like to be. You’re Adrien and Chat Noir, you know, and I love all of it. Because I love all of you.”

His eyes finally slide back up to meet hers. “You’re Marinette and Ladybug, you know.”

Heat creeps up her neck and into her cheeks. “O-of course.”

He swings his legs down and pushes himself up to her level. “You are brave and determined and cunning and creative and honest and thoughtful and a hero.” He leans in until his face is inches from hers.

Her cheeks must be fully red now.

“Adrien, I’m not—”

“If I can be Adrien and Chat Noir, why can’t you be Ladybug and Marinette?”

“I-I am, I just—”

“Am I allowed to love all of you?”

Her tongue tingles as her anxiety mounts. Her brain sparks with all the same misfires it used to around Adrien and Catwalker alike, which is unfair since he’s being particularly impolite and invasive in this moment.

“Adrien, I—”

“You’re my lady and my purrincess,” he says, voice low like Chat Noir’s as he brushes her hair away from her face.

Marinette isn’t sure if her heart or her lungs are going to give out first, but one of them is surely about to clock out for the day and leave her high and dry.

And then he kisses her, and all of her parts call it quits—except her mouth, which seems to find its way around his just fine.

His hand slides through her hair, and his other hand finds its way to her waist. Marinette wants to stop, but she also doesn’t want to stop—ever. It occurs to her, distantly, that Adrien has once again changed the subject away from himself, but that thought is too far from this moment, from the heat of this kiss to do any good.

When he finally does pull away, there’s such a Chat-like mischief in his eyes that only makes Marinette’s blush worse.

“I love you,” he says.

She forces herself—with a fair amount of effort—to remember where they had left off their conversation. “I love all of you,” she says.

He hesitates for only a moment, long enough for her to know the weight of her promise reaches where it ought to. He answers, “Only if you’ll let me love all of you, too.”

It’s a fair trade, at least. Maybe someday Ladybug will stop feeling like a costume, like an act she puts on. Maybe someday she’ll feel worth of all of those grand adjectives. But at least today, at least for now, she’ll feel worthy of Adrien, and she hopes that someday he’ll feel worthy of himself, too.

She twists her hands into the collar of his black T-shirt and pulls him in for another kiss.

#miraculous ladybug #miraculous ladybug fanfic #ml fic #adrienette #adrien agreste #marinette dupain cheng #i think i actually sat down to read fanfic but found myself writing it before i had quite realized what i was doing #if you hold this one up to regardless of perfection and put on the magic decorder glasses #you might be able to catch a glimpse of my imposter syndrome

[technotestechnotes]

A Guide to Mindful Communication in Code Reviews

Code reviews are a core part of being a software engineer. Most of us review code every day. Technical skills are needed to review code thoroughly and quickly. But beyond that, reviewing code is also a form of communication, teaching, and learning. Either as the author or the reviewer of code, being mindful in your communications can make code reviews more valuable for everyone.

Mindful communication

First of all, what does it mean to be mindful in your communication? Mindful communication is a term that means to listen and speak with compassion, kindness, and awareness of yourself and others. This perspective is the basis of most of the tips in this guide, so let’s dive into it a bit more.

Here are some general guidelines for practicing mindful communication:

Put yourself in the other person’s shoes.

Listen to hear what’s actually being said.

Let go of what you think the outcome should be.

These things are easier said than done! So I’ll break down how these guidelines apply specifically to reviewing code and having your code reviewed.

Tips for everyone

A crucial skill to learn for practicing mindful communication is a self check-in. This means taking a moment to see how you’re feeling and take a step back from what you’re communicating.

When you’re doing code reviews, you’ll want to check in with yourself to see if you’re following the guidelines. Good times to check in are right before you start or reply to a review, if you’re feeling frustrated, or right before you hit “submit” on that comment.

When you’re checking in, also consider how you’re feeling in general. Giving kind and considered feedback takes time and energy. If you’re hungry, tired, in a hurry, have a lot of meetings, etc., don’t review code or send out a review. You need to fix those things first. If you don’t care for yourself, you can’t take care of others.

Here are some good questions to ask yourself when you check in:

Why did this person write this code the way they did?

Is the tone and wording of my feedback something I would feel good hearing?

Do I fully understand where they’re coming from?

Do I think I know the “right” way to write this code? Am I allowing space for a solution I haven’t thought of?

Do I have all the information I need to understand this issue?

Have I eaten lunch?

Do I have enough time right now to give thoughtful feedback?

Am I feeling upset/nervous/anxious about something else?

Tips for the reviewer1. Don’t jump to conclusions

Assume the author did what they did for a reason. Put yourself in their shoes. When you make a code change you likely consider a few options, and go with one that fits the needs and constraints of the problem you’re solving. They likely did the same thing.

Instead of telling the author they did something wrong, try:

“What about this other option? It might make xyz better!”

“What happens in abc situation?”

This also hits on letting go of the outcome. You might not have the right answer. You might not have all the information you need to understand why the author took the approach they did. If you step back and try to understand where they’re coming from, it might surprise you!

2. Ask open questions

Listen! Don’t assume. If you think something is 100% off the wall, check in with yourself. You respect your co-workers, so ask them to explain their thinking. You might learn something, or get a glimpse into someone else’s thought process.

Try these formats:

“This part is a little confusing. Could you walk me through what it’s doing?”

“I’m having a hard time following this section. How does it work?”

“What other options did you consider for this part?”

3. Leave out the nits

There’s no need to call out nits or small things that maybe aren’t your style. Linters are great for catching small issues or keeping a code base consistent, so there’s no need for a human to call those sorts of things out. If a linter could catch what you’re about to point out (even if your current setup doesn’t), think hard about whether it’s worth everyone’s time to discuss.

Labeling a comment a “nit” is also to be avoided because it minimizes your feedback. Your input is valuable, so leave out the caveats. If you don’t feel your comment is worth adding without a caveat, consider leaving it out completely.

Avoid starting comments with these:

“Nit: …”

“This is a nitpick …”

“Tiny nit: …”

“This is slightly nit-picky, but…”

(All pulled from real PR comments 😱)

4. Call out if things could be fixed later

So you’ve left out the nits, but there are still things you think could be improved that aren’t strictly necessary. Let the author know you don’t mind if they’re updated in a later or follow-up PR. You might not be aware of a deadline for the team or that there are a lot of changes still coming.

Here are some phrases that acknowledge iterative work:

“This could cause x problem later, but I think it’s fine to fix in the next iteration”

“Can we make a ticket to come back to this section? It might cause x issue down the road!”

“Have you thought about how this will generalize to what we’re working on next?”

“How are you planning to handle this other situation that’s coming up?”

5. Be biased towards approving

Our work is iterative and subjective so don’t be a gatekeeper. Try to approve reviews even if you disagree with the style or approach. People write code differently, and come from different perspectives.

Though I advocate for not blocking PRs on reviews, often the author must get your approval before moving forward. This creates a power imbalance. Avoid abusing that power and approve it unless you’re worried a change will cause major problems. If you’re that worried about something, another option is to go talk in person or use some of the open questions from my earlier tips.

An exception to this is if the change is very large or includes an architectural decision. When a decision is being made that will have long-term consequences, it likely warrants a larger conversation than a code review. After that conversation the review will likely be a quick 👍.

6. Give example code

Particularly when reviewing code for someone more junior, giving a specific example in the review comment can be helpful. This saves them time, and makes it really clear what you’re proposing. Also, you already thought through it, so why make them figure it out on their own?

Here are some examples:

“This section might be more clear if you switch the order like this: if (true) { return “this is an example”; }”

“You might be able to replace this part with a utility we have! I think this would do the trick: const x = utily_thing(y, { a: true })”

7. Link to documentation

Linking to documentation or files you referenced shows the author where to find the information next time. This is particularly good to do if you looked it up while writing the comment. You already have the link, so you might as well. Sharing is caring! But acknowledging that you needed to look something up can also help fight imposter syndrome.

Calling out that you learned something new in the review can have a similar effect. If you come across a new method or syntax that you need to look up, leave a “TIL” comment and include the link that explains what was new to you.

8. End with “What do you think?”

Ultimately the author of the code will be making and owning the change. If you have a more fundamental or big piece of feedback, end the comment with “What do you think?”

This goes back again to letting go of the outcome. Maybe you don’t have all the context — maybe the author already thought about the approach you’re suggesting and there are issues with it that you missed.

You can also ask for history about how the decision was made. If you weren’t part of conversations about the approach, getting some history can be helpful before suggesting a different one. Sometimes junior engineers are following the advice of another more senior engineer, so if you disagree it likely makes more sense to talk to the senior engineer.

Hopefully large or fundamental changes aren’t needed by the time code is reviewed, which leads me into tips for the author.

Tips for the author

If you review code, you likely have your code reviewed also, so think about what makes a PR easier or harder to review.

1. Make small iterative changes

It is so much easier to review small changes — the smaller the better. Smaller changes are less risky, and take less time to review. Reviews with many hundreds of lines changed take much longer to review than several small ones with isolated changes. If each PR maps to one piece of work, it’s easier to understand what the code is doing. The reviewer doesn’t have to pull apart which changes are needed for each task.

2. Link to documentation

Sound familiar? This is a tip for both reviewers and authors! Linking to documentation in your review description or comments can make it easier for the reviewer to understand what’s being changed or implemented. If you’re implementing an interface or using a new library, link to the documentation you referenced while doing your work.

This is particularly helpful for seemingly small changes in things like configuration. Have you ever received a one-line change and had no idea what it meant? A link to the documentation is so helpful in these cases.

3. Assume the reviewer has the best intent

Even if a reviewer follows all the tips above, they can still make mistakes or get careless. Try to keep in mind that we’re on the same team and they likely had good intentions behind whatever feedback they gave. It’s easy to get defensive, but remember, as the author you have to let go of the outcome just like the reviewer. Maybe the reviewer has some knowledge or expertise you were missing, or saw a blind spot you missed because they came from a different perspective.

A major exception to this is if the reviewer legitimately doesn’t have the best intent. If someone is being actively malicious or hostile in a code review, that’s harassment and you should speak to your manager and HR about it.

4. Think about the readability of your diff

Your diff itself is a kind of communication. Make sure it’s well written!

Here are some things to think about when cleaning up a diff:

Don’t refactor in addition to new changes.

Check that your PR doesn’t have unnecessary changes or unrelated files.

As mentioned above, each PR should be one logical unit of work.

If you find yourself leaving explanatory comments on your own code review, those might be better as code comments.

Sometimes diffs are more easily viewed with no white space. You can see a diff without whitespace changes on GitHub by checking “Hide whitespace changes” under “Diff settings” or by adding w=1 to the url. On the command line you can use git diff -w. You can call out that a particular change might be better to view that way in your PR description.

5. Get feedback early and often

Having a quick chat about some implementation options with someone who’ll review your code is a great way to avoid stress when the review comes around. Reviews are usually not the time to work out architectural decisions since the work has already been done.

This sounds like hard work

If this all sounds like a lot of hard work, that’s because it is. Like I said earlier, giving kind and considered feedback takes time and energy. But luckily it gets easier.

You can build up muscle memory of actively giving kind feedback and it will become natural. At first it might feel uncomfortable to ask a question when you think you can just tell someone the answer, or it might feel slow to write out a code example. You might have to stop, check in with yourself, and do it anyway. This is a learning process and learning new things is uncomfortable.

Lastly, keep in mind that every team is different, so these specific tips might not all apply to your team. If you come up with other ways to apply mindful communication to code reviews or building software in general, I’d love to hear about them!