5 ms·

And what do you propose is the correct way of collecting these measurements?

by TheSoftwareGuy 9y ago

aswanson 9y ago
Results. Delivery of requested work products on schedule with quality.
- jnbiche 9y ago
  > Results. Delivery of requested work products on schedule with quality. Because we all know that software estimation is a solved problem. Particularly with non-technical managers.
  - Clubber 9y ago
    >Because we all know that software estimation is a solved problem. Particularly with non-technical managers. Oh wonderful. They don't do estimates at your company then? This was explained to me by one of my professors 20 years ago. There are two types of company mentalities: A: The high school mentality. You show up 8 to 5 but it doesn't really matter what gets done. B: The college mentality. You pass or fail based on how well you do on the test. Show up if you want, or don't. The way I see it, if your manager can't tell if you are productive, he or she has no business being a manager and they are the problem.
    - michaelt 9y ago
      Oh wonderful. They don't do estimates at your company then? You can do estimates without thinking they're accurate enough to let you detect high- and low-performing employees. Intern Ian's tasks are simple and well documented - so they always have good estimates. Veteran Victor is great at complex, poorly understood bugs - but he often takes longer than estimated to fix them, as often the cause is hard to find. It would be a foolish manager that would punish Victor for performing worse than Ian.
- ryan-allen 9y ago
  If you actually had solved this problem you'd be a trillionaire, alas.
- pstuart 9y ago
  LOC /s
  - sobani 9y ago
    You measure your output in lines per second?! It's clear you are more productive than me then.
    - Klover 9y ago
      /s is the way to say you're being sarcastic on Reddit. So they probably meant that lines of code measurements are popular, while they shouldn't be. It's difficult keeping up with the internet lingo. For what it's worth: * You can simply see on Slack if the person is set to Away. In that case they're busy, so don't bother asking them any questions in a traditional open office plan. * A better open office plan has a quiet room where people can collaborate in quiet. You can just send someone a message, asking them if you can ask them a question when they have time. You take your laptops with you into the quiet room. Then you keep the quiet in the office itself. * A good manager knows what people are up to, and how they do it. It's part of their job. They also talk to employees face to face, individually, so they have better understandings on matters. If your manager is not a good manager, then no fancy metrics will help. * Remote working is fine, and especially in the tech industry I find that there are more people willing to work remotely. I am fine with people wanting to work remotely, and everyone is abroad at times, or needs some time alone for deep focus. I do like to see everyone come together regularly, even just working together in quiet builds up a bond, and periodic informal tea & coffee on the work floor makes people a lot more open in approaching me and trying to test ideas together. I do understand that commutes can be problematic for people in certain areas, and that some people really like peace and quiet during work hours. During job interviews, people try to see if you are a good fit for where you are going to be working (I can't speak for everyone of course), but it never hurts to ask if you can meet the team before signing a contract, if for some strange reason you weren't introduced already.
      - sobani 9y ago
        at a risk of dropping below the HN value threshold: whoosh
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
Clubber 9y ago
I mean you know who is good in your team don't you? It doesn't have to be on a spreadsheet, qualitative results still count.
- notyourwork 9y ago
  I generally agree but without some set of metrics/principles to measure against it can become a contest of favorites easily.
  - Clubber 9y ago
    >it can become a contest of favorites easily. I'm afraid that is unavoidable. Any metric you track can and will be gamed before the first collection period.
notyourwork 9y ago
I think by defining a set of metrics and company principles that employees can measure themselves against. Furthermore, by taking into account peer evaluations which reflect on how valuable you are to your team. An example might help demonstrate my thoughts: Last year I worked on a new UI for customers and went through 7 failed experiments. Does this mean that I suck at my job or that our designer dreamed up a failed interface or the business never should have started this initiate? The designer designed what the business gave a green light to, I wrote the code to put this in front of customers. Are we all failures or is one of us a failure? My opinion (at least in this situation) is none of us failed. Why? Because the business justified the project based on a need customer's were showing from data they collected and evaluation of the market. The designer created something that after a handful of iterations was green lit for an engineer to build. I was measured in terms of how difficult iterations were. For example, did it take an entire re-write to go from experiment x to x+1 or did you as an engineer anticipate some possible future directions that project could go which made iterations more easy to integrate into existing code. Some of this is subjective, some is objective, but your peers (team, stakeholders, and adjacent teams) all have an ability to measure and provide feedback to you. Different jobs require different types of assessments but I focused directly on software engineering since I have best frame of reference.

And what do you propose is the correct way of collecting these measurements?

aswanson 9y ago

Results. Delivery of requested work products on schedule with quality.

jnbiche 9y ago
> Results. Delivery of requested work products on schedule with quality. Because we all know that software estimation is a solved problem. Particularly with non-technical managers.
- Clubber 9y ago
  >Because we all know that software estimation is a solved problem. Particularly with non-technical managers. Oh wonderful. They don't do estimates at your company then? This was explained to me by one of my professors 20 years ago. There are two types of company mentalities: A: The high school mentality. You show up 8 to 5 but it doesn't really matter what gets done. B: The college mentality. You pass or fail based on how well you do on the test. Show up if you want, or don't. The way I see it, if your manager can't tell if you are productive, he or she has no business being a manager and they are the problem.
  - michaelt 9y ago
    Oh wonderful. They don't do estimates at your company then? You can do estimates without thinking they're accurate enough to let you detect high- and low-performing employees. Intern Ian's tasks are simple and well documented - so they always have good estimates. Veteran Victor is great at complex, poorly understood bugs - but he often takes longer than estimated to fix them, as often the cause is hard to find. It would be a foolish manager that would punish Victor for performing worse than Ian.
ryan-allen 9y ago
If you actually had solved this problem you'd be a trillionaire, alas.
pstuart 9y ago
LOC /s
- sobani 9y ago
  You measure your output in lines per second?! It's clear you are more productive than me then.
  - Klover 9y ago
    /s is the way to say you're being sarcastic on Reddit. So they probably meant that lines of code measurements are popular, while they shouldn't be. It's difficult keeping up with the internet lingo. For what it's worth: * You can simply see on Slack if the person is set to Away. In that case they're busy, so don't bother asking them any questions in a traditional open office plan. * A better open office plan has a quiet room where people can collaborate in quiet. You can just send someone a message, asking them if you can ask them a question when they have time. You take your laptops with you into the quiet room. Then you keep the quiet in the office itself. * A good manager knows what people are up to, and how they do it. It's part of their job. They also talk to employees face to face, individually, so they have better understandings on matters. If your manager is not a good manager, then no fancy metrics will help. * Remote working is fine, and especially in the tech industry I find that there are more people willing to work remotely. I am fine with people wanting to work remotely, and everyone is abroad at times, or needs some time alone for deep focus. I do like to see everyone come together regularly, even just working together in quiet builds up a bond, and periodic informal tea & coffee on the work floor makes people a lot more open in approaching me and trying to test ideas together. I do understand that commutes can be problematic for people in certain areas, and that some people really like peace and quiet during work hours. During job interviews, people try to see if you are a good fit for where you are going to be working (I can't speak for everyone of course), but it never hurts to ask if you can meet the team before signing a contract, if for some strange reason you weren't introduced already.
    - sobani 9y ago
      at a risk of dropping below the HN value threshold: whoosh

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

Clubber 9y ago

I mean you know who is good in your team don't you? It doesn't have to be on a spreadsheet, qualitative results still count.

notyourwork 9y ago
I generally agree but without some set of metrics/principles to measure against it can become a contest of favorites easily.
- Clubber 9y ago
  >it can become a contest of favorites easily. I'm afraid that is unavoidable. Any metric you track can and will be gamed before the first collection period.

notyourwork 9y ago

I think by defining a set of metrics and company principles that employees can measure themselves against. Furthermore, by taking into account peer evaluations which reflect on how valuable you are to your team. An example might help demonstrate my thoughts: Last year I worked on a new UI for customers and went through 7 failed experiments. Does this mean that I suck at my job or that our designer dreamed up a failed interface or the business never should have started this initiate? The designer designed what the business gave a green light to, I wrote the code to put this in front of customers. Are we all failures or is one of us a failure? My opinion (at least in this situation) is none of us failed. Why? Because the business justified the project based on a need customer's were showing from data they collected and evaluation of the market. The designer created something that after a handful of iterations was green lit for an engineer to build. I was measured in terms of how difficult iterations were. For example, did it take an entire re-write to go from experiment x to x+1 or did you as an engineer anticipate some possible future directions that project could go which made iterations more easy to integrate into existing code. Some of this is subjective, some is objective, but your peers (team, stakeholders, and adjacent teams) all have an ability to measure and provide feedback to you. Different jobs require different types of assessments but I focused directly on software engineering since I have best frame of reference.