This month Steve Hughes asked us to write about conference experiences that have impacted us or changed how we work. I could write about specific talks, but what has stayed with me is something broader.

I had plenty of excuses not to go to that first conference.

• I wasn’t a real developer
• I didn’t use Ruby in my day job
• The conference was expensive
• I shouldn’t waste my vacation time on it
• I didn’t know anyone
• It might be boring

Thankfully, cost wasn’t a huge issue. The conference was in my hometown, so no room or travel expenses to worry about. I bought a ticket and went.

It was a wonderful event. The community was kind and friendly. The talks were interesting and engaging. I found myself deciding which path I would take through the event, selecting talks that seemed most interesting to me. I loved it. Most of all, I loved that so many people with similar interests were gathered in the same place to learn and experience it together.

Since then, I’ve been to several conferences, some locally and some in other cities across the country. I have fond memories of all of them, but the ones that stand out are the ones put together by the community.

The big tech conferences have lots of money to throw around, but they end up feeling like a sugar rush. You feel the excitement of the crowd, see the flashy booths, grab some merchandise, and it’s great, but it soon leaves you hollow. Those are not the ones I prefer.

The community conferences are different. People are the focus. Ideas and friendship are the reasons they come together. Those are the ones with talks that stick. Those are the ones I keep going back to.

In a few weeks, I’ll be at the 20th annual PyTexas in Austin, exactly the kind of event I’ve been describing. I don’t know which talk will change the way I think about something. But I know I’ll leave with new ideas. I’ll spend time with friends I already know and make some I haven’t met yet. That’s what community conferences do. They’re worth showing up for.

I found T-SQL Tuesday just in time for this first post, and I’m looking forward to participating.

What career risks have you taken?

The year was 1997. I was delivering pizzas when an opportunity came along to intern at a small medical management software company. They threw me straight into months of SQL training. It was Oracle SQL, and I loved it immediately.

Over the next few years, I learned so much. Query optimization, scripting, best practices. The internet was taking off, the company went public. I had it made.

Then everything went sideways. I survived a few rounds of layoffs, but eventually, I too was out of my dream job. There wasn’t anything available in the small college town I was in that was close to the job I had and still wanted. It was time to take a risk.

So I moved to Seattle.

I wish I could say I had a job lined up. I almost did. I made it to a late-stage interview and decided it was time to make things happen. I found an inexpensive apartment with a commute and signed a lease. I started making plans to move.

I didn’t get the job.

Seattle is beautiful, and there are many more opportunities in the city for a tech job than where I was, so I moved anyway.

The first few months were very hard. But it didn’t take long before I had a job. I had to pay rent after all. I found work over the next 6 months:

1. A maintenance man at an apartment complex
2. Stocking shelves overnight at Target
3. A customer service representative on the phones at a bank call center

None of these roles was anything like what I was looking for, but it was income, and the call center job had good benefits. I put my effort into the role and started finding out about what other jobs the company had to offer.

I was lucky enough to make a few connections and get a 3-month internship doing desktop support at the call center.

During that time, I focused on the problems that the team had. The biggest issue they faced was that they were asked to log their work so that it could be reported up to leadership and justify the small team. We all had BlackBerrys (not the phone, but the little text screen with a keyboard). They were integrated into the company’s email system.

I built a small database application that connected to email and would scrape formatted emails into the database. This let us techs send a quick note via BlackBerry when we went out on call, and it would automatically compile into a report at the end of the week. The team loved it.

It wasn’t long before the risks paid off, and I was able to get a permanent position doing scorecard reporting for the phone reps across all sites. That role was also my introduction to SQL Server and T-SQL, which became my native dialect over the coming years.

Since then, I’ve made two other significant moves away from data. The first was into change and issue management, which introduced me to business concepts and risk frameworks I didn’t have before. The second was leaving to support an IT department as a risk management partner. Both times, I thought I was stepping away from my career. Both times, I came back to data with a broader perspective that I couldn’t have gotten any other way. My SQL background made me useful in every role along the way, because I could always do my own analysis.

Looking back, the risks that felt the most uncertain in the moment are the ones I’m most grateful for now. If you’re sitting on a decision that scares you a little, that might be the signal worth listening to.