I Want to Speak. What Topics Are Best?

We know that community conferences like That Conference and Codemash fulfill multiple roles in a technology community.  They provide networking opportunities, sure.  But they also provide educational sessions for people to learn new technologies, transition between technologies, or enhance their knowledge within their own skill set.

It's easy to figure that the topics at a conference run the gamut of all possible talks, and that you should just speak about what you know.  To first order, that's sort of true.  But not all topics are created equal, and I thought I'd share what I've found most useful, when attending conferences.

For me, conference talks fill that space between blogs about technology, and books. They're the perfect hybrid of dynamic, up-to-the minute content that books don't have, coupled with the story-telling dynamic presentation format that blogs just can't quite reach, most of the time.  Books work well as references.  Blogs work well as permalink content that can be searched on the web for little bits of esoteric information and deep dives.

If that's the space that conference talks generally fill, then what topics to I find most useful? The topics I look for as an attendee are those talks that

• Help people get started
• Help people transition
• Help people improve

If you're a prospective speaker and are thinking of submitting a talk, here are some ideas that fit the bill:

Introduction to "X"

Obviously, this talk is to help people get started.  In an introduction, you start people with the basics: what open problem this X technology or platform solves, why X is a better solution to those problems than other solutions proposed in the industry, how to get started.  In this type of talk, it's more of a survey designed to help people completely new to this technology, or maybe new to technology in general.  Advanced features and deep dives are unnecessary, and you won't get extremely detailed questions, so this type of talk may favor the new speaker.

"X" for the "Y" Dev

This type of talk is very similar to the Introduction to "X" talk described above, but it has a much more targeted focus: help someone transition from an existing technology to a new one.  Every technology has its way of looking at things and those memes are not obvious.  It's easy to write C# that looks like Fortran.  

These talks tend to have titles like "F# for the C# Developer : Learning to Funtional After Objecting All Your Life" or "TDD for the PHP Developer... Really!"  The point of these talks is still introduction, so the talk can't dive deep into the target technology, and you spend a great deal of time arguing by analogy from one language/platform to the other.  This type of talk favors the speaker that has made such a transition in the past and has good handle on what it takes to be successful with the new technology.

New Features in "X"

Technology changes all the time.  If you happen to be working with the next version of some product, there are people that need your guidance.  These types of talks help people grow in their current skill set.  You can assume a base knowledge for your audience, and sometimes get into really cool demos, as new features are generally put in to have a bit of a "whiz-bang" factor.  Here, you also have the ability to take a deep dive or two.

Top "N" Lists

This format can feel pretty tired, but I personally like seeing these talks.  These are talks like "The 5 Best Underused Features in Angular" or "9 Stories from the TDD Front Lines".  What I like is that while the presentation is centered on one particular topic or technology, you can tell quite a few disparate stories without the need for segue.  It's the presentation equivalent of a book of short stories, and if one doesn't really appeal to you, you wait five minutes and see if the next one does.  Also, some of the items can be beginner topics, and some can be advanced, so you can have a fairly diverse audience.

Real-World "X"

Probably my favorite type of topic.  If you are a frequent practitioner of any particular technology, you've run into situations where things didn't work out the way they did in the demos (Entity Framework? I'm looking at you!).  Your experience in the real world can save your audience time and bring some realism to a topic beyond the hype of the company that promotes it.

Remember, Call for Speakers for That Conference opens soon.  If you want to come out and share your experience, maybe one of these topics is right for you!

How to Be a Great Speaker

Full disclosure: I am not a great speaker.

I have spoken at precisely one user group and one community conference.  I love community, however, and want to offer my perspective on what makes a great speaker from a frequent audience member.  These are things I strive to do in my talks, but still don't have down.  Each one of these tips has personally affected my enjoyment (positive or negative) of a talk I've been to in the past year.

That Conference call for speakers opens in about a week, so you may not be at this stage yet, getting your abstract ready and such, but keep this handy for when you're preparing for your big day on the conference stage.

Practice, Practice, Practice.

This should probably go without saying, but the speakers that seem to do best have everything down. They've rehearsed their demos over and over.  They have their slide transitions down.  When its clear that you're winging it, unless you have a true gift for extemporaneous speaking (you probably don't, even if you've always thought you did), you lose your audience really fast.

Never Complain About the Conference Setup.

I was at a conference recently, and one of the speakers was having trouble moving his mouse in the limited space on the lectern.  That was pretty obvious from his frustrated mouse movements, but on top of letting the frustration show, about every five minutes, he would articulate that frustration. As an audience member, there was nothing I could do, but it made the talk feel like a downer.

Here's the thing: the audience doesn't care about excuses.  They don't need to hear why things aren't smooth. Make them smooth.  If you can't, move on as best you can.  The show must go on.

Give the Audience a Progress Bar.

This is a tip that hits me subtly, but no matter how rapt my attention is during a talk, at one point or another, I end up thinking, "Gee, how much is left in this talk?"  If you put this information right on your slides (Slide 21/44), the audience never has to move their eyes from your presentation, but if it's not on there, then the listener may switch on their phone, see the time, but also see a tweet from a good friend and think to respond.  At that point you may lose your audience member and not get them back.

Never Forget Your Fans.  

Good speakers are public figures.  They are authors, actors, and performers.  Just like the most famous of those, people will follow you.  These people are fans.  On twitter, they will follow you. IRL, they may follow you.  You may see them at every talk.  They're probably not even stalkers. Note that you might be a huge inspiration to them, and they may be starstruck.  Yes, over little ol' you. Embrace that.  These are like-minded folks in your tribe.

Never Complain About Your Time Slot.  

I know all time slots are not created equal.  Speaking over the lunch hour, or maybe very early in the morning when people were out the night before, or maybe last in the afternoon, when everyone's brains are hurting and full - yeah, I get that those time slots have issues.  You may not get the full room you'd hoped for.

But never say that to the audience that is there.  They have given up their lunch or come exhausted to give you the gift of their time and attention.  To learn from you.  Don't insult them.  Remember, you are happy to be there.  You're changing their lives.

Never Diminish Your Subject Matter.

In a recent presentation, I heard a speaker introduce a bit of their presentation by saying "This isn't very exciting."  Really?  Then why include it?  Actually, I haven't seen it, so it's totally exciting, to me.  Don't tell me what I should and shouldn't find exciting either.  I'm in tech.  I like lots of weird things.  I like to learn, too.  I'm interested.

Also, your material was good enough to get you a speaker slot to talk to your peers.  Never sell your material short.

Don't Recognize Comings and Goings.

I've seen lots of speakers do it.  It's like a reverse heckle of people who are coming in late.  "Thanks for gracing us with your presence."  Or "Ok, now that you're here, we can start."  No kidding, I've heard people say this.  People coming and going may be obeying the Law of Two Feet and coming from another sessions they knew wasn't going to be as awesome as yours.  Maybe they are leaving yours because they thought it was going to be more basic than you're aiming.  Maybe all the bacon has their stomach in a knot.  You don't know, so don't give comings and goings any recognition.

There is an exception to the rule.  If you have a packed house (good for you!), people who walk in may assume there are no more seats left and stand against the wall or sit on the floor.  It's reasonable to interrupt what you're saying to let people know that they can come closer and fill in gaps up nearer the speaker.

Don't Criticize Other Speakers.

I've heard speakers actively criticize other speakers.  As an audience member, that does nothing for me. But praising other speakers?  I love when a speaker does that. I'm always looking for great new speakers to check out.  Guide your listeners toward other great speakers.

Make It Easy to Follow Up.

Given that your material may create fans, followers, or folks with interest in what you have to say, make yourself available.  If you Twitter, then offer your handle.  If you have material to offer from your presentation, make sure you let the audience know how to reach your material, whether it's on Slideshare, GitHub, whatever, make sure you offer all links in some kind of url shortener.

Those are just some tips I wanted to share with speakers and prospective speakers.  Given that the Call for Speakers for That Conference opens up soon.  Get out there and speak!

What is a Community Conference?

I know I post a lot about community conferences, but I never really talked about what a community conference is.  Like with a lot of things, there may be many definitions out there, but this is how I think about them.

For me, a community conference is community-driven.  It's grass-roots.  A few people in a certain geographic area, passionate about a particular thing, get together and decide that there have to be other people like them.  People that want to get together and talk about things.  People who want to learn and teach and communicate and network.

Probably some of those people already do this stuff at industry conferences.  Conferences like Build and DevConnections and TechEd for the Microsofties out there are a big deal.  Except not everyone can attend those conferences.  The price tag on them is simply too high.  At a couple grand for a ticket, maybe another grand for the hotel room, air fare, transportation, per diem for food?  It all adds up to a fairly expensive prospect for small to midsize companies when it comes to training.

And what do you get for that?  Sure you get the national platform, and some of them give out pretty nice goodie-bags with expensive tech-gifts in them (which is basically a way for you to get your company to buy you something you wouldn't buy for yourself), but you also generally get only the broadest of pictures.  In the case of Tech Ed, you get broad strokes and marketing spiels.  Many people who are there were sent, and may not be all that into it.  You have lots of managers and senior folks there who may not be getting much out of it, but are there as a perk for their job.

In contrast, a community conference is organic and attended by people who really want to be there. It is truly of the people, by the people, and for the people.  The conference is set up as a not-for-profit, so the ticket cost can be as low as possible.  This allows just about anyone to attend, even if they have to do it on their own dime.

Because anyone can afford to attend, it truly means that anyone with a passion for the conference material can be there, and those are the people you want to be there, both as attendees and speakers. People who are enthusiastic about the subject matter and won't wander off mid-conference to play golf.

Because it's not-for-profit, community conferences tend to be run by organizers in their spare time.  In my experience, however, that doesn't necessarily mean that things are thrown together or that there's no attention to detail, but I think you do lose some of the polish you'd get if you were paying people an annual salary to set up a conference.

In a lot of ways, however, that's part of the fun, knowing that the conference is as good as the community wants it to be, because they have to pitch in to make it special.  It's the difference between consuming and making.  It's possible to consume an industry conference, but you get to make your community conference. You don't get the high-priced goodie bags, but you get a very professional conference, with solid information, delivered by some of the most outgoing technologists you're likely to meet.

Of course I've said that community conferences changed my life, and I truly mean that.  Codemash is particularly well run, but it's pretty far away for me.  That's why I work to run That Conference. If I can help make that change in other people that happened in me, every second I volunteer to putting on a great conference is worth it. In case you didn't know, That Conference is a polyglot (any platform, any language) technology conference held in late summer at the Kalahari Resort in the Wisconsin Dells.  Check it out!

That Conference embraces all folks with a love of technology with open arms.  Hardware?  Software? InfoSec?  Data?  We have sessions on all things tech.  With a ticket price of around $400, it's way cheaper than the big conferences, and for those of you in the Illinois, Wisconsin, Minnesota areas, it's only a short drive away.  And if you stay at the hotel, bring your family and they can enjoy the waterpark as part of the room deal.  Better still, pick up a family ticket and teach the little ones your love of technology.

I would love to see you there.  If you do manage to make it out, come find me!  I'd love to meet more folks in this area that share a passion for technology.

You Should Leave Your Job

Here we are again.  I'm talking to you.  It's just us here, and no one is listening.  Clear your mind.  Take all your preconceived notions about what you were going to do today and toss them out the window.  What I'm going to say may shock you.

You should leave your job.  Soon.  I mean it.  Start looking today.

Look, you know and I know that life is too short to hate your workday.  Let's make a huge assumption: 8 hrs of work a day + 30 minutes lunch + 30 minutes * 2 for commute = 9.5 hrs of your 16 hour day.  That is 60% of your useful day.  If you eat or work longer or are further away from work, the numbers get worse. The numbers get better if you're willing to skimp on sleep for a longer useful day.

You know that every keystroke you give someone is a gift, right?  In this great presentation, Scott Hanselman suggests you check this out.  Are you giving the gift of your limited keystrokes to the right people?  For the right reasons?  Do those keystrokes match up with your values?  Are you giving gifts that others want and only you can provide or are you buying generic gifts that the recipient will ooze with "meh" over.

I've seen your situation before.  You're dark matter.  You're a 5:01 developer.  When you got to the organization you're in, you loved the first project you were put on.  You were hired specifically for that project, so it met your idea of what you'd be doing when you signed on.  You put in lots of time learning, showing people you were excited, showing you could be counted on to deliver.

You were enthusiastic.

But that was years ago.  That was a couple CTOs ago.  That was a couple technology strategy direction changes ago.  The organization has moved on and you've adapted to provide it value, but maybe your day-to-day is not what you wanted to do.  Shoot, it's a convenient commute.  The compensation's right.  Family health matters made it inconvenient to take on a change at that time.

You like what you did at the organization in the past, but now there's very little to do.  You're in maintenance mode for the product you were hired to build.  Management appetite for new development is nil because of cost cutting.  You've been told to keep the lights on.  Leadership doesn't want to spend time adding new features because they would rather buy a replacement system, but never seem to actually complete the research to buy that replacement, resulting in continued use of subpar tools, and missing opportunities to sharpen developer chops.

You're a developer, but because of "budgetary constraints", the organization is not allowed to staff a team that develops software appropriately.  So you are doing business analysis or QA, because there's no one in those roles.  In agile teams that's something that's expected of everyone, but your projects aren't agile.  You spend a lot of time writing up documentation that never gets used or read.

The excellent team you signed on with?  Excellent teams are an unstable equilibrium.  If you were on a tiger team of development that does everything right, did your organization split it up to "seed" the talent in multiple places, not realizing that it's the team that did things right, not the individuals?  Great people working on excellent teams get recruited to join other excellent teams.  So maybe your team fell victim to entropy.

So that team is no longer.  Maybe that was many reorganizations ago, before many different sets of leadership came in and tried to optimize output of a fixed group of resources.

Maybe your organization favors butt-in-seat over other productivity metrics.  For that reason, you can't work from home, contributing to that feeling of wasted commute time.  Collaborative technology is discussed, and maybe even experimented with, but because not enough people are using it, it's never optimized.  Time-shifting is not allowed to enable you to work at your most productive times.

Maybe you're on a support rotation.  That wasn't in the original sign-on agreement, but "You know... We all have to be team players", and you don't really mind since it's not all that often.  Although when it does, even though comp time should be an expectation, it's never discussed.

Yeah, maybe this describes your situation.  Maybe only some of it does.  If it does, however, you should leave your job.

But maybe you're not convinced to move.  You're too complacent.  You're comfy.  This job thing is a solved problem and you don't think you'll ever really need to look for another one.  You can coast out your career on your current skill set.

Maybe, but I've put together a few signs that it might be time to consider moving on.

Signs

• Don't like working on what you're working on
• Don't like who you're working with 
• Don't like your immediate manager
• Don't feel as if the discourse is civil or nonconfrontational 
• Don't believe in management's vision or goals
• Don't believe in your management's ability to make good decisions
• Don't feel valued for your contributions 
• Don't feel the tasks in front of you are very exciting
• Don't feel focused enough on any one thing
• Don't have clear reporting structures; have overmatrixed teams
• Don't feel like your organization can prioritize
• Don't feel like productivity is as important as appearance
• Don't feel like the organization is moving forward quickly
• Don't feel like the organization makes data-based decisions 

I read the following as symptoms of organizational dysfunction.  To change any one of these is like moving a cultural mountain and require clarity of vision and charismatic leadership from the very top.  I don't think that mid-level management in any organization can change these effectively.  If you recognize a lot of these, it may not be just your position in jeopardy; the whole company may be in trouble long-term.

Symptoms

• Very peaked/deep org structures indicate a problem with reporting.  Need a low ratio of managers/doers.
• Lack of information flow
• Lack of recognition
• Lack of celebration for hires or promotions
• Lack of visible employee enthusiasm
• Lack of unity of processes across divisions
• Too many junk drawers 
• Too much reliance on transition plans (which don't work) 
• Lots of Not Invented Here silos of experience 
• Headcount is kept flat regardless of technical investment or debt reduction 

So if any of this resonates with you, consider leaving your current gig.  Fast.  There is too much demand in the development industry to spend time in an organization where you're not happy.  Some organizations just don't get it, but there are plenty that do.  Find one and let the ones that do hire unenthusiastic, unmotivated shlubs to barely work until they go out of business or get sold to a competitor.

If all of this resonates with you, call a recruiter today.  Shoot, call me.  I know enough recruiters and folks at good places to be a good resource, and I'm happy to help you find your passion.  If you just want to talk, I'm here too. You'd do well to find yourself a mentor, too.

And if you're happy with your gig, good on you.  Come on out and be part of the community.

I just want you to be happy.  Yes you.

How to Write

I seem to have been writing a lot lately.  Just the other day, I put out about an 1800 word essay on my blog. I did this because it’s something I've been thinking about, and I follow Scott Hanselman's philosophy on multiplying your effectiveness (it's a 40 minute presentation, but it really is worth your time, no matter what your field).  One of the tips boils down to this: if you have an opinion to articulate, and you’ll want to say it to many people, it’s worth it to spend a little time to polish your thoughts, write it down, and then you can send it to many people at once, and have it available to refer to.

I don’t know how many times I've posted the same points or ideas to Facebook, talking to different friends. The barrier to entry is so darn low to hosting your ideas permanently online that there’s absolutely no reason not to publish your thoughts.  Blogger?  Free.  Tumblr?  Free.

And I've been doing that a lot more.  It occurred to me that I should be encouraging more people do the same, but then I figure they will want to know, “How do you write?  I have thoughts, too, but how do I actually get them on (electronic) paper, organize them, and make them sound good?”

Here’s my secret: I don’t.  Well, not really.

My recipe for writing is as follows:

• Have some thinks
• Write them down somewhere online (as I mentioned, there are free platforms out there)
• Edit (this step is entirely optional)

So let’s break it down:

Have Some Thinks
You'd think this was the hardest part.  I do.  I mean, I did.  Maybe you have this idea that you have to have an original thought, and it has to be a well thought out thesis, or that it has to be so well-researched that it has to be bulletproof.  Here's the real truth, however.

It's a blog post.  It doesn't have to be your Ph. D. defense.  It doesn't have to stand up against a tide of questions or a barrage of counterarguments.

Think about the last argument you had with a family member where you had a difference of opinion.  You probably went back and forth and the conversation diverted here or there into topics unrelated.  Think of a blog post as your opportunity to get your side of the conversation out without interruption.  So you can get your whole opinion out without being interrupted.  This is a great way to get your opinion out, get it off your chest, and maybe even continue a constructive conversation.

Write them down somewhere online

Ok, these steps are so easy I can give you a recipe:

• Pick some blogging platform. I obviously use Blogger, but Tumblr, Wordpress, whatever.  Just pick a free one that lots of other people are using.  
• Pick a sweet username or blog name.  This can be your name or your topic, something hipster, or something classical.  Anything that you feel represents you and what you're most likely to write about
• Write a little test post.  My first post on my first blog (this is my third) was a trivial little nothing post that I can still see and occasionally look at as the genesis of ... wow, 10 years of writing.  Don’t share this test post with anyone.  Just know it’s there.  Let the fact that you've published your thought to the web sink in.
• Next, start getting those ideas out.  Whenever you have something long form to say to someone, say, in an email, blog it instead and send them a link.  Put together a lot of drafts and have them ready to add to.  Whatever you need to do, get those ideas out of your head and onto the page.  Bullet points, fragments, whatever.
• Flesh out a post.  Click publish.  Repeat.  It's not so hard.  Eventually, the problem will be that you have so much to say that you don't have time to say it.  Trust me.  It happened to me, too.
• Publishing gives your thought a permalink, somewhere you can always refer someone to.  Another big benefit to doing this is that you can refer to your former thinks whenever you want without having to rewrite them.

Edit (optional)

If you want to, please feel free to edit your thoughts.  Take some time to proofread them, spell check them, check them for grammar.  Make sure you don't say "like" too many times, or whatever speech pattern you have that doesn't translate well to the written word.  But remember, editing is optional.  Here's why.

Ok, so you’re thinking your thoughts are all disjointed, and that they need editing.  Maybe that's true, but don't let that be the reason you don't publish them.  Perfect polished thoughts can be left to the philosophers and linguists who look to distill ideas into their perfect essences.  Your idea doesn't have to be perfect or bulletproof to have value.  Heck, you thought it, right?  It was good enough for that email conversation you were going to have.  Why not have that conversation with more people?

Afraid you might be wrong?  Well, maybe better to find out than to be wrong forever.  Worst thing that happens if you're wrong is that you learned something.  Worried people won't think you're a genius?  Here's a hint.  They already don't.  Don't worry.  You're not a genius.  But you are valuable, and your opinion matters.  You can have great thoughts even if they're not entirely fully formed.

So get your voice heard.  Speak up.  And then tell me, because I want to hear what you have to say.

Takeaways:

You’re going to have opinions, so don’t be shy.  Share them.  Write them down.  Put them out there.  Share your knowledge and talent with the world.

Or at least with me.

Group Coding, Benefits and Observations

A few years ago, I started up a weekly tech seminar in my organization.  We do everything from demos of new technologies, to sharing technical issues and solutions we found to them, to watching videos from the web of our favorite speakers on technical topics.

There's another thing we like to use this time slot for: group coding sessions.  We take a simple problem from Project Euler, and we code it up as a group on a projected screen.  The sessions allow the developers to share tips on tools, talk about the right seams in code, and

Someone asked me why we would code in a group, and I sent them the following

Benefits

Here’s the benefits as I see them:

·         It’s great for everyone to get to know each other. 
·         It’s great to work with other people and learn how to develop in a more collaborative environment. 
·         It’s great to create a more collaborative environment. 
·         It’s great for everyone to know everyone else on all dev teams.  Especially as some groups are more segregated than others.
·         It’s great to see how people use tools differently, as we all use things differently and become more productive as we work together on things.

So from an organizational standpoint, it’s all good.

That's what I said.  The details are a bit more complicated.  Let me talk a little bit about some overvations I've made and lessons learned.

Results

We've seen great results from working together in these sessions.

It's no secret that I am a big fan of NCrunch (I tweet about them from time to time), and that and ReSharper are two of our key dev tools.  We got enough licenses for every developer to use both, but people weren't really using them.  After seeing the tools in use as we do a test-driven style example, people come up and ask for their license.  Spending a little time coding together has meant that we get a better return on the tools we bought, in terms of usage (hopefully they learn to use it wisely).

We usually send out the solution after the exercise, so everyone can work on any finer points after the fact. We've seen people dive deep into an optimization, or work on finding analytic solutions to brute force problems.  It gets people thinking about something other than the features their day job offers them, and they seem to be really excited about these other opportunities (I'm using the proactive follow up as evidence here).

Further, you get some peer recognition.  Everyone contributes some code, and those people who can code get the kudos of their peers.  Better still, we've found hidden talent and enthusiasm in all our colleagues.  It's great to know who can do what, and it's great to give them props for doing so in a group.

I don't care who you are.  When you start out, coding in front of people is hard.  You have to let go of that ego.  You have to silence that little voice of doubt.  You have to get past freezing up.  And it's better to do it here than, say, during a job interview or a more important coding session at a conference, meetup, or Hackathon.  And everyone does it.  It's harder for some than others, but you see them grow in confidence, both in themselves and in their code.

One Big Observation

One thing that kills, absolute kills a group coding session, and that's negation.  Someone else writes a test and implements a method, and the first thing the next guy does is delete the body of the method and put in a pet implementation.  Maybe it's better; maybe it's not.  I've seen both, actually, and what is most important here is a concept straight out of the improv comedy world.  I know it's a weird place to apply the concept, but one of the core concepts of improv is that you never negate anything anyone else does.  You build on it. You manipulate it.  But you never simply say no.

Imagine a comedy sketch at The Second City that goes like this:

Milli: "And now I'm a T-Rex trying to make a peanut butter and jelly sandwich in a military cafeteria."

Vanilli: "No, you're not.  You're eating a pizza on the set of The Sound of Music."

And where does Milli go from there?  Vanilli has just taken the momentum out of the skit and turned things over on their head.  The same thing happens in a coding session.

The trick of great Improv is "Yes, and..."  In the Milli-Vanilli sketch above, Vanilli can do this by saying, instead:

Vanilli: "Yeah, and I'm a four-star general who walks in and does a double take as you cut the crusts off your sandwich."

Momentum saved, and the skit moves forward.

Yes, And 

So do this while coding.  Sure, someone may have just taken a misstep.  Maybe you see a more optimal way to do something.  Maybe you think your way is cleaner.  Keep that to yourself and don't negate what someone else has done.  Add to the example as is.  One of a couple things may happen. The example might evolve until it's obvious why your way might have been better.  Or you might learn something new.  Either way, I've observed that sessions that are allowed to evolve dynamically are more enjoyable.

Conclusion

I happened to be talking to Clark Sell on Friday during our That Conference call.  He's currently reading a book on Improv Wisdom, and said something very similar.  I haven't gotten to read the book yet myself, but I recognize the rule on the cover... "Just show up."  Which has a familiar vibe to what draws me to the tech community.  A big part of getting better is speaking up, doing, and making things happen with the people around you who also show up.

So get your code on.  Do it now.  Do it with your co-workers.  Just because you're dark matter, doesn't mean you don't matter.  You can do it.

What is My Passion?

So after I wrote about Finding Your Passion, I thought I might write a little about my journey towards finding my passion.

Note, I have many passions, the greatest of which is learning new things.  This means that any job I take can be my passion, as long as it changes frequently enough to be challenging and educational.

I love finance.  I think the whole industry is fascinating.  I have always been involved in investments firms on the buy side, but I find everything fascinating.  Equity, fixed income, derivatives, pricing, valuation, research, automated trading, risk modeling, economics... The field is huge and vastly entertaining.

I am lucky enough to currently hold a position in a financial services company, developing software, improving processes, helping the business find technology solutions, helping integrate and update vended software, managing projects, leading teams, educating and inspiring co-workers, and asking good questions.  I like what I do, and I love my colleagues.  I could easily do it forever.

So what in the world would ever make me want to leave?  I have been thinking about what kind of things I want to accomplish, so here are some things that really excite me.

I love educating people.  Not just when I was a teaching assistant in grad school, but in every organization I have been in.  I've always pushed new ideas and relentlessly developed myself and others, but in my current organization, I started a program three years ago for my technology team to meet weekly to discuss libraries, patterns, trends in tech.  I present frequently, but almost everyone that attends gives a talk or two.  We are creating new speakers, and good community collaborators.

Recently this has come through most importantly in my volunteer work with That Conference.  I write content for a lot of communications.  I'm responsible for the emails to attendees, to speakers, to sponsors, a great deal of the printed program, and the welcome letter.  In a very real way, I am privileged to be a large part of the public voice of That Conference.

And I love it.  You know that Community Conferences changed my life, and I'm hoping that my involvement in That Conference will change the lives of other people.

Technology that saves people's lives, or saves them time, or makes them happy also is really intriguing to me.  Possibly nowhere else is this present in the idea behind the self-driving car.  I've blogged about the benefits of that in the past, but the short answer is that self-driving cars will save lives, save relationships, and save valuable natural resources.  I'm dying to make this a reality, and if there was ever a chance for me to help out, I'd be very interested in contributing. Legal, political, software, being involved in town halls, anything.  Let me help.

Something that leverages my love of data would be awesome, too.  Recently I did a little statistical analysis of the game of cards called War.  I did this because I wanted to learn to use the statistical language R, and I was honored to be able to speak about my experience at the Lake County .NET User Group.  Math, statistics, and data are awesome.

I'm not just a content generator, either.  I love to edit, to polish, to finish, and to critique.  I've done a whole bunch of technical editing for Pearson, Addison-Wesley, and Prentice Hall over the years.  I am quite proud to have worked on most of the books in Thomas Erl's series and to have praise quotes on a great number of his works.

Last, I guess I must like writing, too.  I do the occasional bit of blogging here, and would definitely be open to collaborating on a book, if I were able to find the right project, with the right collaborators.

Your turn.  Hopefully I've managed to stir in you some feelings about what you're interested in.  What's your passion?

You Are in Charge of Your Future

Where do you work?  Are you working for a software development company?  Are you working directly on the product that's making your company money?  If so, great!  You may have a rocking development machine.  You may get sent to conferences to network with your peers.  You may get sent to training on the latest technologies.  You may even have lots of dev tools and libraries at your disposal.

This post is not for you.

This post is for the employees in Corporate IT positions.  This post is for all the Dark Matter Developers.  This post is for all the 501 Developers.  This post is for anyone who is working in what they call a "cost center", meaning that they support the business unit they are in but are not directly responsible for making the money that keeps the company going.

Because they are not revenue generators for their business, these corporate IT departments are often not very well understood.  The businesses they work in are not technical companies, and they often see technology more like a utility service than like the strategic partner or business differentiator that it could be.

Sometimes these departments are understaffed, making it hard to produce code the "right" way.  Sometimes the tools they have at their disposal are subpar.  Sometimes the developers, even if they follow and learn good practices, are only there to maintain what the contractors are brought in to build.  And if you're still following along, I'm probably not telling you something you don't know.

But something you do need to consider: your skills will atrophy in this environment.  Too many people leave a great environment where they have business knowledge that matters, just to get involved in some more interesting technology, because they have become subject matter experts that can't be allowed to work on different things.

Just because you're Dark Matter, doesn't mean you Don't Matter.  We very much want to hear what you have to say.

You can be a great developer, even if you're in corporate IT, but you may not get the help and support you need from your management.  This isn't because they're bad people.  They just may not understand exactly what it takes to keep creative people interested.  Or they may not understand that a couple thousand dollars a year for a training budget to keep a good employee is better than paying alarming penalties in restaffing and training costs when they leave.

What I'm saying is that you may have to take responsibility for your own personal development.  You have to work harder to stay up on things, because the technologies you use where you are may not be the latest and greatest.  They may not even be fun to work with.  But you owe it to yourself to stay relevant, and that isn't necessarily your company's goal.

Commit at least some of your time to reading blogs.  Follow some leaders in the industry that you like.  My personal favorites are mentioned in my earlier post The Cult of Do, but I'll take suggestions.  I love hearing about new thinkers out there who have joined the conversation.  It takes very little to set this up in Google reader, and you can dial the content up or down as you need to feel like you're not hitting information overload.

Another way to get some time in with new technologies: attend free community events.  At a minimum, know what is offered around you.  In the Chicago area, it's things like Chicago Code Camp, a free technology conference, or the Chicago .NET Users Group.  These are great ways to network, and have a good time learning about new technologies that you may not be using.

If you crave experience in a new technology, find some way to do it, even for free.  Lots of people will tell you that you need to do open source projects, but that's just one way to code with folks.  What about giving some of your time to code for charity with a project like GiveCamp?  You can code for charity for a weekend?  Sure, it's some of your time, but this experience may be better than the last year you spend maintaining a Visual Basic application from the early 2000's.

Or maybe you're a little competitive?  Try participating in a team in a Hackathon!  Great prizes, and you get to code with new folks in a new environment.

This one may come as a shock. Yes, you may have to part with some cash on your own to invest in yourself as a professional.  Remember, your company doesn't owe you personal growth.  They owe you cash for your talents.  Keeping your talents sharp may be up to you.

Here are some tools that might be within your grasp as someone who wants to keep up.  A personal ReSharper license costs $149.  Learn to use it, and you'll be coding like a Jedi in no time.  An unlimited annual subscription to Tekpub is $300.  It's got all kinds of cutting edge topics, presented by experts in the field.  If you feel like you're behind on some of the latest/greatest, check it out.

Finally, I want to put in a plug for regional conferences.  Smaller regional technical conferences like Codemash in Ohio are a great deal for personal investment, especially when compared against the relatively expensive TechEd.  These are great ways to meet people and companies in your area, be part of the conversation, and to learn lots of great new things from peers.  Regional also means that you won't have to fly to get there, meaning that cost is even less of a factor.

Consider That Conference.  It's a new polyglot conference servicing the Midwest and is focused on the Web, Mobile, and Cloud.  Three days, 150 presentations, and it's only $349.  Compare that to the couple grand that TechEd will set you back.  Throw in a couple nights at the waterpark resort it's attached to, and you only get set back about a grand total.  Compare that to the thrill of what you'll learn.  Compare that to the confidence you'll have with your new skill set, or the next great job opportunity.  It's an investment in yourself, an investment in your future.  As of this writing, registration for That Conference is still open for 2012.  Consider what it can mean to the future you.

You are in charge.  Make it happen.