We Need to be Smart, and Smarter than Before

At Skillshare, we're iterating every part of every corner of the product, ten times a day. We build something one week, re-build it the next, set impossible deadlines and hit them. It's a familiar story — an echo of an often-narrated 'start-up life', and we love it.

We're all finding new ways to function better in this ecosystem; to better our productivity, our process and our team.

Regardless of our role within the team, the way we make today happen travels fast up-stream through the company, and being an engineer is no different. We need to be smart, and continually smarter than before.

When you move so quickly as a team, how can we, as engineers make sure every decision we make is the right one? And how can we get there efficiently without the tide of change catching up to us?

The code we write today will be irrelevant tomorrow

It's easy to think of every new feature as an opportunity to showcase your skills, to test-drive a new lib and add a dash of magic behind the scenes.

We all crave this experimentation, but there's a time and place. Our timeframes at Skillshare mean that we need to itterate at the flick of a switch, so any code we write needs to be efficient and considered, because tomorrow it will likely change.

Let's remember that non-mandatory code accumulates. Let's not get sucked into building something beautiful, only to have it change tomorrow and washed away down the road at the cost of time.

The code we write today needs to support our future

No matter what stage a company is in, tomorrow quickly turns into 6 months.

Impossible deadlines mean we need to move fast, and with impending launch, it can become all too easy to shortcut a solution just to hit that date.

This is both the toughest and simplest problem to recognize as a start-up. It's tempting to treat each feature as a new project without foundations to build on-top of. Knowing when to plan further ahead than the current moment dictates, can prove a win in support for the future.

At Skillshare we've recently implemented Backbone.js as a solution to better suport our application going forward. Test-drive projects like these. Find small mini-projects inside your product and see how they fit in your family before you roll them out.

Care about your product to delight

The time users spend with our product is an imperative relationship. Delighting users and caring about the experience they have while doing so can make all the difference in keeping them around. Knowing when to care is a delicate lesson in learning to listen and knowing your team and your product. It's ok to go the extra mile when the reason for doing so is a result beneficial to the community and not simply for aesthetic.

In a recent Skillshare update, we revised our learn page. We found that listing our classes vertically, rather than tabular improved readability of the classes. We were challenged with the problem of informing users about where they were located in the list as they load more and scroll down the page. The solution we implemented was inspired by the iPhone's sectioned table view (e.g. address book). We chose to anchor navigation to the top of the page as you scroll providing an informative method of navigation that we feel is both delightfully different for use on the web and non-obtrusive for the user:

We're still a super-small team at Skillshare. We're constantly building, but always in a way that keeps the field of vision wide open in support of the future.

I've never coded so fast in my life, but coding fast doesn't mean coding quick. Taking the time to be smart when building the next new feature can ensure our products prevail. And when the tide does come in to wash away last week's code, that's ok – we can rest assurred knowing that what we built was exactly what needed to be, and now, let's do it again.