Dear Developers: Take On Growth Projects, But Do So Responsibly

As a developer, you should always assume that others will eventually work on your old code. You may never be aware of the fallout, as in when you leave a job. Or more covertly, when a curious dev peeps and “borrows” part of your setup via Inspector tools.

It’ll definitely happen in a situation you pretend doesn’t exist: when a client decides to take a project elsewhere.

Sure, you yourself gleefully take on new work, even if it’s legacy code (or perhaps have to if it’s assigned). And then what do you promptly do? Complain about how awful “the other guy” did.

My plea is to approach work with the intent to do the best job, holding yourself accountable to standards, semantics, and rules of your chosen languages. Don’t just focus on efficiency, which is when shortcuts are taken. A strong focus on speed is when lies of “I’ll fix it later” or “What the client/user can’t see won’t hurt them if it works!” creep in. And the more you allow those lies, the more you do yourself and future devs harm.

When I’ve been most frustrated with an inherited code base is when the dev(s) clearly were more concerned with time than quality. Time is money, right? Always be shipping? Sure. But — for example — do you really feel comfortable shipping malformed HTML that wouldn’t pass even basic validation markers?

Slow down, and have a bit more respect for the project and your own growth.

If it truly is a matter of your own lack of subject knowledge, hire out what you don’t know if time is most important. Later, put in some non-billable time towards learning and improving your craft.

I love growth projects — things that challenge me to use everything I’ve learned up until that point, and then ask me to expand my knowledge even more. I encourage my teammates to take these on. But part of growth is learning when to be honest about your limits. Don’t charge forward into a project when you have doubts about doing the best job given constraints, such as time, at odds with your existing skillset.

Honestly evaluating your limits doesn’t mean you’re admitting failure. Rather, you’re being responsible and respectful of yourself, current coworkers, future devs, the client, and the end user.

You will likely get the opportunity to do similar work in the future. In the meantime, use personal time to improve on areas you felt would have been weaknesses. And build a network of masters in areas you know you might never foray into at all. For example, you may focus on front-end but not have a desire to learn how to design a thoughtful UX even though it’s important to the quality of the final project. With an established network, you can reach out for advice, or hire out/share the workload when needed.

Approaching your work by assuming someone else will eventually take over can do great things for the quality of your code, and improve overall project outcomes. By responsibly voicing your limits in order to take more time to learn, you will find greater longterm success and happiness in your career.


I’d be interested how you handled filling in your knowledge gaps while still turning out a quality product, especially if your operation runs lean.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.