Biased design: How past projects colour our coding choices
23 Oct 2025
He devolves upon his own world the responsibility of being in the right against the dissentient worlds of other people; and it never troubles him that mere accident has decided which of these numerous worlds is the object of his reliance, and that the same causes which make him a Churchman in London, would have made him a Buddhist or a Confucian in Pekin.
-- John Stuart Mill - On Liberty
I think few things bias how a programmer views the quality of code than the past projects they've worked on. This bias can affect everything from their view on the best language, no dependencies and their use, how to architect code, and on testing.
Below are a list of things that I've noticed bias people's approach to programming.
The irony isn't lost of me that this list is based on my experiences. To defend myself, I try to expose myself to different programmers thoughts, and reflect on their approach rather than just imitate, in an effort to avoid learning most lessons by experience. Although I think ultimately we're going to biased towards lessons learned on the projects we've worked on.
How many people are on the team
- If you're used to working on a large project with many programmers, you'll want to code in such a way that nobody needs to understand the whole. Keep each part siloed, and can be tested independently if possible. And you might be willing to pay a heavy cost to do this because of the organisational nightmare ofFirst project is agile/wagile, jira board, etc. will be inclined to think it's necessary for all projects. People don't tend to think outside the box on these things.I'd be interested in working on a project that used Basecamp or something similar.
Team processes
Performance/security requirements
- Heavily intensive testing vs no testing- Mars rover vs internal company tool- Security / uptime requirements
Complexity of the project
I think most programmers believe complexity should be minimised, but the degree varies. In my opinion, some programmers casually introduce huge unnecessary complexity under the guise of cleanliness, organisation, and professionalism.When a project is complex, programmers tend to focus on keeping the solution simple, solving the problem at hand, because it's complex enough as it is. Adding unnecessary complexity can make a codebase unworkable, and to do it on top of an already complex problem is even more deadly.So it seems logical to me that programmers have worked on complex problems are more likely to value simplicity, where as programmers on simple projects will tend toIn this case, I think working on complex problems makes you a better programmer, in the same way that climbing hard rockfaces makes you a better climber. Those working on simpler problems can make mistakes without being stung, as the demands of the project are low.They might even interpret their approach as "best practice" when it wouldn't work with a harder problem. The irony here is that the more able a programmer is to deal with complexity, if they work on simpler projects, the more likely they are to casually add complexity, and make it hard for juniors - if idiosyncratic complexity, seniors too - resulting in a constant need for help.I also think working on hard problems makes a programmer better appreciate the importance of cognitive load.
Deadlines
- Time pressure
UX priority
Team culture