3 ms·

This is an interesting perspective, from a technical view it seems like the difference between writing library and debugging a system. Programming a library re

This is an interesting perspective, from a technical view it seems like the difference between writing library and debugging a system. Programming a library referencing an RFC seems kind, the rules are already there. Debugging a performance issue in a large distributed system is unkind, you need a lot of existing knowledge and ideas to know where to start.

mason55 6y ago
I don't know, I think debugging a perf issue in a large distributed system still falls under kind work to me, assuming you actually have a way to tell when it's fixed. Yes, you need a lot of knowledge, but the rules and outcomes are still clear. Compared to writing a novel or painting, it's very clear when you've reached success and it's hard to argue that you've been successful. IMO the "unkind" work that a typical engineer does is things like writing specs. The work itself does not give you any feedback about if you're making progress or doing a good job. Of course it's all on a sliding scale, and if your perf issue takes four weeks to surface after each deploy then that's a much less kind environment. But, in general, anything that you can put clear metrics around is much closer to the "kind" bucket to me because those metrics give you a clear path for improvement and iteration (the major risk is getting stuck in some local maximum).
- username90 6y ago
  > I don't know, I think debugging a perf issue in a large distributed system still falls under kind work to me, assuming you actually have a way to tell when it's fixed. Yes, you need a lot of knowledge, but the rules and outcomes are still clear. Compared to writing a novel or painting, it's very clear when you've reached success and it's hard to argue that you've been successful. The same goes for poker, you know when you won a hand. However winning a hand doesn't mean you learned something, similarly successfully debugging a large performance issue doesn't mean you learned something either. The learning we actually care about in software engineers isn't kind at all.
Balgair 6y ago
Epstein kinda treats things as a binary: un/kind. But I think there is a spectrum of 'environmental kindness'. Troubleshooting is a good case of this. If all you do is debug a single system, then you'll get really good at it, via practice. It starts out environmentally unkind, but ends up being environmentally kind via repeated use. While if you have to debug multiple systems and add in new systems, then you stay in an environmentally unkind situation. Being a mechanic on your own car is one thing, but working in a shop with new cars and problems coming in all the time is another.
webmaven 6y ago
> Programming a library referencing an RFC seems kind, the rules are already there. Depends. Is there a reference implementation? A format/protocol validator? An interoperability matrix? What's the ratio of SHOULDs and MAYs to REQUIREDs, SHALLs, and MUSTs? Does the RFC reference other RFCs? What are the answers to these questions regarding those? I mean, I wouldn't ever describe the task of implementing a SOAP[0] or WebDAV[1] library as 'kind'. Oh, and if you're working at a sufficiently large org, be prepared to battle it out with a competing internal implementation for the coveted position of 'company standard'. Note that you (or your boss) may not actually want to win that battle, as internal customers will make all sorts of unreasonable demands[2], and implementing them all will cut into your real work and negatively affect your evaluations and career advancement. Also, refusing to implement those requests will get you labelled as "not a team player" and negatively affect your evaluations and career advancement. Fun times! [0] https://www.shlomifish.org/humour/by-others/s-stands-for-simple/ https://www.shlomifish.org/humour/by-others/s-stands-for-sim... [1] https://www.slideshare.net/mobile/tobyS/webdav-the-good-the-bad-and-the-evil https://www.slideshare.net/mobile/tobyS/webdav-the-good-the-... [2] https://dilbert.com/strip/1995-11-17 https://dilbert.com/strip/1995-11-17

mason55 6y ago

I don't know, I think debugging a perf issue in a large distributed system still falls under kind work to me, assuming you actually have a way to tell when it's fixed. Yes, you need a lot of knowledge, but the rules and outcomes are still clear. Compared to writing a novel or painting, it's very clear when you've reached success and it's hard to argue that you've been successful. IMO the "unkind" work that a typical engineer does is things like writing specs. The work itself does not give you any feedback about if you're making progress or doing a good job. Of course it's all on a sliding scale, and if your perf issue takes four weeks to surface after each deploy then that's a much less kind environment. But, in general, anything that you can put clear metrics around is much closer to the "kind" bucket to me because those metrics give you a clear path for improvement and iteration (the major risk is getting stuck in some local maximum).

username90 6y ago
> I don't know, I think debugging a perf issue in a large distributed system still falls under kind work to me, assuming you actually have a way to tell when it's fixed. Yes, you need a lot of knowledge, but the rules and outcomes are still clear. Compared to writing a novel or painting, it's very clear when you've reached success and it's hard to argue that you've been successful. The same goes for poker, you know when you won a hand. However winning a hand doesn't mean you learned something, similarly successfully debugging a large performance issue doesn't mean you learned something either. The learning we actually care about in software engineers isn't kind at all.

Balgair 6y ago

Epstein kinda treats things as a binary: un/kind. But I think there is a spectrum of 'environmental kindness'. Troubleshooting is a good case of this. If all you do is debug a single system, then you'll get really good at it, via practice. It starts out environmentally unkind, but ends up being environmentally kind via repeated use. While if you have to debug multiple systems and add in new systems, then you stay in an environmentally unkind situation. Being a mechanic on your own car is one thing, but working in a shop with new cars and problems coming in all the time is another.

webmaven 6y ago

> Programming a library referencing an RFC seems kind, the rules are already there. Depends. Is there a reference implementation? A format/protocol validator? An interoperability matrix? What's the ratio of SHOULDs and MAYs to REQUIREDs, SHALLs, and MUSTs? Does the RFC reference other RFCs? What are the answers to these questions regarding those? I mean, I wouldn't ever describe the task of implementing a SOAP[0] or WebDAV[1] library as 'kind'. Oh, and if you're working at a sufficiently large org, be prepared to battle it out with a competing internal implementation for the coveted position of 'company standard'. Note that you (or your boss) may not actually want to win that battle, as internal customers will make all sorts of unreasonable demands[2], and implementing them all will cut into your real work and negatively affect your evaluations and career advancement. Also, refusing to implement those requests will get you labelled as "not a team player" and negatively affect your evaluations and career advancement. Fun times! [0] https://www.shlomifish.org/humour/by-others/s-stands-for-simple/ https://www.shlomifish.org/humour/by-others/s-stands-for-sim... [1] https://www.slideshare.net/mobile/tobyS/webdav-the-good-the-bad-and-the-evil https://www.slideshare.net/mobile/tobyS/webdav-the-good-the-... [2] https://dilbert.com/strip/1995-11-17 https://dilbert.com/strip/1995-11-17