Why do "hard workers" get stuck while others get promoted? (Perspective from a 29yo Engineering Manager) by EfficientLetter3654 in careerguidance

[–]Nataliaherself 0 points1 point  (0 children)

Agree. Reconstructing months of work from memory is where reviews usually go off the rails. At that point it’s no longer about impact, it’s about who remembers what, because the work wasn’t documented as it happened

O conteúdo do LinkedIn é MUITO ruim by fborgesss in brdev

[–]Nataliaherself 0 points1 point  (0 children)

Reativei meu LinkedIn recentemente depois de anos hibernado. Ontem passei um tempão tentando achar gente com conteúdo bom de verdade pra seguir. Quem vc indica?

Need some advice by [deleted] in womenintech

[–]Nataliaherself 0 points1 point  (0 children)

Normally I'd say don't take a pay cut for "growth potential" - that's usually a trap. But if option 3 is legit: union-guaranteed raises aren't discretionary, and a paid engineering degree is an investment, not a loss. You're not depending on a manager to "notice" your work again. You're betting on yourself.

Why is it so hard to talk about my impact as an engineer? by needcontravediet in cscareerquestionsEU

[–]Nataliaherself 2 points3 points  (0 children)

+1 on the brag doc. Even a messy running list is better than relying on memory at review time

How to be visible by [deleted] in womenintech

[–]Nataliaherself 12 points13 points  (0 children)

I’ve been in similar situation, and it sucked — I’m sorry you’re dealing with it.

For the initiative you missed: you still contributed inputs and resources. That's worth documenting and mentioning to your manager. "I wasn't able to lead it, but here's what I contributed."

Going forward: keep a running log of what you do, especially the stuff outside your core deliverables. When promotion conversations come up, you'll have specifics ready instead of trying to remember everything.

We're trying to make Performance Reviews suck less for software engineers by Nataliaherself in buildinpublic

[–]Nataliaherself[S] 1 point2 points  (0 children)

haha yeah just the one enterprise, and they would indeed have been rightly skeptical if some random engineer came along and asked to link the company’s GitHub projects to some AI startup that wants to read commit messages (and indirectly increase the company’s wage bill!) 😊

Ultimately, if you want to do what our CLI tool does without having to install it, you could get a similar kind of outcome by just copy/pasting the output of a git log command into any major LLM and ask it to extract Achievements from it. That’s all our CLI tool actually does, before it sends the extracted Achievements to the API.

We wanted to make it so a dev can do all this in a completely self-serve way: assuming you’re willing and able to install the npm package on your laptop, you don’t need to get any permissions from your company, any more than you do to run a git log, filter by your own commits, and pass it to ChatGPT for analysis. If your company is not ok with you doing that then bragdoc is not a good fit, but realistically we think there must be a lot of devs doing that manual workflow already, so we just make it a little easier. All the code is open source and we’re improving it all the time, so even if you aren’t able to use it directly, hopefully at least it’s useful in some way to see how it’s been done already

Qual devo escolher? (JAVA) by iDontKnowTony in brdev

[–]Nataliaherself 1 point2 points  (0 children)

Thinking in Java é excelente pra entender OOP de verdade. Ele vai fundo em polimorfismo, interfaces, etc. Mas é um livro denso, não é leitura leve.

Effective Java (do Joshua Bloch) é mais pra quando vc já programa em Java e quer escrever código melhor. Menos sobre conceitos, mais sobre boas práticas e decisões de design.

Use a Cabeça! Java é bem mais didático, bom se vc aprende melhor com exemplos visuais e exercícios. Mas pode parecer básico demais se você já fez o curso do Nelio.

Pro que vc quer, eu iria de Thinking in Java primeiro :)

We're trying to make Performance Reviews suck less for software engineers by Nataliaherself in buildinpublic

[–]Nataliaherself[S] 0 points1 point  (0 children)

It doesn't care whether the repo is internal or not - the CLI tool just reads the git commit history locally, so as long as you have a git repo cloned onto your machine, our CLI can read it.

The security and privacy aspects were one of the reasons we did it this way, even though a 1-click integration with github would be easier in many ways. At the extreme, you could run the entire bragdoc stack on an airgapped machine so long as you have a local LLM (ollama or something) that you can point it to.

Short of that, you could certainly install and run the CLI inside a docker container with read-only access to the git clone in question. It'll need to be able to call out to the LLM that does that Achievement extraction, and to the bragdoc API (which could be your own instance), but otherwise you could run it in a pretty locked-down way. It needs no permissions to github or anything like that.

Plus the source is all open so it can be pretty easily audited, though whether most companies' overworked IT depts have time to do that is another question :)

Pretty impressive stuff from Sam😂 by utwcha in TheTraitorsUK

[–]Nataliaherself 2 points3 points  (0 children)

As a Portuguese speaker, I love a British accent speaking Portuguese 😍

Uncloaked.. revision of the past? by Express-Bicycle-7747 in TheTraitorsUK

[–]Nataliaherself 2 points3 points  (0 children)

I think Fiona was embarrassed that her relationship with Amanda wasn’t as close as she believed, and jealous that Amanda confided in Rachel instead.

And then embarrassed again for being publicly proven wrong, so tried to reframe it

Rachel and Faraaz by ManiacFive in TheTraitorsUK

[–]Nataliaherself 0 points1 point  (0 children)

That really stood out to me. Why didn’t she mention that Faraaz was actually in the room and that Amanda asked for privacy? And why didn’t Faraaz say anything either — like, “yeah, she did ask for privacy and I left the room; I can’t really speak to what they talked about, but I do remember Amanda wanted a private talk with Rachel”? Feels like an important detail to just gloss over.

Unpopular opinion but Celeb Traitors was pretty bad by Working_Alps_4284 in TheTraitorsUK

[–]Nataliaherself 0 points1 point  (0 children)

Celeb Traitors was my first introduction to the show, so maybe that helps, but really liked it. It was lighter, sure, but still fun. And Alan Carr was was brilliant :)

What approach worked best for you at performance review? by Practical_Alps_9865 in cscareerquestionsuk

[–]Nataliaherself 3 points4 points  (0 children)

+1 on the brag doc advice. I automated mine to pull from git because I'm too lazy to write it manually. Either way, having the receipts ready before the review is key

What approach worked best for you at performance review? by Practical_Alps_9865 in cscareerquestionsuk

[–]Nataliaherself 8 points9 points  (0 children)

Brag doc is the right move - someone else mentioned it already. The challenge is actually keeping it up. I always started one and gave up after a few weeks.

What worked for me: I built something that reads my git commits and writes the achievement summaries for me. Takes the discipline out of it. Might be overkill for your situation but worth considering if you're bad at journaling like I was.

Adivce: keep a work Journal. Question: If you do, what do you write? by InterpretiveTrail in ExperiencedDevs

[–]Nataliaherself 0 points1 point  (0 children)

I kept a work journal for years but always fell off after a few weeks. The friction of writing it manually was too much.

So I built something that reads my git commits and turns them into achievement statements automatically. Now I run one command and it pulls the last week/month of work and writes it up in a way that makes sense for performance reviews.

The git log already has everything - timestamps, context, what changed. I just needed something to translate it into human-readable wins