The field is full of older generations lamenting the behavior of the newer generations. Frankly, it's stupid. Insulting everyone who doesn't do things like you want isn't a great way to go about it.
It's an oft-repeated "joke", but you've never written Java without an IDE, have you? I have, and I would prefer an IDE that takes care of the lines and lines of boilerplate than have to remember all that shit myself.
Evidently humor is an art lost on the young.
I am not lamenting the behavior of the next generation so much as the fact that they are being
wasted and stunted by never being taught in school how to problem solve and how to understand the side effects any design decision has.
We are
hurting in my field for the next generation of engineers.
Part of it is that we tend to burn out 1 in in 3 prospects inside 18 months.
We lose to other parts of the company/longer term burn out, another 50% within 5 years.
When you are dealing with systems that are so complex we do not even trust someone to do more than simple tasks without looking over their shoulder all the time until they have been around for at least a year, possibly two, this really makes you wish that schools stopped concentrating on producing code grinders ( which have their place. 3/4 of the code in my company falls under what can be handled by them. Hell, the entire "Y2K" scare never amounted to much due to code grinders. )
What we need
industry wide is folks that understand the Art of Programming.
And it is an art at it's core.
Proper design and language choice leads to code that can only be labeled "beautiful".
It flowsUgly code is a direct result of a bad choice somewhere.
Could be in the basic design, could be in the language choice itself. ( No language is perfect. All of them suck. Some just suck less for some tasks )
Do not confuse readable by a machine with Artful Beauty.
Just because the IDE does not puke on it, does not mean it is good.
For that matter, I've seen code that would make any IDE shit itself in confusion that was just absolutely perfect.
It took advantage of perfect underlying decisions on layout of data, the language in question, and the compiler quirks from the system being used.
Was it readable? Oh, hell no. Not on first glance. But once you sat back and thought about it, the only proper response was wonderment and the faint hope that one day you could achieve this level of understanding of
everything that went into making this work.
And why it was complete shit if any one of six different things changed.
Programming is not about getting it to work.
I could get almost any 8th grader to achieve that for the simple cases.
Programming is more about the decisions made before you write a single line of code.
Sure, Eclipse may point out when you are calling a library function wrong, but it will do nothing to help you figure out why your frame rate is complete crap, or why it works fine in test and then falls over with production data.
Those "Lines and Lines of boilerplate" possibly have a reason behind them.
If you consider them to be a an annoyance, i would suggest you look harder at your preceding choices.
The language you know the best is the wrong choice.
Or the correct one.
There are a lot of decisions that feed into that beyond the fact that the language de jour is what you are most comfortable with.
Give me someone that has only learned JAVA, but
truly understands programming and common data structures, and when to use them, and I could guide them through writing from scratch a generic B-Tree implementation inside a month that would be production ready, in FORTRAN 66. ( I loath FORTRAN. I used to write my numerical analysis assignment in C to get the output correct, then re-write them in 'F' to have the teacher understand them )
The language/editor is never the core point. ( do better editors help, yes )
It is the basic understanding of how things work.
Beat your head against a wall for 20+ hours entirely due to the compiler being a psychotic little $INSULT even though there is
zero reason for it to not work.
Those pricks that say "In my day" without firmly planting their tongues in their cheeks would be pricks no matter what.
The flip side of that is learning to tell the difference between a prick and someone that has learned from fucking things up.
Anyone who starts off with an obvious joke has most likely screwed something up in a far more
interesting way that you should ever hope( or really have any desire ) to achieve. ( Interesting being defined as costing your company on the top side of 1/2 a million due to a single line of code )
We all fuck up.
Anyone who claims differently is lying to you.
The big difference is how we react in those cases.
( "I fucked up" vs "it is fucked up because of XYZ". guess what? nobody cares. They can tell when you are covering your ass VS just stating that it was broke to begin with VS someone in your crew screwed it up, you missed it and will not outright sell them out as a scapegoat. )
The customer is only stupider that you think when you are defining specs.
They are always smarter than you think when things go wrong.
Those of us that have been doing this for years tend to wrap it in a twisted sense of humor since that is the only way we
got to this point.
gnome