The Ten Commandments of Egoless Programming

The Ten Commandments of Egoless Programming, as originally established in Jerry Weinberg's book The Psychology of Computer Programming with my updated comments.

1. Understand and accept that you will make mistakes. The hardest part here is to make OTHERS understand that you can make mistakes without been pointed as an incompetent  looser. Maybe it is a "large enterprise" issue or an Italian stereotype but I find this particularly hard.
2. You are not your code. kind of a mantra. Feeling an artisan makes you sens your code as the product of your art.
3. No matter how much “karate” you know, someone else will always know more.  Seek and accept input from others, especially when you think it’s not needed. [TOTAL QUOTE]
4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer. [TOTAL QUOTE]
5. Treat people who know less than you with respect, deference, and patience. Very hard! I mean with coworkers you always tries to be understanding but there is a point when you sens you are wasting your time. What to do then? Keep going or Giving up? I got no clear answer... I realy on my gut on this. 
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.[TOTAL QUOTE]
7. The only true authority stems from knowledge, not from position. If you got this about yourself it's a good metric to become a senior. But do not expect this from others. I got too many times the " Because I said so" answer. Many people thinks that position means knowledge.
8. Fight for what you believe, but gracefully accept defeat. UH... too much zen in here if you put it in a long view perspective. How much mud can you swallow before throwing up? 
9. Don’t be “the coder in the corner.” Again do it... but be ready to got someone to tell you "back to your corner, coding monkey!" see points 7 and 8.
10. Critique code instead of people – be kind to the coder, not to the code. Works well with rule number two.

In the end you tailor your way to seniority within contrast and the true art behind it is to learn stuff that matters  learn to understand what is noise and what is important. And not  hanger in the process.

WTF: Why this flow?

Or The gentle art of spaghetti code. I'm Italian. I like spaghetti. As long as they come on a plate with some good recipe on them.
In the code I work with I prefer some other... pattern. What you see in the picture is the actual workflow of a very simple master detail view / controller set in a J2EE application. ( and I'm by far too generous using these definitions) . This is how it works:

1. the user ask for a url handled by a list controller. Without parameters the controller puts an object in the request with a flag which means " this is the first request" ( well this is also the actual name of the property) skip the query part and foreward to the jsp.
2. In the jsp there is a scriptlet ( yes a 90' style scriptlet) that set the above flag to false and set another flag to the "ready to search" value.
3. When the search button is clicked the request is handled by the same controller whom , upon flags examination ( with very elegant nested if statements) decide to invoke the dao layer and perform the query, dispatch to the jsp which , upon other flag examination again with scriptlets (AGAIN) display the results.
4. Clicking on one line in the result list will  invoke a second controller, which set the second flag to "display details now" and dispatch to the first controller which dispatch the request to the jsp

Amen.

Master detail should be simpler then this. In J2EE  eco-system Grails comes to my mind or my defunct project springears. Master detail , as many very very common use case and  should be handled in a DRY way. A simple, granular way. At least in the workflow management if the UI is really really complex ( although it shouldn't be).

This is not a a rant against a specific working day 'shit happens' moment, not Java/J2EE ( I did and have seen great things done with it). It's against bad code. This particular case is the rotten low hanging fruit of bad framework design and lack of long term view. This workflow is repeated dozens of times in the app becoming a pattern without a proper abstraction nor support ( and an ugly design at his root). The saddest final note is that the forth coming lack of will to deliver a good product and proper test do not allow me to make things better.

The bitter end.