Compilation can be a big overhead on C++ codebases even when there is plenty of care in regards to modularity. Projects that are heavy on templates usually benefit a lot from compile caching mechanisms.
Just relax and try to learn the most that you can from this interaction: This person could be on a bad day or be a natural asshole, maybe you did misunderstand your manager comments, you definitely should have looked at other projects and most importantly, now you know how not to give feedback to someone else.
Anyway, this is your first job and you are playing a very long game. Don't let a single interaction determine how you feel. As many others already mentioned, you can also talk about it with your manager to figure out what happened.
Indeed! Design suggestions are fair game, but they are quite rare nowadays and their quality has been dwindling.
The last one I got felt too arbitrary: I decided to improve the behavior of an unused feature from one of our core libraries to unblock a colleague working in the application. The change was straightforward and it took me 1hr to get it into a PR. The feedback was that we should keep the old behavior available, just in case. So I spent a full afternoon wrangling C++ templates to fit in a new API that offered both the improved and old behavior for which there is no requirement.
What started as a small detour from my regular work to help a fellow engineer ended up costing me a day.
In the end, I told my colleague that he would have to take over the PR as I had lost too much time on it. Sure enough, he had to change all parameter names cause the types already describe them well enough:
`foo(Timeout connection_timeout)` -> `foo(Timeout connection)`.
The resulting code looks great, but now it is clear that I have a more pragmatic style. I recognize that I simply failed to stand my ground, and I'll take that into account.
Indeed, it might be time to move on. Or at least talk to the reviewer that bothers me.
Although I push for a lot of upfront agreement, most of the back and forth arises from little things, like a variable name being too long, a newline between struct members, or a docstring that could be removed because the code is expressive enough.
I'm usually okay with all of these suggestions. Still, lately, I'm fell in a position where usually the person who reviews my code is our architect (an amazingly talented engineer). He always flags all the minutiae (very politely, of course), and I find it very hard not to comply as I want to ship better stuff.
Funnily enough, a few days ago, I found myself reviewing a colleague's PR and repeating the same behavior. As soon as I saw myself doing it, I deleted these comments, made the suggestions that I judged valuable, and approved.
Thanks for the input! Just replying gave me a lot of clarity on the subject.
I also recommend removing all payment methods and forgetting about Amazon.
Just make sure to store any emails and support protocols that indicate that the account was recognized as hacked. This will be important if you ever have to deal with the debt in mediation/court.
I can only imagine this happening with external constraints such as parsing the output to perform a DB check, so I'm curious.