|
OriginalGriff wrote: everyone who can run an app on an iPhone assumes they are computer geniuses.
I read this and immediately thought of a previous classmate. He was a React "pro" who was going to make a ton of money as a Programmer. He wasn't a CS student, in that he didn't take either of the Assembly courses, Data Structures, or Algorithms, because they were, "Too hard." He, "Didn't need all that to Code" so he went the IT route. After two Software Engineering classes full of, "React is amazin'" I decided to never touch it. 
I had 4 CS professors who were from Industry, and for me, those experiences were the most beneficial. There were some cool stories, for sure.
|
|
|
|
|
Recently, a friend of mine was complaining about one photographer insisting that you can't call yourself a serious photographer without knowing the chemistry of the development and printing process. This photographer rejected digital photography because it won't allow detail control over all the processes leading up to the final result. When you loose control, it limits you opportunity to create the best photographs.
My friend asked if we are like that in the programming business as well: Do you have to know how the transistors work to make a good program?
I answered "no". Knowing what an instruction set looks like, the architecture of the memory management system and interrupt system may be useful (or even required) when you are working with software at a low level, but that is way above transistor technology! If you make user applications in C# or Java, you should know the basics of a virtual machine an intermediate code / bytecode, but that is way above MMS architecture. And so on.
A photographer should understand shutter speeds, f-stops and ISO-value. If he is really advanced, he will be able to explain why the picture made by a mobile camera (with a focal lenght of a handful millimeters) have greater focus depth than a full format SLR, even though the aperture setting, camera position and field of view are identical for the two. (That certainly has an effect on the final result, but even among the most advanced amateurs, very few can explain it, even though they know it is a fact.)
Anyone needs to know their tools, how they operate. But low level photo chemistry, transistor technology or how to mine iron for making the wrench you are using, is not required to become a good photographer, programmer or car mechanic.
|
|
|
|
|
OriginalGriff wrote: Now, governments are pushing "developing" as a school course. So it's taught by teachers who don't know the subject outside the curriculum, who don't genuinely care about development, who haven't written much more than "hello world" for themselves; and taught to kids who don't care either - they just have to pass the course.
Worse, they course it taught like any other: "Read this and remember it" works fine for History, English Lit., and so forth - but development needs you to think, not remember: that's a very different mindset and that isn't taught.
As with so many things, this (rote learning versus learning to think) that gets lost between governmental good intentions and reality on the ground.
Someone in government realised that we need more technically literate and intellectually capable people and, with the best of intentions, realised that programming teaches people to think and analyse (which are of course the ultimate in transferable skills). So they created a policy of teaching programming.
But then, when it gets to the misery of the school coal face, it becomes just another commoditised check box subject, taught as a "do this, pass exam" subject rather than the original intention of all the best education: Teaching children how to think and analyse for themselves.
The solution? I don't know.
|
|
|
|
|
30 years ago: All the passion, but less on tools.
Now: All the tools, but less on passion.
modified 27-May-20 3:38am.
|
|
|
|
|
And that means that in 30 years from now you will find nobody to answer questions in QA... Not just because there will be no knowledgeable person, but there will be no passion to do so...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Or maybe, QA will be taken over by some AI kind of thing. Just like Alexa or Siri.
|
|
|
|
|
Quote: <mechanical voice>Your question is too dumb to answer; you will be absorbed. RESISTANCE IS FUTILE! brrp, zzzzzqsl pop<creepy silence>
|
|
|
|
|
I promote one fundamental principle: Make sure that you understand how your tools work, at least at the level immediately below the one you are currently working on.
You don't need to be an expert on numerical methods to use a library of trigonometric functions, but you should know how they can be calculated by series expansions. When you use malloc(), you should be familiar with internal and external fragmentation, compaction etc. When using a compiler, you should have some familiarity with machine code in general, and how it relates to high level code.
And so on. An important use of this knowledge (and a suitable test on if you have it) is to make qualified judgements of which tool alternative to select. Why is a connectionless network protocol better, in a given context, than a connection oriented? (if it is!) Should we use a thread or a process based solution? Should we store/transfer data in a binary format or formatted as text - and why?
How well you should know the layer immediately below may vary. You would expect a Master to know it a lot better than a hobby programmer. But even the hobby programmer should have some understandig of what happens behind the curtains when he makes an API call, runs an executable etc. There is a major difference between knowing how a tool works and being able to build the tool; you need the first, but do not need the second (although it never hurts...).
When I mention this principle to developers of my own generation, they always return an affirmative nod.
Developers of the younger generation usually return a shrug, "Hey, it works! I don't care to know how."
When I ask why a given solution was chosen, I far more often hear "Well, it works..." rather than a qualified rationale.
Juniors seem to accept the automagical as perfectly normal. They are perfectly comfortable with having no clue whatsoever about what that API does. It performs a task. Why should I care about how it does it? Why should I waste resources on knowing how? When I need to learn some new tool myself, asking a junior for help to understand its workings below the surface is usually futile, they can tell me the name of the API and the parameters, but it stops at that level.
With that attitude, you are a user, not a developer. Today, we see a rush to become proficient users of as many tools as possible, without minimal understanding of the tools. However, if you spend resources on understanding the operation principles of half as many tools, you have a much more solid background for learning the other half when the need comes. (I would estimate that at least 80% of the tools and technologies I have been working with the last twenty years didn't exist when I got my degree. Yet I have had no essential problems understanding how they work.)
I wish we could get back into the training of new developers that a skilled professional knows his tools, know how they operate. He does not accept anything automagical. He knows not only what to do, but why he does it, chooses that alternative. Even though this implies that you spend resources on aquiring knowledge and understanding that you theoretically could do without (in the short term), in the long term it will certainly pay back.
|
|
|
|
|
Member 7989122 wrote: uniors seem to accept the automagical as perfectly normal. They are perfectly comfortable with having no clue whatsoever about what that API does. It performs a task. Why should I care about how it does it? Why should I waste resources on knowing how? When I need to learn some new tool myself, asking a junior for help to understand its workings below the surface is usually futile, they can tell me the name of the API and the parameters, but it stops at that level.
With that attitude, you are a user, not a developer. Today, we see a rush to become proficient users of as many tools as possible, without minimal understanding of the tools.
And sometimes being a proficient user is more than enough.
I remember one thing my father told me long time ago. "Better be apprentice of many things than master of none"
I don't say it is an universal truth and that is always the right approach. But neither is bad or wrong in every approach
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I just came across a classic example. A QA poster wants to know how to complement a number in C#. So rather than go to the documentation to check what mathematical and logical operators are available in the language (which should be part of the basic teaching), they post a question here and sit back waiting for someone else to find it for them. Not only are they not taught to think or try for themselves, but they expect other people to do most of their work. No wonder we have so many "please do my homework" questions.
|
|
|
|
|
TL;DR; at the end.
I mostly agree with @OriginalGriff's comment, but I think some differences too.
One is... altough in general terms the impression is that youngers are dumb or lazy, there still are people over there that are really good out there and some of then learned it on their own (i.e. Sander). Those who are good and really want to learn, I think they end being even better than many of older generations.
Another factor I think is pretty relevant is... the amount of staff. 30 years ago, you had very very few possibilities (a couple of programming languages, a couple of databases... that was all), so the things could be teached / learned in depth. Today you have so many different things that it is impossible to keep track and be good on everything.
Additionally it is not only the fault of the teachers, many parents are "guilt" too for the situation. I can't say I am the perfect father (I know I have a lot of defects), but when I look around me... I have to      pretty often. Some really have no time to do more, some really don't have the knowledge to teach more, some really don't have the mediums to do more, but many are just idiotic, lazy morons that just think sitting the kids in front of the TV or the Smart Phone is a good education.
Now... back to your question.
I have trained several juniors in previous jobs, and I can only say prepare two different line of action
Start with basic basics and think of it as you are teaching kids, not youngs. Go slow, first only showing overviews and giving easy exercises.
In my experience, only the ones that want (and simoultaneously can) will really learn. The others will be there phisically but their brains (or what actually is in that space) will be somewhere else and won't give a crap on what you try to teach.
So pay a lot of attention on their responses and if you see there is one or two guys that might have the potential, then change to the second line of action, going deeper in each topic.
If there is/are just one or two guys that really learn something, I already consider it a success. The rest won't make it, because they don't really want to. So it doesn't matter if you go fast or slow, deep or not.
On the other hand...
Some of their questions will "WTF" you and you might really get corrected in some of your assumptions or your "universal truths". I trained a particularly good guy during some months that helped me find a couple of bugs (undercovered for some years) in our company library functions (some written by me, some written by guys better than me).
I was myself in some professional courses for new projects and I liked a lot a trainer on robotics, I was getting a basic course for that particular robot (brand / manufacturer) but already had some years of experience in other robots. I asked some questions that he couldn't answer, he honestly admited it and told me "ask it again tomorrow". He used the evening night to look for it / test it himself so at the following day he had a good answer to my question.
At the end of the week he thanked me, his explanation was:
The general trainee just sit, ask standard questions that can be found in a small FAQ, do the test at the end (that already is deleveled to adecuate the standard pupils) and go away with a "attended" degree. But I broke his routine for the first time in a couple years and make him to push himself again and learn some things that he had overlooked / forgotten about their own product.
TL;DR;
Start slow but adequate the speed to the ones really wanting to learn and screw the rest. Be honest with them and yourself and be opened to learn from them too.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 27-May-20 5:17am.
|
|
|
|
|
Nelek wrote: the impression is that youngers are dumb or lazy
I had no such intention. Definitely not dumb! And laziness is mostly acquired...
Obviously anything I told is not universal truth or observation - it is about the mainstream... And it seems that somehow nowadays developers learn fly before walk...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Learn to think vs Learn to code.
Older developers, as a general rule and in my experience, THINK to what they are doing in terms of logic and math. New developers? "Learn to code and get money". No thought, no knowledgem, no process on their part. Find some library and stick stuff together with glue and chewing-gum until it can be delivered without repercussions.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
What I consider an ideal education path:
Get a low level formal education - maybe a Bachelor, but not necessarily that high. Enough to teach you what to do.
Get a job as a junior for 2-5 years, to see how those tools and techniques are applied, understand the needs. Learn the whys of what you have learned.
Return to school for a higher degree to learn the inner workings, the principles and enough theory to thoroughly understand your tools.
A guy who goes into a job without any formal education usually do not have enough background to grasp the needs of the job. He often will do the grips mechanically, with very little understanding. A low/intermediate level of training makes learning in the job far more efficient. On the other hand: Going directly from HighSchool to a Master study without a clue about what all these methodologies, theory, principles of operation, ... will be useful for, is just as limiting to your learning.
When I was a college lecturer, I surely enjoyed those students who had been working in the field for a few years, returning for a higher degree: Their questions were consise and clear and really focused on the essential parts. They could add comments from how they had solved problems in a real-world situation. In group works, they knew how a group is organized and how to collaborate in an orderly way. Practically without exception, they completed their studies with excellent results: They knew the purpose of the knowledge they were obtaining.
Noone should be awarded a Master degree without at least two years of full time working experience in the field. Unfortunately, many (maybe most) Masters do not fulfill that requirement.
|
|
|
|
|
IMHO, A college degree is almost as useful as a Microsoft certification. In other words, not at all useful.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Interesting question.
I have been doing development/programming from 1979. In those days you really got to know how every bit of hardware worked. If you didn't you achieved exactly nothing, it was as simple as that.
I have seen quite a lot of promising young developers go by trying to make it in the embedded electronics world but failing miserably because they can't shed the luxury of having a few gigabytes of RAM to make things work. Additionally they lacked the fundamental knowledge of bits, bytes and how those things actually work, let alone set up and configure peripheral registers etc...
You can't really blame them because these days everything is abstracted and hidden under layers and layers of frameworks and libraries and teaching these days concentrates more and more on using all of those layers instead of getting to know what lies beneath it all.
Ah well, when nobody knows any more how things fundamentally work we will become popular again just like all the retired COBOL programmers these days. 
|
|
|
|
|
fd9750 wrote: hidden under layers and layers of frameworks and libraries
That was my thought while watching Build 2020... The good developer this days, the one knows the latest-and-greatest library of all...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Relational database foundations doesn't seem to be a taught subject any more....
|
|
|
|
|
They have no mainframes with SQL to play with? What are they doing between classes then?
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Geek & Poke might say a word about SQLs low popularity: SQL[^]
|
|
|
|
|
The main diffence is related to access to resources
In 1970 I wrote a couple of assembler programs on and for the PDP-8 and PDP-9 and
there was virtually no one that you could ask a question
In the end of the 70-ties, we hacked Unix kernels and there were some local user groups to
share ideas. Note that the PDP-11 had an address space of 64K, and lots of effort went
in optimizing the use of limited resources. On an RP02 disk putting the free blocks
on tracks such that the amount of waiting time was limited increased performance tremendously
(of course adding an overlay structure to user programs to overcome the limited address
space caused a decrease in performance.
Neverthess, on a PDP-11/70 with a whole (i.e. 1) MByte of memory, two RL02 disks and an RP03
disk we ran a student lab for 30 to 40 students simultaneously, with a link to the
university's mainframe
In the 70-ies and 80-ies - when writing compilers - we exchanged ideas with others using - hard to believe now - regular mail. Sending a draft report from europe to australia with additions and corrections being sent back took several weeks (sometimes more than a month), until
email arrived (around 82 or 83).
The basic facts that nowadays you do not have to worry about memory resources (recall, the PDP-8 has 4K 12 bits words, and for assembling a program you had to load the assembler from papertape), not to worry about storage capacity, and communication is now (almost) instant.
Ask a question and in 10 minutes (seconds sometimes) you have an answer!!.
On the other hand, the domain grew. In the '60-ies and -70-ties you hardly had
programming languages, knowing one or two languages, having some familiarity with
a computer, and being able to use some vague terms you was considered a specialist
in the whole field.
Now you have to specialize in front end technologies, backend technologies, middleware specialists, cloud guru, etc etc, while specialists in different subdomains
do not understand each other!!
As an example, look at the reports of the codewitch, while in the 70-ties (most of the)
stuff she writes about was part of any decent undergraduate program, I bet that 90 % of the CP population does not understand the technolgies she is applying.
(I take that as example, since in the 70-ties and 80-ies I worked in the field of compilers
and happen to understand this part of computer science)
|
|
|
|
|
Member 12982558 wrote: I bet that 90 % of the CP population does not understand the technolgies she is applying.
I would go for 95% (including me among them) 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
You are pointing to something that has drastically changed the way we work with information, not only as software developers, but everywhere.
I have mixed feelings. Do not read that as "negative", but as a true mix of positive and negative feelings.
Between 1990 and 1995 I was involved in a multinational project for developing "Just In Time Learning". It was a pronounced idea that society "cannot afford" wasting resources of train people to give them competence they "don't need". The goal was that you should only learn those skills needed for the task in hand, and not until you really need them. Minimize wasting resources on learning anything that there is no (immediate) use for!
The basic idea of making an ideal of not understanding, not knowing something that you don't have an immediate need for is the most clearly pronounced dumbing down principle I have ever encountered. The very opposite of an enlightened population. Like reducing all of us to nothing but a single gear in the total information society, minimizing educational costs to maximize profits. Avoiding any "outside" knowledge that could end up as sand in the machinery.
In my student days, it was well known that IBM (then still The major actor in the computer world) was not too eager to employ people with a university degree; they took in far more people with minimal education and gave them job training, learning the IBM way as The way. (People were joking that the IBM slogan, "Think!", really was "ThIBMk!")
We are there today. I have a few coworkers who constantly have their smartphone in the hand (if they need both hands for e.g. eating a hot meal, the phone is on the table right in front of them). I have gradually learnt to avoid airing questions, or in any way revealing that I do not have all information available, or even mentioning observations or "facts" that are not hard and absolute: In split second, they are onto their phones: I'll google that for you! Half a minute later they proudly read out loud from a Wikipedia article or other web site, often (again, proudly) being able to make small corrections to the "claim" that led to their googling.
They appear to know "everything", with the help of their smartphones. But it turns out that they really don't understand anything. Often, when I am back at my PC, I check up those googled facts, and see a quite different (and most of all: much more complex) reality than the quoted one.
On the other hand: If you have a decent understandig of a field, you can extend it tremendously, filling in details, have your previous knowledge corrected for both your old misconceptions, updated with more recent information, and set into a context.
I am into a habit of "just checking up" some knowledge or understanding that I think I have, googling, reading Wikipedia articles in mulitiple language versions, finding other information sites. That not only updates and confirms my old knowledge; it also makes me aware of a lot of misconceptions and dubious interpretations that are out there, preparing me for meeting other people on these subjects. Finally: I hardly remember anything from my schooldays' geography lessons, history lessons, lessons about public institutions, ecoonomy and such stuff. Through internet, I am able to recall forgotten knowledge, having it updated and extended.
Internet is a superb source of information ... when you have the background to evaluate it, and absorb the valuable parts. I would say that my grip on reality has become a lot better with Internet. There is no way I would have searched up as much truly useful and significant information if I were limited to traditional sources.
Internet, when used to expand your widsom, is a great thing. When used in an "I'll google that for you" way, I would rather be without. If you can't give me a decent introduction to the subject before you offer to google it, then please don't google for reading out text that really makes little sense to you. Not even if you actually have brought up correct hard facts.
|
|
|
|
|
The main problem is that they're expected to know a little about too many things, and they forego true understanding in favor of an immediate paycheck.
On my team (nine people counting me), I have more experience than all of my teammates put together. Of the nine of us, only three that I know of (the oldest guys on the team) have ever started a project from scratch.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
The main difference I see (very much generalizing) is that the old timers did it for the pure joy of it. It wasn't just a source of income - learning it may have been totally detached from that thought - it was feeding a need.
Now - it's a job. They read some posts and articles that there's a big need for programmers and it pays well and they're in. We're in an era of code-mills - outsourced to parrots.
Perhaps there are as many artists as there were - but they're drowning in a sea of mediocrity.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
