4 ms·

Is that really true, or is it just a well-sounding rationalisation we tell ourselves to avoid doing anything to make things better?

by Asooka 9y ago

wastedhours 9y ago
Granted, I specialise in well-sounding rationalisations ;) however, I do think it's true for some knowledge worker jobs that it's not just the direct knowledge we impart into a specific project, but the knowledge distributed within a company. I know that I've learnt things from meetings where it's evidently a burden/"waste of time" for the party I'm gaining from, and likewise, am fairly certain I've delivered value to others when it's been a waste for me. It might not be the best way of handling it, but some organisations are designed to work that way, and as much as we can try and mould where we work around us, sometimes it's just a different dynamic.
lostcolony 9y ago
It -can- be. I know I am woefully undertasked, and in way, way too many meetings. Oftentimes I'm thrown at things that are floundering despite having no knowledge of them, their history, their current deliverables, etc. Not to actually code, but to just be present. Even though I feel entirely useless in such a role, it seems to provide some comfort to my superiors, and even to the teams in question. There are enough areas I'm extremely knowledgeable in, there are enough times I -am- able to save people/teams large amounts of work, there are enough times I can basically just look at a set of stories that they're predicting will take man-weeks, and say "I'll have a solution in place for you to start playing with tomorrow", that my presence seems to benefit a number of people even when I do nothing at all, just as a security blanket. If that's worth my salary to them, while I still have time to learn things on my own (and, er, browse HN), fair enough.
- Jach 9y ago
  I hope you're an architect-level or at least getting there. I kind of feel sad for some architects though, they rarely get to code anymore, their existence is meetings, but presumably their ability to coordinate and prioritize the big picture outweighs having them apply their coding chops. For coders that can't give up coding it's a self-limiting move to resist that direction, lots of companies seem to have pressure that to advance you have to do 'less'. When you do your big prototype solutions is it usually something you toss over the fence to the team that now takes on the rest of the dev/qe responsibility or do you try to work closely with one or two people on that team as you build it? I mostly ask because another sort of altruistic (or selfish if you're just killing time until the next round of meetings) thing you can do with your role is go around dropping mana on heads-down coding grunts by working with them directly on something; they'll probably have a nice feeling of appreciation like this person, who they aren't quite sure does what but must be very valuable, is taking time to work with them, and hopefully you teach them a few useful things from your deep knowledge to boot.
  - lostcolony 9y ago
    Kind of. Due to some internal politics, we have an 'architecture team' being formed, by someone who I don't want to work for (but who wants to poach me). Meanwhile I've been the de facto architect for a year and a half for software development. My actual title is 'backend tech lead'. As to approach, it depends. Occasionally I've written and hosted a solution, and given endpoints for people to test with, before then walking people through the specifics and bringing devops on board to move it to production, and then will still actively take a hand in making changes/fixes/etc. Other times I've basically just POC'ed it, and then suggested to a team "Hey, this looks like it will solve a problem you're facing, here's some POC code, maybe play with and evaluate this approach, see if it'll fit your needs?" and they have, and in the process have learned more about the particulars than I knew, so that they're in a good place to do the real evaluation and decide what direction to head in. And still other times, especially common with juniors, when someone hits a roadblock, I'll sit with them, seek to understand the problem, and either explain the nature of the problem, and some possible solutions, and leave it up to them to pick one (since they have the most domain knowledge), or work/talk with them to work to and understand an ideal solution (if it doesn't require domain knowledge I don't have).

Is that really true, or is it just a well-sounding rationalisation we tell ourselves to avoid doing anything to make things better?

by Asooka 9y ago

Is that really true, or is it just a well-sounding rationalisation we tell ourselves to avoid doing anything to make things better?

wastedhours 9y ago

Granted, I specialise in well-sounding rationalisations ;) however, I do think it's true for some knowledge worker jobs that it's not just the direct knowledge we impart into a specific project, but the knowledge distributed within a company. I know that I've learnt things from meetings where it's evidently a burden/"waste of time" for the party I'm gaining from, and likewise, am fairly certain I've delivered value to others when it's been a waste for me. It might not be the best way of handling it, but some organisations are designed to work that way, and as much as we can try and mould where we work around us, sometimes it's just a different dynamic.

lostcolony 9y ago

It -can- be. I know I am woefully undertasked, and in way, way too many meetings. Oftentimes I'm thrown at things that are floundering despite having no knowledge of them, their history, their current deliverables, etc. Not to actually code, but to just be present. Even though I feel entirely useless in such a role, it seems to provide some comfort to my superiors, and even to the teams in question. There are enough areas I'm extremely knowledgeable in, there are enough times I -am- able to save people/teams large amounts of work, there are enough times I can basically just look at a set of stories that they're predicting will take man-weeks, and say "I'll have a solution in place for you to start playing with tomorrow", that my presence seems to benefit a number of people even when I do nothing at all, just as a security blanket. If that's worth my salary to them, while I still have time to learn things on my own (and, er, browse HN), fair enough.

Jach 9y ago
I hope you're an architect-level or at least getting there. I kind of feel sad for some architects though, they rarely get to code anymore, their existence is meetings, but presumably their ability to coordinate and prioritize the big picture outweighs having them apply their coding chops. For coders that can't give up coding it's a self-limiting move to resist that direction, lots of companies seem to have pressure that to advance you have to do 'less'. When you do your big prototype solutions is it usually something you toss over the fence to the team that now takes on the rest of the dev/qe responsibility or do you try to work closely with one or two people on that team as you build it? I mostly ask because another sort of altruistic (or selfish if you're just killing time until the next round of meetings) thing you can do with your role is go around dropping mana on heads-down coding grunts by working with them directly on something; they'll probably have a nice feeling of appreciation like this person, who they aren't quite sure does what but must be very valuable, is taking time to work with them, and hopefully you teach them a few useful things from your deep knowledge to boot.
- lostcolony 9y ago
  Kind of. Due to some internal politics, we have an 'architecture team' being formed, by someone who I don't want to work for (but who wants to poach me). Meanwhile I've been the de facto architect for a year and a half for software development. My actual title is 'backend tech lead'. As to approach, it depends. Occasionally I've written and hosted a solution, and given endpoints for people to test with, before then walking people through the specifics and bringing devops on board to move it to production, and then will still actively take a hand in making changes/fixes/etc. Other times I've basically just POC'ed it, and then suggested to a team "Hey, this looks like it will solve a problem you're facing, here's some POC code, maybe play with and evaluate this approach, see if it'll fit your needs?" and they have, and in the process have learned more about the particulars than I knew, so that they're in a good place to do the real evaluation and decide what direction to head in. And still other times, especially common with juniors, when someone hits a roadblock, I'll sit with them, seek to understand the problem, and either explain the nature of the problem, and some possible solutions, and leave it up to them to pick one (since they have the most domain knowledge), or work/talk with them to work to and understand an ideal solution (if it doesn't require domain knowledge I don't have).