Something I learned from the game industry is that sucky code can be the best code. Coming from the university and a company that treasured beautiful code, it w

Something I learned from the game industry is that sucky code can be the best code. Coming from the university and a company that treasured beautiful code, it was hard to get used to. I find that it's pretty similar to premature optimization. First you make it work. Then you ship it. If you constantly keep coming back to that code and find it difficult to work with, then you make it beautiful and modular. Some caveats: * You need a small team and a small code base, so at least one person near you knows how it's working. * Projects need to be time-limited. Ugly code will be much harder to read when you forgot how it worked. If the project is done and over with within a year, then it's fine. * Everyone on the team needs to agree that it's possible to work this way. Some people just freak out when code isn't beautiful. I got over it, but I'm not sure everyone can or want to. * One of the reasons we write beautiful code is that it's just simpler to write. It's a way to structure thoughts. In those cases, you should of course do that. It takes a while recognizing when to write ugly code.