6 ms·

>You should make sure all the offices have glass walls so you can see if someone is in their office and have an idea what they are doing. this is silly. a pers

by ice109 9y ago

>You should make sure all the offices have glass walls so you can see if someone is in their office and have an idea what they are doing. this is silly. a person should have the freedom to relax every so often throughout the day - we're not soldiers standing watch. >But mainly you should review all code as it's checked in for quality, and it should also give you a good idea of their productivity. this is the correct answer

ErrantX 9y ago
The latter also sounds horrifying; who has time to check all their teams commits? And what sort of motivation (or not!) does that drive into a team :/
- valuearb 9y ago
  It's horrifying to me that you don't check all of your team's commits. How do they and you improve as developers if you don't discuss how they and you implement things? Most of software development is spent finding and fixing bugs. Doing a little work up front in validating that code is written well and correctly saves a lot of work on the back end.
  - toast0 9y ago
    In my team, people have responsibility for their code. If they're not sure about something they can ask. If they think it's fine, they can commit and deploy without waiting for a review. If it blows up, they have to fix it, too. For new people to the team, there's usually some amount of frequent code review to start, but once you have shown you know what you're doing, you can just do it. Knowing if something is likely to cause problems is an important skill, and experience with making bad pushes is probably the best way to learn what is risky and what isn't. (You can and should also learn from other's bad pushes too) I'm a big believer in making it easy to push, because if it's easy to push, it's easy to push fixes, and you don't have to spend a lot of time with prerelease testing. Clearly you can't push a major change to storage libraries on Friday afternoon, but if you can't trust your engineers to make good decisions, you have the wrong engineers.
    - valuearb 9y ago
      I think a significant benefit of my job is that I get to spend part of every day discussing why I or a coworker wrote some code in a specific way. This means I and them are regularly learning and communicating new ways to do things, and improving as engineers. It's also an important part of our QA process. We test our own code, then we test each others code, then we code review each others code. That adds an important layer of quality that we need. In my job, once an app is on the store it's too late, hundreds of thousands of people are going to be using it in the next 24 hours and you can't stop them or push a fix without at least a 24 hour delay in app review.
      - toast0 9y ago
        > In my job, once an app is on the store it's too late, hundreds of thousands of people are going to be using it in the next 24 hours and you can't stop them or push a fix without at least a 24 hour delay in app review. Yes, that's absolutely true -- I'm coming from the server side (mostly). On the client side, there are barriers to pushing that can't feasibly be removed -- in that case, it makes a lot more sense to hunker down and make sure every build is good; some users only rarely update for whatever reason, and you don't want them to be running a bad build for months (or to abandon your product because their first download was a bad build).
    - swift 9y ago
      Not all contributors to a project know all aspects of that project equally well. People also come from a variety of different backgrounds that lends them different insights into the code. Beyond that, it's easy for even experts to make mistakes that they don't recognize in their own work - we've all had the experience of coming back to a piece of writing after a day or two and noticing errors and typos that we couldn't see during the writing process. Waiting for code review is frustrating sometimes (and for that reason, it's important to have a culture of prioritizing code review) but it really helps produce higher quality code, which is a major time-saver in the long run. It also has the side effect of keeping other team members informed about what you're doing, which is important for the overall effectiveness of the team. I agree with you, though, that knowing if things are likely to cause problems is an important skill. If you asked me to give you some examples, not requiring code review would be at the very top of the list. =)
  - ErrantX 9y ago
    Does that require checking all commits though? That sounds like micro-management which is a massive morale killer. Also; the team should self-organise on quality and help each other improve. I set the quality expectation and get enough data to understand their progress against that expectation (FWIW: I've always found a teams expectations sit higher than mine - which is as it should be to help motivation).
    - patmcc 9y ago
      >>>That sounds like micro-management which is a massive morale killer. I could see that if all commits go through your boss or something, but lots of places do peer-based code review. So have another developer check on your stuff and you check on theirs (or round robin it, or two on one, or whatever). This helps in a lot of ways - maybe they'll catch something wrong, maybe it'll trigger a good idea in them, maybe they'll just be more familiar with a part of the code they hadn't seen much of before. And it honestly doesn't take that long; code that can be written in an hour can usually be checked in five or ten minutes.
      - ErrantX 9y ago
        Yes I suspect that's the misunderstanding; I was approaching this from a "boss" perspective, not a peer one. Peer-based reviews are critical.
valuearb 9y ago
Ideally as a manager you should trust your employees. But I also know when I was self employed it was really hard to get started every day relying entirely on myself, too easy to get distracted surfing the web or working on some side project. When I'm in an office working with others I have zero problems getting started or working on the right stuff, and never surf the web. So the question naturally occurs to me. If being visible to others helps make me more productive, would it help others. It's not a question of a manager watching them, but giving them the best environment to work in.

by ice109 9y ago

ErrantX 9y ago

The latter also sounds horrifying; who has time to check all their teams commits? And what sort of motivation (or not!) does that drive into a team :/

valuearb 9y ago
It's horrifying to me that you don't check all of your team's commits. How do they and you improve as developers if you don't discuss how they and you implement things? Most of software development is spent finding and fixing bugs. Doing a little work up front in validating that code is written well and correctly saves a lot of work on the back end.
- toast0 9y ago
  In my team, people have responsibility for their code. If they're not sure about something they can ask. If they think it's fine, they can commit and deploy without waiting for a review. If it blows up, they have to fix it, too. For new people to the team, there's usually some amount of frequent code review to start, but once you have shown you know what you're doing, you can just do it. Knowing if something is likely to cause problems is an important skill, and experience with making bad pushes is probably the best way to learn what is risky and what isn't. (You can and should also learn from other's bad pushes too) I'm a big believer in making it easy to push, because if it's easy to push, it's easy to push fixes, and you don't have to spend a lot of time with prerelease testing. Clearly you can't push a major change to storage libraries on Friday afternoon, but if you can't trust your engineers to make good decisions, you have the wrong engineers.
  - valuearb 9y ago
    I think a significant benefit of my job is that I get to spend part of every day discussing why I or a coworker wrote some code in a specific way. This means I and them are regularly learning and communicating new ways to do things, and improving as engineers. It's also an important part of our QA process. We test our own code, then we test each others code, then we code review each others code. That adds an important layer of quality that we need. In my job, once an app is on the store it's too late, hundreds of thousands of people are going to be using it in the next 24 hours and you can't stop them or push a fix without at least a 24 hour delay in app review.
    - toast0 9y ago
      > In my job, once an app is on the store it's too late, hundreds of thousands of people are going to be using it in the next 24 hours and you can't stop them or push a fix without at least a 24 hour delay in app review. Yes, that's absolutely true -- I'm coming from the server side (mostly). On the client side, there are barriers to pushing that can't feasibly be removed -- in that case, it makes a lot more sense to hunker down and make sure every build is good; some users only rarely update for whatever reason, and you don't want them to be running a bad build for months (or to abandon your product because their first download was a bad build).
  - swift 9y ago
    Not all contributors to a project know all aspects of that project equally well. People also come from a variety of different backgrounds that lends them different insights into the code. Beyond that, it's easy for even experts to make mistakes that they don't recognize in their own work - we've all had the experience of coming back to a piece of writing after a day or two and noticing errors and typos that we couldn't see during the writing process. Waiting for code review is frustrating sometimes (and for that reason, it's important to have a culture of prioritizing code review) but it really helps produce higher quality code, which is a major time-saver in the long run. It also has the side effect of keeping other team members informed about what you're doing, which is important for the overall effectiveness of the team. I agree with you, though, that knowing if things are likely to cause problems is an important skill. If you asked me to give you some examples, not requiring code review would be at the very top of the list. =)
- ErrantX 9y ago
  Does that require checking all commits though? That sounds like micro-management which is a massive morale killer. Also; the team should self-organise on quality and help each other improve. I set the quality expectation and get enough data to understand their progress against that expectation (FWIW: I've always found a teams expectations sit higher than mine - which is as it should be to help motivation).
  - patmcc 9y ago
    >>>That sounds like micro-management which is a massive morale killer. I could see that if all commits go through your boss or something, but lots of places do peer-based code review. So have another developer check on your stuff and you check on theirs (or round robin it, or two on one, or whatever). This helps in a lot of ways - maybe they'll catch something wrong, maybe it'll trigger a good idea in them, maybe they'll just be more familiar with a part of the code they hadn't seen much of before. And it honestly doesn't take that long; code that can be written in an hour can usually be checked in five or ten minutes.
    - ErrantX 9y ago
      Yes I suspect that's the misunderstanding; I was approaching this from a "boss" perspective, not a peer one. Peer-based reviews are critical.

valuearb 9y ago

Ideally as a manager you should trust your employees. But I also know when I was self employed it was really hard to get started every day relying entirely on myself, too easy to get distracted surfing the web or working on some side project. When I'm in an office working with others I have zero problems getting started or working on the right stuff, and never surf the web. So the question naturally occurs to me. If being visible to others helps make me more productive, would it help others. It's not a question of a manager watching them, but giving them the best environment to work in.