The reason for this, and this is where I agree with you, is most of these ’senior’ programmers have spent little time maintaining others’ code, have rarely, if ever, had their own code reviewed by peers, and have likely never jointly coded projects. In fact, the only consulting with others has been in the months of meetings before a small to medium sized project begins ‘designing’ the ’system’, with everyone attempting to assert their prowess in theoretical algorithm design (no math, no psuedocode, noting pertaining to the problem at hand, only gibberish and nonsense).

And the worst thing? The managers have not written code in 25 years yet consider themselves to be excellent programmers. They’ve never seen any of the code their current or past programmers have written, and are shocked to hear that all of the code in that has been written on their watch is unmaintainable spaghetti, because hey, it worked, right? Well, it sort of worked anyways. Except that’s only because the ‘junior’ programmers have been fixing the myriad MAJOR bugs in these systems for all these years, while the senior programmers worked on their next ‘masterpiece’.

While I am more experienced than anyone I currently work with, and more experienced than most that I have worked with in my life, I again find myself in the ‘junior’ programmer position, as the newest programmer at the healthcare institution I have now been with for a year. It is extremely frustrating trying to deal with old fogies who really and truly believe they are some of the best programmers in the world, yet cannot seem to grasp why when using an object oriented language, 2500 lines of code that do 30 different things should not be stuffed into one method, and maybe that shouldn’t be the only method in the class, and maybe your display logic and your data access logic and your business rules logic shouldn’t be all mixed up in the blender that is your code, but I digress.

You are spot on regarding code reviews, though in my experience they are generally of more benefit to the ’senior’ citizens, I mean developers. The idea should always be knowledge exchange. Learning from the mistakes of others, seeing how they use code, and sharing your expertise, that is what makes developers better, and that is what makes a strong, maintainable code base.

For the last 10 years I have been in the enterprise, so that may explain the difference in our experiences. It is no place for those of us that really care about code. I would guess that you may work at a software company, and your story would ring far truer in that world. That world, unfortunately, is one that I only get to experience evenings and weekends. Not too much longer though, I hope. As is evident in this comment, it is sucking the life out of me.

I think the best solution is use the framework. Whether the juniors write wrong or not, if it run correctly, it means that he/she (the junior) follow all the instructions. Especially when they using Struts. Even there is a lots of work. If they are NOT following the procedure using the framework(for example, bind the ActionForm, Controller and forward request at the struts-config.xml), there is no way they will success run the code.