4 ms·

The main problem I see with this article is the author is totally focused on himself. If you are a solo developer this is fine, but if you are part of a team th

by ebbv 10y ago

The main problem I see with this article is the author is totally focused on himself. If you are a solo developer this is fine, but if you are part of a team then his attitude is detrimental. I work as part of a team and we all work remotely most of the time, but we work the same hours because working different hours would cause problems. It's hard to conduct a daily stand up if everyone's working weird hours. We have some flexibility for people but everybody has to be around for the 9:30 stand up. This helps with coordinating of larger projects and bringing up blockers which the PO or Scrum Master can remove. If some lone developer is working 3pm to 11pm then that person is not really coordinating with the rest of the team. Also I'd really hate to hear what this guy thinks of pair programming.

eip 10y ago
There are a lot of good code review tools. If you want to do pair programming then do it async using code reviews. Doing it sync is just wasting two peoples time.
- ebbv 10y ago
  Code reviews != pair programming. Code reviews are great, but it's not remotely the same.
ylhert 10y ago
I love the teams I work with, but that doesn't mean I want them to interrupt me all day long while I'm trying to do meaningful work. I think it's important to be flexible with work hours, but that goes both ways. My concern is with places where strict requirements are set up for hours, and places that are not willing to be more open minded about crossover work hours. As far as I am concerned, 4 hours of overlap per day amongst the team is sufficient. If more overlap than that seems necessary, it is probably a process problem. I love pair programming! However I cannot pair program in an open office plan with tons of noise/distractions.
- ebbv 10y ago
  Four hours of overlap CAN work but it depends on the overlap. For example, if the rest of the team is working more "normal hours", starting before 10am and you don't start until 3pm, that means they can't have the whole team can't have a stand up meeting until 3pm when you get on. End of the day stand up meetings CAN work, but the natural flow is to start the day with it so you can talk about what you WILL be working on today and what you DID work on yesterday, rather than what you think you'll be working on tomorrow. Also, it's hard to ensure the whole team has overlap if the times are too flexible. I have a teammate who starts at 7am, if we had another teammate who wanted to start at 4pm, they would never overlap.

by ebbv 10y ago

eip 10y ago

There are a lot of good code review tools. If you want to do pair programming then do it async using code reviews. Doing it sync is just wasting two peoples time.

ebbv 10y ago
Code reviews != pair programming. Code reviews are great, but it's not remotely the same.

ylhert 10y ago

I love the teams I work with, but that doesn't mean I want them to interrupt me all day long while I'm trying to do meaningful work. I think it's important to be flexible with work hours, but that goes both ways. My concern is with places where strict requirements are set up for hours, and places that are not willing to be more open minded about crossover work hours. As far as I am concerned, 4 hours of overlap per day amongst the team is sufficient. If more overlap than that seems necessary, it is probably a process problem. I love pair programming! However I cannot pair program in an open office plan with tons of noise/distractions.

ebbv 10y ago
Four hours of overlap CAN work but it depends on the overlap. For example, if the rest of the team is working more "normal hours", starting before 10am and you don't start until 3pm, that means they can't have the whole team can't have a stand up meeting until 3pm when you get on. End of the day stand up meetings CAN work, but the natural flow is to start the day with it so you can talk about what you WILL be working on today and what you DID work on yesterday, rather than what you think you'll be working on tomorrow. Also, it's hard to ensure the whole team has overlap if the times are too flexible. I have a teammate who starts at 7am, if we had another teammate who wanted to start at 4pm, they would never overlap.