It’s the first day of the startup and you hopefully have a few engineers (If you don’t, go get em’). You sit for many days thinking what you should develop you read the articles, books and sit through countless product brainstorm meetings. You know all about being Lean and Agile so you define the smallest MVP you can think of. It’s HUGE. Probably 5 times the size you actually need, but you don’t know that. You get your designer friend to help out and create a mock, you define and design the projects perfectly and you start coding.

This first piece of code is going to be one of the best crafted pieces of code you are ever going to write. It is fully covered in tests, scalable, beautiful and efficient. You have sleepless nights perfecting it, fixing and tweaking the web animation and any pixel that might be out of place. This is your baby and you love it dearly.

A month later you find yourself sending this code to the only appropriate place for it – the archived code museum – and you have to start from scratch because as beautiful as it was – this code is not useful anymore. As you’ve just learned from the clients who don’t need it like that, but rather would prefer something else.

Your next piece of code is going to be far less perfect, but far more efficient. You learn the actual definition of MVP, you shorten your cycle, you deliver features that weren’t really implemented, you test out calls to actions, you build frameworks and then replace them with other frameworks. You learn that a lot of your assumptions about what’s coming next are wrong over 50% of the time. You learn how to live in an environment that is more unpredictable than predictable. It is a hard process to go through as a developer and your code goes through it as well.

You will now move into a phase where your code is becoming downright rude and disrespectful, ignoring a lot of the things you once held dear. It is not fully tested, not robust, and sometimes it is not scalable. Small hacks are introduced to ignore bigger problems and shortcuts are the norm. Some architecture arguments end with phrases like “you never know what we’ll be working on tomorrow” or “I’m not even sure this code will still be here next week” and sometimes it is still there a month later. Above all else – you deliver, you test hypotheses, and learn as you go. Learning is the number one goal and if it means your code can’t scale to millions of users, you get used to living with that.

Your code is now hitting its teenage years and it’s becoming rebellious. Things break, systems become more complicated, and decisions you made in the past come back to haunt you. You get a lot of “Yes, I know this code is bad, but when we wrote it we had no idea that…” or “We had 2 days to deliver that feature – we had to hit the deadline”. In terms of product, you are no longer shooting in a dark room hoping to hit something. You know your market – you know your product, you might not have an exact product-market fit, but you are getting there. Your maneuvers become smaller and your code is becoming more consistent, and while it is becoming older, a few small scars linger of the stupid mistakes it made as a kid.

The final stage – adulthood – has arrived for your code. This is the time to replace what must be replaced and improve all the rest. It’s a healing process and you can feel its maturity setting in. Your team is bigger. You talk more about the code quality than before. New features look much better than old ones. You use new tasks as excuses to fix and improve on less mature, older code. Every new line that is being written makes your codebase better than before. You throw away a lot of code. Entire systems are replaced by ones that are a much better fit for your entire system. Test coverage is going up and better development processes are forming. You want to fix everything at once but you are smarter than that now. You know that incremental improvement is what works well. Code duplication is going away and better frameworks are the new norm. When you look at your code now, you feel proud at how it grew into the code it is today. Your code is completing the transition into being an adult and soon it will be as beautiful as ever and your task will be to keep it that way for as long possible.

Your code is not different than any other part of the startup – it grows and matures as much as your team and your product. It’s truly a pleasure to watch the process, especially from the driver’s seat.