Imposter Syndrome

This is a quick write-up of my near-impromtu grok talk on Imposter Syndrome I did at DDD East Anglia.

Impostor syndrome (also known as impostor phenomenon or fraud syndrome or the impostor experience) is a concept describing individuals who are marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud”. — Wikipedia.

I wanted to talk about Imposter Syndrome in relation to talking at User Groups or conferences, such as DDD. The common complaint is that “I’m not good enough”.

Way back in the early days of Scottish Developers (2004), one of the organises suggested I do a talk on SQL Injection Attacks as I had been talking about it in the pub after an event and he recognised I was quite knowledgeable about how to prevent it. I protested, but he continued to try and persuade me. Eventually I did do a talk the following year and I got good feedback from it. I thought I was behind the curve and everyone knew more than me, but it turns out that wasn’t the case.

Last year .NET Rocks came to Scotland and one of the interviewees, Chris McDermott, said he felt a little like an imposter after they had interviewed such luminaries as Dan North, folks that had published books. But, having worked with him, I know he really knows his stuff, and he gave an awesome interview.

But don’t just take my experience or others in the developer community with imposter syndrome, some really clever people including Professor Richard Feynman, who won the Nobel Prize for Physics in 1965 for, as a he described it, as a result of piddling about with plates. He also helped develop the atom bomb in the 1940s and worked out why the Callenger Space Shuttle exploded shortly after takeoff in 1986. Yet, in a speech in the mid-1970s he said he felt like a fraud. He said he was just playing and having fun.

Meryle Streep once said in an interview: “You think, “Why would anyone want to see me again in a movie? And I don’t know how to act anyway, so why am I doing this?”

Daniel Radcliffe said: I think the most creative people veer between ambition and anxiety, self-doubt and confidence. I definitely can relate to that. We all go through that: “Am I doing the right thing?” “Is this what I’m meant to be doing?”

So if these talented people get impostor syndrome and they’re really talented, maybe you are too. Maybe you could do this, and be really good at it.

So I encourage you to try, ask to speak at a local user group. Maybe just start with a grok talk or a lightening talk and work up. But you are better than you think you are!

Feedback from my DDD Scotland Talk on Parallisation

DDD Scotland 2011 Talk Opening SlideI got my feedback from my DDD Scotland 2011 talk on Parallelisation. I was actually pleasantly surprised. I guess I was being a little too self critical and the talk went over a lot better than I thought it had.

Some of the highlights:

  • Good clear samples and demos.
  • Enthusiastic speaker who really knew his stuff. Great talk!
  • Nice easy to understand examples. Getting the concepts across without clutter.
  • Useful info. Genuinely learnt something new.

And of course my favourite comment (despite being somewhat irrelevant, or should that be irreverent): Colin’s funky hair.

There were a couple of points that I need to address in future versions of the talk.

I only gave an overview of locking and the only demo that went close was the ConcurrentDictionary example in which all the locking mechanisms are internal to the ConcurrentDictionary. One person wanted more detail on locking so I shall endeavour to add a little extra into the presentation for DDD South West on locking including, if time allows, a specific demo.

The aspect of locking I need to address, is that I talked about when I used a semaphore in a project to restrict access to a scarce resource, but again I didn’t elaborate on it and another person would have found an example of a semaphore being used useful. I have already written about semaphores in a previous blog post, so I shall try and work that in to the next version of the presentation.

The other part is that the intro appears to be a little long and I need to shorten than slightly. If I can do that, it will at least free up space in a one hour talk to add the additional information on locking in later on.

I really appreciate the additional few moments people took at the end of my talk to write specifically what they enjoyed and what they disliked about my presentation, especially as lunch was waiting for them. It really gives me something to work with in order to improve the talk.

Background tasks and application exit

During my talk on Parallelisation at DDD Scotland 2011 I was asked what happens if the application finishes while there were still tasks running.

At the time, I was showing the Tasks Within Tasks demo and I showed what happened when the Wait call was removed in the Main method. Since the Wait call was removed the lines following it were immediately executed. Those were: to output that the program was ending; and to wait for a key press (to give the audience time to read the console output).

So, what happens when the application naturally concludes like when the Main method completes? When preparing the talk that question had simply not occurred to me. Do the background tasks continue until completion or do they all stop? I suspected they would just stop.

During the talk I simply removed the Console.ReadLine call, but then the console window appeared and then disappeared in a tiny fraction of a second. Did the tasks stop? Or, did the tasks simply continue without a console window available?

Since a further investigation at the time would have disrupted the talk I said I’d investigate further and follow up on my blog. So, this is that follow up.

I’ve now created a new example where the tasks output to files rather than the console. If the tasks stop, the files either won’t be created or contain incomplete output. If they are allowed to continue then the files will be complete.

Here is the code:

class Program
    private static readonly string folderName = DateTime.Now.ToString("yyyy-MM-dd HH-mm-ss");

    static void Main(string[] args)
        // Create a directory for the output to go.

        // Start the tasks
        for (int i = 0; i < 20; i++)
            Task.Factory.StartNew(PerformTask, TaskCreationOptions.AttachedToParent);

        // Give the tasks a chance to start something.

    public static void PerformTask()
        // Create a new file in the output directory
        string path = folderName + "\" + Task.CurrentId + ".txt";
        using (StreamWriter writer = File.CreateText(path))
            // Ensures that all write operations are immediately flushed to disk
            writer.AutoFlush = true;

            // Write stuff to the file over a period of time
            writer.WriteLine("Starting Task {0}", Task.CurrentId);
            writer.WriteLine("Ending Task {0}", Task.CurrentId);

In the Main method, the Sleep waits long enough that the first few tasks will run to completion and further queued tasks are started.

The result on my machine is that the first 4 tasks run to completion, the next 4 tasks are in still being processed when the Main method naturally concludes. At this point the application exits. All the running tasks are forced to exit leaving files with only the first part of their content in them.

So, in answer to the question I was asked: If the application finishes while there are tasks still running then all the running tasks are all stopped without being allowed to complete. No more queued tasks are started.