| When I started out as a junior developer, I was put onto a team of 4 other developers that was building a booking system for a leisure company. I got the impression that one of the developers on the team was particularly smart because he would lock himself away for a few hours at a time and build something amazingly complex that nobody else really understood. Ultimately, he only worked well when the application was still in development. When it came to shipping it, a lot of the areas of the application that he had worked on had shortcomings or just didn't work. Fixing them was also difficult because of the complexity, which was always made worse by the frustrating thought of "why the heck didn't he just implement this the simple way?". The work got hard, and the team crunched to fix the problems. He just resigned and left and found another "greenfield" project to work on somewhere else. In a way, him leaving ultimately helped the remaining developers - we didn't have to keep his unintelligible, not fit for purpose code. Now, all of these years later and I'm the lead developer elsewhere. I now often have to politely brush off efforts to introduce needless complexity that developers propose infecting our codebase with. Writing code is fun, and building a caching system might be fun, but in a working environment you need to deliver what the customer wants and is happy to pay for. If the work being done isn't on that path, it shouldn't be done. I guess I'm sharing this to say, perhaps those brilliant developers aren't that brilliant. |