How to ship features in your first job
I wrote this how-to for the new-hires and interns who joined Peoplebox recently. It might seem obvious for folks who have been doing this, but not for first-timers.
- Understand the feature
- Understand the feature, design, see what is there current experience. If new, understand the current code.
- Find out broken flows in the feature shared by the product/design person.
- Find out which customer needs it and why. See if this is the best solution. Wear your product manager hat.
- Understand how this helps the business. Your change should either bring in 🙂 or 💰
- Break into smaller releases/versions
- If the feature seems really large, break it down into multiple small, meaningful releases.
- This might be harder at first, but you could figure out what features to remove from scope from first release, but still be valuable for the customer.
- Benefits - faster release, less code changes to review, easier to test.
- Do the task breakdown
- Break the tasks down to minimum one day or half day.
- If something takes more than 1 day, break it further to achievable goals for each day.
- You’ll have a rough estimate of your dev complete. Accurate estimation is a myth.
- Add testing time to your estimation as well - this can give you task estimation.
- Build clarity in the tech implementation
- If there is a necessary technical architecture change required - plan for it
- For Backend folks - plan your models, important logic flows, service objects.
- For Frontend folks - Redux stores, Component Breakdown, Reuse of design systems
- Find better libraries, gems that can help you to solve this problem easier. No code is better than elegant code. Elegant code is better than shitty code.
- Start writing code
- This is when you should actually start write code.
- If you were fresh out of college, you would have started here earlier. So hi 👋 . Just acknowledge there are enough things to do before writing code.
- Update progress in the daily standup, if you foresee any delays - share in the standup.
- Keep back merging regularly. And keep pushing code to github as frequent as possible. Data losses happen.
- Test the feature
- Start with testing your code and components.
- Then move on to integration testing. If you are a backend person, test along with the frontend person.
- Find out edge cases - no one would know edge cases better than you.
- Code review
- Give it for code-review, don’t always request from the most common person. Find someone else in the team who can code review.
- Make changes based on what they suggest. You’ll learn, they’ll learn.
- Give it to test
- If all good, push code to staging environment to be given for testing.
- Help the Test team understand the edge cases.
- If any test data creation is required, help them to set it up.
- Release it to production
- Merge your code with master
- Release to production with senior engineers.
- Watch metrics after the release - see if users are using your features.
If you read this, also read 20 tips for your first job