mrmaloke

Agreed. His hacking day of the week is definitely Wednesday

I would disagree with your disagreement and instead argue that the UX is indeed horrible.

SAP is very inconsistent across different views. It's not about learning a different concept, but memorizing each little detail.

On some forms you need to press <enter> to get to the next one. Sometimes it's clicking a button. Another time it's <F3>.

You can become a pro in SAP UIs, of course. But it's tedious and your knowledge applies nowhere else.

> Feedback should almost always be based on data

I do agree with you here. What I wanted to express is that you should hold back on interpretation. If you talk about your own perceptions, it allows other interpretations to also be valid.

Thank you for the example on clogging the CI servers. Indeed, I would find it hard to turn this into positive reinforcement. Also I would agree that it's dishonest in not telling them. I guess I would try to highlight my own pains with their behavior like "I was blocked five times in deploying because of your failing tests. Please run your tests locally first.". I would always want to give them the opportunity to take my perspective and understand my reasoning.

> 1. Ask (“Can I give you some feedback?”) > 2. State the behavior (“When you X…”)

Yes, please do this when giving feedback

> 3. State the impact (“…the result is Y.”)

Your conversation partner might hear an immediate accusation out of this. Your statement will never be objective. Rather talk about yourself as in "... this is how I perceive your behavior".

> 4. Encourage effective future behavior (“Keep it up!” for positive feedback ...)

Yes, it's great to get positively reinforced.

> “Can you change that?” for negative feedback

If you do this to me after 5 seconds of conversation, I will shut off and not take any advice from you. This is bossy.

Tell your conversation partner what their behavior makes you feel like. Formulate a wish for the future. You're not entitled to "change" people. Tell them how you would like to be treated.

If you want to change people, then give them positive reinforcement. If you try to "change" others by negative feedback, they will likely do less of everything and try not to be caught doing anything because it might be the "wrong thing".

edit: formatting

That way you force a serialization standard upon everyone. I'd rather force a formatting standard upon everyone and get the benefit of readable code with any tool e.g. also code reviews in version control. There's hardly a way to read code "the way I like it" in a webapp.

I find these terms strange. I have to pay for the high resolution and SVG but still have to check for right violations. For a payment of 5$ (compare stock photo prices), I expect the right to use it

A friend of mine made a presentation on tips and tricks on bash (and more). I learned some really helpful shortcuts from it. http://joschi.github.io/shell-for-developers-presentation/#c...

The most valuable feature from rebase to me is, that the one who commits to a feature branch, also "merges" the branch to the current master. So right after you finish your work on a branch, you can rebase even before having it reviewed by another person. When it's good to go, the actual merge is fast-forward.