Designing Your First Feature
Four Things To Help The Process Go Smoothly
Hi all,
I’ve talked about this a few times on my channel, but I’ve always felt that one of the biggest issues with college was that we didn’t focus enough on things you actually do on the job as a software engineer. A number of things fall into this category (and I’ll likely write posts diving into some of these topics), but one of the big ones is the process of designing and implementing features.
College assignments are generally quite limited in scope and require very little creativity in the sense of thinking about the end user. You’re given a description of the assignment, a rubric spelling out what you need to do to receive a good grade, and the peace-of-mind of knowing that what you’re trying to do…is actually possible.
Designing features in industry presents a new set of challenges that college doesn’t prepare you for - and I’ve learned a lot over the past two years from building my own features that I wanted to share, just in case it can help anyone else who’s about to tackle their first feature.
I’ll dive more into that down below, along with a few great resources, a sneak peek of what I’m working on, and this week’s question.
- Kyle
Designing Your First Feature
My first few months on the job primarily consisted of making bug fixes, contributing to small features, and a lot of learning. But, after a few months, I finally got the opportunity to design my very first feature - going all the way from the initial idea to shipping it as part of the product.
Since then I’ve continued to work on increasingly-complex features, and I’ve learned a lot about what the process should and shouldn’t look like. Here’s four things to keep in mind that should help the process go a bit more smoothly.
Get input
Unless you’re working alone, there’s a good chance that you’ll be surrounded by other developers who have more experience than you. Meaning, they’ve gone through this process before, and they probably have a few ideas about how to make your feature a success.
Before you invest too much time into your work, ask for feedback. You don’t even need to have a working prototype, let alone anything ready for PR - this can be as simple as writing up a brief outline that answers questions like:
What’s the purpose of this feature, and who is it for?
What are the basic details of the implementation?
How will users interact with the feature?
What are the risks/breaking changes/complications that might result from this feature?
The goal is to give people an idea of what the change entails (before involving code). If you can’t even agree on whether the feature is worth doing, it’s probably a good idea to sort that out before you spend a month working on it.
As you get further along in the development cycle, you should also solicit feedback on your prototypes. This can be in the form of code reviews, but this can lead to nitpicking the rough edges instead of focusing on the experience (although, code reviews can be very valuable at this stage if there are issues with the architecture of the feature). Depending on your product/team, you might be able to get some feedback from real-world customers using preview releases, which can be hugely valuable since dev-testing often isn’t representative of how users engage with a tool.
When receiving feedback, one of the trickiest things is striking the right balance between defending your ideas and being open to what other people think. You shouldn’t blindly accept every piece of feedback you receive…but you should listen to all of it. Sometimes people don’t have as much context as you and rely on incorrect assumptions (design can also be very subjective) - but if you’re getting a lot of feedback that runs counter to what you’re proposing, take a step back and consider a different point of view.
On my first big feature, I “invented” a more concise mechanism for allowing users to express configuration…and I thought it was pretty great. But it clearly had some shortcomings, and after receiving similar feedback from a few members of the team I went back to the drawing board and addressed the issues with the original design. That revised design is what I ultimately built and shipped, and I never would’ve made that change if it hadn’t been for that initial feedback.
Figure out the hardest technical challenges first
I read a great piece of advice a few months ago that talked about the importance of recognizing the biggest technical challenges you’ll face, and making sure you tackle those things first.
When you start working on a feature, it’s tempting to go straight for the fun stuff - this is something I’ve been guilty of doing on numerous occasions. But if you build 80% of the app and can’t get a fundamental piece working, all you’ve done is waste a lot of time building something you can’t finish. Start by proving out that you can build those challenging pieces, then move on to everything else.
Progress will be non-linear
It doesn’t matter how much time you spend on planning - you won’t be able to account for everything you’ll need to do. Some pieces will be a breeze to code and get working…other parts will be a nightmare and take way longer than you anticipated. Developers are notoriously not great at time estimates. If you can, give yourself flexibility and acknowledge that you’ll get stuck on some things. You also want to leave space for unexpected changes that might come up - when you’re planning out a large feature, it’s easy to overlook details that will become apparent later in the process. Too tight of a timeline, and those things can wreck your planned progress.
Of course, this isn’t to say that you shouldn’t have a plan - as stated in the previous points, you should try to get a sense of the challenges you’ll face and the scope of your change. But especially for big features that are slightly out of your domain, it’s hard to know exactly what you’re going to encounter until you get there. Even the changes that look trivial on the surface occasionally have hidden complexity - which can be incredibly frustrating when the task you planned to knock out in an afternoon ends up taking a week.
Don’t feel like you have to do it alone
When you’re working on your first feature, it’s easy to fall into the trap of feeling like you have to do everything by yourself. This was something I really subscribed to early on - the feeling of needing to “prove” that I was capable of doing an entire feature all by myself. The reality is: engineering generally benefits from collaboration, and especially if this is your first big feature, there will be probably be areas where you won’t know what to do.
There’s nothing wrong with asking for help, or even delegating parts of your work to teammates when it makes sense - the same way that you’ll work on parts of other people’s features, they’ll also work on your features.
Putting your own ego aside, it’s also important to recognize when you need help from someone else for the success/safety/timeliness of the feature. If you don’t have any context on something that needs to be done ASAP, it’s much better to work with someone who has context than to hack something together and hope it’ll all work out OK. This isn’t an excuse not to learn about areas where you don’t have experience…it’s recognizing where you have limitations, and that the product is more important than feeling independent.
Things Worth Reading
From The Archive
In Case You Missed It
Sneak Peek
Here’s a few things I’m working on…coming soon!
(Video) Putting Learn-To-Code Platforms To The Test
(Post) Making A Case For Automated Tests
This Week’s Question
I want to hear from you! Leave a comment on this story or email me at support@kylekeirstead.com with your thoughts/ideas.
What’s the most complicated feature you’ve ever worked on? How long did it take to get from idea→shipped?