Marty Haught

Product Development, UX and QA in Small Teams

Wed, 04 Mar 2015 00:00:00 GMT

In the early years of my software career, I worked in larger organizations where we had different groups of developers along with non-technical teams working collectively inside formal processes. Imagine some form of waterfall process where you had an architect group backed by business analysts, multiple teams of software engineers, and a quality assurance team all watched over by a group of project managers. It was slow and inefficient at delivering the software that business needed. During the late 90s and early 2000s, it was all I knew.

Fast forward a decade later and now I exclusively work in small, cross-functional teams that are fully self-contained. We ship software lightning fast, can react to change requirements overnight and are incredibly efficient.

However, one weakness that I’ve observed lately is when the client doesn’t own the traditional product owner role fully. It seems odd that this would happen but on two recent projects I noticed a trend where the client wasn’t interested in completely steering product development and/or user experience. It could be that they felt comfortable with how our team at Haught Codeworks was handling both pieces. Or maybe past experience with traditional web consultancies led to bad patterns of interaction.

When the client doesn’t fully own the three areas of product development, UX and QA it leaves a vacuum. It’s rare that software engineers will think of these aspects on behalf of a client. If a client asks for feature A, we assume they know what they’re asking for and will verify after we ship the feature that it meets their needs. When a client doesn’t take product ownership, features sometimes get built in a way that isn’t ideal for the user experience. With no one thinking of the bigger picture features are built with a lack of context and assumptions go unchecked. Who’s to blame in those cases? Ultimately both sides are and given that a software consultancy should be the expert on shipping quality software, it’s become clear to me that we need to guard against this. The product needs an advocate, even if it requires the team to adopt that role.

The trick is, who owns this piece on a small team? In a perfect world everyone on the team would own product development. In practice it’s not realistic to spread this responsibility across the team. Product development is very time consuming when done properly and it’s not something I want to leave for the team to ‘sort of’ provide in an ad-hoc manner.

My thoughts lately have shifted. What if I had one person own these three roles? First, product development would focus on representing the user and making sure the client understood how best to build the software to meet the user’s needs. This person could dig a bit deeper than clients might on their own and really get the product moving in the right direction, long before any code has been written. UX could be properly handled up front with usability having a dedicated champion as features are planned out and tested. Finally, they could do the last check of finished features to make sure they match the intentions of the product owner and provide a good experience for the users. It’s hard for engineers to reliably verify their own work, so this also functions as a second set of eyes to test a feature before the client ever gets to see it.

I haven’t heard of anyone mixing there three facets of product ownership into a single person’s set of responsibilities. Is it too much of a stretch? Any other gotchas? I am curious what others have experienced in this space and if they are starting to see value in this sort of thing for smaller teams. Finally, I’d like to add someone to the Haught Codeworks team in this capacity. If you or someone you know might be interested, reach out.

Project READMEs

Thu, 31 Oct 2013 15:38:09 GMT

A practice that I have my projects follow is a self-guided README file. The concept is simple. The README should guide you through everything you’d need to do to get this app up and running on your local environment. It seems like an obvious must have on projects yet I’ve encountered several that don’t do this.

As I value efficient use of time, I find having everything I need to get an app up and running in easy steps is huge. As a consultant I end up running easily a dozen apps each year. This README saves me time and makes sure I didn’t forget any important steps. There’s nothing as frustrating as doing the normal rails setup steps only to find an app failing due to some unusual dependency or missing data. Having the README avoids this issue. It’s especially helpful if I haven’t run an app in a long time and just want to make sure I don’t need to redo any of the steps.

The README is particularly useful for those new to the project. I find it valuable for both newer and experienced programmers. When your team has a culture of writing these READMEs you know when you come onboard a new project that it’ll be there for you to get you up and running as fast as possible.

Let’s explore what these READMEs should include. Before I get started, I delete all the boilerplate contents that the Rails generator puts in there.

Start off with the project’s name at top. Even though it’s implied by its placement at the root of your Rails app, I still like it there.

Next I like to put requirements for the app. Usually this is the version of Ruby, any required databases and other special services/libs that you may not have installed on your system. I don’t list gem dependencies in this area since Bundler handles that. I do assume that anyone installing the app has a Rails compatible environment.

The meat of the README will be the steps to get the app up and running. This includes steps like configuring your database.yml, copying and adjusting any special config, running bundle and any steps to seed or bootstrap your environment with necessary data. These are typically written out as shell commands so someone could copy and paste it into their prompt.

Next I like to include information on deploying the app along with basic data on where that is. This piece isn’t as necessary but we find it convenient. This is especially true when you have many different apps and some may be on Heroku while others are on other servers that may use Capistrano for deployment.

If there are common tasks that we do I like to call them out here. Perhaps you have some external service you infrequently pull down data from. Maybe you process csv files.

Finally, if there are any special notes or tips that I want the team to know about this app, they go at the end. If these notes are important to the setup process I’ll mention them above with a fuller explanation towards the bottom.

One key principle is I want these READMEs to be self-guided. I shouldn’t need to ask questions of the team as I follow the guide. Hopefully it’s fast with clear steps. If not, that’s a red flag that the README needs an update.

Speaking of that, the first task that a new person on the project (experience level doesn’t matter) has is to update the README as they setup their machine. If anything is stale or inaccurate, they update it. If something isn’t clear or they have questions on it, we look to see if something needs to be clarified or not. If there is room for improvement, they make it better as they go. This process also helps flush out any implicit steps that needs to be defined.

Though it takes some extra time for the README to be written and kept up to date, I truly believe it’s worth every minute spent on it. Even when I am solo on a side project I still do this. On several occasions I’ve been immensely thankful that I did.

One thought on the evolution of this idea is to do literate programming where the README not only provides the kind of human readable documentation mentioned above but is also executable commands. Even further is the notion of full machine setup automation or images, such as Boxen. Depending on your team that might be preferred. However, I’d start with getting your project READMEs into shape before going beyond.

RubyConf 2013 CFP and Diversity

Wed, 18 Sep 2013 00:00:00 GMT

The RubyConf 2013 program was partially announced yesterday and there was immediate fallout regarding the lack of women speakers. At first, there appeared to only be 2 women-led talks out of 44. Indeed this percentage is terrible and a step back from where we have been. At the same time there has been a lot of misunderstanding and jumping to conclusions that simply couldn’t be answered over Twitter. I’ve been terribly busy and traveling ever since this all came out and I finally have some time to take more than 5 minutes to respond.

First, I want to apologize to all of you who expected better from the RubyConf program. We really should have done better on many more fronts than you realize and the lack of diversity is only one symptom. For anyone that cares to look into my background or what I’ve done with the tech community over the last several years, you’d see that I am not one to discriminate and am more like a defender of diversity. I also had the most involvement with the CFP process and am ultimately responsible for the end result, which I will take the blame for.

The next thing I want to make perfectly clear is that RubyConf does support and encourage a vibrant and healthy community, of which diversity is an important part. We have the Opportunity Scholarship which is often used to promote diversity. In the next week we will open up applications for scholarships to RubyConf. It is absolutely false to claim that women or any marginalized person would not feel welcome at RubyConf. We have a solid Anti-Harassment Policy and have had this policy for some time now.

There’s a lot to cover about the process and what was lacking that I’ll go into shortly. First, I need to clear some things up. We’ll start with some numbers. The numbers are constructed as best we can as the CFP process does not ask for gender or any other demographic. I can confidently say we know how many women vs. men proposed talks. I cannot say anything about people of color or any other segment of marginalized people.

We had 278 total submissions, of which 25 were by women (9%). If you look at individual proposers then we’re at 207 total with 19 of them women (also 9%). The final program will be at 47 talks, 6 of which include women (or a girl in one case). That’s 12% representation which is lower than we’d like but not as bad as many who thought our program was at 2/44. Since our process was blind, I’d say that women actually fared much better than people are acknowledging. What’s even better was the process was driven by talk quality so this is not some quota or artificial percentage. Their talks rose above many, many others. One really important thing to point out is that we had a ton of good submissions for 47 slots. Many good talks were rejected simply because there wasn’t room. I don’t think people realize how tight the competition was.

Let me talk a little bit about the CFP process. First, it was blind. This means that reviewers could not see the name or bio of the speaker and thus could only be influenced by the content of the proposal. Second, we had a review committee (8 people) where every talk got at least 4 reviews. Since I was managing the entire process and could see all the data behind the talks, I did not review a single submission, since my reviews would not have been blind. I wanted to respect the blind process that way. I was only involved in the final selection. We had decided how the CFP process would go months ago and this is the first year RubyConf had run it like this.

One notable piece missing from the the CFP was any sort of proactive outreach. We didn’t do anything in this department and just announced the CFP as normal. Since we only had 9% submission rate you can’t expect better representation. This is something we need to do better for next year.

Another piece that felt lagging was giving better instructions on the CFP. We gave specific instructions to reviewers and there were some things that we left implied, based on what RubyConf has been. Which I think is important to speak a bit about: this is the conference for the niche and unusual talks about Ruby. It is not a general purpose tech conference but the one time where all those really interested in Ruby come together to talk about the language. Thus reviewers rated talks that met this criteria higher. Many great talks that would be perfect at a conference didn’t meet muster as they may not have focused as much on Ruby. This criteria would not be clear to someone new to RubyConf. It seems obvious now that we should have communicated this better and we’ll get this fixed.

The CFP process lacked feedback. Many reviewers simply didn’t leave comments for proposers. If we had started sooner and given feedback as talks came in, then proposers could have adjusted talks and known why their talk(s) may not have made it. When you’ve got nearly 300 talks to get through in 2-3 weeks, it’s daunting. We used our own software for the CFP and it lacked some important features to do this process properly. I personally finished off this code but I had to fit it into my busy schedule and thus it wasn’t ready until late August, just a week before the CFP closed. What would it have looked like if that would have been ready from the beginning and our review committee was ready to go as the talks slowly trickled in? Unfortunate circumstances that usually do not affect smaller conferences due to our size.

This may not be clear to many of you, but this isn’t a full-time job for most of the organizers nor the program review committee. We’re volunteers and in my individual case, I have to balance organizing two large conferences a year with running my business, raising my family and the other obligations that come with life. I simply don’t have the time to do everything I want to do. When I ran Rocky Mountain Ruby, a small regional Ruby conference, I could take extra time because I had a 1/4 of the submissions and overall less logistics to deal with. I know many of you say you’re willing to help but that’s not as easy as it sounds. I’ve tried delegating to volunteers in the past and that’s gone poorly.

I don’t want to make excuses as we will figure out a better way next time. However, I did want to give a fuller story to the tidbits that have come out on Twitter over the last 24 hours. It saddens me to see how quick people are to react so strongly on all sides of the issue based on assumptions without waiting to hear the real story. I don’t think there are any villains here and things are way more nuanced than they seem. I’m just sorry that I’ve let people down. Hopefully you can all make constructive actions for improving our community going forward. Yes, RubyConf will still be a great experience this year. We care too much to not let that be the case.

Supporter Ticket at RubyConf

Tue, 06 Aug 2013 00:00:00 GMT

This year we’re trying out something new for RubyConf. We’ve introduced a new kind of registration called the Supporter. At $1,000 this is in between buying a regular ticket and being a sponsor. We’re offering this as a way for the community to contribute back to RubyCentral as well as for businesses that don’t want a full blown sponsorship but would like some recognition.

You may ask why anyone should contribute back to RubyCentral. We’ve slowly been working on our new rubycentral.org website for the past several months to clarify what our mission is and how we’re going about it. One vital service that we provide is RubyGems infrastructure, it’s not cheap running servers that deliver all the functionality the RubyGems provide.

RubyCentral also runs community support through our conference grant program and the new Opportunity Scholarship program. The conference grant helps new regional conferences get up and running, allowing those not able to travel to either RubyConf or RailsConf the exposure to our community-centric conference culture. The Opportunity Scholarship is a new program that I brought in from Rocky Mountain Ruby. We ran it at RailsConf 2013 and several other regionals have run similar programs with RubyCentral support this year. This program will help introduce new programmers to Ruby and our conferences. We hope this gives them a welcoming entrance into our community and sees them blossom as contributing members in the coming years.

By choosing to register as a Supporter at RubyConf 2013, you’ll be helping fund these programs going forward. RubyCentral is a registered 501c3 non-profit in the U.S. and makes sure those funds go back to helping our community improve.

We already have two such supporters, Wayne and Stark and DNSimple. Check them out on our sponsors page. I look forward to seeing more of you listed there and thank you for the support!

Blind Reviews at RailsConf 2013

Fri, 03 May 2013 00:00:00 GMT

For RailsConf 2013, we used a different approach for reviewing all the proposals we got — all reviews were blind. This is where the reviewer can only see the proposal’s title, abstract and detailed information. We reviewers had no idea who submitted the talk, their experience level or gender/ethnicity. Though I have been organizing conferences in some fashion over the last seven years, this is the first time I’ve done a blind review process.

Before I continue, I want to point out that I strive to not let a person’s background or identity unfairly affect how I rate their talks. I think I do a good job since I truly believe that gender, ethnicity and other ways people are discriminated against play no part in the quality of a presentation they might be offering. However, the reality is I can’t be completely objective. We all carry unconscious bias with us and seeing someone’s name or bio could well color how we value their talk. Thus the first benefit of the blind review is that these things are removed.

Second, I know a lot of people in the community, many of which might be submitting talks. No doubt I could easily be swayed to give extra value to a talk from a good friend or a high quality speaker. Worse yet, I might not give an honest rating since it may hurt their feelings. The blind review eliminates these things as well.

It’s quite freeing to not worry about these things. It allows me as the reviewer to totally focus on just the quality of the abstract and talk details. It also makes talk reviews faster since I don’t need to factor in the quality of the speaker or his/her background. For RailsConf, I only did initial screen and rating of the talks and allowed others to sift through nearly 400 proposals in narrowing down to around 50 talks.

If you’re a conference organizer, I encourage you to do your first screening blind, especially if you have a review committee. I would state explicitly in your Call for Proposals that you’ll be reviewing talks blindly and ask that submissions do not reveal the speaker’s identity, gender or ethnicity. It would also be good to have someone not on the committee screen the proposals to make sure they’re sufficiently scrubbed (meaning there’s no leak of the speaker’s identity, gender or other identifying details).

I do believe that as an organizer you’ll still want to curate the final talk selection and considering the actual speaker and their experience is important. In all of my conferences I’ve seen some submissions that looked pretty good but the speaker didn’t have the experience or savvy to pull off what they were proposing. I don’t know if you can get around this with a truly blind review process. However, I see no reason not to have initial talk review and ratings be done blind.

Opportunity Scholarship at Rocky Mountain Ruby

Wed, 29 Aug 2012 00:00:00 GMT

I wanted to pass along a cool new program we’re trying out at Rocky Mountain Ruby. We’ve been in discussion the past couple months about diversity in our programming communities. A small community around RailsBridge has formed and they’re beginning to bring in new women programmers. We wanted to build on that by creating the ‘Opportunity Scholarship’. It’s a free pass for the conference and workshop for beginner programmers that are primarily women, minorities or other under-represented groups. We’re going to also match these folks up with experienced programmers to be their guide during the conference. This way the whole process isn’t as intimidating. If you or someone you know fits into this description, encourage them to read more and apply: Opportunity Scholarship

Deadline is September 7th but we strongly encourage those interested to apply immediately. We have limited spots available and will be rewarding them as they come in.

We’ll see how this turns out but I’m excited to give it a try. One component about this is that part of this program’s success will be to reach out to those that aren’t as connected as many of you. Any help on passing this along is appreciated.

New Education Model

Sun, 18 Mar 2012 00:00:00 GMT

Paul Graham recently wrote about frightening ambitious startup ideas. After reading this I was struck by #3 Replacing Universities. I’ve long wondered how the cost of 4-6 years at a university studying computer science compares to the benefit. I’m pretty sure there’s a better way to teach people to program for considerably less. So given the topic my mind went to work envisioning what would be ideal and here’s what I came up with.

First, you’d want to tune the education so that you really teach things that matter. Second, I would want most of the instructors to be industry veterans that know what it’s like to be out there. Though I would still see place for academics I think most of the program should be pragmatic and prepare students for the likely challenges they’ll face. I would also focus on doing quarter system. This is where you just sign up for a 3 month block of classes. You could just do a single quarter or 2 years worth. I’m not certain about degrees initially although I suspect you’d want to offer that. I’d personally avoid that in the beginning but it would make sense to look at that further down the road. You could tailor the program and classes to include core subjects as well as many interesting electives that relate in some way to their field — such as AI, graph theory, security and distributed systems just to name a few. I would start off focusing on web programming and design, but there’s no reason management, accounting, sales, marketing and other core business topics shouldn’t also be taught. Think of it as eventually teaching all aspects of what technology businesses would need.

Imagine how cool it would be if some position at a tech company only need 6 months of focused training followed by 6 months of field work. All of this could be accomplished at this school. Thus companies could send potential hires to the school and a year later they’d have their employee ready to go.

You’d want to make the education affordable and reasonable. With a smaller institution the overhead costs would be lower and thus you could easily come under what universities charge. However, I think you can go even further by making the institution multi-facted. I would pair a consulting business and incubator with the school. I see the interplay between these three as significant.

The consulting side would give the company a solid line of revenue. It would offset some of the overhead the school would incur. Second, it would give instructors direct access to what’s happening out there now. I would see the chance for instructors to rotate into consulting to sharpen skills and keep them current while others rotate into classroom duties. Furthermore, students could have sessions with the consulting arm as they go through their classes. Imagine your lab time not always being pointless exercises but work on real projects with experienced devs.

The incubator side would give the company some long range capital in the form of equity for access to the incubator program. The consulting arm could assist entrepreneurs when needed as well as let the incubator teams sharpen their skills if needed. It already fits with the education model that the entrepreneurs would have some classes just like the students. Their program would have less classroom time and more networking and launching their product.

The other piece that could be wonderful is the community aspect of all these groups mingling together in one place. I would expect they’d all feed off one another in some way and make the entire institution stronger. I would also want this open to the community at large so that local tech meetups, code retreats and other tech-related events could be held there. There could even be open classes or workshops that anyone could attend.

I also see this sort of venture functioning as a think tank on what works best in all for three sides — an organization that is constantly learning and adapting. There would also be a natural fit between the business sector and the institution to work on joint ventures for emerging technologies.

There are already things happening that are changing the way folks can get into programming. Code Academy and Hungry Academy are two that I’m aware of. We’re even getting something similar in Colorado called DaVinci Coders. These types of outfits already put into play some of the elements that I want to see. However, they don’t go as far as I’m thinking. I’d like to see something that could be that short, if that’s all you need, but could also have a deeper program that would allow students to stay longer, say 2+ years.

The cool thing about this idea is that you could start it small, just like any other startup, and scale it up. So maybe it resembles a 3 month program in the beginning but would expand over the years to something that would rival the depth of a traditional CS department.

Though I don’t have plans to start this sort of program any time soon, I am attracted to the idea. Maybe others are as well?

Developer Opportunities, The Rest of the Story

Tue, 13 Mar 2012 00:00:00 GMT

Picking up where we left off, I want to go deeper into the opportunities that you have once you’ve got some meaningful experience. Whether that’s 3 years in different gigs or 10 years, it doesn’t matter. You’re skilled enough to know how to build software on your own and you can now entertain offers from just about anywhere. What do you do? I’ll break this down into two categories — Mid game and end game. What if you’re not at this point in your career? I’ve got a third post that will cover how to get started and get up to this point. Expect that in a few days to a week.

Mid Game

The mid game, as I’m calling it, is all about building up the resume and experience. You have so many options so go out and see the world of software. Travel, stretch yourself, experience. You should be able to make yourself a healthy salary while doing so. You may also want to go into business for yourself and you may not. I am going to separate these opportunities into two types: one based on work style, another based on project domain.

Work Style

There are primarily five types of work style that I see for programmers — product companies, consulting, freelance, training and content. Perhaps you’ve done one or two of these types so far in your career. Great, consider trying some of the others for a while.

Product companies are most familiar as they exist everywhere and vary incredibly — from latest hot startup snapping up rockstar devs to the well-established corporation. You might choose one company as it has a certain culture or quality of team. Another reason, which I’ll go into further down below, is its problem domain. With product companies you also have a higher chance to become a specialist in some area, like big data or highly concurrent processing. From what I’ve seen the deepest knowledge about a domain is typically attained via a product company. My recommendation here is make sure you’re not just looking at the compensation part of the equation and make sure both the culture, team and project’s challenges help you in some way.

Consulting and Freelance are both based on client work though there is considerable variation between these two. Consulting companies are a larger organization where your role is simply the development portion. You are not on the line for business development, marketing, sales or operations. You will be one of many consultants that provide value to clients. Pivotal Labs and Thought Works are two good examples. When looking at working for a consulting company, pick one that has really skilled developers and/or a process you’d like to have more experience with such as extreme programming. The other benefit is you can learn more about interacting with clients and recognizing when you’re delivering value. These skills are invaluable and though you can learn them elsewhere, I see more emphasis put on them at consulting gigs. The other benefit of these types of gigs is the variety both in team mates and projects. For larger consulting shops it’s common to switch teams and projects after a while.

There are some downsides too. First, you may grow tired of doing this type of work. Perhaps you are rolled off projects before you’re ready. You may also reach a point where you feel you aren’t really growing your skills. I’d say 2-3 years seems more than enough in this type of environment. Pay is usually pretty good and wherever you end up next should be a higher level position.

There are other flavors of consulting that I’ll touch on briefly. One is the recruiter/local placement companies. I consider these staff augmentation as you still go for an interview at the client and assuming you are selected you then work side-by-side with their team. You can be either W-2 or 1099 for the consulting gig. I consider these gigs a last resort if you can’t find other work. It’s also something I see in the earlier years of a software career though it can be useful as as fallback while you’re bootstrapping a new venture.

Freelance is on the other spectrum of client work. The reason I consider it different is that you own the entire business. You have to do business development, marketing and sales. You have to handle your own accounting, taxes and legal needs. As you are your own boss, you have ultimate flexibility. I think freelancing is a wonderful thing you try your hand at for at least a couple years. You will learn so much about how to run a business as well as software development. There is a lot you’ll need to invest but you can easily bootstrap the business. It can also scale so you can bring in subcontractors or even hire employees yourself. I won’t go into any further advice on how to do this as that’s easily its own series of posts. There is higher risk with freelance so you should make sure you have saved up some cash to cover dry spells.

Training is another direction you may want to go in that will take you a bit away from developing. You still get to work with software but more of your time will be spent mentoring and teaching others. I understand there is excellent money to be made in this field and it can be incredibly satisfying if you like helping others. Like freelance, you’ll have to own the business yourself. I know there are some organizations that will hire you on to be a trainer but I’m focusing more on when you take your software expertise and create your own training courses. As I have never personally done this, I can’t offer more insight. I’m pretty sure that you’ll want to make sure you really enjoy doing this before you take the plunge. It’ll require dedication and perseverance to succeed.

Finally, I want to cover becoming a content provider. This is where you leverage your expertise and make content you can sell such as books, screencasts or other written material. The most common flavors are pay per item or subscription service. If you have the passion to create this content as well as enough expertise then I think it’s a wonderful idea. Like freelance and training, you’ll need to build up your business’s reputation. However, the potential to scale your content to thousands of developers is really nice so there’s very good earning potential in this space. I hear Amy Hoy’s 30×500 class really helps get this type of business off the ground.

Project Domain

The other direction you might take is seeking out certain kinds of project domains to round out your experience. I’ll mention a few notable examples but there are many more I won’t touch on. As you read through these keep in mind the idea I have is that you want to round out your experience.

Rescues are very common in my line of work. These are apps that someone wrote, and typically wrote poorly, and for whatever reason are no longer maintaining them. Perhaps the company fired them or they left for greener pastures. You should expect a mess that extends beyond just code quality. They may have built the wrong features or painted themselves into a corner. Maybe the software doesn’t even work. With most rescues throwing out the code and starting fresh is not an option. Thus these can be very challenging. Not only from a technical angle but a political one as well. To successfully rescue a few apps in your career can really teach you a lot about writing and maintaining software. I personally recommend everyone do at least two of these at some point.

Enterprise/big App is a broad category for software that is complex and has teams of developers involved. Things are harder when you start to get into 20 or more developers. If you add multiple groups with different leadership it ups the ante considerably. There are some thing you will learn about software, teams and leadership only when you play in this sort of space. Though I don’t think everyone needs to have this experience, you can learn an awful lot. Hopefully you won’t lose your mind in the process.

High concurrency/throughput is another kind of situation that can yield a lot of experience. I personally have never worked on an app of this nature but I have friends that do. Code that works for 95% of applications out there will simply not be good enough if you’re pushing thousands of operations per second. It’s rare that many of you will need to write code at this level but what valuable experience if you do.

The domain specific category would be something very targeted like banking, security, telecommunications or medical. The choices are incredibly numerous so I won’t bother mentioning any more. Software in these different domains can vary so you might want to try your hand in something different from your previous gigs.

End Game

The end game is what I’m referring to once you’ve got enough experience to do pretty much whatever you want. Basically you’ve been in a lot of different environments and worked on different type of projects. Maybe you haven’t ‘seen it all’ but darn close. Perhaps you’re tired of doing what you’ve been doing and something else speaks to you. At this point the question comes should you do this for yourself? This was actually what James Edward Gray was getting at on Ruby Rogues that eventually developers will want to build something for themselves, whether it’s content or their own product. Other options may appeal to you such as taking a high profile gig as a CTO or technical co-founder of a promising startup. Whatever you choose, it should be something fulfilling and makes you happy. Hopefully by this point you’ve made enough money so that others factors are more important that just cash.

I would agree with James that many of us, at some point, will want to start something of our own. In the mid game section I covered a few options that put you there. Now, there’s nothing stopping anyone from going into business for yourself from the get go. Matter of fact, Nate and Natty of Everlater decided to create the travel experience sharing service they wanted and taught themselves to program in the process. There are no rules here and if you have the passion, there’s no reason not to dive in. Let’s go over the primary choices I see.

Consulting, Content and Training

I’ve already covered these in the mid game section. Very little has changed in the here except you likely have made a name for yourself. Since that will drive business you’ll find it easier to stay busy, charge higher rates and see your business flourish. There’s no reason you can’t build an impressive business by this point. Look at Peepcode, Pragmatic Studio or Envy Labs as examples.

VP/CTO

This is where you decide to join the leadership ranks at either an existing company or a new venture where you’re not necessarily the founder. This mirrors the traditional path that great devs go into management. This isn’t bad as there is real need for technical leadership. If you’ve had enough experience and you feel draw to lead the engineering/technical part of a business, by all means go for it. There are plenty of challenges in this direction and you can really make a difference. You don’t even have to grow pointy hair. It goes without saying that you can further your reputation by taking this sort of position and doing well. Compensation should also be there but then you’re also working for others. Also, you’ll have to deal with politics like never before.

Entrepreneur

This is where you start something new with you at the helm. Starting your own consulting, training or content business also falls in the entrepreneur category but for this part I’m just referring to building a product or service for others to use. A lot will be asked of you if you take this path. I have many friends that have gone here and it’s a lot of work. However, if you are passionate about your idea you will love it. Don’t expect riches any time soon but there’s something very satisfying about working for yourself and building something meaningful. The business you create could stay small and support you for years to come. Some call this a lifestyle business. You may also build the next Facebook too. The possibilities are endless here.

If you do go this route, I’d highly recommend trying to bootstrap and avoid taking investment. The moment other people fund your idea you will have to answer to them. This might take away a lot of the joy of doing your own thing. Additional pressures will be introduced so be prepared. I personally haven’t taken investment so this is second hand from those that have. No doubt there are plenty of businesses that would significantly benefit or require investment capital but think carefully about going in that direction.

Angel Investor

This is an interesting direction you can take after you’ve had at least one successful venture and have more money than you can put to use. You may be tired of running companies yourself and building products. If you have the capital and you still want to stay connected, doing small angel investments might be for you. You’ll have to learn the VC/investment world but it would give you a way of keeping in touch with what’s happening and giving back to a new generation of programmers building the future.

Or Not

As you can probably tell, there is a lot of ambition in some of the types of gigs. While making your own product isn’t the same as being the CTO of a high profile company, you will have to do many things developers aren’t asked to do. For many of us, we may welcome the new set of challenges while others may not wish to venture there. There are immense rewards for developers who take the risk and stretch themselves this way. Whether you’re willing to go there and wear some non-programmer hats will determine how big they’ll be. The thing is certain, you have a lot of great options. You can easily stay a developer if that’s your cup of tea and still be rewarded with a good paying, happy career.

Staying a Developer

Thu, 08 Mar 2012 00:00:00 GMT

Do you need to leave programming to advance your career?

This question came up recently in two places. First, during the Ruby Rogues episode 44, which I was a guest on, James Edward Gray opened the discussion with a related statement. He said that ultimately most developers will want to transition into a content provider (railscasts, peepcode, etc.) and asked me to prove him wrong. Second, tenderlove asked on twitter the other day about career options for developers. The premise of both of these questions is if it’s viable to remain a developer for your entire career and that you must transition to something else. Must you leave programming to advance your career?

While I think many do leave programming to further their careers, I do not think this needs to be the case. So let’s break this down in more detail.

First, I love to program. I love to build software and solve programs. Though I might get tired of solving the same problem over and over again, I’m not concerned that there won’t be something down the round that I won’t enjoy solving. From this standpoint, I can see a happy life of writing software for 15-30 years. Thus it is not given that I will outgrow building software. I think many others share this sentiment.

Second, demand. This falls into the obvious category but the demand for programming isn’t going to decrease any time soon. More and more aspects of our lives involve software and someone’s going to have to write and maintain these programs. Right now there are endless opportunities for software to disrupt status quo businesses and old ways of doing things. We seem to be in a boom for startups and they need skilled programmers to bring their ideas to market. There are plenty of entrepreneurs taking their shot at this and plenty of investors giving them money. Thus I think the supply of developer jobs at all levels is ensured for the foreseeable future.

Coming back to our question, I believe a viable career is hinging more on either money and/or happiness. Let’s start with happiness briefly.

Happiness is relative and based on your expectations. I think it’s fair to say that you’d hope your life improves steadily over your career. Much of this could simply be that you have more control and options in your choices. That’s fair. I think it could simply boil down to where you can live the life you’ve always wanted. Definitely don’t place your happiness on some dollar amount. That is not the way to happiness. Depending on what you’re shooting for, this is definitely obtainable as a software developer. I know many of my fellow programmers that have more than enough money, have flexible schedules and have adapted their lifestyles to what they want — all while continuing to be a developer. Expanding more on happiness is its own post so I’ll leave it at that.

Now let’s return to the money angle, where I believe most of the focus is on. Salary ranges are fairly large for software developers and I’m seeing lots of incredible offers for top notch talent. While junior and mid-level devs won’t see a huge payout, I do believe that with dedication and hard work you can get to the high levels in the software world and easily get comfortable 6 figure salaries. More importantly, you’ll get your choice of offers which can include many perks as well as a supportive culture.

It wasn’t long ago that many developer jobs capped out at a mid level and if you wanted to ‘get ahead’ you had to go into management. This was pretty much de facto in corporate world. While I know some startups in the 90s bucked this trend I still saw the mentality of paying your devs the typical salary and possibly enticing with options. Now I’m seeing better offers than they used to be as well as real interest in creating an attractive work environment and culture. It’s like they realized what matters most to devs and really catered to that. This is plain smart.

More over, the demand is so high right now that I see devs in the driver’s seat. That’s probably the biggest difference I’m seeing now compared to even 2-3 years ago.

All of this can be yours while staying dedicated as a software developer. I will follow-up this post with advice on how to get to the higher levels of software industry. Look for that in the near future. Additionally, there’s more to the picture in terms of options for software developers and their career so I will follow this post up shortly with the rest of the story. Consider that this and the upcoming posts as an extension to what was covered in the Ruby Rogues podcast. It’s just that big of a topic and hate to leave somethings unsaid. Thanks for reading and by all means, leave your thoughts on the subject as a comment below.

Event Organizing 101

Wed, 02 Nov 2011 21:18:48 GMT

I’ve been speaking at both conferences and user groups about building community and improving what we already have in the Ruby community. At Ruby Midwest, I am giving a sub 30 minute version of this talk and had to cut out a good number of slides. In this process I realized several of these slides might do better as a blog post on the basics of event organizing. While this is not meant to be exhaustive it does try to cover the basics on putting together your first event.

To be more clear, this advice is mostly for ongoing local events such as user groups, hackfests, code retreats and the like. I won’t go into why you should organize, just the how.

Network

The first piece of organizing will focus on your network or connection to the local community. Hopefully you know your community somewhat. If for some reason you don’t, you’ll want to do this immediately. Get out and see what’s happening out there. Attend events, talk to people that are active in the tech community, see what they have to say. I’ve heard this a few times where someone started a new type of meetup only to find an existing one after the fact on a different night of the week. Instead of duplicating effort, exploring the option of combining efforts is much smarter and will lead to a healthier event long term.

Communicate your idea to your network. See if there’s any interest. You might find that by talking about it you’ll not only grow interest in it but also spread the word about the possibility. Your idea may grow once others start to give you feedback. While this may seem scary to you now, it’s a good thing as you can end up with a better event because of it. Though it’s just as important to know when your idea is being hijacked and you should say no.

Seek advice from other community leaders. It doesn’t matter if they’re in the tech sector or not, running an event is similar regardless of topic. They likely will be happy to give you advice and this can make things much easier to get your event started.

Finally ask for help. If you don’t ask, no one may offer help. Many will say no or seem uninterested, this is fine. Some may say yes while others may connect you with another person who might help you out. Don’t be shy, ask away.

Core Group

Before you proceed with your event, I strongly recommend you identify a core group of interested people. I’ve seen a suggested number of 10-20 but honestly this just needs to be big enough for you to still be willing to go forward with the group. If you’re doing a code retreat it could just be 5 people (a facilitator and two pairs).

Locating your Space

Finding a space to hold your event is pretty important and something you’ll want to arrange early on in the planning process. As I recommend you start small, look for a small space that your event will be comfortable in as it grows. Usually you’ll want to look for a free space. There are plenty of good sources in most communities. Depending on where you are looking to have your event this might be easy or challenging. The following list is sorted with the best choices on top.

co-working spaces – great choice that will likely have amenities you need and will likely be open to hosting you for free.
ruby friendly tech companies – another good choice for free space, may be limiting though on how much room you can use.
theaters, performance halls – while not free, these can be great locations for larger events of 50+ people
universities, colleges – typically colleges have space that students can use and will often rent out rooms to the community. It really helps if you have a connection to the school.
public libraries – I usually see these as free or very affordable. Some have restrictions if you’re charging admission though.
public schools – like public libraries, some public school districts will let community groups use their space. Never hurts to check in.
coffee shops – depending on the coffee shop, this can be a great space depending on the event type. I find the excessive foot traffic make it undesirable though.
bars – like coffee shops, bars aren’t a great choice though I have seen some work out just fine.

Finalize Details

Once you have your space, core group and general idea of your event figured out, you need to work out the details of the event. Start with drafting a schedule. Imagine what takes place in each part of the meeting. As you do this make a checklist of things you need to do as well as anything you need to bring and setup. Plan out your schedule to the minute and think of the little things such as where people get water, use the restroom. What about power, internet access, seating and table space. Though this is largely common sense, it’s worth mentioning so you don’t start your event and realize you forgot something critical and now have to scramble.

Web Presence

I almost didn’t put it in but figured it’s best to briefly touch on this so it doesn’t get skipped over. If you’re holding a public event, then you should have a public face for information. Essentially someone should be able to google your event name and find all the basic information they need on it such as time, date, location, description and any other details on signing up, what to bring, requirements, cost, etc. You should have a twitter account or some other source for sending out updates on your event. Having a mailing list/google group is another good idea for any group that meets regularly.

Budget

You should determine your costs by this point. Hopefully you’re running a free event but if not you need to have a basic budget laid out. Determine all your costs and record them. In the beginning you might have to estimate placeholders until you can get firm bids on whatever it is you need to supply. Common things include space rental fee, AV equipment and food. Consider getting sponsors to cover some of this as well. Many companies interested in sponsoring might have some of what you need or at the least are happy to pick up the tab for part of it. This is especially true if you’re running a free event that is there to benefit the community.

Finding Sponsors

This is for the larger events that have a budget and will draw more attendees. There are lots of places to find sponsors but it varies by community. The following list will give you some ideas on where to look. It’s sorted with the best bets up top.

local Ruby shops, especially consulting companies
tech companies interested in devs
recruiting firms
training companies
larger Ruby consultancies, companies not local
Ruby Central **

Ruby Central has in the past supported certain type events with grants. I would try to get all support locally first before approaching Ruby Central but it’s good to know the option is there.

One more thing I want to mention on sponsors is that many of them will have marketing or outreach budgets that can easily cover your costs (unless you’re doing a huge event). It’s good to seek them out early in the process and give ample time for them to review your event, what you’re asking and match it up to their budget and goals. Though I won’t get into detail on the process of negotiating sponsorship deals I will give a few pointers. First, be clear on what you’re asking for and what benefit the sponsors will get. Before approaching sponsors, have this figured out. There are plenty of cases where you might find a sponsor before you’ve planned this out which is totally fine. However, a typical sponsor will need to see this before they can consider supporting your event.

Reaching Out

This is probably the easiest and the hardest thing about event organizing. Getting the word out about your event and attracting people to it. Initially I recommend you rely on word of mouth, twitter and a blog post or two. Let it start organically and as time passes up the effort to expand your reach. The following list should give you some ideas on reaching out.

nearby user groups
tech friendly hang outs
word of mouth via core group
twitter, blogs
sponsorsâ€™ network
flyers at college campuses
meet with community leaders
local calendars

Every community is different so you’ll just need to be creative in asking around and figuring out how to get word of your event to ears that haven’t heard it. I think this is really important if you’re trying to grow community and go beyond those already plugged into local tech events.

Event Upkeep

This part is all about the various things you need to do for ongoing events. Though planning out the first meeting is usually the most work, you can’t just sit back and let it go. Depending on your format you’ll need to keep bringing in speakers or content for your event. At the least you’ll need to monitor how things are going and make sure you’re still on track with what you envisioned for your event. If things are drifting or people are losing interest, then figure out why and make course corrections. You should be constantly talking to your attendees and seeing what they think.

Part of this upkeep is the concept of ‘inviting continuously’. This can refer to speakers and content as well as reaching out to new people to come to your event. Encourage local tech companies to get involved. The shape this takes depends on your event but the point is you want as many companies as well as local speakers and devs to be invested in your event and cheering for your success.

Unwanted Behavior

The slide title for this section was ‘Weeds’ which I think is a great way of thinking about unwanted behavior. While you might not think this is a big deal, it surely can be. When left unchecked it’ll grow like a weed and overtake whatever you’ve planned. It also has the possibility to poison the waters and turn away potential attendees over time. I believe it is likely that all groups or events will eventually have to deal with unwanted behavior. This could take shape as bullying, offensive language, inappropriate comments or solicitations of various kinds. Hopefully it’ll never come up but prepare yourself for dealing with this reality.

One of the first things you should do is determine what sort of behavior is unwelcome. Draft up some basic language on what you expect or allow at your event. It doesn’t have to be legalese, just plain english is good enough. Some of this behavior will come from people who are unaware or insensitive to the fact that their behavior is a problem. Spelling out what is acceptable will go a long way to helping curb this sort of stuff. However, you’ll still need to be ready to deal with it. What I recommend is to be firm but tactful in asking the offender to stop the behavior. Language such as “this sort of behavior isn’t cool with the group” can be effective. Ultimately, you have to decide what’s the appropriate response based on the situation. The one thing I hope you do not do is look the other way. That how these sort of ‘weeds’ get out of hand.

I hope this gives you plenty of tips to get started and go build up your community. Though it can be a lot of work at times, I find it very rewarding and have stuck with it for nearly 6 years. If there’s anything I didn’t address here that is related and you’d like to know more about in terms of event organizing, please post a comment.