Moving to the architecture side of the programs made me ask a simple question all-day long: "Why?"
Most of the time I get reasonable answers, some developers actually know better than I do what is the problem they solve. From time to time there are good discussions which teach me. When a discussion which teaches me happens it means the day was extremely profitable! The problems arise when the answer is awkward.
In some cases, rare ones, I received an answer beginning with "it's for..." followed by some unrecognizable sounds and a quick "I'll call you later" hang-up. The code on the 2nd call somehow was lighter, more efficient and readable.
In most of the cases I get an answer like "the book says it", or "I'm used to" or "why shouldn't I use a time-wasting algorithm on a fast computer". Usually it happens when the developer is a fresh developer out of the academy or whatever they call it. Those are the most hard to handle people, too much theory not enough field practice. The fact 90% of the people wear watches on their left hand doesn't mean the other 10% are wrong. Same goes for using some design patterns. Separating the company to 3 different environments (DEV, QA, PROD) is usually a good practice, but creates extra efforts if there are separated programs in each section. The effort multiplies if each product has its own set of testing environments. The end result of not separating it correctly is "job security" for the poor DevOps.
All those problems could have been solved, or at least handled a priory by asking the simple question "why".
"Why do you separate the environments by product instead of work mode?" Is it because the company works this way or because it's coming from a book? Does the permissions model come from a business requirement or is it a "nice to have" feature equivalent to digging random potholes in the floor? Same goes to the communication protocol used, did you choose something according to requirements or according to tech-department's amusement? Left on their own techies use the latest technology possible, but it might mean the older technology pieces won't work. My new DELL computer doesn't have any legacy USB ports, you can guess the annoyance it causes when the company supplies only USB headphones.
When it comes to development the first "why" is regarding the framework - programming language, source repository and build machines. Companies which have some infrastructure already built are exempted from this, the cost of moving from TFS to Github is huge for a mid-large company. When you have the infra in place it's usually better to continue with it unless other issues intervene. For a new company or a small one the question is different. Switching a small project from one infra to another, regardless of it being the programming language or build machine, "cleans" it from the extras accumulated over time. That code which was added at 2AM during "the caveman hunting feast" crisis, and suddenly fails due to an invalid reference, in this case the "why was it added" is clear, but "why wasn't it removed yet???".
