28 ms·
Be careful what you measure, because you will get more of it. I don't think # of seconds editing a file is a good proxy for measuring bug free and understandabl
by ballenf 9y ago
Be careful what you measure, because you will get more of it. I don't think # of seconds editing a file is a good proxy for measuring bug free and understandable code. But if you want more # of seconds with files open and being edit, this is your tool it seems.
Am I missing something about this product in that it measures anything related to code quality?
If a company relies heavily this tool to measure its devs productivity, that would be a red flag about what developer attributes the company rewards. I guess it could be combined with other measures, but the leaderboard and gamification will incentivize behavior not closely tied to getting things done, in my opinion.
And, yes, the success is inspiring and despite my negativity I'd be curious to hear how the tool has been used to improve a team's productivity. I spent some time on the product's web page, but it doesn't really address how time spent in a file relates to productivity.
- startupdiscuss 9y agounless you reward people for spending less time in your files? Or time spent vs feature complexity? Or maybe it just shows you what is actually done. "Oh, we spend all out time in the file on data import - let's revisit the architecture"
- chrisan 9y ago> Am I missing something about this product in that it measures anything related to code quality? I think it is just a tool to be used as you desire. It can certainly be misused, like any tool or method, and promote bad results. If you have someone wanting to measure you by time alone you have bigger problems with that decision maker than just this specific tool being put in place. I was in a fitbit group challenge where one guy found himself in the hospital after going to extreme measures to "win". Yet, I don't feel fitbit is a bad entity. Used correctly it promotes good habits.
- muzani 9y agoI use it to test out other productivity habits - sleep, exercise, meditation, nootropics, etc. Yes, it's possible to have some false flags, like working on an easy project will produce a lot more hours. But if you cater for such things it's a great tool. Like LOC, it should not be your sole metric, just things that you track along with everything else.
- rubidium 9y agoMy read is that this isn't a productivity tool at all. It's a way to capture who to bill for your work (Billable vs. overhead time). "generate and send PDF invoices pre-filled with your coding activity." is in the future roadmap. And the pain of keeping track of billable hours is what drove him to write it to start with. Keeping track by program used is a nice-to-have, because then someone on the team could notice "hey we spend a lot more time with tool X then makes sense, maybe there's a way to improve that?"
- ballenf 9y agoFeel kind of silly for missing that use case. Could be especially helpful on consulting based teams, for sure. I'm rather consoled by these responses that the expectations for the tool are lower than what I expected. It does one simple thing very well it seems. Some need that data, some don't, but no one here is purporting it to equate with code quality or productivity.
- Domenic_S 9y ago> "generate and send PDF invoices pre-filled with your coding activity." is in the future roadmap. I love the guy's success but man do I hate this idea. I'm billing for more than time in vim. If you're my client and I'm answering an email from you, I'm billing you for that. If we're on the phone, the clock is running. If we're on a Hangout, you're paying. Could you imagine if your employer only paid you for time spent in an editor?
- welder 9y agoThis is solved with good UI, where you see the time you were coding as a starting point then add any non coding time before sending the invoice.
- curun1r 9y agoI don't think it's about quality or productivity, I think it's about predictability. Most teams have an estimation process where features are sized so that they can arrive at a product plan. Most teams also don't have a good way to loop back and see whether their sizing was correct or not. I've seen a number of teams that have a field in Jira for the number of hours/days spent on an issue. It's mostly filled out by developers guestimating based on their unreliable memory how long they spent working on it and they frequently forgot to fill it in at all. This product seems targeted at that. It's automatic feedback on sizing/estimates and it's how teams get more accurate in their future assessments and how businesses get more predictable product plans that they can rely on to make business decisions. Productivity of a development team is almost a secondary concern to predictability. Delivering on-time, whenever that time is predicted to be, might be more important than delivering quickly since the business doesn't have to wait until product is done to start selling, promoting, partnering, etc.