How our ego can affect coding and architectural decisions

One of the rules that I made for myself as a developer is not to get attached to my code. Really, we tend to love our creation once it takes shape, but I find that it can go too far and have negative effects on the job.
This problem is less apparent with personal projects, more to do with projects I do  for clients, typically within a team.


Almost anybody who does creative coding considers code as a craft, of fine art. It starts as a rough idea with a vision and then you construct it piece by piece with careful attention, tackling problems during the process. Now you own that code, and over time you develop a sense of pride and confidence in the tools and techniques. This is where things can go wrong. Pride and confidence boosts you ego which can grow over time and cloud your judgement. I find it far too easy to cross the line from professional confidence to a being defensive and territorial about a certain piece of code (or architecture) and eventually becoming over protective and stand guard against any changes.


In the life cycle of a project there is a point, right after a stage is delivered and ‘sealed’ – that developers tend to protect their creation. “Don’t touch it” – I tell my client, the risk of breaking functionality is too apparent. Is that being over protective, or simply good risk management?

Remember, any code has an expiring date. In our dynamic field, technologies change rapidly and what might have been cutting edge 2-3 years back can look ineffective today. Not to mention code that was not so good in the first place and contains many TODO comments and is still waiting to be replaced. Rewriting and refactoring is part of our reality as coders, and no code is perfect – at least not for long.

Also, at some point any technology starts reaching its limits, and the existing code or framework simply does not support certain requested features. By then, the common line I give is “No, we can’t do it that way”. Ooops.. line crossed. Managers never like to hear about things that can’t be done, and rarely care about some technical mambo-jumbo. By then, its not long before they lose respect for you and start looking for some other developers to do that job.

But there is a way out, or rather a way to avoid these kinds of situations.
Don’t let your ego overtake your willingness to try new ideas – keep a balance between what works now and what might be a good solution down the road. Start by not getting attached to your code – as beautiful as in may be, since it could always use some improvement. Seriously, don’t fall in love with your code. The best way to prevent that is asking for ideas and criticism from within your team and being open to hear their opinions  - a fresh look can give new insights you never considered.

The same goes for entire technologies and frameworks. Being open to look at new technologies at all times to solve exiting problems is always important. Try to be dynamic, don’t marry into a single platform or technology or you will probably end up being confined to its limits. keep your eyes open for possible alternatives, and when the time comes break free and move on.

I’d like to hear if other coders face the same problem. What is your approach?