4 ms·

I like how you describe focusing on your plot of land as a positive coping strategy. I had been doing it instinctively (or necessarily), but had thought of it

I like how you describe focusing on your plot of land as a positive coping strategy. I had been doing it instinctively (or necessarily), but had thought of it as some kind of failing. Your comment makes me feel better about it. The end goal of software I work on is to help airplanes land safely. But actually, I work on the software which presents the user interface that displays and sends configuration settings to a device on the ground that helps achieve that. So my day to day is figuring out whether two bytes in a serial buffer an ad hoc protocol are actually transposed, or if the comments are in 20 year old code are lying about which is which. Or trying to figure out whether a Win32 font setting command from two decades ago is still interpreted the same on Windows 10. The rabbit holes and yak shaving just go on and on. I have it in me to enjoy doing the work, but when I think about how many steps I am removed from the actual airplanes and I feel badly for filling my brain and my workday with trivia.

TeMPOraL 6y ago
Thanks for sharing your story! Yeah, I also initially felt this is some kind of failing (I'm usually the "big picture guy"), but ended up accepting this as a coping mechanism. It's not that I forget about the purpose completely - just learned to think about it more when planning and designing, where the wider perspective also affects the task in a meaningful way. When deep in the codebase, I try to put it aside, so that I don't get in a depressive session of thinking "why do I have to shovel this garbage back and forth to satisfy some low-level requirement, instead of, I don't know, talking to people who'll use this on-site and getting some real feedback from them?". Rationally, I know that shoving garbage is an important part of getting quality software that helps others do exciting things. Emotionally, I just wish I was in their shoes (probably just as much as they wish they were in mine). You seem a bit more positive than me when facing this reality, so I'm glad you have it in you to enjoy this. I almost have it, so I find ways to cope, and enjoy the opportunities to do something less mundane that come every now and then in such projects.
curryst 6y ago
> but had thought of it as some kind of failing. Your comment makes me feel better about it. I do it as well; I think organizationally it's a failure, but it is an effective personal coping mechanism. In other words, it's bad for the organization that their codebase isn't really a melting pot of different developers' ideas but instead, if you zoom in enough you notice that it's really a series of hundreds of small fiefdoms each with their own slightly different customs and semantics. This is what creates that software bureaucracy. For employees though, it works. It's about the only way that I really derive any sense of satisfaction from software engineering. When I can stand back and say yes, this package is mine, I made it and I will take care of it. With the melting pot packages it feels more ambivalent; some portion of the code is mine. Probably not the clever bits, they're probably bugfixes. So I don't have enough mindshare to get satisfaction from achievement, I don't have the satisfaction of at least solving one of the hard problems. No, those people have come and gone, and I'm left with the shale oil of satisfaction: fixing bugs, writing unit tests, and adding documentation. Like shale oil, the joy it brings is very close to the effort it takes to extract it. This isn't the "I accidentally hit an oil vein while digging a garden" joy of really getting to solve something. Some people derive a lot of joy from doing things that help others (like unit tests, bug fixes and documentation); I'm unfortunately not one of them. Sometimes I wonder if it isn't at least partially because it's so hard to feel the impact. I know HN hates the idea of gameification, but I wonder if it couldn't be applied to good effect here. If someone could make an integration with CI, and with major editors, we could scrape data regarding how many times your unit tests have caught bugs, and how many times your function/class documentation has been viewed. There could be a leaderboard for people that are into that. But for me, just the raw numbers is enough. "Unit tests you have written have exposed 137 bugs in PRs, and documentation you have written has been viewed 138,476 times" would be a huge motivator. It gives me that warm and fuzzy "I actually productively contributed" feeling. Right now I get nothing back; I have no idea if anyone has ever read the documentation I spent hours writing, or if my unit tests have caught any issues.
milesvp 6y ago
Oh man. I’ve dealt with so much legacy code I avoid reading comments as long as possible, they lie more than I’d like. Sadly something like bit fields are the one place I feel I have to trust the comments god help you if they’re no longer accurate.

TeMPOraL 6y ago

Thanks for sharing your story! Yeah, I also initially felt this is some kind of failing (I'm usually the "big picture guy"), but ended up accepting this as a coping mechanism. It's not that I forget about the purpose completely - just learned to think about it more when planning and designing, where the wider perspective also affects the task in a meaningful way. When deep in the codebase, I try to put it aside, so that I don't get in a depressive session of thinking "why do I have to shovel this garbage back and forth to satisfy some low-level requirement, instead of, I don't know, talking to people who'll use this on-site and getting some real feedback from them?". Rationally, I know that shoving garbage is an important part of getting quality software that helps others do exciting things. Emotionally, I just wish I was in their shoes (probably just as much as they wish they were in mine). You seem a bit more positive than me when facing this reality, so I'm glad you have it in you to enjoy this. I almost have it, so I find ways to cope, and enjoy the opportunities to do something less mundane that come every now and then in such projects.

curryst 6y ago

> but had thought of it as some kind of failing. Your comment makes me feel better about it. I do it as well; I think organizationally it's a failure, but it is an effective personal coping mechanism. In other words, it's bad for the organization that their codebase isn't really a melting pot of different developers' ideas but instead, if you zoom in enough you notice that it's really a series of hundreds of small fiefdoms each with their own slightly different customs and semantics. This is what creates that software bureaucracy. For employees though, it works. It's about the only way that I really derive any sense of satisfaction from software engineering. When I can stand back and say yes, this package is mine, I made it and I will take care of it. With the melting pot packages it feels more ambivalent; some portion of the code is mine. Probably not the clever bits, they're probably bugfixes. So I don't have enough mindshare to get satisfaction from achievement, I don't have the satisfaction of at least solving one of the hard problems. No, those people have come and gone, and I'm left with the shale oil of satisfaction: fixing bugs, writing unit tests, and adding documentation. Like shale oil, the joy it brings is very close to the effort it takes to extract it. This isn't the "I accidentally hit an oil vein while digging a garden" joy of really getting to solve something. Some people derive a lot of joy from doing things that help others (like unit tests, bug fixes and documentation); I'm unfortunately not one of them. Sometimes I wonder if it isn't at least partially because it's so hard to feel the impact. I know HN hates the idea of gameification, but I wonder if it couldn't be applied to good effect here. If someone could make an integration with CI, and with major editors, we could scrape data regarding how many times your unit tests have caught bugs, and how many times your function/class documentation has been viewed. There could be a leaderboard for people that are into that. But for me, just the raw numbers is enough. "Unit tests you have written have exposed 137 bugs in PRs, and documentation you have written has been viewed 138,476 times" would be a huge motivator. It gives me that warm and fuzzy "I actually productively contributed" feeling. Right now I get nothing back; I have no idea if anyone has ever read the documentation I spent hours writing, or if my unit tests have caught any issues.

milesvp 6y ago

Oh man. I’ve dealt with so much legacy code I avoid reading comments as long as possible, they lie more than I’d like. Sadly something like bit fields are the one place I feel I have to trust the comments god help you if they’re no longer accurate.