* Senior tradesman -> manager is not a natural transition;
* Senior tradesmen take business into account without needing to transition;
* Both technical and business understandings are attributed to management while business is subtracted from senior tradesmen. Hilarious.
I'm glad at one point in my life, I have the option to transition to this magical role where all of a sudden I will understand everything and even if the potential users of this potential idea might potentially touch the potential application.
I wish I could have written a clearer statement instead of this empty half-rant, but as it stands, I am but a senior engineer so am forced to come to grips with my own limitations. If only I would transition... and after, maybe I'll naturally transition to president of everything.
The other developers let me do it and, looking back, they obviously didn’t want to rain on my parade as a junior dev that was eager to help out and “improve” things, god bless them.
I think I actually prefer your type, at least they care about improving things, and they're going to make it theirs.
For context, I work predominantly with stats/DS problems, where errors may not actually cause obvious (or indeed any) warnings/errors.
And sometimes the harder it was to understand something, the more invested you become in it and the more you want to defend it.
The best commits have more red than green.
Imagine that you are developing a storage with an s3-compatible API for internal use. Maybe you should give up and install CEPH instead
Point being, yes, of course you can come up with 1000s of examples where it's good/bad to delete all code. The point of my comment wasn't "It's never good to remove all code for a project" but rather "If this change is good or not depends on variables from outside the Git repository".
- they know something about the context that I was unaware of or have an insight that I hadn't thought of and so I learn something and change my mind - they realise they've missed or misunderstood something, or were unaware of something which I can communicate to them, so they learn something and change their mind. Sometimes this can be as mundane as "this isn't idiomatic, we should prefer the community style.
It's almost always a learning experience for one of us, frequently both. I've learnt a lot over the years of reviewing other people's code.
In the cases where neither of these things happen it's because it's a question of personal taste, there's nothing wrong with the code, I just wouldn't have written it that way. In those cases I leave it alone.