Rethinking dev.idaho

I'll never forget the very first discussions about what would eventually become the dev.idaho conference. It was 2010 or 2011, and we were just putting together the ITC software alliance. 

Matt Rissell was the president of the software alliance, and I was the chair of the education committee (I didn't work for Matt at the time. I was still at SAP and had a trip to WhiteCloud in my future). Matt kept saying we needed a "big event". I thought it was a terrible idea. We were a group of volunteers giving everything we had to just make a difference with our small community initiatives. Typical short-sighted engineer response on my part, but I felt we were spread thin already and an event would be an absolute waste of time.

I chose to focus on my committee and abstained from all planning and discussions about the event. This was my first experience with Matt's persuasive personality and his ability to get people around him to step up to a challenge. It was also my first experience with Martin Hambalek's project management and planning capabilities. I would learn over the years that both are incredibly capable and this single event was not an anomaly. 

I attended the first dev.idaho event, which was paired with Tech Cocktail, and I was blown away. The community showed up, the startup showcase was a blast, the speakers were great with awesome stories to tell, Mark Solon dropped some F-bombs and after the event a number of attendees shut down The Modern. It was an experience to say the least!

Over the years, Martin's team has organized multiple events that fill the gap between a developer conference like Boise CodeCamp, and an entrepreneur or business conference.

This year's agenda is a departure from the format used the last couple of years and promises to entertain, educate and motivate like never before. A fantastic keynote from Hadi Partovi of code.org combined with numerous panel discussions from local software peers and a new networking format should make this a brand new experience even for those who have attended the event in the past.

I encourage everyone to attend the redesigned dev.idaho event, contribute to the discussions, network with your peers, and remember why we loved the first event so much.

I despise Hackfort and dev.idaho, and I will attend EVERY year

When push comes to shove, I despise attending Hackfort and dev.idaho. But I will go EVERY. SINGLE. YEAR.

I’m a sucker for people who have an idea, a vision, and execute on it. I love people who DO THINGS versus talk about things. I love people passionate about Boise and software, and even if only a small group of them assemble at these events, I want to be around them and talk to them.

I have no affiliation with Hackfort, but nothing but respect for volunteers who can get four to five hundred software engineers to assemble in a single place at a specific time.

Three themes emerged during discussions at Hackfort today that come up every single time Boise developers and entrepreneurs assemble, and they all drive me freaking crazy:

1. Lack of funding in Boise
2. Inability to pull software developers from their “day jobs” to work on a startup
3. How we stay involved as a community and meet more frequently

Topic number one is BS. If you have a great idea, you can find funding anywhere and develop your product from Idaho. Better yet, bootstrap with a few angel investors (even if they aren’t from Boise) and build something cool. The reality is rather than being short on funding, we are short on innovative ideas. It’s hard to stomach and say out loud, but money is easy to find if your idea is sound. It’s too easy to blame a lack of funding when the reality is we are short on awesome ideas and teams that can execute on them.

Topic number two is also BS, but I understand the frustration. If your idea is compelling, and developers think it will work, they will help you build it. The problem is software engineers today are in high demand, often very well compensated, and they are very likely happily employed. When you offer no salary and limited equity in something that is simply an idea, you shouldn’t be frustrated when they are not chomping at the bit to drop everything and join your new venture. Believe it or not, they are people too, and have families to support. They are by definition risk-averse and analytical type-A personalities. I’m sorry your super-popular and personable high school quarterback friend can’t build out the infrastructure for your new product idea, but that’s the way things go. Offer developers an awesome salary and equity, or expect to be shot down. I’m sorry, but that is reality.

Topic number three should be so simple, but even I struggled today with a simple answer to the question of “how do I get involved or connect with the Boise dev community." The reality is, there are a LOT of software user groups, and a lot of entrepreneur groups meeting regularly in Boise. The Idaho Technology Council has a page listing a ton of meet-up groups (http://www.idahotechcouncil.org/local-places-techies-network). Myself and some friends agree there should be an easy to remember URL to find a list of active groups, and next week we will start something up so in the future we as a community can answer this question with a simple URL. Update: We're starting with a easy URL that redirects to the ITC page for now, and we'll build out a better (and more dynamic) site as we can: gemstate.io

What do we need to do to build Boise’s tech startup community? Simple:

1) Build awesome, compelling products and companies

2) Stay in Boise when you exit the business
3) Stay in Boise and keep building your business (never exit)

Build cool products and services, and if you have a liquidity event, please stay in Boise and build something else. That’s it. We should all be striving for this. It isn’t easy and it won't happen overnight, but until we reach critical mass, nothing is going to change and we will continue to attend events where all we do is fantasize about being the next big “tech hub."

Update: Most of the conversation around this post happened when Jess posted it on Facebook. You can read those comments here.

Two "Must Use" Chrome Dev Tools Shortcuts

I switched from Firebug to the Chrome Dev Tools about 4 months ago and couldn't be happier. Until this week (May 14th, 2012), navigating to specific script files and functions was tedious. I'm happy to see some of the Chrome beta tools make their way to production this week.


Brand New

• In scripts tab, cmd-O now brings up a dialog to open a specific script file. No more mousing over to the scripts drop-down.
• Even better, cmd-shift-O brings up a dialog to navigate to a specific function in the current script. The only thing that would make this better is if it worked across ALL loaded scripts, vs just the current script. If this feature alone doesn't excite you I question your geek standing... seriously.
• In options (the gear icon at the bottom-right of the dev tools screen), select "dock to right" to dock the dev tools with your existing browser window. Awesome option when you have a good monitor (24" or wider). I wish it could dock left, but this is better than nothing.
• In options, "enable source maps". Cool way to map source files from compiled js to the actual source files. I REALLY hope this turns into a more advanced feature where you can map a server source file to a local host version, and then persist your in-browser changes to disk.
• Speaking of in-browser changes, you can modify js source files in the dev tools and their changes are respected until you do an explicit browser refresh.
• Tree view of loaded scripts. I'm not fond of this, and I hide it since I can cmd-O to find them anyway, but still a nice addition.

Not New, But Useful

• cmd-shift-F, search for a string across ALL loaded scripts
• would be even cooler if could get cursor into the results automatically (can set up keyboard maestro command to get there, though)
• cmd-shift-C, activate the "select element to inspect" functionality
• cmd-option-I, start debugging session

Side Effects

Last month we hosted a CS Extras event at Keynetics, inviting all CS students, but focusing on freshman and sophomore students. The Keynetics team put on a great presentation. They focused on describing what kinds of things students can expect in the workplace, what a typical work day/week/month is like, why they love their jobs and the industry, what tools they use, etc.

The November presentation itself was a success, but I wanted to focus on how small events like this can indirectly result in long lasting returns.

To someone on the outside an event like this might seem like a waste of time or a futile effort. "How will talking to 20-60 students for 2 hours increase the number and quality of software professionals in Idaho?". This is a great question, and one I constantly ask myself as it can often feel like we are fighting an uphill battle.

This presentation, and the events following it helped solidify my motivation and confidence in our program.

At the BBQ after the presentation, two students told me they had been considering switching to an Electrical Engineering degree, but now they were motivated to stick with Computer Science and excited about the opportunities. That provided a warm fuzzy feeling and I was more than happy to take that as ample justification for the event. But that isn't why I'm writing this.

It wasn't until two weeks later that I realized the full impact of the event. This is a circumstance of one small act of giving turning into something much bigger than itself.

Amit, a professor at BSU, told me that the students came back to class and asked him about automated testing (which was mentioned in the presentation). As Amit uses tests to verify the students programming assignments, he was able to expose an interface the students could use to run his tests against their programs before submitting them.

If you work in the software industry, you understand the significance of that last paragraph. We now have first year CS students that understand the value of automated testing and how it can be applied to almost any program. This is a fundamental career skill that will not only help them with programming tasks in college, but that they will take with them into the work force.

We have a situation where one event, that was easy to coordinate, and took only a few hours of each volunteers time, instilled a process that will likely stick with these students (and possibly the curriculum) for years and years to come. In addition, the benefit of the presentation has now filtered to all students in that class, not just those who attended CS Extras.

Perhaps I'm being too optimistic, but these are the kinds of positive side effects that you just can't plan for but that can make the entire endeavor worthwhile.

To keep up with CS Extras events; like our Facebook page, subscribe to my blog, or watch the ITC website for event updates. To volunteer, post on the ITC LinkedIn discussion group and I will contact you.

Update: Be sure to check out the comments on this post, more good side effects.

Hello Tomorrow

I started at Extended Systems in the fall of 1995 during my second year of college. I was immediately placed on a team with incredibly smart people working on fun products. That trend has continued for the past 16 years and I have had a wonderful time. Great coworkers, cool customers and constantly changing technologies have kept things interesting for a very long time.

I’m also excited to take on some new challenges and with that in mind I have accepted a position at a local startup and will be saying goodbye to my friends at ESI/Sybase soon.

While the last few years I have been the public face of Advantage via blog posts and screencasts, this product is much bigger than one person and is in great hands. The development team is strong and works with an equally experienced sales, support and marketing team. I know Advantage will continue to thrive.  

I still plan to continue writing, however the content will likely shift a bit towards different software technologies. I look forward to continuing our conversations and friendships.