IIS site? Take app offline quickly

Simply put a file called app_offline.htm in the root of the app folder.  Anyone surfing to that site will just be served that file.


See http://weblogs.asp.net/scottgu/426755

(Scott's link is bad, it is supposed to be:  http://weblogs.asp.net/pleloup/taking-an-asp-net-site-offline-with-a-message )

I haven’t fully investigated all of the aspects of this, but based on my current knowledge,

Good for all genders:

https://adainitiative.org/2013/06/kicking-impostor-syndrome-in-the-head-lessons-from-adacamp-dc-and-sf/#transcript

Talk transcript: Denise Paolucci, “Overcoming Impostor Syndrome”

This talk transcript is based on the caption file for the video of Denise’s talk, prepared by Mirabai Knight of StenoKnight CART Services.

[Slide text that Denise repeats is not shown separately. Where text appears in italics, it is also being shown as slide text.]

[Slide: linux.conf.au 2013, Come join the party…]

[Slide: Overcoming impostor syndrome, Denise Paolucci]

Denise Paolucci [voice]: I’m ready, and the technology is ready.

Bianca Gibson [moderator]: Our next speaker is Denise Paolucci, talking about overcoming Impostor Syndrome.

[Slide: Overcoming Impostor Syndrome, Denise Paolucci, Dreamwidth Studios.]

Bianca: How many times have you caught yourself worried that someone’s going to figure out at any minute that you’re faking everything? You’re not alone. It’s called impostor syndrome, and you’d be surprised how many people in the tech industry feel the same way. Come hear about the things you can do to overcome your Impostor Syndrome, along with tips and techniques you can use to convince your brain to get out of your way and let you keep doing awesome things.

[applause]

Denise: So overcoming Impostor Syndrome. As we’ve just heard, Impostor Syndrome, if you listen to Wikipedia’s definition is a psychological phenomenon, in which people are unable to internalize their accomplishments. Despite external evidence of their competence, those with the syndrome remain convinced they are frauds, and do not deserve the success they have achieved. Proof of success is dismissed as luck, timing, or as a result of deceiving others into thinking they are more intelligent and competent than they believe themselves to be.

And that’s the Wikipedia definition, but there’s a much simpler definition that you can use for figuring out whether or not you have impostor syndrome, and that is: If you’ve ever caught yourself saying, “Oh, crap! They’re all going to realize I have absolutely no idea what I’m doing.”

Can I get a show of hands here how many people have ever had that feeling? [Denise raises own hand, another is shown raised directly in front of the camera, most of the audience cannot be seen.]

That’s what I thought. You will notice my hand is up. I spent last night working on my slides and thinking… “They’re going to figure out I am totally not qualified to talk about this.”

And the root cause of all of this is… sometimes your brain is a jerk. I don’t know if any of you guys ever read Captain Awkward, the advice columnist. She has this whole thing that — you have your jerk brain, and the jerk brain is the thing that lives in the back of your mind, and just keeps telling you the awful, awful things and it’s hard to not listen to it. Because really, it’s a really, really big jerk. And it’s going to keep lying to you. You’re going to be walking along just fine…

[ Slide: warning sign showing stick figure walking towards the edge of a cliff. ]

Denise: and all of a sudden, you’re going to find yourself just about to step off the cliff, and boom.

So here’s a couple of very brief tests.

[audience member sneezes]

Denise: Bless you.

If somebody comes up to you and says,

[Slide: “You and John and Jane are all so good at what you do!”]

Denise: “Wow, you and John and Jane — the three of you are all so good at what you’re doing!”

Denise: Do you say, “Thanks! I really enjoy working with them!”? Or do you listen to the back of your brain and say, “Well, they’re good at this. I’m the one who’s just pretending.”?

I know which one I’m usually thinking.

[coughs]

Denise: Excuse me; I have the death crud here, so…

If somebody comes up to you and says, “I always look at you as a role model!”

Do you say, “Well, thanks! I’m really glad that I can inspire you!”?

Or do you say, “Well, you wouldn’t if you knew how bad at this I really am.”?

Somebody comes up to you and says, “You’re so good at solving problems for other people.Thank you so much!”

[Slide: Thanks! We all help each other out whenever we can.]

Denise: Do you say, “Thanks! You know, we all really help each other out here as much as we can.”?

Or do you just stop, and the back of your brain starts going, well…

“Okay, except for that one mistake… And then the other one, and then the really huge one, and the time I broke everything, and everybody had to clean up all my mistakes, and I spent a week hiding, because I felt guilty, and I was really sure that everybody was going to blame me for wasting all their time, and I kept waiting for somebody to say something, and they didn’t, and I was positive they were all talking…”

[Denise mimes inhaling deeply, with her hands near her diaphragm.]

Denise: Okay, we’re going to breathe.

[Slide: (breathe.)]

Denise: As a matter of fact, I’m so stressed out just by, like, relating this, that we need to stop and look at a picture of my cat with some yarn.

[Slide: picture of cat lying on its side in a patch of sun, with a blue ball of yarn near its belly.]

Denise: This is my cat. He doesn’t care if I know what I’m doing, as long as I feed him on time.

So let’s talk about why Impostor Syndrome sucks. And it sucks for you, and it sucks for the people in the community around you.

And here’s why. It is absolutely impossible to take pride in your work, because even when you accomplish something really big and epic, you can’t stop and look at it and evaluate it honestly, because all you’re seeing is the stuff that you didn’t do, or the stuff that you did wrong.

It means that it’s impossible for you to admit that you don’t actually know something.

Because if you’re feeling like you’re worried that everybody is going to figure out any minute that you don’t actually know what you’re talking about, you’re not going to feel secure enough to be able to ask the questions, and so you’re going to muddle around for a long time, when you really should be just stopping and asking somebody to confirm something really quickly, and then move on.

Prevents other people from having perspective too.

And I saw everybody looking around, when I raised hands, and said, “How many people have felt like this?” That’s a really powerful reality check. Because if you’re sitting there and thinking that you’re the only one who’s feeling this way, you’re going to be less likely to actually admit it, but if you’re talking about it honestly, then everybody knows that they’re not the only one, and you can get that sort of reality check.

But most importantly, why Impostor syndrome sucks is it just makes you feel like crap.

And you don’t want to feel like crap.

You know, if technology is your job, you don’t want to go to your job and spend 8, 10, 12 hours a day feeling like crap. If it’s your hobby, you don’t want to go to your hobby and feel like crap, because that’s (inaudible).

So let’s talk about some ways to address the problem.

These are not exhaustive, and I want to be very clear in saying that none of these techniques are going to work for everyone. There are some things on this list that I personally find, like, totally unhelpful. There are some things on this list I find the opposite of helpful. So you have to evaluate it yourself, and see whether it’s helping you or hurting you, but keep these techniques in your toolbox, so that you can drag them out and use them.

And another thing that I want to say is that I actually got a lot of these ideas from a session at AdaCamp DC, last June. It was an unconference put on by The Ada Initiative, and Impostor Syndrome was such a popular topic that it actually wound up scheduling five separate sessions over two days to talk about it. So that everybody would have a chance to attend a session on the problem. So a lot of these ideas came out of those sessions.

Step one: Talk about the issue. Just talking about it means that you’re more likely to hear somebody else admitting that they feel the same way, and just validation is super helpful. When you hear somebody that you really look up to saying, “Yeah, half the time I feel like I have no idea what I’m doing,” it’s going to wind up — you’ll look at them and say, “Wait a minute, you feel like that too?”

Especially if you’re a community leader, or if you’re somebody in a position of authority, inside your own community. It’s really critical for you to talk about this to other people, to serve as a role model. But especially if you’re a community leader or in a position of authority in your own community, you’re probably feeling like that already. So just admitting it to other people, have other people turning around and saying, “I feel like that too.” And that’s major backup.

Two: Watch your language. Some ideas are self-reinforcing. And in this, I mean both verbally and in email. Example: Some of the things that are self-reinforcing and self-diminishing language — “just” and “only”.

If you find yourself starting to type a sentence, and say, “Well, I’m just a beginner at this,” or, “Well, I’ve only been studying this for a couple of years.” Things like that. Those sort of little qualifiers minimize your experience, and they minimize your authority, so you wind up talking yourself into believing that you’re less experienced than you actually are.

“I think”, “I don’t know if”, other qualifiers like that — if you are offering advice, if you’re offering a suggestion, or if you’re participating in the friendly argument cage death match that Open Source arguments often turn into, you find yourself typing out qualifiers like, “I think we should do this.” Or, “I think we should solve the problem that way.” No, you don’t think that. You believe that we should solve the problem that way. The “I think” should always be implied, because it leads others to believe that you’re less authoritative than you actually are. And again, it leads to you convincing your own brain that you are less authoritative than you are.

Qualifiers such as, “Well, I’m not a real…” whatever. If you catch yourself writing an email to somebody, and saying, “Well, I’m not a real developer.” I do this all the time on Dreamwidth, because I’m actually not the technological half of the co-ownership team. I’ve learned a lot of stuff since then, but when we started this whole thing, I was going to be the business half, and my co-owner Mark was going to be the tech half.

I catch myself all the time saying, “Well, I’m not a real Perl programmer, but —” and then I stop myself. Do I program in Perl? Yes. Therefore I’m a real Perl programmer.

And then the one that really is insidious, and I have to work like heck to get out of my vocabulary. “Should”. We should be doing this. We should be working this way. This should be done… Whatever. Well, I should have accomplished more than I actually did.

Should is one of those little words that has a lot of implied meaning to it, and when you unpack the word a little, you start realizing that what “should” is — is it’s a club to beat yourself up with. It is a little marker, saying that you feel that you are not living up to something.

These are really, really hard to get out of your language. They are very hard. They are so very hard, that after four years of really concentrating on trying to minimize that sort of talk, I’m still not very good at it. I suggest a swear jar, only instead of a swear jar, make it your self-deprecating language jar. And then, when you have enough money in it, take everybody out for a beer or whatever.

Point three. Teach the things that you know. Even if you think you don’t know them, you know more than you think you do, and just by sitting down and explaining something to someone, it forces you to structure what you know in a logical and orderly fashion.

And when you’re explaining it to them, you’re going to catch yourself saying things that you didn’t even realize you consciously knew. Because as you’re explaining something to someone, you’ll realize — “Oh, I forget to talk about this whole thing!” Because it really does fit here. And then you realize, well — “Wow, I actually do know a whole lot about this whole thing.”

Four. Question the corrections that other people give to you. And this is one of those things where it’s kind of iffy, and sometimes it works, sometimes it doesn’t. Sometimes it can lead to you having a raging case of ego.

It’s really common in the Open Source world for people to fight and argue about the small details. I don’t know if anybody has ever heard the Parable of the Bike Shed, and What Color Should We Paint the Bike Shed? I think they have it at bikeshed.org right now, because it’s just one of those parables that just keeps getting passed down.

The idea that people like to argue about implementation details on small things, whereas they ignore the implementation details on the big things. If you’re building a nuclear power plant by committee, most of the committee is going to say, “Well, I don’t know anything about nuclear power plants, so I’ll just trust that these plans are accurate.”

If you’re building a bike shed, everybody can get their brain around the concept of a bike shed. It’s concrete, it’s tangible, you’ve probably seen one, so people feel more qualified to have an opinion on the bike shed. And specifically, on what color we should paint it.

In any Open Source project — in pretty much any technology project — you’re going to wind up having a lot of bike shed arguments, where somebody wants to put their stamp on a project.

So if you bring a proposal to a mailing list, if you bring a proposal to a work group or what have you, you’re going to get a whole bunch of little corrections of —

“Well, maybe it should be blue.”

Or, “Let’s paint it purple!”

Or, “Let’s paint it chartreuse, with pink polka dots.”

These sort of corrections can really pile up on you, and you wind up — if you post something to a mailing list, and the first 20 messages you get are somebody nitpicking the implementation details, you’re going to wind up feeling like crap, because you’re thinking like — maybe they’re right.

Sometimes they are right. Sometimes the corrections really are something you failed to think about, something you didn’t flesh out properly, but sometimes the corrections are really just picking on the details.

And sometimes your argument is invalid.

I don’t know if you guys know Mike Holmes.

[Slide: picture of a pale-skinned blond man with muscled arms crossed, wearing overalls and staring into the camera. Macro text reads “Mike Holmes sez: Your foundation will not support your structure. (Your argument is invalid.)” Slide text reads: “(That’s Mike Holmes. He never worries if he’s qualified.)”]

Denise: He is a Canadian contractor. He has a television show called Holmes on Homes, and his schtick is he comes in, and he looks at things that other contractors have done, and he looks around, and he goes, “Well, that’s crap. Just take it all down.” So sooner or later, he’ll parade in, and just, like, undo everything, and start from the very beginning.

So sometimes the people who are critiquing your idea are Mike Holmes. Sometimes they’re going to storm in, and they’re going to want to take down absolutely everything, and build it from the ground up. That’s not always the right solution.

Number five: Ask questions. And this sounds counterproductive, because if you’re worried that everybody’s going to figure out that you don’t know what you’re talking about, why should I be telling you to ask questions? Because then it’s going to be certain that you don’t know what you’re talking about, right?

The problem is that if you are slightly out of your comfort level, and if you’re working with something that is not 100% clear or whatever, if you don’t understand something, if you don’t have a certain bit of information or whatever, fear of being discovered as an impostor is going to lead to you just try and keep working your way through, without getting that clarifying information.

If you ask a question right up front, you’re going to have that information. It’ll be clarified. You’ll know what you’re talking about. And then you can proceed with confidence.

If you are working on a particular code base, and there’s this one function in there, and you’re staring at this function, and you can’t for the life of you figure out what this function does, and of course it’s not documented, because God forbid we have code documentation. And you can’t figure it out, and you can’t figure it out, and you’re starting to feel like an idiot, and you’re starting to feel like, “Oh my God, they’re all going to realize I’m pretending. What the heck?”

Sometimes when you turn to somebody else and say, “Hey, this particular function — I can’t figure it out. Can you help me out here? Give me a bit of a clue?” Sometimes it turns out that that’s the one thing that everybody in the entire project has no idea, and it’s just been sitting there in the bottom of the code base for 15 years, and, you know…

So by asking questions early, you can clarify the point and move on.

All right, I’m going to have to speed up real fast here. Sorry.

Six: Ask for perspective checks from a friend.

And that is, if you have a trusted friend inside your project, inside your organization, you can go to them and say, “I’m feeling really insecure about this. I don’t know whether or not this thing that I did is good enough. Can you take a look at it, give me a second pair of eyes?”

That’s really important. Nine times out of ten, 99 times out of 100, your friend is going to look at it and say, “No, you’re totally fine. You’re imagining things. It’s perfect. Just go with it.”

Sometimes they’ll catch something. But just having that extra pair of eyes really helps.

Seven: List your accomplishments and own them.

And I’m going to link here to — this is a screenshot of my private blog.

[Slide: SYNECDOCHIC recent entries, YAY IT’S MONDAY, followed by blog text.]

Denise: Every Monday, we post something known as the Pride Thread, and it is an invitation for everybody to stop and post something that they did in the previous week that they’re really proud of.

Sometimes it’s something major, like, you know, next week I’m going to say, “Yeah, I traveled to Australia, and I gave a bunch of talks at a conference, and it was awesome.”

Sometimes it’s really, really minor. Like, somebody will say, “I got out of bed and I went to work every day this week, because the depression was trying to keep me in bed, and I didn’t let it.” And that’s just as major.

So keeping a list of what you actually do and having an accurate list of your real accomplishments lets you look back every time you think, “Well, I’m not doing anything. I’m not accomplishing anything.”

It doesn’t have to be public like this. It can be your own list, on your own desktop. But keep the list. And it will help give you another reality check.

Eight: Practice accepting compliments. This is the hardest thing in the world. And this, out of all of the points, is the one that I have the worst problem with. If one of you guys comes up to me later today, and says, “Thank you, I really enjoyed your talk,” I guarantee you that I am going to say something like, “Oh, it was nothing. I just put the slides together last night.”

It’s horrible to do. Because it convinces your brain that the things you’ve actually accomplished are not worth being complimented. It convinces your brain that your accomplishments are minimal, and that you shouldn’t really take pride in them. And that leads to feeling like crap.

So practice accepting compliments. It’s crazy, but get together with a friend, and just have them say something like, “That thing you did was really great.” Practice just saying, “Thanks.” Or even, “Thanks, I worked really hard at it.”

Nine: Get more background information for comparisons. And the reason for this is — sometimes it’s hard to tell if it’s just you, or if the organizational culture really is that screwed up.

[coughs]

Excuse me.

Robyn [moderator, voice]: Is everyone enjoying what Denise is talking about?

Audience: Yes!

Robyn: Do you want to hear more?

Audience: Yes!

Robyn: The next talk is a fill-in by me.

Denise: Oh, okay! Well, I’ve only got, like, another two more minutes on the talk.

Voice: We can discuss it, also.

Denise: Okay, great. I actually do have an audience participation part of this that I cut out.

Okay. So get more background information for your comparisons. It’s hard to tell if it’s just you,
or if the organizational culture really is that screwed up sometimes. And that makes it really hard to have a perspective check.

So if you do some more background reading, and figure out what best practices really are, sometimes you can, like, actually get the perspective of thinking — it’s not just me being incompetent. My manager really is that bad.

It’s not just me being incompetent. Our house coding style really is that screwed up. So if you have the information about what a normal environment looks like, you can more accurately assess your performance in your current environment, which may not exactly be normal.

Finally, you are awesome.

[Slide: 10. Remember that you are awesome. Really. I promise. (And others feel this way, too.)]

Denise: And this is a really, really hard point to remember. And it’s something that I keep repeating to my developers. We mentioned Dreamwidth earlier. For those of you who don’t know — Dreamwidth Studios — it’s a blogging platform. It’s a code fork of the Livejournal code base. We started out in 2008, with a code base that was 12 years of legacy Perl.

And if you’re not wincing right now you really should be, because it was that bad. It was this complex, Byzantine — I don’t have enough adjectives.

And now… four years later, five years later, oh my God. It’s 2013 now. Five years later, we have a contributor base that is 65% women, and 60% people who have never programmed before. And what we did in order to do this is — we have many, many tips and strategies and techniques, but the number one thing that we did in order to get people involved in this is combating Impostor Syndrome.

The number of beginners who come in and say, “Well, I always wanted to do something like this, but I’m nowhere near qualified. I don’t know what I’m doing.” And you just turn to them and say, “No, you’re awesome. You are awesome, and you can do this.” You have to repeat the message over and over and over again. It helps if you also have somebody who’s making the failures and mistakes very publicly.

[raises hand] I am that person for Dreamwidth. I was saying earlier that I wasn’t going to be a programmer in all of this, and it just started turning out that way, because I needed to finish the thing in time for launch.

But if you keep encouraging people, if you keep encouraging yourself, you can accomplish a lot of things, and you can have an accurate assessment of your own capabilities.

So thank you very much. Go out and be awesome.

And if we want to keep talking about this, the audience participation exercise that I was thinking of including, before I decided I was going to give the tips — I would like everybody to come up with something, some self-deprecating thing that you have thought to yourself in the past couple weeks, past month, whatever. “I’m a total failure at this. I’m never going to be able to finish this code. I’m never going to get this done on time. I am so incompetent that I should have my keyboard taken away from me.” Et cetera.

So think about that for a minute. And if you are willing to, I’m going to ask people to raise their hand and share that self-deprecating statement, and then have everyone who has also thought something like that in the past year or so — raise their hands.

So I’m going to start off. And the thing that I found myself saying in the past month or whatever was… “I am totally unqualified to be teaching people about this thing.” [raises hand] How many people have felt something like that in the past year or so? Yeah, look around and see how many people… Look around and see how many people this has been happening to. It’s just this really powerful moment of — you are not alone.

So does anybody else want to offer their particular brain weasels? That’s what we call it. The brain weasel. It sits on the back of your brain and gnaws on your brain stem.

Voice: I’m totally out of my depth, and I shouldn’t even be coming in to work. [Denise raises hand.]

Denise: Okay, next?

Voice: Somebody asked me this morning what do I do, and I really floundered for something to say, and I ended up saying, “Oh, I used to teach Desktop Linux.”

Denise: That’s a good one that should also go on the — “used to”. So how many people have found themselves putting their accomplishments in the past, instead of… [raises hand] Okay.

Okay, somebody else want to volunteer one?

Voice: I’m not working fast enough, and not accepting patches fast enough, [Denise raises two hands] and I’m failing as a maintainer.

Denise: I’ve got both hands up here. Anybody else not working fast enough? Not accomplishing things fast enough? Yeah, time management is one of the things that you can use as a club to beat yourself up with more than anything else in the entire world. Because we all have this image of — things should be on this super fast-forward pace. Things should get done immediately. We’re all used to a very 24-hour response cycle. We’re used to getting an answer within an hour or so. And if you can’t keep that pace up forever — and you can’t, because you will burn yourself out faster than anything, trying to do that — so if you can’t keep that cycle up, you wind up using it as a club to beat yourself up with.

Anybody else have one? Up there in the —

Voice: I’ll never get my PhD. Therefore I’ll be a failure all my life.

Denise: I’ve never tried for a PhD, so I can’t, you know… So let’s go for a more generalized… “I’ll be a failure my entire life.” [raises hand] Yeah, okay. There’s one up there in the corner.

Voice: Mine’s more comparative. Like, how come I’m doing this so slowly, and somebody else is doing it so quickly? Or their time management — how do they find the time to do all of these extracurricular kind of additional things in life, and how is it that I don’t have that time? Where am I failing?

Denise: So let’s go with… Comparing yourself to somebody around you, and feeling that you came off worse in the comparison. [raises hand] Me too, me too.

Okay, so I hope what we’re getting across here is that you are not alone, and that these horrible, horrible feelings you have of doom, gloom, incompetence, and impostorness — you’re not alone. You are actually in the majority. All of the other people around you are probably feeling the exact same way, and if you just stand up and say, “Hey, I kind of feel like crap about this, so let’s talk about that,” you can wind up reaching a lot of people who are just going to stand there and say… “Yeah, actually, yeah.”

Voice: Who else has heard of the Dunning-Kruger effect, and used that as an excuse why they’re not actually as good as they think they are? If they do think they’re good, it’s just because they’re secretly crap at it?

Denise: Okay, for those who don’t know what the Dunning-Kruger effect is, the Dunning-Kruger effect is kind of like the converse of Impostor Syndrome in a lot of ways. It’s the idea that people who actually are less competent are less likely to know what they can’t do. And so they are more likely
to evaluate themselves positively. So essentially, the worse you are at something, the better you are likely to think you are at it, because you don’t fully understand the scope of the problem.

So how many people have ever heard of the Dunning-Kruger effect, and thought, “That totally applies to me!”? [raises hand]

[coughs]

Yeah, excuse me. Okay, in the back there.

Voice: So this relates to kind of perfectionism, and it’s — no matter how hard I try, I’ll never be good enough.

Denise: “No matter how hard I try, I’ll never be good enough.” [raises hand]How many people have caught themselves saying that? That’s a good one, yeah.

Voice: We were talking in the early part of the talk about, you know, self-deprecating language, and saying things like, “You shouldn’t use language like I don’t know or I’m not sure” or something. But is it okay to have a kind of skepticism of yourself, where appropriate? Is it okay, or indeed, is it essential to be able to say, “I’m not sure, or I don’t know,” if that’s actually true?

Denise: If that is actually true, yes. If you are actually legitimately not certain about the answer, if you think there are multiple ways to solve a problem, and what you’re proposing is only one of them, absolutely it is better to admit that you don’t know something, because that way you’re not giving a false impression of your confidence.

What I was referring to in that slide is the sort of speech pattern in which every time you are offering an opinion, a design opinion, or a thought, or putting forth your idea of how something should work, there’s a real temptation, sometimes, to use that minimizing language. So if what you’re talking about is a statement of opinion, or if you’re fighting in a standards war, and you are putting forth your proposed standard, you know, for things like that, it’s a good idea to try to strip the minimizing language.

If you are absolutely not certain about something, and you want to make that very clear, just a simple disclaimer up front. “You know, I’m not — I haven’t fully investigated all of the aspects of this, but based on my current knowledge, this is what we should be doing.”

Voice: And is there sort of a difference between things that are sort of subjective or personal, and things that have a more clearly defined technical argument?

Denise: Absolutely.

Voice: One of the tips in the presentation was to get a reality check from peers. Say, “Hey, I’ve been feeling this way about this particular aspect of a project, or my life, or whatever. Is this something that I’m actually being paranoid about, or is this something that I should be considering?” And people that you trust and that you respect to give you help on that —

Denise: Absolutely. Fanfiction fandom has the concept of the beta reader, which is — when you’ve finished your piece of fan fiction or whatever, and you’re ready to release it to a wider audience, you grab your friend, who’s your beta reader, and say, “Here, read this over, and tell me if it makes as much sense outside of my head as it does inside my head.” And so having a beta reader for your emails or for your technical communications, or for your talk slides or whatever, is really valuable like that. Like you said, just for the perspective check of — am I totally off-base here? I’m being paranoid in rereading this. Did I actually communicate? Did this make this outside of my head?

There’s a microphone back here.

Voice: Yeah, I was just thinking — probably the one point you had, following up on this self-talk and the language you used, deprecating — and I’ve had to deal with explicitly the — “I’m not sure.” And if you put it in what you’re saying to others, it’s putting yourself down. On the other hand, what I’ve found is — you have to carry through. It’s the — so I say to myself, “I’m not sure. Let me check.” And that’s where — if I just leave it as I’m not sure, I’ll spiral down and just go.

Denise: Yeah, absolutely. You know, it’s closely related to depression, in a lot of cases. Because if you are susceptible to depression, sometimes anything will use — your brain will use anything to convince yourself that you just are not worthy. So you have to just, like, head it off at the pass, and start, like, kicking the Impostor Syndrome in the head, and banishing the brain weasels.

Microphone there?

Voice: Just something that you were saying about — if you’re feeling uncertain, ask. Something that I’ve had to take on board, listening to people talking recently, the frustration that people get when somebody else has tried to do something,they’ve muddled along, muddled along, taken a lot of time, and ended up not getting anywhere, and it was, “Why didn’t they ask me sooner?” And it was actually something relatively simple, that could have been sorted out, and then got on with it, and it’s something that I’ve realized that I need to learn to do that as well, instead of muddle along and keep my head down, and think, “My God, I hope they don’t catch me.” Actually ask a question.

Denise: Yeah, that’s why I put in the slide the point about — ask questions. If you ask questions early, and here’s something that, if you’re a community maintainer, or if you’re a member of an Open Source community, you can actually work to help minimize that problem with other people. Have regular check-ins. If you’ve got somebody who took on a bug, that’s a project that you think might be a little bit out of their comfort zone, just, you know, give them a couple weeks, and then stop in and say… “Hey, I wanted to just catch up with you on… You’re implementing such-and-such. Do you want to chat about it? Do you want to sit down and explain to me what you’re doing right now, in order to help get your head straight on it, or whatever?”

You know, don’t ask them if they need help. Ask them to explain what they’re doing to you, and explain their thought processes to you. Because if you ask them an open-ended question like that, they start to teach you what they’re doing. And that goes back to my point about how you don’t know what you know until you try to teach it. So nine times out of ten, they’ll wind up starting to explain their code or their design or their architecture to you, they’ll get 10, 15 minutes into it, and they’ll stop and they’ll say, “Oh, crap.” And then they go off and they fix the problem that they didn’t even know that they were having.

It’s the Teddy bear at the door effect. Do you guys know that one?

Voice: Rubber duck debugging.

Denise: Yeah, rubber duck debugging is that if you’re having a problem, or you need an answer, if you go to your manager, and your manager says, “Well, you can explain your problem to me, And I’ll help you solve it, but before that, you need to tell the Teddy bear at the door.” And just the simple action of explaining your problem to the Teddy bear or the rubber duck winds up halfway through — you get halfway through, and all of a sudden, you go, “Oh, that’s how it works! Okay, thanks, bye!”

Voice: I’m getting one of those at work.

Denise: Yes.

Voice: Monday

Voice: Rubber duck or Teddy bear?

Voice: I have a plush Cthulhu.

Denise: Oh, that’s a good one, that’s a good one. Yeah, my wife actually —

Voice: (inaudible)

Denise: My wife actually solved a sysadmin problem I was having last week, when I was tucking her into bed and she’s like, “What were you having a problem with?” And I said, “Well, you know, I’m doing this, and I’m doing that, and I’ve checked everything. I’ve checked the… I didn’t check the permissions! Love you! Goodnight! Bye!” And that’s what it was.

Just the simple act of laying it out for somebody. So if you have a new developer, who may be less confident or whatever, prompting them to do that, to explain it to you, will help to increase their confidence, and it will have them point out the points where they may be floundering a little bit. And you can say, “Well, do you want to keep struggling with this? Do you find it satisfying to overcome the problem by yourself? Or do you want a little bit of advice here, and guidance?”

It’s really important not to just take over from them, because then that winds up reducing their confidence level.

Yes?

Denise: Yeah, just what you’re talking about reminded me of a late contribution to the audience participation part.

Denise: Oh, absolutely. We kind of got afield from that. But that’s okay; go on.

Voice: Yeah, something that I often get stuck with — I don’t know enough to ask this question. So I get stuck in this loop of, “I need to research enough, so I can ask what this thing is that I don’t understand.”

Denise: Yes, oh, yes. Especially since there’s such an emphasis in the Open Source community about asking intelligent questions. And really all that does is make you paranoid about — “Oh my God, is my question too stupid?” Yeah.

So actually, I want to tell one story, and then I think we’re kind of running out of time here, but… Yesterday afternoon, I actually wound up playing hooky from the conference yesterday. And we went down to the National Museum, down at the base of the campus here. It’s a really good museum, and we were walking around, and we went into one of the special exhibits, which — sadly, it ended yesterday, so I can’t tell you to go and see it as well. But it was an exhibit on conservation, and it had all sorts of details about how the museum’s conservators preserve or restore, and how they make the choice between preserve and restore, very, very interesting.

But they had a couple of the conservators actually sitting out there, doing some of their conservation work in front of the visitors. And I stopped to talk to one of them, because I’ll talk to anybody. I’ll talk to absolutely anybody, and absolutely anybody will talk to me. And we started chatting about — “Oh, what are you here in Canberra for?” And I explained that I was here for the conference. And talked a bit about the talks I’m giving. Which, by the way — I’m also talking on Friday about web accessibility in a tutorial. So you should come see that as well. And I said that I was giving that talk, and I said that I was giving this talk on Impostor Syndrome.

And he said, “Oh, what’s that?”

And I explained a little.

And he said, “Wow. You know, we had this intern. She was fabulous. She came in as an intern through the University program, and she was just amazing at everything that she did. She had a really good sense of what needed to be done to the various items, and she was so amazing that we went to hire her straight out of University, as soon as she graduated. And she came back to work with us full-time. And as soon as she did, she started feeling like she had no idea what she was doing. Feeling like she was totally unqualified, that all of the items that would come in — and she had to make the conservation decisions herself — she felt like she didn’t know what she was doing. And we had to explain to her that that’s how conservation works. Because no two objects are exactly the same. No two scenarios are exactly the same. And you don’t have a standard set of books of instructions of what to do here, here, and here. It’s very much an art, as well as a science, and it’s the conservator’s discretion, in a lot of cases.”

And he said, “And here she was, somebody that we hired straight out of college, because she was just that good, and she felt like she didn’t know what she was doing, or anything.” And he said, “And I always thought that was really strange. And you’re telling me that this is actually a phenomenon?”

And I said, “Yes, you should go look it up!”

He said, “Because we have a lot of conservators in the community who have that problem, because they want the simple, easy answers. They want the flowchart of if-then statements. But you can’t have those, because it’s so individual.”

And technology is a lot like that. In technology, there is often not one right answer. And in disciplines where there is no one right answer, you’re going to wind up feeling a lot more insecure than if you’re dealing with math, and you start with a bunch of pieces of the equation on this side, and then you’re looking for the pieces of the equation on the other side, and there’s a right or a wrong answer. Now, I know that in some kinds of math, there isn’t a right or a wrong answer, but that’s the kind of math that I never got to.

So keep reminding yourself that technology, for as much as it is a science, and as much as it is an engineering discipline, technology is an art as well. There are a lot of ways that you can solve any given problem, and because, if your solution is not the solution that everyone around you would have come up with, that doesn’t necessarily mean that it’s wrong.

I think — are we out of time?

Robyn [voice]: Yeah.

Denise: Okay. Thank you very much.

(applause)

Denise: Thank you also for donating your talk slot, and to all of you guys, for sitting through and listening to me for two slots.

Visual Studio Publish - log

I have several publishing profiles for a project.  I also have several endpoints I use to publish to, for testing purposes.

After a while, I really needed to know when a version had been published.  A Google search told me that it was either enormously complicated to create any kind of publishing log or just impossible.  In either case, there was NOTHING BUILT IN TO VISUAL STUDIO OR IIS THAT GAVE YOU THIS INFORMATION.  Which is INSANE.

Well, turns out, that information does exist. At least, the time it was last published.

You can find it in your project.  Under the project "Properties", then "Publish Profiles".  You need "Show All Files" selected.  Then after each .pubxml files (for each Publish Profile), there is a .pubxml.user file.  After each file being deployed, it has:

<publishTime>