moonarchia
The Scientific Shitlord
- 29,367
- 57,043
IT/Software career thread: Invert binary trees for dollars.
- Thread starter Traak
- Start date
Noodleface
A Mod Real Quick
- 39,403
- 17,866
Have my EOY convo coming Monday. Expecting all good things from my boss but it made me question something in my head.
You guys that don't write much code anymore, how do you measure your productivity? I feel like quantifying what I do is impossible And it makes me wonder what others think of my output at work. Was going to raise the question to my boss in the EOY convo.
You guys that don't write much code anymore, how do you measure your productivity? I feel like quantifying what I do is impossible And it makes me wonder what others think of my output at work. Was going to raise the question to my boss in the EOY convo.
- 2
TJT
Mr. Poopybutthole
- 46,466
- 126,929
I write a fair amount of code still but a lot less than I did 5 years ago. Despite that, I still have tickets in my name which remain evidence of my productivity. I still own the features deployed and various projects. So yeah, its more subjective but if you don't even have tickets anymore like managers do its going to be more about selling what your team accomplished. Which remains evidenced in tickets and documentation.
- 2
- 3,080
- 5,019
I'd argue we still haven't figured that out, and probably never will. IBM had this metric with thousands of lines of (debugged) code:
It's obviously bullshit. Also, SCRUM story points are bullshit, too. There was also an idiot that measured productivity with ... VCS checkins. Of course every programmer in the building started to game the system, by checking in code with typos, and then fixing typos one by one in individual commits.
Tickets are also an iffy thing, because from "fix this typo" to "re-architect the entire application and database so we can extend it for this feature that a single user wanted" everything can be inbetween.
- 1
Noodleface
A Mod Real Quick
- 39,403
- 17,866
I have tons of tickets in my name but my management does not give a shit about that. I mean, my manager has told me how great I'm doing so I'm not worried... Just kind of a rhetorical question.
Most of the code I write now is fixing things with long debug sessions resulting in a single line change. Most of my time is spent designing, architecting, and leading a smaller team but I am still an IC.
Doesn't matter too much, I just care what my boss thinks.
On the lines of code thing Raytheon was the same. Their measurement was SLOC, source lines of code, or something. I always felt that was prioritizing the wrong things but that's a dinosaur defense company so par for the course.
Most of the code I write now is fixing things with long debug sessions resulting in a single line change. Most of my time is spent designing, architecting, and leading a smaller team but I am still an IC.
Doesn't matter too much, I just care what my boss thinks.
On the lines of code thing Raytheon was the same. Their measurement was SLOC, source lines of code, or something. I always felt that was prioritizing the wrong things but that's a dinosaur defense company so par for the course.
moonarchia
The Scientific Shitlord
- 29,367
- 57,043
As long as you have your accolades in writing you are good to go. Remember, you are the one keeping your thing going, right? And it is important to the business? And you are the only one who actually knows that thing?
- 17,630
- 8,650
Where/when do you guys decide it's time to cut and run on a feature? As in, it's not done right, but it works and you definitely don't have time to do it right.
I hacked together some ugly after_script so that our pipelines would be less gay. This was unprompted, no planning, and well received, including my boss. Then he sees how I did it, and now it's "gross" and I should have spent the extra tens of hours refactoring to do it right.
I'm not going to disagree that inserting [[ATTACHMENT]] links into xml with sed is...gross. But I feel like the context of serious refactoring and how far behind we are is being ignored. Was this my mistake for not getting the work properly planned? I'm at the point where almost nothing I do gets properly planned. Loose concepts get assigned even looser story points and I usually just git er dun. I would like better planning, but we're a small enough company where the many hats thing really interferes.
I hacked together some ugly after_script so that our pipelines would be less gay. This was unprompted, no planning, and well received, including my boss. Then he sees how I did it, and now it's "gross" and I should have spent the extra tens of hours refactoring to do it right.
I'm not going to disagree that inserting [[ATTACHMENT]] links into xml with sed is...gross. But I feel like the context of serious refactoring and how far behind we are is being ignored. Was this my mistake for not getting the work properly planned? I'm at the point where almost nothing I do gets properly planned. Loose concepts get assigned even looser story points and I usually just git er dun. I would like better planning, but we're a small enough company where the many hats thing really interferes.
Noodleface
A Mod Real Quick
- 39,403
- 17,866
This sounds like something that unfortunately agile solves. There shouldn't be unprompted duct tape projects, it should all be planned.
That said... We do it all the time.
Control
Golden Baronet of the Realm
- 5,466
- 15,553
Contrary to popular sentiment, there are tons of things that are worth doing but that absolutely aren't worth doing right. If it's worth doing right, then great, you made a quick proof of concept, and now doing it right can be properly scheduled. If it's not worth properly scheduling, then I guess your boss gets to pick if it's "worth doing wrong" or "not worth doing". Of course, that assumes things are being run sanely, and that's probably not the case. Once someone sees something working, loss aversion kicks in at the thought of it not working anymore. It's not only a boss problem though. Devs can sink a project/company trying to do things right that just don't justify the time commitment. Some devs also love to add things that seem good/useful initially but without considering the future maintenance nightmare that they're creating (sometimes counting on the "they'll love it once they've seen it" thing to get support for their pet project).
That doesn't answer your question of course, but if no one launched products without spit and duct tape holding some things together, we wouldn't have very many products.
Grain of salt and all since I'm really bad at this too, but just consider how your boss justifies his own effectiveness to his boss. You may not technically be a manager, but performance-wise, you should probably think of yourself as one. The work you do (or don't do) is basically a buff/debuff on other teams, right? So it makes sense that you get credit for a portion (maybe most) of their results. What would the outcome look like if you hadn't designed the system that others implemented? or if you hadn't fixed that one-line bug? Think of it in terms of organizational impact, and try to frame it in a story that your boss can tell to his boss to make himself look good. If you bailed tomorrow, how fucked would your boss be? or maybe slightly less theoretically, what would things look like now if you had bailed the day after your last performance review? That's your lift. You just have to be able to illustrate that lift in a constructive way.
alavaz
Trakanon Raider
- 2,017
- 723
For the past 5 or so years I've kept a running log of things I do in Task/Action/Result format. Even for meetings I use that format so that my impact (or lack there of) on attending can be quantified. Then I can copy/past these notes into all the Jiras, SharePoints, emails, and other BS I have to report frequently.
Luckily for me as an integrator, I'm never unable to quantify work since completing said integration stands on it's own merit. I am also pretty fortunate to be in an environment where I can constantly test and refactor based on the feedback from the end users.
Prioritization is always a problem though. Sometimes I get told what my priorities are, other times I just have to go with my gut. This is where working at the same location for 9 years now really helps since I have a lot of background and context from just being around to draw on.
Luckily for me as an integrator, I'm never unable to quantify work since completing said integration stands on it's own merit. I am also pretty fortunate to be in an environment where I can constantly test and refactor based on the feedback from the end users.
Prioritization is always a problem though. Sometimes I get told what my priorities are, other times I just have to go with my gut. This is where working at the same location for 9 years now really helps since I have a lot of background and context from just being around to draw on.