You only get to be "new" once, You only get to have a fresh perspective once. There is a reason that you're a bad judge of the "usablity" of your product. You already know how to use it. your numb to it's mistakes and flaws. New team members dont suffer from this!

The bigger lesson here is for the team, and its sadly between the lines! You can get a lot of insight based on what new people ask about, where they stumble and what they need real help with.

The thing is, that not all people suck equally bad at this. A big part of it is to actually care and be empathic enough to put yourself into the shoes of the un-initiated. Two people who both have used the Bash shell a million times might have a completely different understanding of what makes it weird and unintuitive to someone starting out, even if both had trouble when they themselves did.

Looking at things with a fresh mind is a skill one can get better at, just like you can learn how to look at actual light and objects to draw what you see instead of drawing what your brain tells you you see. It is a hard thing to learn and it is something that can fail you even once you became somewhat decent at it, but every good educator needs that skill.

Instead, by writing it down and NOT expressing it just yet, you give yourself time to learn the lie of the land and why things are the way they are; to orient yourself in the workplace. And when you are comfortable, settled with accounts/permissions/authorisations, you have a nice list to move on.

The team is then more likely to think you are being helpful rather than a popup muppet exclaiming "WTF is that!" all the time.

Both of these steps were crucial. The presentation serves a ton of purposes, it ensures both the student and the teacher learn the material enough to present with a whiteboard, and the team can catch any mistakes or misunderstandings at a time when they'd have the most sympathy towards ignorance. It also is a good low-stakes way to force someone to present and get used to the team and talk to everyone in a formal setting. We also always ordered pizza + beer after too make it a "fun" (or at least casual) environment that wasn't too serious.

I spent the whole 3.5 weeks I worked there starting fights and noped right back out.

But I expect starting a journal like this, waiting for a list to grow, is also a great path to resensitizing oneself to all the potentially useful problems to solve.

Writing down something and then waiting is such an immediate, low effort/immediate reward (my list got longer!), but long-term high-payoff act, I think it can be easily relearned with a systematic practice like this.

I like the continuous separation of recognition and recording, from the downstream progression: Create a map (see), take time to study it (learn), form a party of the co-concerned (lead), before running off into the forrest.

I have been journaling like for (8 years). Both notebooks and Scrivener. I like Nat's journaling method. This way he avoids looking like a fool/jumping the gun, and he gives the time for things to unfold (or not).

One of the best things my company does is allow me to sit down on a chair next to the people who use my products as they use them.

I just sit there with a notebook and write things down, and talk to the users as they're using the product.

Once you start doing that, you understand that it doesn't matter how many terabytes of "telemetry" you gather, you will never understand how people use your product as well as actually speaking to them.

The tech industry really needs to get over its fear of other human beings.

Watching people use your app behind a 2 way mirror was probably the most illuminating thing ever. Users from outside the tech bubble have a very different take from most of the HN set. It influences how the look at, use and think about applications.

You can watch 7 people DO the right thing and then tell you, out loud, that it sucks for the same reason. Every app is filled with problems like this. If you aren't testing with "inexperienced" end users you are likely missing a LOT!!

I recently took a 2 month break from work, and coming back I had plenty of these moments too.

Things that previously I thought were smooth weren't. Processes that I thought worked fine seemed to crumble. The overall application speed felt like treacle where previously I thought it was fine.

Sometimes a fresher perspective on the state of things is important, although unlike a new team member it's not doing me many favours pointing some of this stuff out.

Being a new team member is also an amazing opportunity for being able to speak freely about problems and point out that the emperor is nude.

I’ve been doing user studies on developers for more than a dozen years. It got a lot easier once screen sharing was more common. But letting new hires or devs with brand new machines twist a little when going through the setup docs and taking notes. Or doing similar when I’ve made a major change or introduced a new API to see what fresh eyes see that I did not (or in some cases, that which was true but no longer is).

If at all possible I task them with fixing the docs. First, as you say, they don’t have the Curse of Knowledge, so how they word it will reach down the ladder behind them. Second, if what they say is completely wrong, then I can correct the miscommunication easier when they’ve used their own words to repeat back what we discussed.

Making edits to the wiki is usually the first contribution I want to see from a new hire. Even if it’s just untangling a run on sentence.

Of course only new hires notice. Maybe only new hires who have been enough places to realize that it doesn't have to be this hard...

I think the greatest mistake in software design is the pattern of structuring UI/UX around assumptions. Every assumption made in software design is a demand for the context that that software will be used. The reality is that context will always be fluid, and that it will often contradict itself. Free software can be liberated from its assumptions, but it requires redundant work for every unique contextualization.

Managed that...would not recommend. When you're in a large organization and word spreads that you're the guy that can sort out issues...that goes viral and not in a good way.

Recently had a guy reach out to me from Serbia for a solution. I didn't even know we had a fuckin office in Serbia let alone some guy there wanting a slice of my time.

For starters, at that company, I always fortunate to have a manager that had my back when it came to deflecting requests that didn't come from him or her. If a random person reached out to me with a request to do some non-trivial work that I either didn't have the bandwidth or interest to do, all I had to say was, "Sorry but I don't have the time to look into this right now. If you need this prioritized, please run it by my manager." 99 times of 100, my manager never heard from them.

The biggest upside to being the go-to guy for people across the department/company is that you get to collect acquaintances and contacts. It's a fun little micro-superpower. Extremely valuable when you need some bit of info from someone outside your team, or need someone to cut through some red tape to get something important done. It means I also have a modest network of people to hit up when I go looking for new opportunities. (This is how I have landed 100% of the jobs in my decade and a half of civilian employment.)

That's the thing. You don't get credit for those death by a thousand cuts queries that come with a universal X is the person with the answers rep.

None of my superior knew we had an office in Serbia either...let alone crediting me with "yes havoc is totally flooded but he helped serbia guy anyway".

Note that I'm talking general corporate here. Things may be different in a pure SWE eng context. My observation is strictly corporate life...may or may not extrapolate to SWE context.

You can only write so much code per day. If you can help 100 people be 10% more productive, you're leveraging your knowledge to help the whole company do 10x more than you could personally do. Congratulations!

But i'm seen as knowledgeable and my manager basically lets me completly alone doing my thing and gives me all benefits regarding salary he can to keep me.

That promotion is going to need a backfill and the organization may decide that it’s best to keep you in your place. Though it could lead to being able to negotiate a raise earlier than normal.

> I'll ask why things on the list are that way, and how they got to be that way. I'm trying to establish credibility as someone who's genuinely curious and empathetic, who's patient, and who respects the expertise of my coworkers. That's the reputation that's going to let me make changes later.

I would not try to establish credibility, but earn it. I will not try to be genuinely curious or empathetic. I either am, or am not.

> At this point I'm looking for one or two problems that have been bugging one of my new teammates for a while, and that have relatively simple solutions. I'm looking for something I can put on the retro board and know I won't be the only person who's bothered by that problem.

This screams to me as playing the work game. If someone can spend time looking for problems over their coworker shoulders or "something to put on the retro board" it just means they are out of meaningful tasks to do.

> Then, during the team conversation about the problem, I'll identify something that teammate suggests as an action item that we could try immediately. That way the team starts to see me as someone who helps them solve their problems.

Change the context and this sounds like a pickup artist explaining dating tricks, or a con man telling you how to infiltrate or someone on the secret service trying to enter a gang.

> The feeling that I want to create, the association I want people to have with me, is, "Oh, Nat joine [...]

Feelings are not something one goes around creating unless they are actively manipulating people around.

> There's a very specific reputation I want to have on a team: "Nat helps me solve my problems. Nat get things I care about done." That's the reputation that's going to get me the results I want in next year's performance review.

I could keep going on, but I think these are enough examples

However, it's worth saying that: Being intentional about relationships is not manipulation.

If I decide "I want to be a better husband" and then spend time noticing and writing down a list of things that my wife says bother her or would make her happy or she thinks would be romantic, and then I go through and choose some of them and set myself reminders in my calendar to do them... Am I "manipulating" my wife into "thinking" I'm a better husband? Or am I just plain being a better husband?

Would it be worse if I got the idea from a book titled Would it be better if, instead of being so intentional, I just let my passions and romance sweep me into doing romantic things without any conscious thought? Why?

To make my point clear: Being very intentional about relationships (how others perceive and feel about you — and what actions you take to make them feel and perceive you that way) is not manipulation. If I act in a way that makes my coworkers think that I'm a good coworker, then I AM a good coworker! The fact that it was on purpose and not accidental is...?

Manipulation happens when you develop your "be-a-good-coworker" skills (which is good) and then use those skills in a way that intentionally hurts your coworkers or makes them act against their interests (which is bad).

I see evidence in the article of the first but not the second.

To take your marriage example. The genuine motivation would be: "I acknowledge my flaws and I'm willing to put in the effort to change myself for the benefit of my wife". If the motivation is to just tweak your wife's views of you, that may not be manipulation but it's not very loving either.

People will be able to sniff out if the goal of his behaviour is to have people think of him a certain way, versus having the goal of wanting to bring beneficial change and helping a team out. The behaviour may be the same on the surface, but the intent is very different. I would be very wary of judging people's motivations, but the fact that the author explicitly mentions it bothers me.

But... How do I know which actions will "benefit" my wife? I argue that one of the best ways to know is to ask myself: "Will this action make her feel positively about me?". That way, I'm not going to do things that are important to me but not her, or that I think she SHOULD appreciate but she doesn't actually care about, or whatever.

Of course, to answer that question accurately requires plenty of listening, understanding and empathy.

In the past, I thought more like you. But I think it harmed me. Ultimately I came to the conclusion that intentionally doing things so that other people like to be around you isn't "disingenuous", it's a wonderful thing to work towards!

Of course control might be a valid goal, and controlling your need to control might be a good meta step, too, in a professional environment. The issue of the line between caring and controlling just seems not been discussed enough. And not seeing and mentioning that obvious emotional aspect might already make it look a bit weird.

It's one thing to say that you want to get things done. It's another to say you want to be _seen_ as someone who gets things done.

Again, I don't intend to mind read here, and I think the author actually has some really good data gathering ideas. But the language definitely smacks of political motivation, which some folks (myself included) find off-putting.

Re:'It sounds like a con artist', the techniques for getting people to trust and like you are often the same whether your intent is good or bad. I don't think these techniques should be reserved for people who have an innate wellspring of curiosity and cooperation.

This person is trying to earn credibility, and is specifically focused on the 'new' phase of being on a team, when you do not have a big pile of meaningful tasks yet and your primary goal is getting the lay of the land and establishing good relationships with your teammates.

Finally,

> Feelings are not something one goes around creating unless they are actively manipulating people around.

I don't really understand what this means. I create feelings all the time, intentionally and unintentionally. I often do things where the primary purpose is to make somebody feel good, usually things like 'make some effort to solve a problem that I don't think matters' or 'let somebody explain something to me that I already know about'. It's not about gaining power and status, it's about greasing social wheels and making friendly cooperation easier.

Am I 'manipulating' people? Well, I am often trying to influence them so that they act in a way that I believe will benefit both of us. I do want to rise in my career, but I want to do it by making positive impacts and relationships, not by stepping on others. I don't think that's a bad thing.

Hedging against that with conscious social strategies can be a reasonable thing to do, at least if you are in or are likely to end up in such a large organisation.

I've made the choice to be in a small organisation, in part because my contributions don't need packaging and announcements to become known to those with more power in it than I have. If I were to change my mind and join a large organisation I wouldn't think twice about entertaining a 'game', balancing the degree to which I exploit other people and organisational weaknesses to gain money and stability for myself against a semblance of professional and personal ethics.

Perhaps these techniques come naturally to some people, and others need to learn it by instruction? I'm in the latter camp. I often need to think about how I sound and make sure I don't come across as too negative.

First, the author is doing 101 new leadership stuff. I’ve done it, I’ve seen it done, there’s a science to it. I can distill the whole blog post into when taking over leading something (as an experienced IC, as a new manager, as an army officer, it’s all the same), take the first 30-90 days to not change anything, and just seek to understand how and more relevantly why things work. There are a mess of organization benefits to this, it would take more than a comment to explain why. But in short, ya this is how it’s done.

Second, engs have worked for awful managers, can’t often understand or exactly place why but they know their manager sucks. I can argue capably in thread about how often this difficult to explain “sh*ty manager” sense boils down to the manager not doing like tactically good leadership. In the same way as engineering is a taught skill, so is leading teams. Issue is only a few places teach it intentionally. Top of mind for me is the military, and senior exec training. There’s an actual science to it, full stop. You either get taught it by orgs that treat it this way, or you pick it up from a mentor who learned it somehow. Note - the author learned it this second way. This is really common.

Third, to work for good managers, you actually want to work for good leaders. Leadership is a tactical skill, the same way efficient lines of C++ are. Leadership tactical means tactically shaping and steering people to achieve a goal greater than the sum of the team’s individual parts. This full stop requires what in a certain light is what you point out - it’s a bit manipulative feeling. It’s using leadership methods to make people work together in a way that is effective. A lot of this is good EQ and stuff like the author maps out.

So, who do engs like working for? Often it’s working for technically inclined good people who go to bat for their team with external parties, shield their team from stupid stuff, resource the team to complete its goals, praise in public criticize in private, give good but not overly micromanaging guidance on where to steer things, recognizes and rewards performance, holds unperforners to a standard, and so on and so on?

Some examples of who knows how to do this but for the wrong reasons are people engs don’t like working for - to stereotype: charismatic jocks out of MBA programs who can know nothing about tech but know corp politics and deploy this stuff tactically.

Who do engs hate working for often - technical hires promoted into management and they hate/are bad at their jobs bc management != tech chops, as my above covered.

So, what that leaves is a scenario where teams are led by the occasional person that inherently knows good leadership chops, or more often it’s pissed off engineers who hate working for someone manipulative or incompetent.

To raise the collective industry odds that tech teams work for skilled and competent leaders, that leaves as the solution spelling out tactical leadership - how to do it, what it looks like, how people fit into it, like this blog does.

Pick your poison - more of the same, or good people who just need clear guidance learning from resources like this on how to run teams people want to work on? HN certainly complains to no end about the dynamic caused by not approaching leadership as a skill vs some nebulous thing people somehow know how to do.

Your job is a really important part of your life - and you will also affect a lot of other people. It's important to be a bit strategic. Otherwise, even if you have wonderful intentions, there's a great chance you'll work on things that don't matter and that leadership knows nothing about, until your career quietly fizzles out.

This should be near the top of the article, not buried at the bottom. This level of self awareness is a real skill that is worth mastering.

The ex astronaut Chris Hadfield talks about a similar approach he used when joining new missions and teams in his book. Basically being in observation mode first to learn if these WTF moments are valid, and not annoying new team members. Its worth a read.

Then there's some time to review/prioritize/etc before any sort of discussions.

There will be plenty of times where things were rushed or mistakes were made, but sometimes it really is the case that you just can’t wrap your head around some piece of complexity right away just by looking at a line of code.

I don't bring it to management's attention like the author suggests, but it gives me a perspective on what sticking points the team and company have that I need to work through over time.

In contrast, the ones that use the time wisely, and take notes end up getting fast tracked to architecting systems on their own (with my oversight and code reviews). Those are the teammates that I love to work with, the ones hungry for knowledge and aren't afraid to make mistakes (assuming they aren't hiding them). I'd say I get almost as much knowledge out of mentoring as the new new hires do from learning new techniques and technology. It can be extremely rewarding.

Sometimes management doesn't prioritize problems because they're short-sighted or overwhelmed. But sometimes it's because they just don't understand how big a problem it really is, and the team fails to communicate it to them effectively.

For example, I've heard devs complain about how "the tests take too long." On one team I was on, a couple junior devs were complaining about this, but it turned out that "too long" meant five minutes. Could they be more efficient? Maybe, but getting that down to one minute would take a lot of work with no impact on our ability to develop and deploy multiple times per day. Once I showed them how to run their tests locally on just the files that changed, the problem was solved. But before that, they thought the problem was "technical debt," when really it was just a training issue. (Or, you know, a lack-of-ability-to-Google issue, but I'm trying to be generous.)

On another team, when I heard this complaint, the team explained that the full test suite took almost an hour, and flaky tests meant that they often had to rerun the tests or merge with failing tests. Needless to say, this had a clear impact on our ability to deliver rapidly with high quality, so this was something I prioritized.

Managers don't do the same work as you, so they don't feel the pain firsthand. And they're often not incentivized to care about the same things as you, at least on the same scale. As an IC, you tend to be focused on the next task at hand. The manager is thinking about their quarterly OKRs or whether the team is on track to meet their sprint commitment. If you want something to change, you have to connect the problems you have on the micro scale to the problems the manager cares about on the macro scale.

And if you can't do that, or your manager won't listen, then yeah: let the problems bubble up until the manager feels the pain, as long as it won't come back to bite you.

Ideas rarely appear when you need them, but come throughout the day as you do other things, and at least in my case, I can never remember if I don't jot them down.

Then when it's time to get something done, I just cross things off one by one. Never have to wonder what to do next, never run out of ideas, which allows some pretty spectacular bursts of productivity.

The irony is that, while I know I have a treasure trove of amazing ideas, at my age I don't think I care enough to execute them like I would have in my 20s. Oh well!

I see what you are saying, though I find it a bit unfair. I don't think age has to stop anyone, and I was more so using it as a proxy for being a different person with new priorities. In my years approaching 40, I can't say I care at all about sitting in front of a screen for hours on end making some doo-dad when I could be forming relationships that I missed out on earlier in life.

I will definiteky check our your video, though.

It totally was, and on purpose!!!

>> In my years approaching 40,

At 48 I can tell you that slowing down is NOT what you want to do, speed up!

>> I can't say I care at all about sitting in front of a screen for hours on end making some doo-dad when I could be forming relationships that I missed out on earlier in life.

One does not preclude the other. Hell everything is better with friends! The thing about old people is we dont want doo dads we want to get shit done. You can build all the things you want as beer money projects with the friends you make and if one of them hits, well... Im sure you know better what to do with money now then in your 20's.

"Beware of an old man in a profession where men die young"

Maybe your team is only doing sensible things and all is perfect. Maybe you're blind to things that could be better. Heuristically, if you're writing software, it's not likely to be the first case.

My professional project moved to GitHub recently. It is terrible. The pull request / review system is borderline unusable. But already I can feel myself adopting clumsy workarounds and losing sight of how much better it should be.

If they'd had someone do the former, most of the time they'd not have needed the latter quite so much.

but maybe that’s just me.

You don't need a new hire to fix those problems, but it certainly helps shed new light on some problems. Especially if you are hired as a senior dev or a team lead, you will be expected to fix some of those things.

Now the project is financially a total shit show, I'm besieged by dweebs, and I've been quietly looking for a new job for 6 months. Apparently, this was an avoidable situation.

The immediate cause is lower management can't be assed to learn anything, and nobody makes them. This is in part because at big firms after 5-10 years you can politic or job-hop into management and be an email engineer who does little outside of scheduling meetings and marking up PDFs. Young engineer training is usually informal and in master-apprentice fashion. Your mentor will show you how he or she learned it 10 years ago, which is how his or her mentor learned it 10 years before that.

There is little technological progress in civil engineering design that is not externally imposed, and the last big step forward was Excel and replacing hand drawings with CAD in the 90s. Digital delivery will be the next leap, but it's going to take lobbying, fanatical champions, and pure luck that Autodesk and Bentley don't use their billions to suppress it.

Procurement laws, client ignorance, and network effects shield engineering consultants from the discipline of the market. Wasteful practice is not punished. That and licensing regulations have created a sort of guild socialism that has allowed backwardness to survive.

Now I have a fun name for it :D

Also, now I know there's a link! Sometimes you have a new hire or team member who's a little too eager to criticize and fix everything they see, and you need to sit them down and explain this strategy. Now thanks to Bennett, you can back it up with a link.

I'd caveat that while a "two week" waiting period might work well for Bennett as a senior engineer moving between similar-enough teams, a brand new hire or a junior dev might do better with a longer delay.

Seems like an excellent corollary to Chesterton's Fence, about someone who comes upon a fence they want to remove:

"If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it"

Or, more explicitly: "Although this looks out of place, we do best to assume that those who came before us were intelligent, and there is a reason for it. That reason may be obsolete, but it must be accounted for or we'll simply repeat a mistake."

This works for a referral, but it is a career killer. I did this for 20 years in different departments. Every time they wanted to keep me there to solve their problems, but this never puts you on the promotion list. I had a colleague that retired after 40 years, he was the go-to person for any problem, but he was never promoted, he was way more competent than any of his managers and their peers. He was the ace in everyone's sleeve, rarely recognized (it was considered to be "normal" that he solves any problem) and never rewarded; his performance was considered an expectation, while the rest of the people at the same level had a much lower bar. In the last performance review, his manager said that his performance is compared with his goals and targets, not with peers. I was told the same by a different manager, so it is not an accident.

At the same time, this sounds very political, and not traceable to goals of the business:

> There's a very specific reputation I want to have on a team: "Nat helps me solve my problems. Nat get things I care about done." That's the reputation that's going to get me the results I want in next year's performance review. That's the reputation that's going to get me a referral a few years from now.

I like to be on teams for which, if new to the team, mostly you notice things being done sensibly (in context), and the 3 things you see that you don't understand, you can just ask about them, because everyone on the team just wants to work well together to achieve the genuine goals.

Not to have to bank observations as an asset, to be introduced diplomatically and strategically, according to a script, to maximize performance reviews and peer approval ratings.

I've observed this kind of culture mostly at startups. Once places start to make a lot of money -- things become political.

So if you want to work at the highest paying jobs, you'll have to deal with politics. Because once they make enough money to afford you, the company also makes enough for savvy gatekeepers to entrench themselves in a core system and carve off a piece of that revenue for themselves.

However,

> For two weeks, that's all I do. I just write it down. I don't tell the team everything that I think they're doing wrong. I don't show up at retro with all the stuff I think they need to change. I just watch, and listen, and I write down everything that seems deeply weird.

> [...]

> Before I started keeping this kind of list, I brought up problem I saw immediately, as soon as I noticed it. The reputation I got was, "Nat's always complaining about things. Nat thinks we're never doing things right." People stopped listening to me. I was personally frustrated, and professionally ineffective.

Not bringing up things that you think could be improved in a retro.. that's pretty silly. If you are getting a reputation of 'always complaining', and coming across as 'telling people they are doing things wrong', etc. then you are just bad/unprofessional at communication.

Communicate things as 'I was thinking maybe we could do better if , what do you think?' and make it a genuine discussion with people, rather than 'WTF ?' - especially when it is someone else's work and you want to remain on good terms with them.

You don't have to wait 2 weeks, compile a secret list and then bring it to your manager - though. You can communicate things that you think can be improved in a polite/respectful manner as they occur. Being on a team is about working together. If you cannot safely do that when communicating effectively, then you are with a terrible team/company.

I have 20 years of software engineering and infosec experience can fill a few hours talking about all the crazy risks I find in a day of looking around most any company I interact with.

The status quo for security in our industry is abysmally bad. Not washing hands while working in a hospital WTF bad, everywhere.

Bringing it all up as I go can burn everyone out on interacting with me or trusting me at all if I am not careful, because survivors bias is a hell of a drug.

Two weeks to collect information and context is about right. I just usually do it as a contract security auditor now and provide a detailed report at the end.

By watching and waiting a bit, it gives time to learn why the stupid things are stupid, what is actually being worked on, etc. This helps build trust in the team, because it shows the new person respects the team enough to take some time to learn how things are before trying to change it. I don’t trust anyone in a leadership role that starts changing things before taking the time to learn how and why things are currently done the way they are.

A guy on my team now takes your approach. He derails every meeting with the way things “should” be, and he is just saying what everyone already knows, he just lacks the understanding on why the problem is more difficult to fix than he realizes. If he would talk less and listen more, he might understand those things better and stop wasting everyone’s time.

If I see a common problem, I want to fix it immediately and say something like "I see big batch sizes all the time and they have a simple, counter intuitive fix. In fact, of you had read more than 30 minutes, you would see it addressed."

One kind of WTF that isn't usually obvious from looking is when doing what looks like a simple thing takes excessive time and effort. Sometimes, after a couple of weeks, you can see something that has been in progress but not completed for no clear reason. Oftentimes these extra effort things don't show up because the team avoids doing them unless absolutely necessary. It's worth asking a team member for a tour around something you know from past experience in similar situations should be easy and quick. A big tell is when the response to your request for a demonstration or explanation involves a need for someone to block out extra time or involve a specific individual who knows it best.

My first note would be:

- WTF! I ate five Lindt chocolates (they tasted so good) during a intermittent fasting session. I should burn in hell.

I eventually stopped this because it kind of made me feel like a sociopath and/or narcissist myself. I don't really think it's healthy to keep tabs on everything that pisses you off, like some kind of scoring system. It's not like me writing this stuff down helped anything, and it just felt like I was trying to keep score so that if I get in trouble I have a retort. I think it's actually good to occasionally forget stuff and let it slide, because there will always be bullshit management policies at pretty much any company with more than like four people, and writing this stuff down just makes it easier to let stuff continuously bother me.

ETA:

To be clear, it wasn't my idea to write it down, I was getting in trouble for complaining too much at this job, and my direct manager suggested I write things down. I think he thought it was a way to cool off, even though I don't think that was the effect.

or, channel your inner complainer into your promo-seeking behaviors.