The concept of course was Jerry Weinberg's in The Psychology of Computer Programming (1971). I always felt like that book should have had a different title. Maybe "Computer Programming as a Human Activity", which is what he said it was about in the preface: http://wiki.c2.com/?ThePsychologyOfComputerProgramming. The concepts of the book are more social than psychological, as I recall. Even "egoless programming", which is psychology in the sense of looking at how we identify with our ideas, is also about interactions on teams.
Early on on my career, the products I made were an extension of me. Bugs were an insult, design critiques a personal attack. The code was precious and deleting large swathes of it unthinkable.
The consequences? I was probably not that easy to work with, and my software wasn't as good as it could be.
Nowadays I'm proud of what I create, and I enjoy the act of creation. But nothing delights me more than someone (can be me, can be others in the team) taking a hatchet to large chunks of what we've produced, I value criticism of approach and I need people to find faults and bugs to help me deliver a better product. My focus has entirely shifted from "I produce intricate works of art" to "let's find the simplest, most robust way to deliver what my client needs"
How ironic that reading this, I jumped to the Errors of TeX link, something I've read parts of in the past, and then found myself wondering was I in that file?
This doesn’t resonate with me, because so much of programming is craftsmanship. Often the only purpose of some aspect of programming that matters is that I made it. I crafted it. The design that exists matters because I made it. I didn’t pay someone else to do it. I didn’t copy it. I made it. The act of making it is very fundamental.
I think it would be similar to artwork. There’s no such thing as egoless art making. It’s literally the product of the artist.
Programming is a creative act and requires substantial creative mental force. Anytime we are creative, we are putting ourselves out there and making ourselves vulnerable. This naturally causes us to be defensive. The ego connotation misses the root of the problem. We are defensive only because of our insecurities in our identities, not the identity itself. The code we write is an expression of our identity. I find it similar to an artist that paints a portrait and immediately gets critiqued.
Being able to take this criticism without feeling that it is an attack on your expression of yourself is a skill that is learned. I think it only comes from one or both of two things: 1) realizing that you are expressing yourself and that some may find it useful and others won't and be okay with that or 2) be in an environment that doesn't immediately judge your production. I find the latter scenario to be the building block for the former.
In any creative venture, there needs to be an environment of acceptance of failure. If people are comfortable with failing, then they will succeed.
Yep, and you can stop after that. Process is the only important thing. After that you'd better to distinguish you and your program/design. It's mere artifact without value.
Why not just serve plain HTML pages like C2 wiki used to do. Why use Javascript and Google Analytics. Why ask why.
Fact: It took more work for someone to convert the HTML to JSON, write the Javascript and set up the proxy than it did for me to write a shell script.
Not sure what were the benefit(s) to that person versus the one-time cost of switching away from plain HTML to requiring Javascript. No doubt he deemed it worth the time to set up.
What I do know is the benefit to me versus the one-time cost of writing a shell script. It means I do not need to use Javascript or submit to Google Analytics. I do not even need internet access once I have downloaded the C2 wiki, converted it to text and stored it on local media. If it one day disappears from the web and the IA, I still have a copy. This wiki is a piece of history and it is not changing.
Apologies for the error with the quotes. Here is a fix
This is one of the best pieces of advice I've read in a while!
I've talked with my teammates about this topic before, but I've struggled to put it so well. This article (or a book chapter?) is a very nice nexus between psychology, philosophy and programming best practices for collaboration.
Coding Horror republished the ten commandments from the Gerald Weinberg book (any book he's written is worth reading by the way) mentioned in this article:
One of the things I love most about my current job is that at some point the whole team has been through the codebase, and no one owns anything. In fact, any one in the team would be hard pressed to tell who wrote what in the first place, even if they themselves did it.
The result is that anything that needs fixing or improving is simply fixed, no questions asked, no feelings hurt. Once code review approves it it goes back into the communal codebase that we all maintain equally, with all credit shared.
At some point, I've gotten to a place where I see it as a bad smell if you can tell a team member's code apart from the rest.
> The idea is that programmers must fight the natural tendency to treat their programs as part of themselves, and therefore to reject all criticism.
This seems to suggest that the author believes people have a natural tendency to reject all criticism of themselves, and that the programs they help build are just an extension of that. In that case, why single out programs? OTOH I could be interpreting that completely wrong; most of that page seems to be about various definitions and interpretations.
A perfect example of why humans are so strange. Our default human response could have been wired to be "i can't possibly feel bad when criticized, because i know i'm not a master" and "i love having people examine my work, because it's a shortcut to getting better even faster", but instead we take all the wrong lessons.
This is true when I perceive the examiner as more knowledgable but more often than not I perceive them as less knowledgable and ignorant. This can both be true, that they are less knowledgable and ignorant, and that it's wrong of me to assume so. Often it comes from the belief, based on my perceived tone of the examination, that the other person believes they are the expert and are correcting me, the noob. So, feeling perceived as a noob feels disrespectful, especially given a topic for which I'm an expert. That in no way means I shouldn't grow and welcome all examination. But I'm not the Dalai Lama. I'm a normal flawed human being who gets upset when they feel insulted. It will probably take me a lifetime to get better at not feeling insulted. In the meantime, when I remember, I try to couch my examinations of other's code in ways that will hopefully not make them feel insulted.
Based on dunning-kurger, you would expect everyone who is less knowledgable than you to actually think that they are more knowledgeable, so you could say that they are acting with somewhat honest intentions in their attempt to correct you. But then this also acts in the opposite direction as well, in that you might think you are more knowledgeable because you are, but you might also think it because you aren't. So, how do you know if you are "right" to be insulted? You probably would need multiple orders of magnitude difference to be sure, but that's very rarely the case. That is to say, it's probably best to be charitable with my interpretations of others.
I feel often the issue ends up that I am more knowledgeable than the other, but only slightly more, so my instinct says that they are off. However, I can't express it well enough, because I can't absolutely describe all the circumstances in which their advice is correct, and all the circumstances in which their advice is not, and then prove why it's not applicable in this specific case. If I could do so, I'd explain it fully, there would be no complaint from the other, and it'd be a great teaching moment. So then maybe such situations where someone is trying to correct me, but I can't give an absolute response back indicates a gap in my self-held expertise.
And either way, experts can learn insights from those who are noobs (though often not in the way that the noob intended).
> Our default human response could have been wired to be "i can't possibly feel bad when criticized, because i know i'm not a master" and "i love having people examine my work, because it's a shortcut to getting better even faster", but instead we take all the wrong lessons.
This would not be practical nor evolutionary advantage in practice. Saying that as someone who used to believe the above is something to strive for.
It makes you super vulnerable the moment politics appear or when you work and are judged among peers. Among other things, if you welcome and accept criticism while others dont, you will appear less capable to third parties because your mistakes are constantly pointed out and theirs are not. Impression matters. You will be more likely to be convinced you are wrong when you are right or when difference is matter of opinion. You wont be perceived as potential leader.
You will also be getting a lot of bad advice from overly confident people. They will be perceived as more capable then you, even if you realize the advice was wrong. People with hardwired do end up nitpicked and favorite target of those who like dominate others. Which is why such trait is not evolutionary advantage, even if it would be collectively helpful.
Hmm, I kind of see that as a completely separate category -- how I manage my perception within the organization, how I manage relationships and influence, how I present myself, what I say in what situations.
Accepting criticism to me seems like a more internal thing. There's of course the external response to criticism. People will always say whatever they want, so then, do you dismiss it? do you get angry and lash out? do you try to turn it into a teaching moment? do you try to spin it into something else to make people feel like they contributed?
I don't know if accepting criticism means I would be convinced that I am "wrong" when I am "right". Let's say, in some meeting where we're trying to come to some solution, I generally try to frame it as "let's work together to solve this problem". Certainly you have your own thoughts on what the solution would be, or at the very least some instinct on the direction, based on your experience. So then everyone is laying out their thoughts and opinions, and you try to build upon the facts, try to get consensus on points, until you reach the end goal. Of course, it's up to your own skill to metagame the conversation to get people to come to your own solution by their own, usually by enumerating all the approaches, enumerating their strengths and weaknesses, and letting others tally up the points in your favor. Or maybe through the process the group ends up with a better solution than you had originally come in with, which will almost always be the case on some level. It's not a matter of "the expert is correct and we do whatever they say".
Of course, with things like opinions, if it doesn't matter, it's often not worth arguing about, and if it does, there should be concrete evidence in its favor. You might also choose to allow for suboptimal solutions. Let's say we all agree on the overall approach in the meeting, but the person who's going to be implementing the project has a particular opinion on a detail of the approach. Your experience says it's not quite the perfect approach, but not that bad and still meets the bar, you might let them go with that, because it gives them more motivation, lets them feel more ownership, it's something they're more familiar with, etc. The people and team aspect is often more important to optimize than the "technically optimal" solution.
I would also treat the confidence aspect as something else entirely. You present your confidence by having strong well-thought-out and evidence-backed ideas. You make sure that you've always thought more deeply about the issue and are more prepared than anyone else in every meeting. And that you are always sharp to understand, incorporate, and build upon everyone else's ideas. Actually, I might say that this confidence is what allows you to learn and improve from other's criticism, without feeling attacked and beat down by it.
Robert Kegan's Constructive-Developmental Theory could be useful in understanding this.
It basically defines an evolving relationship between Subject (what one is) and Object (what one has).
Criticism targeted at objects (what one perceives) is tolerated. Criticism targeted at the subject (what one is) is frequently a source of stress.
For example, criticism towards one's religion elicits different reactions if the religion is part of Subject (what one is) versus if the religion is Object (what one has).
The same with programming, if the piece of software gets entangled with one's identity, criticism of the software becomes criticisms targeted at one's identity and losing a piece of identity is akin to dying. For someone who only views software as objects, the reaction of a person that has their identity entangled with the software would appear blown out of proportion.
In the end I think the best we can reasonable wish for, anywhere, is non-demented. Everything else is up to entropy, the whims of organized crime, and the pressures of evolution and information.
Are young women better leaders than old women? Than young men? Old men? Is it truly causation? What prompted you to make this association? Any other countries make the list that don't have young women leaders?
Gender and age probably do matter in lots of things. Usually when I hear it brought up, it's either to grind an axe, an act of defense, or a hidden agenda. Almost universally lacking objective truth seeking.
I also dislike the current US president, but IMO calling him out and then promoting the idea that young women are best just polarizes people... In fact if I was a Trump 50-center that's exactly what I would do to try and alienate as many people as I could under the guise of a "lefty socialist".
Sure, the sample size on female leaders is very small. But what about the sample size of female bosses ? Are female bosses significantly better than male bosses ?
I'm surprised that you think that being in middle or upper management is the same as running a business. Do you have anything to support that equivalence?
Agreed on Warren, and I'd love to see President AOC someday. The only reason male leaders have been bastards since time immemorial is because, as you rightly point out, they were mostly men. Most good leaders have also been men. I agree women should be given fair opportunity at leadership though.
The Finnish PM's party got 18% of the vote in the last election. She didn't stand for election, she was appointed and her party has 13% popularity right now.
So literally 13% popularity (party) and unelected.
She had 3 years of experience in federal politics before being promoted (not elected) leader of a nation.
She also has a gushing Goop-like Instagram full of gorgeous pictures of her and her boy at exotic destinations, 'thinspo' shots, glam shots.
She doesn't have any intellectual, academic, or otherwise rigorous credentials.
She's also easily the most attractive person in Finnish politics.
So the real question is - how do intelligent people interpret those who are utterly unqualified and illegitimate in almost every way, who are obviously popular at least due to their visual social media profile and nothing more ... to be 'leaders of integrity, capability, and virtue'?
And of course, arbitrarily picking two leaders from some group (ie female) as somehow evidence of something?
This the exactly the same thing as Trump, just the other side of the coin. It's anti-intellectual & I don't think we want this in politics or real political discussion.
There might be some interesting 'gender' argument somewhere there, but this is not it.
Can you elaborate on what do you mean by 'becoming one with the computer'? My understanding is that you mean that we should put some assumptions aside and try to look from the CPU point of view, which can be helpful for debugging, testing, design, etc. Am I right?
edit: spelling mistake
