Planning for 2017: Do You Want Me at Your Event?

I'm planning my calendar for 2017. I'm going to scale things back a bit, so I'll be prioritizing the events I'll be at. If you'd like me to come speak at your event, please contact me. You'll go to the top of the list.

A Busy 2016
The reason that I'm scaling back for 2017 is that I was on the road quite a bit this year.

• 35 Events
• 53 Talks
• 41 Airplanes (not many direct flights)
• 95 Days Away From Home

Note: These numbers include my trip to Orlando next week.

2016 US Travels

2016 International Travels

I've had a really great time (and look for the upcoming "Year in Review"), but I don't think I can keep up with this type of schedule.

Looking Forward to 2017
I want to get to some new events in 2017. And I'd also like to return to a lot of events I went to this year. But I won't be able to include everything I'd like to do.

If you'd like me at your event, contact me.
This will help me prioritize my schedule.

Feel free to drop a comment on this article, send me a tweet (@jeremybytes), or email me: speaking (at) jeremybytes (dot) com.

I'm looking forward to another year of awesome events: helping developers, meeting tons of people, making new friends, and catching up with old friends. Hopefully I'll see you somewhere along the way.

Happy Coding!

Jeremy Talks with Steve Bishop about TDD

Today I had the opportunity to talk with Steve Bishop on his YouTube channel. Steve gave me the chance to show some code and talk about using TDD in a real-world scenario -- in this case, creating a class that gets data from a service.

You can watch it on YouTube: Real-Time Coding with Jeremy Clark - Test Driven Development

Or you can watch it here:



The code is taken from a talk (and hopefully soon-to-be-produced video series) which shows a few of my struggles with adopting TDD. It's easy to get stuck when we try to do things in a particular order. There are certain things that are difficult to unit test, and sometimes we need to skip over them and get on to other things.

If you'd like to download the code, you can visit my website: Test Driven Development in the Real World.

The code download has 3 states: (1) the starting code (if you'd like to follow along), (2) the "minimal" completion state, which is how we left the code at the end of this video (more or less), and (3) a fully-completed state that has all of the methods and has been refactored into a few different classes. This is just one option for completing the task. The specifics always depend on the needs of our particular application.

Also, if you'd like to take a closer look at exception handling (as mentioned in the video), take a look at this video on my channel: TDD Debugging and Testing Exceptions.

A big thanks to Steve for hosting me on his show. I'll look forward to doing it again in the future.

Happy Coding!

December 2016 Speaking Engagements

The year is winding down. I have just one more event for 2016, and it should be a good one (and it starts next Monday).

Mon - Fri, Dec 5 - 9, 2016
Visual Studio Live!
Orlando, FL
Conference Site
Topics:
o I'll Get Back to You: Task, Await, and Asynchronous Methods
o Learn to Love Lambdas (and LINQ, Too!)
o Unit Testing Makes Me Faster: Convincing Your Boss, Your Co-Workers, and Yourself

Visual Studio Live! is part of the Live! 360 event in Orlando (6 co-located conferences). There are tons of sessions and speakers on a wide variety of topics. I had a great time at this event last year, and I'm looking forward to the same again this year.

I've got three talks, and they are all on topics that I love to talk about (granted, pretty much all of my topics are ones that I love to talk about). I gave a preview of the talks on a webcast a while back. You can still get to it if you provide your email address: Visual Studio Live! Orlando Preview.

If you're at the event, be sure to hunt me down to say "Hi". Or join me at the Birds-of-a-Feather lunch; I'll have my own table.

A Look Back
In November, I drove out to Phoenix AZ to speak at the .NET user groups. I have several friends in the Phoenix area, and it was great to be able to catch up with them in person.

At the North West Valley .NET User Group (NWVDNUG) in Glendale AZ, I talked about practical ways to use reflection in our applications:

Thanks to Barry Stahl (@bsstahl) for the photos.

At the South West Valley .NET User Group (SEVDNUG) in Chandler AZ, I talked about how to get the right levels of abstractions in our code:

Thanks again to Barry for the photo.

While I was in Phoenix, I visited the Desert Botanical Garden. I had a bit of a hard time there. I'm a very tactile person, and I like to touch things. The problem is that everything at the botanical garden is pointy and really doesn't want to be touched:

A Look Ahead
In January, I'm headed back to NDC London. I'm really excited about this. The event was really great this past January, and I made some new friends that I've kept in touch with. I'm looking forward to meeting some new people and seeing some great talks (the talks I'm giving will be great, too). In addition, I get to spend a couple days in London, so I'll get to see some of the things I didn't get to when I was there last time.

Lots more to come. I hope to see you at an event soon!

Happy Coding!

Simple Mocking in F# with Object Expressions (I Like This)

Last time I talked about how I had some mixed feelings about testing C# code using FsUnit. I took the last example a step further and added mocking to the FsUnit test. I really like how easy F# makes it to do simple mocking.

Here's a reminder of the test comparison from last time:

FsUnit testing GetSunset

NUnit testing GetSunset

I had some mixed feelings about this (and I'm still working on them a bit). But I decided to take this a step further and add mocking.

Mocking with C# Code
The code above uses hard-coded data in the production file. The next step is to add an actual service call. But, of course, this messes with the tests.

We don't want to have a service call in our tests, so in the code, we add a property to our class so we can do some property injection. But then we need to create a mock of the object.

Here's the interface we need to mock:

And here's a test in NUnit that uses Moq to mock up the interface:

NUnit with Mock Interface

I've used Moq quite a bit in the past, and I've found it to have the features that I've need in my code.

With that said, the setup for Moq takes a bit of getting used to. But what the second line of this test is saying is "If someone calls the 'GetServiceData' method on this object (no matter what parameter), please return them the 'goodResult' object." The "goodResult" object is the JSON string with our test data.

Then a bit further down, we assign the "serviceMock.Object" to the property on our class. We have to use "Object" because this is how we pull the "ISolarService" object out of our "Mock<ISolarService" object.

This is code that I'm used to seeing. But I found it can be a bit better in F#.

Simple Mocking with F#
First, I started to look at Foq (which is an F# version of Moq). But with a little more searching, I found that I didn't even need to use a mocking framework for the simple call that I needed here.

Here's the same test in F#:

FsUnit with Mock Interface

Take a look at the "mock" item at the beginning of the function. This is an Object Expression. By using this, we have an object that behaves like the mock we created above. If someone calls the "GetServiceData" member on the object (with any parameter (as denoted by the '_' that we don't use later)), we want to return "goodData", our JSON string.

Then a few lines down, we assign the mock to the "Service" property. (And we don't have to use the "Object" property like we did with Moq.)

One other thing that I did to this code that cleans it up a bit: I removed the "new" keywords before all of the constructors. This is optional in the F# world, and it makes things a bit better to read.

Wrap Up
I'm still working on readability. This is a key attribute of unit tests. I really like the Object Expression syntax that allows us to create simple mocks very easily. This is more readable than using Moq in C#.

So I'll keep working through this. If you have any suggestions, feel free to let me know. I'm always looking for tips from folks who have more experience with this than I do.

Happy Coding!

Mixed Feelings About FsUnit

A few days ago, I did an initial experiment using FsUnit to test C# code. My initial tests were pretty positive. Since then, I've done a bit more experimentation, and now my feelings are a bit more mixed.

For the code, I'm using the project from "Test-Driven Development in the Real World". The scenario is getting data from a service, parsing the JSON result, and then converting things to date/time objects that we can use. We'll look at tests written in FsUnit and tests written in NUnit. Granted, I might be "doing it wrong" with FsUnit (since F# has a different coding style), so if you have any suggestions to improve my "problems", I'd like to hear them.

The Good
We'll start by looking at some scenarios where I like the FsUnit tests a bit better. These are similar to the tests we saw in the previous article.

First up, parsing a particular value from a JSON string:

FsUnit testing JSON parsing

NUnit testing JSON parsing

These tests are pretty similar. For the FsUnit test, not having the intermediate variable helps with readability (and we could do something similar with the NUnit test). But here, the "fluent" syntax works pretty well.

The same is true when we're checking to see if our class implements a particular interface:

FsUnit checking for an interface

NUnit checking for an interface

Here again, the code is very similar, but I like the readability of the FsUnit. In fact, I think this could be improved a bit by removing the line break between "calculator" and the pipe-forward operator. This would give us a very sentence-like structure: "calculator should be an instance of ISunsetCalculator".

The Indifferent
There are a couple instances where I don't have a clear preference between the styles of the tests.

Here are two ways that we can check to see if a method threw a specific exception:

FsUnit checking for an exception

NUnit checking for an exception

Again, these are very similar. Part of that is because I'm using the NUnit-specific "Assert.Throws" method that takes a delegate as a parameter.

The FsUnit code also needs to have a function call passed in to the "should throw" function. The piece that I don't like about this code is the "|> ignore". I really wish this was not necessary. But without this bit of code, the test does not compile.

So I do like the more sentence-like code of FsUnit (where we have the function call first). But the "|> ignore" seems to clutter things a bit. That's why I'm putting this test in the middle. I'm not sure if I have a preference either way.

The Ugly
Once I got to the point where I had a bit more setup code and more complex test values, things got a bit uglier for FsUnit. Again, I'm open to suggestions on improving the code here, so feel free to send them in.

This test checks to see that a time string is turned into an appropriate DateTime value. For this, we need a couple of DateTime objects to use for the tests:

FsUnit with DateTime values

NUnit with DateTime values

This is where I prefer the NUnit test a bit better. One reason is that I can have a clear Arrange / Act / Assert layout to the code. The first 3 lines set up our variables that we use for the tests. The next line performs the action of calling the method. And the last line checks that the actual output matches the expected one.

The FsUnit test is a bit less clear. I ended up with a bunch of "let"s to set up the different variables. So, I added an "expectedTimeString" to the top of the file that had the "4:44:12 PM" value that we've seen in other tests. I don't know if this made things better or worse.

I don't like having a lot of setup code because that moves information out of the tests, and now I need to go look somewhere else to find it. But I do like factory methods for setting up things like mocks. This will take a bit more work to try to figure out the most readable way of putting this together.

Here's another example which checks the end-to-end functionality contained in the "GetSunset" method:

FsUnit checking the full process

NUnit checking the full process

I have the same readability concerns as the prior example. The NUnit test has a clear Arrange / Act / Assert organization. The FsUnit has some setup and then the calls. Because of this, the "fluent" syntax of the action and verification gets a bit lost. Again, there may be some ways to make this a bit better.

The fun part about this particular test is that it is incomplete. The code is not yet accessing the service that generates the JSON result. Once this is in place, we need to mock out the service call so that we can test independently. Here's what that NUnit test looks like:

NUnit with a mock service

I haven't written a similar test in FsUnit because I want to see what I can do about some of the concerns that I found with this set of experiments. I've got some more to look into.

[Update: I explored simple mocking with F#, and I *really* like what I found: Simple Mocking in FsUnit.]

Wrap Up
When dealing with more real-world OO code, the readability advantage of FsUnit seems to fade a bit. If you have suggestions on improving readability, please send them along.

For me, readability of unit tests is extremely important. There should be no trickery in tests (even if we need some trickery or optimization in the code we're testing). They should be approachable and easy to maintain.

Readability is a concern that I have with functional programming in general. And this may be something that I need to "get over". But I'm all about making code as approachable as possible. I don't want to exclude people who want to learn functional programming because the learning curve is too steep. I know that there is a happy medium there somewhere.

Happy Coding!

Getting Started with FsUnit

A couple weeks ago, I had a really good chat with Reed Copsey, Jr (@ReedCopsey) regarding F#. Specifically, he recommended using F# for unit testing as a good way to start incorporating F# into your environment.

This makes sense for 2 reasons. First, unit tests are atomic, so they lend themselves to functional-style programming. Second, it isn't production code, so your team (and boss) may be less concerned about impact to the project itself.

Today, I decided to give it a try. Reed suggested FsUnit, so that's where I started. For this first experiment, I decided to TDD into FizzBuzz in C# (which I've done before). Since this is a known problem, I could concentrate on the testing bits.

Setting Up FsUnit
The first step is to get FsUnit up and running. This was pretty easy to do. FsUnit is available from NuGet, and there are some good examples for getting started as well.

I'm starting with a project that already has a shell for the FizzBuzz library:

This is a placeholder method (in C#) that takes an integer as a parameter and returns a string.

Next, I added a new F# Library project to my solution. I called it "FizzBuzz.Library.Tests":

Then I used NuGet to get FsUnit:

This package relies on NUnit under the covers, so it will also bring down the NUnit framework. As usual with NuGet packages, it adds the appropriate references to our project:

Here we can see that both "FsUnit.NUnit" and "nunit.framework" were added.

Note: if you'd rather use xUnit, there is a "FsUnit.xUnit" package.

Since I've been using NUnit quite a bit recently, I'm happy with using the default FsUnit package. This also means that we can add the NUnit Test Adapter so that our tests show up in the Visual Studio Test Explorer:

Make sure you grab the "NUnit3TestAdapter" because FsUnit uses NUnit 3.5.

Your First FsUnit Assertion
To get an idea of how to actually use FsUnit, check out the Syntax section on the "What is FsUnit?" page: http://fsprojects.github.io/FsUnit/

Here's a snippet:

The first section shows that we need to bring in the "NUnit.Framework" and "FsUnit" namespaces. The next sections show the various ways that we can do assertions.

I like the use of "should" and "should not'" using the pipe forward operator. This means that we can create some pretty readable code (similar to Fluent Assertions and contrasting with the standard "Assert" class members).

Here's a first test just to make sure that everything is set up right:

At the top, I created a module to hold the test functions. This name will show up in the test explorer, so I want it to be nice and readable.

Next, we have the two "open" statements that we saw above.

Next, we have our test function. Because we're using NUnit, we want to use the "Test" attribute for this function. (Attributes in F# use the square bracket/angle bracket syntax.)

For the function name, I'm using a sentence rather than a traditional method name. This is also what shows up in our test explorer, so we want to think about this. (Note: this varies from the 3-part naming scheme that I've use previously. I'm experimenting with something different here.)

The body of the function is pretty simple. In this case, we're piping in "1" to the "should equal 1". This is quite trivial, but it will show us that our tests are set up appropriately.

Here's the output in the Test Explorer:

Notice that our module name and the function name both show up here. Things are green which means we're running successfully at this point.

But we need a real test now.

Your First Real Test
So let's TDD into our "GetValue" method. For this we'll create a real test that calls the method:

Now we can see that the assertion syntax makes a bit more sense. Let's look at this a bit more closely.

Notice that I've included "open FizzBuzz.Library". This is the namespace where our "GetValue" method lives.

Next, the test name is "When 1 return '1'". Again, this is what will show up in our test explorer.

Finally, the body of the method shows how FsUnit makes things pretty readable. We call the "GetValue" method with our parameter, then we pipe it to the "should equal" to compare it to the string "1".

This test fails (since "GetValue" throws a NotImplementedException):

We can then update the method with the simplest code possible to get the test to pass:

And now the test passes:

This is a bit of a naive test since we know that our method needs to be a bit more complex than this, but it's a start.

Parameterizing Tests
Just like when we were writing these tests in NUnit in C#, we want to parameterize the tests so that the same function can be used for multiple test cases.

Quite honestly, I'm not sure if this is the best way to do this in F#, but this is one way that I know based on my NUnit experience. We'll use the "Values" attribute on a function parameter:

This changes our function so that it will run with the values of 1, 2, and 4. In this case, we expect that a string version of the integers comes out: "1", "2", and "4" respectively.

Notice that in the "should equal", we need to have parentheses around the "input.ToString()" call. This is because this needs to be evaluated before it is passed as a parameter to the "equal" function.

At this point, just one of the tests passes (which should not be a surprise):

The output shows us that the test that uses "1" passes, but the other two fail. So we can parameterize tests just like we do with NUnit. (Again, I'll keep an eye out to see if there's a better way to handle this in FsUnit.)

The "GetValue" method is easy enough to update to satisfy these tests:

And now the tests pass:

Yes, I realize that we put in two failing tests here, but we're looking more at how to use FsUnit as opposed to TDD methodology.

Completing the Tests
Here are the rest of the tests showing values for 1 through 20:

Because we have parameterized tests, we can cover all of these cases with only 4 test functions. The "GetValue" method has been completed at this point:

So we can see all of the passing tests in the test explorer as well:

Comparison Between FsUnit and NUnit
Here are the same tests written in NUnit (and C#):

If we look at the tests themselves, we see that we have about the same amount of code whether we use NUnit or FsUnit. But I have to say that I like the look of the FsUnit tests a bit better.

Intermediate Variable
In the NUnit tests, we have the intermediate "output" variable. We really need this for readability. Otherwise, we would end up with the "GetValue" call inside the assertion itself. And that would be a bit difficult to read.

In the FsUnit tests, we don't need the intermediate variable. Instead, we can pipe the output of the "GetValue" call straight into the assertion.

Assertion
In the NUnit tests, we have the traditional assertion where we use a function such as "AreEqual" to compare to values. This is code that I'm used to reading, but I have to say...

I like the fluent syntax of the "should equal" in FsUnit. This reads much more like a sentence, and this is the way that our brains work. So it looks a bit better to me. (This is the same reason why we want to consider something like Fluent Assertions as well).

Wrap Up
This is just a first experiment with FsUnit and using F# for unit testing (even if the production code is not F#). I like what I see so far, and I'll be looking into this further.

First, I'll take a closer look at parameterization of tests. If using the standard NUnit approach (with various types of attributes) is the way to go, then I'll stick with that. But I'm also curious if there are other ways to approach this.

In addition, I'm interested to see how things work when things get a bit more complex. FizzBuzz is an extremely simple example. The good news is that there is some guidance available on the FsUnit for NUnit page. This shows how to set up a test fixture (or multiple test fixtures) to work with objects that are in a particular state. This will be interesting to explore further.

My first impression is that I agree with Reed. This is a good way to start incorporating F# into your environment. The tests are very readable, and generally we like to keep tests simple and straightforward. In addition, since it doesn't directly impact our production code, it's an easier sell to the team. Definitely worth looking into further.

Update: I've done a bit more experimentation with mixed results. More to come!

Happy Coding!

Low Risk vs. High Risk

I have always been a low-risk person. I tend to take small steps where even if I fail, I don't have too far to fall. I've been happy with the outcome (for the most part). Right now, I'm looking at a high-risk decision, and I'm not sure if I can take that step.

Where I am in My Career
If I look at where I am in my career (independent consultant and international speaker), it's a vastly different from where I was even 7 years ago (corporate developer in a cubicle). And since I am a low-risk person, if you had told me that I was going to be independent, I would have said, "There's no way that will ever happen." I would have sworn that I always needed the security of a regular paycheck (even if the security is ultimately an illusion).

Career Goal #1: Becoming a Professional Developer
I've been a hobby programmer for many years (really going back to when I was 10 years old), but I didn't think about it as a career until much later. I graduated from college with a B.A. in English. I had a lot of temporary jobs, but the first one I really stuck with was when I worked in reservations for the Disneyland Hotel.

This is when I first started thinking about how to get into development. I thought about signing up for night classes at a tech school, but there was something that didn't feel right about it. So instead, I concentrated on looking for a more technical job.

Small Step
I found it in the communications area the Disneyland Resort. My first project (and why I was hired) was to move data from a DOS-based CMS to a hyper-media system. This was a good job, but it was really a pretty small step: I was moving from one hourly role to another hourly role.

Small Step
As time went on, I was offered a salaried position in the same department (although I was still classified as "clerical" staff). This was another small step with a low risk of failure, and the cost of a failure would also be pretty low.

At that same position, I was put onto a multi-year project with the development team. My co-worker and I were on the user side of the project, working with the various business areas and figuring out the needs of everyone, and then we worked with the development team on what exactly could be done with the resources that we had available.

Small Step
The development manager saw something in me (I'm not exactly sure what it was), but about a year into the project, she offered me a junior developer position on her team.

And that's how I became a professional developer through a series of small, low-risk steps. I might have failed anywhere along the way, but none of the steps would be much of a set back. But it also took me 6 years to get to that point.

The good news is that the team was awesome. I worked with very good senior developers who were willing to share and wanted the team to move forward. That's how I was able to grow and become the developer I am today.

Small Step
I worked as a developer for the Disneyland Resort for 11 years. It was time for me to move on to something else, so I took a job at a startup.

You're probably thinking that going to a startup was the exact opposite of low-risk. But it really wasn't. In this case, the startup was about 4 years along (so it wasn't brand new). In addition, I knew the CEO (he's someone I used to work with), and on top of that, one of my former co-workers had gone to work there.

So this was another small step, and I got to work with some amazing people while I was there.

Small Step
Probably the biggest step I took along my developer journey was when I decided to leave the startup (this was when it was acquired by a larger company after I'd been there about a year and a half). Because of my current situation, I left that position without having another job.

This sounds like a *huge* risk. But it really wasn't. I was well paid at the startup, so I had about 6 months of living expenses readily available. The job market was also good for senior developers, so I knew I wouldn't have trouble finding a new job.

Small Step
After leaving the startup, I looked for jobs where I could include my love of speaking (see Career Goal #2 below). I explored a few different options including working for a boutique consulting company and working as a developer evangelist. I spent a bit of time interviewing with different companies, but these didn't lead to anything. Fortunately most of the interviews ended with an agreement that it wasn't the right position for me, so I didn't have any huge disappointments. Also, going through this process helped guide me away from a direction that wasn't going to be productive for me.

Small Step
From here I started pursuing other things (see Career Goal #3 below). Some of those things didn't work out. But because of my situation, I was able to pick up a 6-month contract with no problem. That re-filled my bank account enough for me to be comfortable, and I was able to move on to other things.

Result
All-in-all, this was an 18 year process (crap, I feel old now). But it was a series of small steps that got me to where I am today.

Career Goal #2: Speaking at a Professional Conference
While I was working my corporate developer job, I had the chance to attend professional conferences. I've always been a bit of a teacher by nature, so I had a dream (more of a fantasy, really) in the back of my mind that I would like to speak at a conference one day.

What held me back is that I didn't think that I had anything of interest to share.

Small Step
There were some interesting techniques that I had found useful as a developer, and I would share them with other people on my team. Eventually, this led to me sharing things in meetings with the entire team. This was my first foray into speaking. But I still didn't think I had anything to offer the world at large.

Small Step
One day I was listening to an episode of .NET Rocks, and they were talking about how there needed to be more people talking about beginning and intermediate level topics. (I've written about this several times before). I signed up for a local code camp and did my first presentation in front of strangers. The risk was low since it was really just a handful of people who I didn't know. Failure would not be a huge deal. This was a free event to attend, so it's not like anyone was going to ask for their money back if I failed.

This was January 2010.

My presentations went well, and I was hooked. I really loved helping other developers, and I really loved watching people learn.

Small Step
Signing up for code camps is easy and low-risk. I could sign up for the So Cal Code Camps (which had 3 a year at the time) and the Desert Code Camp in Phoenix, and there was no fear of rejection (since they didn't reject anyone).

The next small step was reaching out to user group leaders and asking if I could speak at their events. Here's the first awkward situation that I remember: a user group leader from the next county over was speaking at the group that I normally attended. During the break, I asked him if I could come speak at his group. I really felt like I was pushing myself on him, and he didn't seem very excited to put me on the schedule. But he put me on the schedule anyway (for 6 months out). 3 months later, I was at the Desert Code Camp in Phoenix, and he was also there. He had seen me speak that day and asked if I was interested in coming out to speak at his group. I sheepisly mentioned that I was already on his schedule.

As I spoke at more places and met more group leaders, it was easier for me to ask them if I could come out and speak at their groups.

Small Step
After speaking many times, the dream of speaking at a professional conference didn't seem quite as out of reach as it did originally. The next small step that I took at to start traveling away from home a bit.

Up until this point, I had been speaking at free events: user groups and code camps. The next step for me was to speak at an event that people had to pay to attend. I submitted and got accepted to Nebraska.Code() last year. This is a regional conference that had around 500 people that year.

It was a risk because I had to spend quite a bit of money on travel (previously I had driven everywhere). And there was also a risk that I wouldn't do a good enough job. But I wasn't too worried about this because I had been speaking for 5 years, so I was more or less comfortable with the process.

This was March 2015. 5 years into my speaking adventure.

From here I submitted to more and more regional conferences. Some of them accepted my talks, some of them rejected my talks. This was my first experience with rejection. It was hard, but I'm more used to it now (I don't think rejection ever gets easy).

Small Step
The next step wasn't planned. Among the people that had seen me speak, I would get requests to come speak for their company. This was another risk. Now people were actually paying me to come speak for them. But at the same time, it seemed like a pretty small risk. If I really blew it, they wouldn't pay me. But that was about it. (And this ties in to Career Goal #3 below.)

Small Step
I really wanted to get my foot in the door for a professional conference. I knew this was harder because people were paying literally thousands of dollars to attend, so the organizers can't take any chances with the speakers. I had tried submitting to several conferences, but I was rejected each time.

I was fortunate enough to have someone recommend me, and I had the chance to speak at Visual Studio Live! in November last year.

This was probably the most nervous that I had ever been as a speaker. Up until then, I wasn't too afraid of the consequences of doing a bad job. But this was my shot at the "big time". If I blew this, then it could impact my ability to speak at other conferences at that level.

I did a lot of practice, and test-drove my presentations to user groups for 6 months leading up to it. That work paid off, my presentations went well, and I've had a chance to speak at that event a few more times.

Small Step
I feel like I turned a corner soon after as I was accepted to speak at NDC London in January this year. It was a big step to travel internationally, but I felt like it was a small step from where I was. After I was there, I was a bit worried that my content really wouldn't fit based on the other talks I went to, but I had a good turnout and very good response.

In addition to London, I also got a chance to speak at NDC Oslo. I'll be going back to NDC London in January 2017, and it looks like I'll be at another London conference in May 2017.

I feel like I've turned a corner because I've had to decline some conferences because I had already accepted the invitation to speak on those same dates somewhere else. I have become careful about my submissions to make sure that things don't overlap. I still get rejections from events I really want to be at, but the acceptances seem to outweigh those for the most part.

Result
I'm really happy with where I am as a speaker (I've spoken at 31 events so far this year). Ultimately, it took me 6 years to go from speaking at my local code camp to speaking at a professional conference in Norway. I know many people who have taken a much shorter path (and I'm happy for them). But I've gotten to where I am with a series of low-risk decisions.

Career Goal #3: Teaching Developers
Obviously my goal of being a speaker and my goal of teaching developers overlap quite a bit. But no one makes a living by speaking at developer conferences (okay, there are a few people, but it's an extreme minority).

After I left the startup (see Career Goal #2), I really wanted to see if I could get into a job as a developer trainer. I knew a few people who were making a living as trainers, so I tapped into them for advice and see if I could find a company that I would fit into.

Small Step
One of my friends had done some work for a particular training company and thought that I would be a good fit there. She had actually seen me speak pretty early in my speaking adventure and had told me how impressed she was with my preparation and presentation.

This was a low risk decision for me. I had my 6-month living expenses buffer, so I could afford to take some time with the process. The process took a bit longer than I had hoped (and that's why I ended up taking the 6-month contract job).

Eventually, I got accepted and signed up with the company. And they couldn't get me my first class. Unfortunately, this was at a time when classroom training was in decline due to online offerings.

I invested quite a bit of time in this pursuit that didn't work out. But ultimately, I wasn't out anything other than time. I wasn't in a worse position than I was before.

Small Step
After the 6-month contract, I decided to try again. As a next step, I signed up to do a course for Pluralsight. This was really a brand-building step. The goal was to get my name in the course catalog alongside well-known people. That would hopefully give me a bit of a credibility boost.

What happened instead was that my course did unexpectedly well. This turned out to be a good financial situation for me, and I was able to do more courses.

Again, this was a fairly low risk situation. If my course didn't do well, then it would be right there alongside many others. And there would no negative impact.

In Progress
This goal isn't quite completed. I'm working on getting a steady income through in-person teaching engagements, whether workshops, seminars, code reviews, or mentoring. I'd really like to be in a position where I get to help developers, watch them learn, and make an income that feels stable.

Right now, I am stable financially, but I don't expect my current situation to last much longer, so I'm working on building my brand and speaking at lots of events so people can see that I am really good at making complex topics easy to understand.

It's taken me 4 years to get to where I am now, and I expect to continue.

High Risk Opportunity
If you've made it this far, you're probably wondering what the point of this article is. Recently, I've come across a potentially life-changing opportunity. But it is also quite high risk.

This isn't specifically career related (although it will impact my career). And I'm really not sure if I can make an active decision on this. I keep running through the scenarios in my head.

If I do nothing, I end up staying where I am. I'm not particularly content with this part of my life, but I've kind of resigned myself to how things are.

If I take the risk and fail, I end up negatively impacting this part of my life.

If I take the risk and succeed, I may end up in an awesome place, or I may end up finding out that it's not where I really want to be (or I'm not prepared to handle it). And it would not be possible to get back to where I am today.

I've never been the high risk person. My brother is. He's the kind of person who would jump out of an airplane and look for a parachute on the way down. I'm a bit of the opposite.

I have had substantial changes in my life. I've gone from corporate developer to independent consultant. I've gone from speaking at local code camps to speaking at international professional conferences. But these have all been through small steps.

I don't know if I can make the high risk choice. There are no small steps here. And if I make no choice, the opportunity will go away, and life goes on. To make things more interesting, I'm not thinking very clearly since I'm exhausted from conference travel and a bit fuzzy from illness and cold medicine.

[Update Jan 2017: Update: Low Risk vs. High Risk.]

[Update Aug 2017, I took the high risk path: Taking the Risk.]

And yes, this doesn't have anything to do with coding, but in addition to being developers, we are also all human.

Jeremy Chats with Scott Nimrod (Bizmonger)

Scott Nimrod (@Bizmonger) and I had a conversation earlier this week. We talked about a number of things, including living as an introvert, code quality, developer ego, and functional programming. It was a pretty long conversation (close to 2 hours), but we shared some great ideas.

You can watch it on YouTube: Talking to Jeremy about software craftsmanship and F#.

Or you can watch it here:



I met Scott at NDC London back in January, but I first heard from him in September last year when he left a comment on the .NET Rocks episode that I was on: Becoming a Social Developer with Jeremy Clark. I still remember Carl Franklin coming up to me at NDC London and saying that I needed to meet Scott.

We just had a brief conversation then (and we've had some Twitter chats since then), but it was great to talk at length this week. If you'd like to share in two developers talking about stuff, then be sure to take a listen.

Happy Coding!