3 ms·

On the "anti-fragile" aspect of things, I studied Architecture in college and grad school (buildings, not software/system architecture) before transitioning to

On the "anti-fragile" aspect of things, I studied Architecture in college and grad school (buildings, not software/system architecture) before transitioning to programming and the entire education model is built around dozens of critiques over the course of the semester. We don't have final presentations, they're Juries. Each semester culminated in working your ass off for weeks, pulling all nighters for days on end, then presenting whatever drawings and models you had to a panel of jurors who were assuredly going to rip you a new one. They weren't intentionally being mean, but you're a student, and there's plenty to pick apart as there's never enough time to think and do everything. Regardless of how good my projects were, after those final juries were done, I always felt like I'd gotten a heavy dose of criticism. Going through that process over and over again has been incredibly helpful in my professional life, even though most of the criticism I receive is rarely structured like those juries. The first thing I learned is that it's rarely useful to try and refute or respond to the criticism directly in the moment. If that's your instinct, then chances are you aren't fully thinking through the criticism and responding from a more emotional state, which is not good. The key is to try and actually listen (rather than "shutting down"), remember the key points to process later, and to let the person offering the criticism know that you've acknowledged it. Second is to realize that nothing is perfect. There is always room for improvement, things that you couldn't foresee, and things you simply didn't have time for. Obviously, the bigger those things are the more concerned you should be, but as your work becomes more and more refined, the criticisms become about smaller and smaller aspects of whatever you've done. The goal is not to get zero criticisms of your work, but to have the criticism that you do receive be about less and less important elements. Third is that someone will always have something to say. Interpret that in a number of ways. If you're getting a code review, you're soliciting someone's opinion or your development process is dictating it. People will come up with criticism because that's what's being asked of them, and even if it's "perfect", responding with nothing makes it seem like they're not doing what they should. People like to offer criticism because it makes them feel important; they see a "flaw" you didn't, even if they don't really understand the totality of what you did. And while its disappointing to say, some people will criticize you for personal reasons, be it against you directly or because they think they stand to gain something by doing it. Ultimately, you have to decide what is worth listening to and what is not. If nothing is ever worth listening to, then that's something that's likely more on you than the criticism you're receiving. It's also very tempting to discount criticism from certain sources because of past issues with that source. Process each criticism from them in the same way, regardless of the past, because you never know when they actually might have something worth listening to.

deltarholamda 3y ago
>Going through that process over and over again has been incredibly helpful in my professional life I agree 100% with this. Art majors (depending on the school) go through much the same process, with the added bonus that artists can be even more capricious. E.g., "blue is totally the wrong color for that." Filing the burrs off of your ego is often a good thing. There is an issue with some people who are just not structurally fit for that sort of thing, where the slightest criticism can make them collapse into a heap of self-loathing and depression. Discretion and discernment are important so that you don't break a fellow human. So the flip side is that being a part of critique juries is also training in how to give criticism, which is an important skill in and of itself. Programming, especially in the open source world, tends to be a very solitary endeavor. It's quite akin to art in that way. And programmers tend to spend a lot of time up in their heads. And they tend to be rather blunt about their opinions. Getting some time in the reviewer and reviewee seat is useful.
- polygotdomain 3y ago
  > E.g., "blue is totally the wrong color for that." That's a little of what I was getting at with some of the points above. Tons of criticism is just plain subjective. How do you evaluate the validity of someone else's subjective decision? The ultimate answer is that you can't if your response to it is to flip the table and leave the room. >There is an issue with some people who are just not structurally fit for that sort of thing, where the slightest criticism can make them collapse into a heap of self-loathing and depression. I agree, but I think that in and of itself is a bit of a different problem. A key aspect of the modern human condition is being able to deal with criticism. If the slightest bit of it will "make you collapse" then that's a strong indication that you need some professional help to learn how to deal and process things. >Discretion and discernment are important so that you don't break a fellow human. So the flip side is that being a part of critique juries is also training in how to give criticism, which is an important skill in and of itself. I don't disagree that teaching people how to criticize will help have that criticism be better structured, less aggressive, and more constructive overall, but the reality is that we can't expect everyone to have "the proper training". There absolutely were jurors that I had that were more about tearing you down than trying to help improve. Dealing with those people was a learning process in and of themselves. >And programmers tend to spend a lot of time up in their heads. And they tend to be rather blunt about their opinions. Getting some time in the reviewer and reviewee seat is useful. This points to the social nature of giving and receiving criticism. There needs to be emotional awareness from both perspectives. Programmers, as a generalization, tend to be more anti-social than other professions. A key aspect of social interactions is empathy; being able to see things from others' perspectives. When I look back at some of poorest delivered criticisms or responses to criticisms I've experienced in my professional career, they've come from the most anti-social developers. Bluntness can have two interpretations, being straight to the point and/or not going into details. "This is poorly structured" is blunt, but doesn't attack or make things personal. "This is crap" is just as blunt, but has a far more negative connotation and interpretation to it. Neither is all that great of a criticism if they're not expanded on or explained.

deltarholamda 3y ago

>Going through that process over and over again has been incredibly helpful in my professional life I agree 100% with this. Art majors (depending on the school) go through much the same process, with the added bonus that artists can be even more capricious. E.g., "blue is totally the wrong color for that." Filing the burrs off of your ego is often a good thing. There is an issue with some people who are just not structurally fit for that sort of thing, where the slightest criticism can make them collapse into a heap of self-loathing and depression. Discretion and discernment are important so that you don't break a fellow human. So the flip side is that being a part of critique juries is also training in how to give criticism, which is an important skill in and of itself. Programming, especially in the open source world, tends to be a very solitary endeavor. It's quite akin to art in that way. And programmers tend to spend a lot of time up in their heads. And they tend to be rather blunt about their opinions. Getting some time in the reviewer and reviewee seat is useful.

polygotdomain 3y ago
> E.g., "blue is totally the wrong color for that." That's a little of what I was getting at with some of the points above. Tons of criticism is just plain subjective. How do you evaluate the validity of someone else's subjective decision? The ultimate answer is that you can't if your response to it is to flip the table and leave the room. >There is an issue with some people who are just not structurally fit for that sort of thing, where the slightest criticism can make them collapse into a heap of self-loathing and depression. I agree, but I think that in and of itself is a bit of a different problem. A key aspect of the modern human condition is being able to deal with criticism. If the slightest bit of it will "make you collapse" then that's a strong indication that you need some professional help to learn how to deal and process things. >Discretion and discernment are important so that you don't break a fellow human. So the flip side is that being a part of critique juries is also training in how to give criticism, which is an important skill in and of itself. I don't disagree that teaching people how to criticize will help have that criticism be better structured, less aggressive, and more constructive overall, but the reality is that we can't expect everyone to have "the proper training". There absolutely were jurors that I had that were more about tearing you down than trying to help improve. Dealing with those people was a learning process in and of themselves. >And programmers tend to spend a lot of time up in their heads. And they tend to be rather blunt about their opinions. Getting some time in the reviewer and reviewee seat is useful. This points to the social nature of giving and receiving criticism. There needs to be emotional awareness from both perspectives. Programmers, as a generalization, tend to be more anti-social than other professions. A key aspect of social interactions is empathy; being able to see things from others' perspectives. When I look back at some of poorest delivered criticisms or responses to criticisms I've experienced in my professional career, they've come from the most anti-social developers. Bluntness can have two interpretations, being straight to the point and/or not going into details. "This is poorly structured" is blunt, but doesn't attack or make things personal. "This is crap" is just as blunt, but has a far more negative connotation and interpretation to it. Neither is all that great of a criticism if they're not expanded on or explained.