search

loadsmart / culture

How we work
Creative Commons Attribution 4.0 International
79 stars 10 forks source link

Principles & Practices Proposal #34

Closed q2santos closed 3 years ago

q2santos commented 3 years ago

Hi Gustavo, here's the skeleton of the principles and practices I brought from the Software Engineering as a Disclipine presentation. Intended as a starting point; not a comprehensive list.

barbosa commented 3 years ago

@thiagocaiubi true.

@q2santos Maybe we could delete coding.md and bring some of the things that are more specific to practices.md.

Thoughts?

q2santos commented 3 years ago

@thiagocaiubi true.

@q2santos Maybe we could delete coding.md and bring some of the things that are more specific to practices.md.

Thoughts?

That makes sense, @barbosa and @thiagocaiubi.

q2santos commented 3 years ago

@barbosa and @thiagocaiubi, I just made a commit that distributed the coding items into the Practices & Principles sections. Please let me know if I missed transferring any item.

Also made a few changes based on your other comments.

I have to say that one practice I personally do not like is pair programming :) I wonder if we should make it optional. (When I am coding, I like to take the time to think before I write the code. Sometimes, I take 2-3 minutes staring at the screen thinking about what I am going to write. When you are pair-programming, you can either focus on the code you are trying to write, or pay attention and really listen to the programming partner. I find it hard to switch between both modes when I am coding.)

q2santos commented 3 years ago

One question: are the multiple line breaks in a sentence intentional? Personally, I find it a little bit harder to read and the rendered version also shows them as a complete sentence anyway.

It is intentional, to make them easier to edit and diff. I couldn't figure out a way to optimize for both reading and editing. So, I've been reading the text on GitHub, and then editing and diff'ing on PyCharm. (PyCharm also has a preview window for reading.)

q2santos commented 3 years ago

Revised the Pull Request Accretions practice:

Each pull request should be an [accretion](http://wordnetweb.princeton.edu/perl/webwn?s=accretion).
It is a new layer on top of an existing foundation (previous PRs).
If the foundation needs to be changed,
consider having the refactoring as a separate PR from the new feature implementation.
barbosa commented 3 years ago

I have to say that one practice I personally do not like is pair programming :) I wonder if we should make it optional. (When I am coding, I like to take the time to think before I write the code. Sometimes, I take 2-3 minutes staring at the screen thinking about what I am going to write. When you are pair-programming, you can either focus on the code you are trying to write, or pay attention and really listen to the programming partner. I find it hard to switch between both modes when I am coding.)

@q2santos Agreed. We can make it optional. Not everyone feel comfortable doing pair programming. Desired but not required.

q2santos commented 3 years ago

I have to say that one practice I personally do not like is pair programming :) I wonder if we should make it optional. (When I am coding, I like to take the time to think before I write the code. Sometimes, I take 2-3 minutes staring at the screen thinking about what I am going to write. When you are pair-programming, you can either focus on the code you are trying to write, or pay attention and really listen to the programming partner. I find it hard to switch between both modes when I am coding.)

@q2santos Agreed. We can make it optional. Not everyone feel comfortable doing pair programming. Desired but not required.

@barbosa, rewrote the Pair Programming practice as follows:

Recommended being done frequently, but not required.
Pair-programming allows having feedback on your code sooner than code reviews.

@thiagocaiubi and @rcmachado, are you ok with merging this PR?