As some of you might know, I started my career as the first
developer at a startup, way back in 2012. It was a challenging
but rewarding experience, and I got to learn a lot and explore
the full breadth of the software stack. The following are some
learnings that I wish I could tell my younger self.
Prototype like your life depends on it
“I know you guys are restless to get started, but before you
write a single line of code — Make a prototype and run it by your client”
I heard this line from one of the co-founders of a very successful
software services company. In a startup, the client might be your
founder who’s sitting in the desk in front of you, but code is costly
to work and rework. Always prototype, at least on paper. It’ll help
everyone visualise what they’re building, and see issues and limitations
before you even start on the implementation.
Image by Samuel Mann
Write a spec, and check it twice
Software is all about the spec. It defines the scope and the tests that
need to pass to mark the work as done. A spec might be as simple as a user
story followed by some acceptance criteria in the Gherkin format, but it’s
very important for estimations, avoiding the dreaded scope creep, and writing
high quality code.
A sample spec:
As a logged in user,
I want to access the Account page,
so that I can see my Account Settings
Feature: Access account settings page Scenario: Janith accesses the account settings page Given I am logged in as "[email protected]", And I am in the home page When I click on "Account" on the top menu, Then I am navigated to the "Account" page, And I can see my Account Settings.
Remember, you will most probably be your own QA, so write a solid automated
test suite that covers these conditions.
Timebox, timebox, timebox
You probably won’t have a Project Manager, nor will anyone really care about
Agile or sprints. The constant mantra will be “just get it shipped”. This is
damaging in two aspects: a team without a welldefined end goal and a timeframe
to achieve it in will drift and probably get demotivated, and you will not be
able to set up a good measure of how much work your team is able to tackle in a
given period of time–which will make it really difficult to draw up a project
Avoid this trap. Set up 1 or 2 week sprints, take up only stories that the team is
confident they can achieve in that timebox, and have a retro at the end of each sprint
to discuss what went well, what failed, and how the team can improve. Try your best to
ship production code at the end of every sprint. It will give the team a sense of
achievement, and that which is most valuable: customer feedback.
Know when to use Frameworks and Libraries
There are some terrible frameworks.
Often, code you write from the ground-up for a specific purpose will be faster and more performant.
frameworks for the longest time. This cost us a lot in terms of delivery speed and
maintainability, and especially made onboarding new developers hell. I still wonder
how things would’ve turned out had I used — say, Laravel or Python with Flask, or
KnockoutJS from the earliest days. We probably would’ve shipped a lot more features,
and at much higher quality.
Read up, seek support
Look, when it’s a tiny startup and it’s just two junior devs fighting fires every
day, you will miss out on a lot. You won’t have leads who will guide you on best
practices and design patterns, or architects who explain why TDD is awesome, and
why you should read Clean Code by Robert C. Martin.
It will be up to you to reach out: follow your favourite library authors on Twitter,
subscribe to a few good tech blogs on Medium and turn on the “Daily Digest” email.
Participate in the community and tech meet ups, and try to reach out to batch mates
or seniors working in bigger companies for advice and tips. There are so many people
willing to help if only you’d ask.
So yeah. Those are a few things I learned the hard way, and I wouldn’t trade it for the world. I hope you find it useful.