I spend a lot of time building and reading reports. I also spent a lot of time shuffling files around, and formatting data.

If you’re like me, you probably also spend a great deal of time doing simple, mindless, monotonous tasks like normalizing data, working with log files, or transferring files from one development region to another. While they are completely necessary, these simple mindless tasks take a ~long~ time.

One of my favorite things to do when executing these types of tasks is to figure out where I can eliminate the inefficiencies in my process. Since I’m running a startup, and am not subject to the process of some large bureaucracy, the power (and responsibility) to optimize time-inefficient tasks falls with me.

What types of tasks I automate
Most of the time, this process starts with a task that I have to do twice. The first time I do it, I groan, but I suck it up and do it the brute force way. The second time, I look for a pattern to emerge, and if one exists, I write a script to do the bulk of the work for me.

Part of the fun with this approach is that, while you are performing a mindless task, you can let your mind wander about the ways you could be improving your workflow.

Tools of the trade
If you aren’t familiar with shell scripting, you probably should be. If you’re on the LAMP stack, get to know your cron tab. Also, QTP is a great tool for Windows UI automation.

Some Use Cases
Here are a few examples of time-saving scripts I’ve written. In the past, I’ve written scripts that
- Build Regions.
- Normalize Data into JSON, MySQL, or XML formats.
- Build cached versions of my codebase.
- Find Database Integrity issues, correct them, and notify me so I can investigate deeper.
- Backup my codebase and database.
- Comb my log files for a search query.
- Email daily, weekly, and monthly statistics reports to my team.

Bottom Line
It’s a best-practice to always be looking for ways to optimize your processes.

How much time could you save if you automated your repetitive tasks today?

One of the biggest differences between writing code at school and writing code today has been the need to work with, interpret, modify and/or rewrite code that my teammates have implemented.

It’s been a humbling experience, to say the least.

Everyone has their own habits, their own rhythms, and their own way of thinking about code patterns & implementations.

And when you don’t draw a line in the sand upfront, things can get messy, really, really quick.

So, one of the biggest boons to team morale (not to mention, my sanity), in the last 12 months, was when the team, together, developed coding standards to adhere to.

And the biggest boon was when we actually started following them.

Here are the standards that, in my experience, have been the most helpful in keeping both team morale & team sanity up:

- Introduce indentation standards. It’ really simple. Just nest if statements, loops, and function declarations with tab indents. It allows my eyes to scan code 3x faster than when for loops, if statements, and methods aren’t indented. And that’s just fantastic.

- Comment every method you create. We list the preconditions, postconditions, return variables, and input variables for each method in our code base. We have a standard comment template that is already formatted to receive these values. Here’s what it looks like:

/*********************************************************/
// - Input vars:
// - Preconditions:
// - Postconditions:
// - Returns:
// - Comments:
// -
// -
function Name($InputA,$InputB,$InputC,...) {
//Method code goes here
}


- Introduce variable & method naming standards. Simple standards around how you name your variables can help code readability a lot. Start with simple things like what to do with individual words in variable names ($AVar or $avar?), whitespace ($A_Var or $AVar?), upper & lower limits on length.

- Make code granular & reusable. This is another one that sounds like a no-brainer, but in practice sometimes it’s a hard one to stick to. There’s an entire body of academic research on why your code should be de-coupled and cohesive.

- Find & follow a standard design pattern. The nice thing about design patterns is that someone has thought out the common issues and written rules for you to follow. For me, Model-View-Controller has made my life so much easier. If you’re writing a web app, that’s probably the main design pattern you’ll want to familiar with.

- Peer architect. I like the practice of talking over solutions with teammates before I implement them. It’s a useful way to lay out your design theory and test your assumptions, before you actually write a lick of code

There you have it. I’d be interested in hearing what standards your team has developed, and how you enforce them / make sure you stick with them.

Oh, and if you want to follow musings of the awesome development team I work with, please do so here: @nleach @aycaaksu @maxstoller @maxmeyers, and @zeve .

One of the most crucial things our team did over the last year was adhere to a rhymic development schedule:

Every Monday, we release code from our development region, to our production region. For the rest of the week, we analyze our business requirements, design accordingly, and implement new features in our development region.

This allows us draw a line in the sand when it comes to prioritizing features. It allows you set firm targets and deadlines. Abstract questions like “Is feature X more important than feature Y?” become more practical. The conversation becomes: “Can you get both feature X AND feature Y into the release on Monday?” , “No? Ok, how about just feature Y, then?”.

It also allows us to break projects into manageable chunks to iterate on week over week. Iterating, measuring results, and repeat. It’s a fantastic way to stay agile. And staying nimble & agile is the goal for the development team when you’re trying to find the ~right~ product for your market.

On to the details:

What day do you release?
We’ve had a lot of internal debate on what day of the week to release. We chose Monday because it allows us to start fresh and focus on new priorities for the week (Provided there were no issues with the push).

How long should your iteration cycle be?
My team releases weekly. I’ve heard stories of many other startups who release weekly. Some release daily. I’ve found that the overhead involved with pushing code live is too great when pushing on a daily schedule. Anything over a week, and I’m concerned that we aren’t iterating fast enough.

How much effort do you contribute to QA?
Quality assurance is a major concern when you’re developing a consumer app. In my opinion, it’s best to design multiple levels of QA into your process, executed throughout the week. A suite of unit tests helps to catch bugs introduced throughout the course of a week. Next, each team member is expected to troubleshoot and certify their own features by release time. We also do a weekly QA session in which we catch bugs before we do the push.

Do you follow any ‘development methodologies‘?
No. For now, we’re wary of adding too much process too early in our company. Though, we do regularly study our process and evolve it as needed. Agile looks like an interesting option for the future. As does Lean Programming.

All in all, your release rhythm will probably depend a lot on your product, market, and most importantly, your team. When making decisions about your development rhythm, start with the low hanging fruit, like ‘How long do we want our cycles to be?’, and ‘What time of the day/week/month/quarter do we want to release?’, and move on from there.

Oh, and don’t forget to have a fun through the process. One of my favorite parts of being in a small team are the fun little events (LAN parties, dinners, lunches, etc..) that we schedule to celebrate a big release.

Initially, the idea was the share ideas, make jokes, and be involved in the hacker community. The idea was heavily inspired by Awkward Rules, xKcd, and Abtruse Goose. It was way harder than I thought it’d be. Especially as a side project. In the end, I discontinued the project as a result of a) a lack of motivation and b) a lack of inspiration.

Here’s a few unexpected things that happened, and the lessons I learned from it:

I overcommitted. From the start, I promised new comics 5 days a week. That turned out to be too much, especially for a newbie author who has little experience creating creative content. I found myself running out of energy to create good content, and I think I settled for some punch-lines that weren’t my best. I think, next time, a better strategy may be to just publish as the content comes to me.

Good content is not easy to create. I’ve come to think that humour is one of those things that is easy to understand, but hard to create. It’s really really tough to create good content on a consistent basis. To do so, you need to continually search for inspiration, even when you don’t want to.

It’s hard to fight a war on two fronts. My work at Ignighter comes first. When you’re giving 100% to something, it’s difficult to contribute more energy to a side project.

All in all, I’m glad I did it. I had some fun times and shared some laughs.

Here’s some of my favorite startupcomix:
Please forgive the formatting. I wanted them to be readable here, but couldn’t find a way to do that and still make them fit within the content area.

- 0×13 - Be careful you don’t get a PWI

- 0×9 - SVN Revert

- 0×7 - Precisely, how long until Google controls everything around us?

- 0×6 - Strangely Hypnotic

- 0×2 - I’m a PC, and I (insert quippy remark here)

- 0×14 - Top Ramen, the food of kings.

- 0×18 - E! True Interview Story. The Awkward Interview Question.

- 0×19 - Did you hear about the guy who was born on January 1 1970?

- 0×1b - Twittles of Existence

In my experience, a lot of young developers don’t seem to do a lot of research on the company they’re interviewing with. And, they also don’t understand or haven’t fully contemplated the differences between their current corporate job and the startup environment that they want to work in.

Inspired by Brad Feld, who recently wrote a post called Preparing For a First Meeting With Me, I thought I’d lay out some of the things that are most common interviewee patterns I look for. Luckily, a few of these patterns correlate nicely with success on our team, even more than a candidate’s resume, or technological know-how.

Here we go:

Be a self-starter. Though the term ’self-starter’ may be an overused buzzword, actually being a self-starter is the #1 leading indicator of success for a prospective team member, in my opinion. If you’re excited about work, and like working hard in order to better yourself, your skill set, and your company’s product, you’re going to find a way to do a great job. In contrast, there’s no bigger turn-off than a team member who calculates how little they can do and still get by.

Don’t make outrageous compensation demands. Like many things, working for a startup is all about balance. We’re an early stage shop, work is challenging, but it’s a lot of fun for us, and we aren’t made of money. If you want a 6-figure salary, you’ll probably be better off interviewing at one of the banks down on Wall st. EDIT: I should note that, while we don’t pay a base salary that’s comparable to a late stage, well-established company, we do offer generous stock options, which are designed to be very profitable when you help the company grow.

Do a little homework on us. Our team is kind-of like an open book, if you know how to use Google, Twitter, or Facebook. Spend a little time checking out our site, our about page, team page, blog, and magazine. It’ll give you an idea of what working with us will be like. Plus, it’ll give you something to talk about with the interviewer. If you can figure out what my biggest problem is, and position yourself to be the solution to it, then let’s just say.. you’re in great shape, to say the least.

Be sharp. Just because we don’t have a dress code doesn’t mean we tolerate sloppy thinking. Give thoughtful, honest, and engaging answers, and please please pleeaseee have a few questions for your interviewer.

Have a track record. The old adage, ‘actions speak louder than words’, speaks very true to me. If you are coming from a corporate IT job, have no record of entrepreneurship, and want a job with a startup, then you’ll probably do better to a) evaluate why you want to make the switch, b) whether you have the energy, and c) if so, why haven’t you tried something on your own? It’s never been easier to start a web shop out of your apartment than it is today. And even if you try and fail, you’ll at least have shown that you’ve tried.

Establish that you’re trustworthy Eye contact, strong references, and a balanced demeanor are all good ways to start.

Be yourself. We’re a startup, not the borg (yes, I saw the new Star Trek movie). Don’t be an automaton. There must be something interesting about you. If you have a drop of personality in your body, don’t be afraid to show it, it will help us get to know you, and may even help your chances of getting the job.

Welp, that’s my shortlist. How about you? Entrepreneurs, what indicators of success do you look for when selecting new teammates? Job hunters, what strategies do you use to convince interviewers that you’d make a good fit on their team?

Wow. what a weekend.

I’d forgotten how much Boulder is the type of place that will just humble you. Beyond the natural beauty in the town & the energy of the hundreds of people hanging out on Pearl st for the Boulder Creekfest and BolderBoulder this weekend, I was completely re-envigorated & energized by the technology community in this town.

We kicked off the weekend by meeting with David Cohen, Dave Morin, and speaking on a panel about do’s & don’ts for the Techstars summer program. Afterwards, the team went out to dinner with EventVue, Foodzie, Brett Jackson, and Occipital. Other highlights of the weekend were the Tee & Cakes Cupcake eating contest, in which Boulder’s own Micah Baldwin placed 3rd, and hanging out with the 2009 Techstars teams on Saturday afternoon.

I’d forgotten how fantastic it is to just connect with people who are doing what you’re doing, starting a new web community from scratch. The tech community here is passionate and energetic. They are humble, but they are bold. It’s amazing how much the tech community in Boulder has grown over the past several years, given the leadership of some of the established folks in the area.

I’m thinking a lot about community, lately. I think that, maybe, technology’s biggest offering in a globalized world could be it’s ability to connect us to others around common interests, hobbies, or passions. I’m thrilled to be building a platform for a community of people who are passionate about meeting new interesting people at Ignighter. And, it’s a lot of fun.

My 3nd week on the job, I discovered a major bug in our app. One of the main flows was broken. And it wasn’t pretty.

So, what did I do? Simple. I did what any competant developer would do: I fixed the bug.

Though it only took me 15 minutes to fix the bug, it had taken me 3 weeks to figure out it had even existed.

Although the bug had been fixed, I faced a major problem. I couldn’t let this happen again! How could I prevent something like this from happening again on the app? Or, at the very least, how can I make sure I’m aware that it’s happening if it does? That part wasn’t so straightforward. But, over time, I’ve developed a system. First, I capture what’s going right, wrong, or part-right and part-wrong, in the system. Then, I built reporting tools to notify me when things are going badly, and to give my team data to help us lay the foundation for making decisions on what features to build, iterate on, or decommission.

Here’s the solution I devised. I have a method that I can call to log an event anywhere in the system:

MetricLog::LogEvent($EventName,$EventMetaData,$User);

Doesn’t look like a lot of code, does it? It isn’t. It should be stupid simple to track anything in the system.

Though the logging code may be minimalist, the table that I record my events on is anything but. It’s several million rows of data, each with 20 columns of metadata about that event.

At a high level, here is the list of data I track for each event on our system:

- Unix Timestamp
- Event Name
- Event Metadata
- User who performed event
- User metadata (age, sex, location, etc..)
- Group who performed event (We’re a group dating site, remember)
- Group metadata
- Client metadata (IP address, user-agent, physical location, signup source, re-engagement source)
- URL that event was performed on.
- A hash that uniquely identifies the session.
- The split the user was on, if event was performed on an A/B test.

I track everything from 404 errors, to major technical hiccups, to pageviews , to new registrations through this system. Building the reporting system in house allows me to build whatever reports I want on top of the data. Tracking EVERY aspect of each event allows me to split the data in my reporting system. Imagine if you could build reports that could be spliced by age, sex, location, timeframe, visitor location, visitor referral, and user-agent. Another thing this allows me to do is track the exact flow of a user who encountered an error, or evaluate how many users an error has effected. It’s pretty freakin’ useful.

After you’ve got the basic system setup, it’s trivial to set up a cron job that emails you if something’s amiss. Our team receives daily, weekly, and monthly reports of all relevant activity on the system.

It’s nice to know what’s going on in your product. It helps you build a data-driven decision process.

Also - I should note that your privacy policy or TOS must state up-front that you’re tracking what happens on your system, that this data will be used to make the app better, and won’t be shared with anyone outside the team. It’s an important disclaimer.

Good luck, and feel free to leave a comment if you have a question.

This post’s intended audience is current & future Techstars technical co-founders, though many of these lessons apply equally to any technical folks who’re launching their own consumer web startup.

These are some of the practical software-development best practices that I somehow missed during the first 3 months at Ignighter:

1. Use source control. If there’s one thing I’ve learned, it’s that sometimes, you just gotta revert what you’ve done. Sometimes, you may need branch your source code in two directions. It’s best to have source control in place now, rather than waiting until you need it. I recommend subversion, but have good things about Git.

2. Log everything. If you’re only human like me and are on an intense delivery timeframe, you’re bound to make a mistake or overlook something. 404 errors, user input, slow scripts, or any other sticks-in-the-spokes problems. I log it all.

3. Get a designer. A lot of programmers just can’t wear both the design hat and the coding hat. Myself included. I try to adopt the mantra: ’suck less every day’. But, in the meantime, find someone who knows what they’re doing, and use their stuff. I recommend Techstars Sponsor, Slice of Lime

4. Don’t open up your system to the public until you’re ready. Two words: brand dillution. Ignore it like the plague, at least until your shit works.

5. Use standards compliant patterns. I can’t tell you how many times I tried to take a shortcut at the expense of learning & using the standards-compliant way of implementing a solution. Save yourself the hassle. Just do it the accepted way, erhm, the right way, the first time.

6. Don’t get attached to your code. There’ve been a few times when a business reason developed in which a certain area of our site wasn’t needed anymore. I’ve found that it’s less painless to let go. Just… let… go. I always try to remember: Biz dev sets the strategy. Development executes.

7. A/B Test. At many times, our team would find ourselves at an impasse over the direction to take a feature or design. Sometimes, rather than a spirited debate among ourselves, implementing features both ways and testing how actual visitors respond is best.

8. Find good help. Whether it’s through the techstars mentor network, the Boulder community, or a new hire in your company. If there’s a skillset you’re missing, look to fill it. You’ll never have a better network of talented young developers than you will this summer.

9. Develop code quality standards, and stick to them. I was nearly driven insane until our team adopted a strict MVC pattern. ’nuff said.

10. Develop a rhythm. It helps build a sense of progress and a weekly deadline to shoot for. Product meetings on monday. Log review day is on friday. QA is on friday. We release on Mondays.

Good luck with everything. Oh, and don’t forget to enjoy it. 2008 was a landmark summer for me, in no small way.

I’ll see you around the bunker. Oh, and you can follow the musings of the ignighter team on twitter at @ksowocki, @danosit, @arsachs, @aycaaksu, and @nleach.

Come to think of it, many of my favorite folks from Techstars last summer were runners. Krista Paul, Brad Feld, & Vikas Reddy to name a few.

Distance Running is all about not giving up. So is starting a startup. Here are some other parallels I see between being a good entrepreneur and being a good runner:

- You’ve got to take it one foot at a time.

- You might now know where exactly you’re going when you set out, but you have to have faith in your ability to get there.

- Though the lifestyle is a lot of work, the payoff is worth it.

- Intellectual honesty is key. Know your abilities, and learn to tell the different between when you’re getting burnt out, and when you can push yourself harder.

- Both are excellent exercises in learning to marginalize your self doubt.

I’ve had some fun results using twitter to find recommended applications. In my experience, tweeps respond to queries only if they are specific and easily relateable. (see screenshots below)

Pandora vs. Last.FM. In this case, Last.FM won.

Do people recommend delicious? The answer is a resounding YES.

This one was just for fun. Turns out, many people who use Twitter have dual-monitors.

Twitter is great for web nerd questions. Below, JQuery vs. MooTools. Turns out it was JQuery 2 to 1.

4/4 of the people who responded this twitpoll respond to, welll… twitpolls. Go Figure. Must be some sort of implicit bias.

Have YOU had any luck finding interesting new applications, new hobbies, new workflows, or new people on twitter?