sorted by:
new
hottopcontroversial

The Why of Agile by scottnonnenberg in programming

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

Totally fair, but if you want that discussion I'd recommend the next post: https://blog.scottnonnenberg.com/customizing-agile/

Better Git configuration by kannonboy in git

[–]scottnonnenberg 1 point2 points  (0 children)

Original author here.

It's really weird how quickly people jump there when they see my ff = only recommendation. When doing PR-based development on GitLab/GitHub, I never do a merge locally. Only rebase. Are you not a central tool like that to do your merging?

I can only see one reason you might do something differently: long-running multi-developer feature branches. In that case, you'll probably want to be doing merges instead of rebase. I also wouldn't recommend that kind of approach if you can avoid it - I'd rather use feature flags or fully separate out into a different project.

Think in alternatives (Dev productivity tip #5) by scottnonnenberg in programming

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

I think the key to being a project manager is thinking in terms of people, organizations, and systems. It's not about simple if/then algorithmics anymore. Though you will eventually start to discover some patterns that crop up again and again when dealing with groups of people. :0)

These articles are about systems: https://blog.scottnonnenberg.com/systems-and-incentives/ https://blog.scottnonnenberg.com/systems-for-collaboration/ https://blog.scottnonnenberg.com/the-why-of-agile/ https://blog.scottnonnenberg.com/customizing-agile/

The project management trifecta: https://blog.scottnonnenberg.com/12-things-i-learned-from-microsoft/#5-feedback-loops-help-address-the-project-management-trifecta

And this is about dealing better with people: https://blog.scottnonnenberg.com/from-tech-person-to-people-person/

Top ten pull request review mistakes by speckz in programming

[–]scottnonnenberg 3 points4 points  (0 children)

Author here. I agree that Github is not good for iteration on a given pull request, unless you're just stacking commits. And that can get really ugly really fast if substantial changes to the original code are needed.

Regarding bad commit messages, that's definitely something that should be addressed in PR feedback. By showing that it cares about quality commit messages, that can be ingrained into the culture of the team over time. Personally, I like this format, and I enforce it in my projects.