It is all about the audience and the message you are trying to convey. What you say and how you say things to a group of developers is much different than mid-level management. The terms you use and the level of detail needs to be appropriate for the people that will consume it. So, start with the point you are trying to convey. Then ask what is a meaningful way to talk about that point to the audience. That will get you going in the right direction. Good Luck!

Do you think it is possible that they are growing in other ways? Maybe in areas that are not directly visible at work. To be charitable, I think you must recognize this as a likely possibility.

I also work in the manufacturing industry and have had many years of on call support. Even though it is not always fun, it was very valuable. In the manufacturing industry (industrial robotics) it really helps to understand the environment in which these machines operate. It is important to also understand all the different kinds of users. This domain knowledge is what differentiates the great developers from good or average developers. The code we write is not always that difficult, but without an understanding of the context, it is easy to make the wrong technical decisions. I am glad I did the on-call support early in my career. Definitely....

Are you describing something similar to LabView? A kind of flow chart programming system that has been around a long time.

A better question... Is it your awesomeness that makes you so great, or your greatness that makes you so awesome?

First of all, remember who you work for. There is no need to be subversive. From your description, it is clear you have a very incomplete understanding of the business domain/problem domain. I suspect your boss also lacks a practical understanding of how the business operates as well. All of this is OK. It happens. You need to turn this situation so it is not a power struggle between you and the boss, but a discussion on the correct business process between you and the organization as a whole. There is nothing wrong with proceeding as he requests as long as you create a feedback loop that is open and transparent. Go ahead and design that monstrous screen. Give it to some of the experienced users and watch them use it in action. (You must spend time with them as they use it. Make your own observations. By watching them, you learn the business domain and create personal credibility with the users.) Document what the interaction is like (the bad parts and the good parts) and their feedback. Get the feedback "on the record" so it can be presented to the organization. You might be surprised that it is better than you thought. If it is, you have learned a lesson. If it is not a good interaction, then focus on the user feedback when discussing the problems with the owner. It is not you with the objections, it is the users. No matter what you design/code, there will always be an iterative process. The monstrous screen may be the end result of a coding phase, but it is simply a starting point for the iterative development process. Focus on the process more, less on the personal conflict with the owner. If you focus on the conflict, you will more than likely lose. Good luck

I happen to have 2 undergraduate majors: pilosophy and mathematics (numerical analysis). I have been programming in the robotics industry for 20 years and am quite sucessful and proficient in a domain which is very demanding. I have seen many programmers come in/out of this industry and I can tell you that education is not really what makes a quality developer. We have all worked with many CS graduates that were ineffective and helpless. It is more about the person then the degree. I thought this issue was well understood. Perhaps not by all.

1. Always know your audience. Taylor the presentation to their expectaions, needs, and capacity to understand/absorb the materials. For example, do not have code listings or UML diagrams for a presentation to the CFO/CEO... Put the presentation using language and terms they understand and relate to! 2) Practive your presentation several times before giving it. Do not walk in cold and wing it. Go over it enough so you have a good outline of what you will say throughout the presentation. If you do not, it may look like you are "fumbling through" the presentation.