Things To Do Before And After You Write Code

The most effective engineers I’ve worked with were effective not just because of how they wrote code, but because of things they did when they were not writing code. Here’s my (growing) short list of things you should do before or after you write code.

Before

1. Understand what you’re building. Do you have specs or requirements? Are they clear? Do you understand what users you’re building for and how they’d use what you’re about to build?
2. Understand how it might need to change in the future, so you can design for adaptability. Are there any assumptions you’re going to make now that might hinder your ability to adapt your code in the future or expand your functionality.
3. Understand why you’re building it. If you’re building it, there should be value to your users and the business. What is that value? Do you agree with it?
4. Understand why build it now. Presumably, there are other things you could spend your time on. Why is this important right now? Is it creating more value than other options? Does it unlock other dependencies that require that this be completed?
5. Have a plan for how you will build it. Depending on the complexity and the stakeholders, this plan could be a couple sentences you run by a team-mate, like “I’m going to have to modify our data model, which will involve a migration, and change one API call.” For more complicated changes with many stakeholders, this might involve a Request For Comment document, or a fully-fledged Design Document to discuss with your team and other stakeholders. There must be some thought. If you can’t put it in words, you’re not ready to put it in code.
6. Think through side-effects. Will you stress certain parts of your infrastructure? Have to refactor a part of the code base?
7. Develop a mental map of stakeholders. Who might you need to check with or communicate with as you build? Your product manager? Designer? Executives/leadership? Someone else on your team who’s irrationally excited about this feature and has been championing it for months? Anyone who would be surprised by any your work, positively or negatively, is a stakeholder.

Note that you might need to do some “pre-work” to figure out some of the above, like #5 and #6. That’s fine. But treat that work as “pre-work” not as actual work.

After

I’m a big believer in follow-through. None of that “get it done and toss it over the wall crap”. This may sound like it’s not your responsibility, but you should always own the quality of what you’re building.

1. Instrument some metrics / quantitative results. Depending on your product and number of users, this might be very simple or very complicated. But you want quantitative numbers that show how many people are using what you build and how.
2. Gather qualitative information. Ask to watch someone use what you built. Use products like FullStory.
3. Do your own QA. Even if you have product managers, QA testers, etc, own your own quality. Figure out what the testing plan is and decide whether it is sufficient or not. Test it yourself. Dogfood it. Ask to roll out incrementally.
4. Get feedback from users and stakeholders. Have a list of what was successful and what wasn’t. What can be changed in the future? Have a list, even if it’s not going to get worked on now.

You’ll notice as you do these things more and more, that your work will stand out. People will value working with you. The quality of your work will improve. And most of all, you’ll build better and better judgment for how to do your future work.