Add Value without Writing Code

While most of the ideas in this section so far have involved coding, there are other ways to add value without writing any code, such as writing documentation. Often overlooked by both young and experienced developers, the ability to write clear and concise documentation will set you apart from the rest of your teammates.

Transferring knowledge through written sources has been used by almost every civilization that’s ever existed. There’s a reason it’s so valuable, and writing is a skill that anyone can do and anyone can learn.

As a business matures, knowledge is gained. That knowledge is valuable, and it probably took a lot of effort on someone’s part to build an understanding of a specific problem, a customer pain point, or a nuance of the industry. When you work hard to solve a problem, fix a bug, or develop a new feature for a customer, try to document what you learned on an internal knowledge base.

It may seem like it’s extra work, but it adds significant value even if it goes unnoticed at the time. For starters, you can reference this in the future, as mentioned earlier. You may forget why you made a certain decision or chose to solve a problem in a specific way, and it’s helpful to be able to look back on your notes to figure out the context behind a decision.

Second, it’s an easy way to contribute to the knowledge base for your company, and it’s something you can do on day one when starting a new job. You may not even have access to the codebase yet, but you can make edits to the onboarding instructions if something was confusing or missing.

Third, the content you create on your company’s knowledge base will be searchable, so it will help your teammates find answers to their questions quicker and sometimes without interrupting you and your coworkers. It’s an asynchronous way to share knowledge, ideas, decisions, and processes that help newcomers build on the work of those before them.

Fourth, new developers will join your team and experienced ones will leave. Sometimes, important knowledge about how part of the codebase works or why something was built the way it was will disappear when a developer leaves the team. By documenting what you know and what you learn, as well as encouraging others to do the same, you’re able to pass along that knowledge to those who come after you.

Just like well-defined processes, thorough documentation is a quality of high-performing engineering organizations. If your team already has good documentation, you can add value by contributing to what’s already there. If your team doesn’t have any documentation, you can add value by documenting what you know and what you learn as you fix bugs and design new features, and by sharing that information with your teammates.

An important point to remember, however, is that it’s common for documentation to become out-of-date if it’s not updated regularly. When you’re concerned with shipping a new feature or a critical bugfix, it’s easy to forget to update the documentation to reflect the new changes. It takes discipline to keep documentation up-to-date and prevent it from becoming a knowledge graveyard. If you don’t take time to remove outdated documentation, it could easily have the effect of turning people away because they know the information in the company wiki is out-of-date and no longer relevant. Just like code, it takes a lot of work to maintain an internal knowledge base, but the payoff from a well-maintained system is significant.