3 ms·

> Talk About Your Work I strongly disagree with this one, although I'm not sure if my reasoning is broadly or only personally applicable. The last thing I want

> Talk About Your Work I strongly disagree with this one, although I'm not sure if my reasoning is broadly or only personally applicable. The last thing I want to do at the end of a long day of work is recap what I did. Even in the best-case scenario of a day full of victories, it's just exhausting to try to relive all of them with the added burden of explaining the decade-plus knowledge base you'd need to understand why Problem X was so hard to solve. I'm much happier with a base of other interests to talk about after work with a non-programmer instead.

khedoros 10y ago
I know that my wife appreciates hearing some about how my day went. I don't go into any really deep detail, but talking about how hard a problem was and how good it feel to solve it, or venting about something stupid that a coworker did are things I've come to enjoy. The technical details and why it was hard to solve aren't the parts that matter.
- jdminhbg 10y ago
  > I know that my wife appreciates hearing some about how my day went. I believe that. My girlfriend really pushes me occasionally about my day, and I think it's because she knows that talking about her day really helps her. I'm happy to listen for her, but I've just come to the conclusion that trying to recap things I've done makes me more stressed out, and the fifteen seconds of "no, I really don't want to talk about it" is worth it. And for what it's worth, having read back over that, I am not in a high-pressure job. I consult about thirty hours a week or so.
  - alvarosm 10y ago
    Well if you really must not talk about it because you're in a stressful situation... but it's not ideal.
  - douche 10y ago
    That's a classic male-female issue. Women, for whatever reason, are conditioned to need to talk about things to process them. Men are more likely to brood in silence instead. When I come home, I too would really rather not relive the last eight hours of fighting with broken hardware, broken tools, broken networks, and broken customers. Its time to put it out of mind, as best as can be done. I'd rather play with the dog, water the garden, and cook dinner.
  - VLM 10y ago
    "trying to recap things I've done makes me more stressed out" Its about the same in low pressure full time work. So to my annoyance at work my happy sea of happy freebsd has gained two unavoidable ubuntu, and ansible worked on them precisely once after initial install and then never again. Incredibly frustrating. Obviously must be a problem with our standard sshd config although ssh into the boxes works fine... Turns out ansible does NOT just use ssh, but speaks sftp which is a subtle difference in protocol and is handled completely differently inside openssh and I never use sftp other, apparently, than every time I ansible-playbook something (all scp here for generic file transfer) so I never noticed it. To make a long story short sftp is implemented in a loadable subsystem module located in /usr/libexec/sftp-server which is specified by FULL PATH in sshd_config on a unix-like OS but on Ubuntu its in /usr/lib/sftp-server. Thanks Ubuntu, wish you were a unix! Also if sshd tries to access its sftp loadable module and fails because of wrong path in sshd_config, there is no error logged to any file and running the client in verbose mode tells you nothing other than connection dropped, almost like a firewall dumped a RST packet on us. There is no way to indicate the problem, the only symptom even if you run the client -vvvv option is the connection just drops, nothing in syslog on the server side, nothing auth.log, nothing. Once the problem was found all I need to do is have ansible provide /etc/ssh/sshd_config with slightly different OS specific paths based on specific OS which is a good 30 seconds of work. So no small amount of my work time is pounding head on desk swearing and annoyed until I isolate the problem and then the fix takes about 10 seconds. Actually given that I'm pretty good at this stuff and highly experienced and I know the business problem domain very well and I know my toolset, the easy stuff is all automated or avoided or well known and all I do all day is pound head on table for hours until truly obscure problem is isolated, then implement fix in about a minute, repeat. Figuring out the correct solution is about 99% of my day and endless judgment calls takes a lot out of a brain. After that end of workday I had no interest in talking about SSH or ansible or any of that, in fact it took near 24 hours to cool off from that one and write this post, went home, ate an awesome homecooked meal, took whole family to hiking trail and tried to catch pokemon, generally hung out and had a good time and enjoyed the nice park and nice weather. My wife used to program PBXes and did something with ACD call routing on an old fashioned physical PBX (don't remember the language, its all obsolete now replaced by VOIP and doesn't matter) but even back when we had similar-ish jobs I think we both just need time to chill out away from work. If work is stress, I don't need constant stress or constant work, no interest in talking about work outside of work.
asadlionpk 10y ago
I understand your frustration but I disagree. You should try explaining your work to a non-programmer. It's a challenge to 'dumb it down' and you only succeed if you truly understand your work. Sometimes the non-programmer is successful in suggesting a very possible solution which turns out to be a fun conversation.
- fatman13gg 10y ago
  Like Feynman said in this video https://www.youtube.com/watch?v=wMFPe-DwULM https://www.youtube.com/watch?v=wMFPe-DwULM, when trying to explain how magnate works to the reporter. I think it's hard for someone else to actually understand the problem when you two are not in the same knowledge framework. Cause then she/he will be perpetually asking the why and how question and being not satisfied. edited.
  - asadlionpk 10y ago
    amazing video!
  - justinhj 10y ago
    Nevertheless Feynman made many successful lectures to the public and undergraduate students and was able to explain things as complex as quantum electrodynamics in layman terms. Recently I tried explaining how Akka clusters work and what partitions are to a completely non-technical colleague. Not only was I able to explain the parts I understand well in a way that she understood, I also quickly found out there are parts that I don't understand at all.
- ubertaco 10y ago
  Yeah, I find that when I take the "implementation details" out and explain the general problem, my fiancée both loves hearing about how my day went, and sometimes has good ideas how to solve it (and sometimes she doesn't, but the process of distilling the "essence" of the problem helps me to see the problem myself more clearly). By stripping out the technical details, I explained to someone who thinks that the monitor is the computer and the tower is the "CPU" what the Maybe monad is and why it's needed. That being said, I also find that some problems are strictly-technical in nature, and can't really be distilled to anything informative (e.g. Ionic's livereload dev server randomly serves up an old build rather than the most recent build due to weird interactions with gulp watch). In those cases, sometimes it's okay to just say something like "our tools were being frustrating." The goal, at least with my fiancée, is to make an effort to communicate with her how my day went, because on a deeper level what I'm communicating is that I want to share my life with her, and that we're a team. There's a lot of implicit emotional elements to human communication, and sometimes to communicate one thing implicitly, you have to work really hard to communicate something seemingly-unrelated explicitly.
alvarosm 10y ago
It's not about what you want it's about what others may like to hear from you. And if you're doing something all day long and you can't talk about it, what do you talk about? you'll be like a foreign object to others
- jdminhbg 10y ago
  > And if you're doing something all day long and you can't talk about it, what do you talk about? Music, sports, reality tv, literature, friends, etc. Basically anything else.
deleted 10y ago
[deleted]

khedoros 10y ago

I know that my wife appreciates hearing some about how my day went. I don't go into any really deep detail, but talking about how hard a problem was and how good it feel to solve it, or venting about something stupid that a coworker did are things I've come to enjoy. The technical details and why it was hard to solve aren't the parts that matter.

jdminhbg 10y ago
> I know that my wife appreciates hearing some about how my day went. I believe that. My girlfriend really pushes me occasionally about my day, and I think it's because she knows that talking about her day really helps her. I'm happy to listen for her, but I've just come to the conclusion that trying to recap things I've done makes me more stressed out, and the fifteen seconds of "no, I really don't want to talk about it" is worth it. And for what it's worth, having read back over that, I am not in a high-pressure job. I consult about thirty hours a week or so.
- alvarosm 10y ago
  Well if you really must not talk about it because you're in a stressful situation... but it's not ideal.
- douche 10y ago
  That's a classic male-female issue. Women, for whatever reason, are conditioned to need to talk about things to process them. Men are more likely to brood in silence instead. When I come home, I too would really rather not relive the last eight hours of fighting with broken hardware, broken tools, broken networks, and broken customers. Its time to put it out of mind, as best as can be done. I'd rather play with the dog, water the garden, and cook dinner.
- VLM 10y ago
  "trying to recap things I've done makes me more stressed out" Its about the same in low pressure full time work. So to my annoyance at work my happy sea of happy freebsd has gained two unavoidable ubuntu, and ansible worked on them precisely once after initial install and then never again. Incredibly frustrating. Obviously must be a problem with our standard sshd config although ssh into the boxes works fine... Turns out ansible does NOT just use ssh, but speaks sftp which is a subtle difference in protocol and is handled completely differently inside openssh and I never use sftp other, apparently, than every time I ansible-playbook something (all scp here for generic file transfer) so I never noticed it. To make a long story short sftp is implemented in a loadable subsystem module located in /usr/libexec/sftp-server which is specified by FULL PATH in sshd_config on a unix-like OS but on Ubuntu its in /usr/lib/sftp-server. Thanks Ubuntu, wish you were a unix! Also if sshd tries to access its sftp loadable module and fails because of wrong path in sshd_config, there is no error logged to any file and running the client in verbose mode tells you nothing other than connection dropped, almost like a firewall dumped a RST packet on us. There is no way to indicate the problem, the only symptom even if you run the client -vvvv option is the connection just drops, nothing in syslog on the server side, nothing auth.log, nothing. Once the problem was found all I need to do is have ansible provide /etc/ssh/sshd_config with slightly different OS specific paths based on specific OS which is a good 30 seconds of work. So no small amount of my work time is pounding head on desk swearing and annoyed until I isolate the problem and then the fix takes about 10 seconds. Actually given that I'm pretty good at this stuff and highly experienced and I know the business problem domain very well and I know my toolset, the easy stuff is all automated or avoided or well known and all I do all day is pound head on table for hours until truly obscure problem is isolated, then implement fix in about a minute, repeat. Figuring out the correct solution is about 99% of my day and endless judgment calls takes a lot out of a brain. After that end of workday I had no interest in talking about SSH or ansible or any of that, in fact it took near 24 hours to cool off from that one and write this post, went home, ate an awesome homecooked meal, took whole family to hiking trail and tried to catch pokemon, generally hung out and had a good time and enjoyed the nice park and nice weather. My wife used to program PBXes and did something with ACD call routing on an old fashioned physical PBX (don't remember the language, its all obsolete now replaced by VOIP and doesn't matter) but even back when we had similar-ish jobs I think we both just need time to chill out away from work. If work is stress, I don't need constant stress or constant work, no interest in talking about work outside of work.

asadlionpk 10y ago

I understand your frustration but I disagree. You should try explaining your work to a non-programmer. It's a challenge to 'dumb it down' and you only succeed if you truly understand your work. Sometimes the non-programmer is successful in suggesting a very possible solution which turns out to be a fun conversation.

fatman13gg 10y ago
Like Feynman said in this video https://www.youtube.com/watch?v=wMFPe-DwULM https://www.youtube.com/watch?v=wMFPe-DwULM, when trying to explain how magnate works to the reporter. I think it's hard for someone else to actually understand the problem when you two are not in the same knowledge framework. Cause then she/he will be perpetually asking the why and how question and being not satisfied. edited.
- asadlionpk 10y ago
  amazing video!
- justinhj 10y ago
  Nevertheless Feynman made many successful lectures to the public and undergraduate students and was able to explain things as complex as quantum electrodynamics in layman terms. Recently I tried explaining how Akka clusters work and what partitions are to a completely non-technical colleague. Not only was I able to explain the parts I understand well in a way that she understood, I also quickly found out there are parts that I don't understand at all.
ubertaco 10y ago
Yeah, I find that when I take the "implementation details" out and explain the general problem, my fiancée both loves hearing about how my day went, and sometimes has good ideas how to solve it (and sometimes she doesn't, but the process of distilling the "essence" of the problem helps me to see the problem myself more clearly). By stripping out the technical details, I explained to someone who thinks that the monitor is the computer and the tower is the "CPU" what the Maybe monad is and why it's needed. That being said, I also find that some problems are strictly-technical in nature, and can't really be distilled to anything informative (e.g. Ionic's livereload dev server randomly serves up an old build rather than the most recent build due to weird interactions with gulp watch). In those cases, sometimes it's okay to just say something like "our tools were being frustrating." The goal, at least with my fiancée, is to make an effort to communicate with her how my day went, because on a deeper level what I'm communicating is that I want to share my life with her, and that we're a team. There's a lot of implicit emotional elements to human communication, and sometimes to communicate one thing implicitly, you have to work really hard to communicate something seemingly-unrelated explicitly.

alvarosm 10y ago

It's not about what you want it's about what others may like to hear from you. And if you're doing something all day long and you can't talk about it, what do you talk about? you'll be like a foreign object to others

jdminhbg 10y ago
> And if you're doing something all day long and you can't talk about it, what do you talk about? Music, sports, reality tv, literature, friends, etc. Basically anything else.

deleted 10y ago

[deleted]