3 ms·

> Not Being Attached to Outcomes This is something I wish could be taught at Universities instead of having the opposite reinforced every step of the way. It h

> Not Being Attached to Outcomes This is something I wish could be taught at Universities instead of having the opposite reinforced every step of the way. It has by far been the hardest thing for me to deal with. University taught me that the only thing that actually mattered at the end of the day was succeeding and that it was better to work yourself to death, just barely "make it work", maybe even try to pass it off as not being made of tech debt, and then just submit/push and never look back. Prior to university I would have never considered doing this but after repeatedly being put up against the choice of either "requesting more time to do it right and potentially failing the assignment/project" or "jerryrigging a barely functional piece of code/hardware", my first instinct when faced with an unattainable deadline on the horizon became to drop all attempts at seeking accommodation or assistance, go into crunch mode, and desperately slap together a last ditch effort to put it all together. This understandably got me into hot water at work quite a number of times in the past. I still haven't entirely gotten over this bad habit/coping mechanism/whatever you want to call this awful behaviour but even now when I come up against a challenge with a time limit, my mind immediately shifts to "flee from admitting your incompetence and try to do it all yourself regardless of whether it's feasible". I've gotten better at noticing it and snapping myself out of it but it's an incredibly unpleasant mindset to get put into every time something takes slightly longer than expected.

nonrandomstring 4y ago
I sometimes teach Research Methods. One lesson, I explain scientific method, honest empiricism, falliblism, and how most experiments don't have the expected "successful" outcome. I explain that you can still get an A+ grade from a completely failed experiment if the results are analysed properly. I see rows of blinking, uncomprehending eyes and looks of confusion. How can you fail, and yet succeed? It takes months to beat the "perfomative ego" out of them, and even then some would still rather fudge their results to feign "success" than report what feels like failure. Market economics and a culture of "success uber alles" have done so much to damage science in deep and subtle ways.
- lucasfcosta 4y ago
  Totally agree. It’s this same mentality that cause companies not to understand the true concept of agile development. Failing successfully and learning with these failures is better than creating artificial success. It’s this fear of hearing “no” or seeing their hypothesis is false that causes most of the waste in product development.
csydas 4y ago
I'm not sure it's exclusive to Universities -- consider that the majority of jobs that don't require higher education typically have a very direct focus on "success" and this is the metric used for performance, I think it's just generally pervasive in business to want to see a specific desired outcome. "Line goes up" is a meme, but this is what runs a lot of businesses. I left University with a research mindset, which was further developed by living with a bunch of people in deep sciences who thought very research-like about everything in life (to a fault I'd say), but the end result was I ended up becoming a lot more analytical whereas I had entered University very outcome oriented. As I transitioned more and more into technical items, I understood how this approach was so much more useful. My classes in University were not technical but more research oriented, and while there were deadlines, there was not a specific outcome sought, just present a position, research it, and defend it. I believe this has done pretty well for me. It becomes a lot easier to solve issues (technical or otherwise) by understanding the full business rules of a situation and not being attached to specific outcomes but instead just implementing what makes sense. When I still did support and research, it became a lot easier to understand very challenging issues and getting time to research more by simply explaining how I understood the issue so far, what I had researched, why I thought this was relevant, and my next steps. The hardest clients weren't ones with very difficult and complex issues but instead the outcomes oriented ones that needed a solution X by Y date, Y being arbitrarily picked. The answer given in most cases was not to these clients' satisfaction ("we can make "something" by Y, but understand it will be a kludge. Or we can find the real answer, and I can't tell you when that happens since we don't know what the answer is yet."), but typically there is _someone_ at the client org higher up that understands the options and wants the real answer and stamps out any idea of arbitrary deadlines and instead accepted reasonable and proper updates on the investigation. It's not always the case as sometimes Outcome Orientated is just an institutional pillar for a company, but often it worked. My favorite part of actual research is realizing in situations when Z is not working, do you really need Z at all? I've solved more coding issues by simply not trying to shoehorn in Z or battling with Z's nuances than I have by writing novels of code to work with Z. The owners for Z typically get grumpy about the situation, but it's understandable they have an investment in their item, so they tend to be defensive.
ozim 4y ago
One cannot be detached from outcomes if their life depends on it. If someone is actually incompetent next blunder can cost them job. From my point of view post author seems incompetent in debugging - he is not just slow. Points he listed as "tricks" are just basic things to do while debugging. Depending on the situation you might just read stack trace from exception check code lines and you know right away what is the problem. My main point being: *you can, not be attached to outcomes, only if you really are competent* Not being attached to outcomes does not make you competent.

nonrandomstring 4y ago

I sometimes teach Research Methods. One lesson, I explain scientific method, honest empiricism, falliblism, and how most experiments don't have the expected "successful" outcome. I explain that you can still get an A+ grade from a completely failed experiment if the results are analysed properly. I see rows of blinking, uncomprehending eyes and looks of confusion. How can you fail, and yet succeed? It takes months to beat the "perfomative ego" out of them, and even then some would still rather fudge their results to feign "success" than report what feels like failure. Market economics and a culture of "success uber alles" have done so much to damage science in deep and subtle ways.

lucasfcosta 4y ago
Totally agree. It’s this same mentality that cause companies not to understand the true concept of agile development. Failing successfully and learning with these failures is better than creating artificial success. It’s this fear of hearing “no” or seeing their hypothesis is false that causes most of the waste in product development.

csydas 4y ago

I'm not sure it's exclusive to Universities -- consider that the majority of jobs that don't require higher education typically have a very direct focus on "success" and this is the metric used for performance, I think it's just generally pervasive in business to want to see a specific desired outcome. "Line goes up" is a meme, but this is what runs a lot of businesses. I left University with a research mindset, which was further developed by living with a bunch of people in deep sciences who thought very research-like about everything in life (to a fault I'd say), but the end result was I ended up becoming a lot more analytical whereas I had entered University very outcome oriented. As I transitioned more and more into technical items, I understood how this approach was so much more useful. My classes in University were not technical but more research oriented, and while there were deadlines, there was not a specific outcome sought, just present a position, research it, and defend it. I believe this has done pretty well for me. It becomes a lot easier to solve issues (technical or otherwise) by understanding the full business rules of a situation and not being attached to specific outcomes but instead just implementing what makes sense. When I still did support and research, it became a lot easier to understand very challenging issues and getting time to research more by simply explaining how I understood the issue so far, what I had researched, why I thought this was relevant, and my next steps. The hardest clients weren't ones with very difficult and complex issues but instead the outcomes oriented ones that needed a solution X by Y date, Y being arbitrarily picked. The answer given in most cases was not to these clients' satisfaction ("we can make "something" by Y, but understand it will be a kludge. Or we can find the real answer, and I can't tell you when that happens since we don't know what the answer is yet."), but typically there is _someone_ at the client org higher up that understands the options and wants the real answer and stamps out any idea of arbitrary deadlines and instead accepted reasonable and proper updates on the investigation. It's not always the case as sometimes Outcome Orientated is just an institutional pillar for a company, but often it worked. My favorite part of actual research is realizing in situations when Z is not working, do you really need Z at all? I've solved more coding issues by simply not trying to shoehorn in Z or battling with Z's nuances than I have by writing novels of code to work with Z. The owners for Z typically get grumpy about the situation, but it's understandable they have an investment in their item, so they tend to be defensive.

ozim 4y ago

One cannot be detached from outcomes if their life depends on it. If someone is actually incompetent next blunder can cost them job. From my point of view post author seems incompetent in debugging - he is not just slow. Points he listed as "tricks" are just basic things to do while debugging. Depending on the situation you might just read stack trace from exception check code lines and you know right away what is the problem. My main point being: *you can, not be attached to outcomes, only if you really are competent* Not being attached to outcomes does not make you competent.