Generation, what's left?
-
What do you see as the main difference(s) between the older (let say 30+ years in the filed) and younger (less then 10) 'generation' of developers? What are the main reasons? (The reason I'm asking - beside pure curiosity - is that I was asked about building a course for future developers...)
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
"It never ceases to amaze me that a spacecraft launched in 1977 can be fixed remotely from Earth." ― Brian Cox
-
What do you see as the main difference(s) between the older (let say 30+ years in the filed) and younger (less then 10) 'generation' of developers? What are the main reasons? (The reason I'm asking - beside pure curiosity - is that I was asked about building a course for future developers...)
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
Education. Back in the day, computing was a specialist job, and was taught by people who understood it, who knew what they were doing. And that rubbed off in how they taught, what they taught. And mostly, what they taught was "language basics" and "how to think like a developer". 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. And if the teachers don;t even know the debugger exists - and most don't - how teh heck are the students supposed to know? Software is seen as a simple way to make a load of money - it's well paid, with no heavy lifting - so it's a route a lot of people want to take, even if they have no interest, skill, or abilities in that direction. And of course, everyone who can run an app on an iPhone assumes they are computer geniuses. This is just the impression I get - mostly from QA - and is probably well and truly wide of the mark in a lot of cases: but we don't get those case except rarely ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt -
What do you see as the main difference(s) between the older (let say 30+ years in the filed) and younger (less then 10) 'generation' of developers? What are the main reasons? (The reason I'm asking - beside pure curiosity - is that I was asked about building a course for future developers...)
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
Education. Back in the day, computing was a specialist job, and was taught by people who understood it, who knew what they were doing. And that rubbed off in how they taught, what they taught. And mostly, what they taught was "language basics" and "how to think like a developer". 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. And if the teachers don;t even know the debugger exists - and most don't - how teh heck are the students supposed to know? Software is seen as a simple way to make a load of money - it's well paid, with no heavy lifting - so it's a route a lot of people want to take, even if they have no interest, skill, or abilities in that direction. And of course, everyone who can run an app on an iPhone assumes they are computer geniuses. This is just the impression I get - mostly from QA - and is probably well and truly wide of the mark in a lot of cases: but we don't get those case except rarely ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
It is interesting - as all my teachers were... teachers. Not developers who take on teaching as a second job... However, all of them were writing some more serious software to teach and help teaching - so not only 'hello world' there... I think the problem with today teacher, that they can get anything ready-made from the internet. So they have no experience at all (which means they can not even pick the right sample from the internet). Lack of experience leads to lack of confidence when standing in front of the students and to avoid any 'scary' questions teachers going on the boring-but-well-walked path... The other part IMHO is the connection with the tools... Back then we had a no 'middle-men', no OS or IDE or such... We new our hardware and the means to communicate with... We were tool and language agnostic as we done our job on the lowest possible level (without soldering iron). Today you do not move without a few GB of installation before you try to write a single command...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
30 years ago: All the passion, but less on tools. Now: All the tools, but less on passion.
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
-
It is interesting - as all my teachers were... teachers. Not developers who take on teaching as a second job... However, all of them were writing some more serious software to teach and help teaching - so not only 'hello world' there... I think the problem with today teacher, that they can get anything ready-made from the internet. So they have no experience at all (which means they can not even pick the right sample from the internet). Lack of experience leads to lack of confidence when standing in front of the students and to avoid any 'scary' questions teachers going on the boring-but-well-walked path... The other part IMHO is the connection with the tools... Back then we had a no 'middle-men', no OS or IDE or such... We new our hardware and the means to communicate with... We were tool and language agnostic as we done our job on the lowest possible level (without soldering iron). Today you do not move without a few GB of installation before you try to write a single command...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
Kornfeld Eliyahu Peter wrote:
Today you do not move without a few GB of installation before you try to write a single command..
That's true: You could figure that a C# "Hello world" is a minimum of 4.5Gb: .NET Framework system requirements | Microsoft Docs[^] whereas you could fit it easily into well under 100 bytes in my early assembler days ... :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt -
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.
-
Kornfeld Eliyahu Peter wrote:
Today you do not move without a few GB of installation before you try to write a single command..
That's true: You could figure that a C# "Hello world" is a minimum of 4.5Gb: .NET Framework system requirements | Microsoft Docs[^] whereas you could fit it easily into well under 100 bytes in my early assembler days ... :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
well under 100 bytes
On my 6502 it is 28 bytes, of which 12 is the text to print...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
"It never ceases to amaze me that a spacecraft launched in 1977 can be fixed remotely from Earth." ― Brian Cox
-
OriginalGriff wrote:
well under 100 bytes
On my 6502 it is 28 bytes, of which 12 is the text to print...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
There was hardware setup code on my Z80 based VDT's: without that in there it wouldn't be readable on screen. Telling the hardware where the video memory was, that kind of thing.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Education. Back in the day, computing was a specialist job, and was taught by people who understood it, who knew what they were doing. And that rubbed off in how they taught, what they taught. And mostly, what they taught was "language basics" and "how to think like a developer". 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. And if the teachers don;t even know the debugger exists - and most don't - how teh heck are the students supposed to know? Software is seen as a simple way to make a load of money - it's well paid, with no heavy lifting - so it's a route a lot of people want to take, even if they have no interest, skill, or abilities in that direction. And of course, everyone who can run an app on an iPhone assumes they are computer geniuses. This is just the impression I get - mostly from QA - and is probably well and truly wide of the mark in a lot of cases: but we don't get those case except rarely ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Or maybe, QA will be taken over by some AI kind of thing. Just like Alexa or Siri.
-
Education. Back in the day, computing was a specialist job, and was taught by people who understood it, who knew what they were doing. And that rubbed off in how they taught, what they taught. And mostly, what they taught was "language basics" and "how to think like a developer". 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. And if the teachers don;t even know the debugger exists - and most don't - how teh heck are the students supposed to know? Software is seen as a simple way to make a load of money - it's well paid, with no heavy lifting - so it's a route a lot of people want to take, even if they have no interest, skill, or abilities in that direction. And of course, everyone who can run an app on an iPhone assumes they are computer geniuses. This is just the impression I get - mostly from QA - and is probably well and truly wide of the mark in a lot of cases: but we don't get those case except rarely ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
Back in the day, computing was a specialist job, and was taught by people who understood it, who knew what they were doing. And that rubbed off in how they taught, what they taught. And mostly, what they taught was "language basics" and "how to think like a developer".
20 years ago, from the 4 teachers I had related somehow to programming... 2 were damned good and one could learn a lot from then, the other 2 were just so bad I spent the time of their lectures learning myself in a table in the corridor. Luckily there were other good teachers in their department too and even more luckily they were not morons and they allowed me to go to their open door sessions to ask my questions although I was not in their lists.
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.
-
What do you see as the main difference(s) between the older (let say 30+ years in the filed) and younger (less then 10) 'generation' of developers? What are the main reasons? (The reason I'm asking - beside pure curiosity - is that I was asked about building a course for future developers...)
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
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 a
-
What do you see as the main difference(s) between the older (let say 30+ years in the filed) and younger (less then 10) 'generation' of developers? What are the main reasons? (The reason I'm asking - beside pure curiosity - is that I was asked about building a course for future developers...)
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
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.
-
What do you see as the main difference(s) between the older (let say 30+ years in the filed) and younger (less then 10) 'generation' of developers? What are the main reasons? (The reason I'm asking - beside pure curiosity - is that I was asked about building a course for future developers...)
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
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 :omg: :wtf: :doh: :sigh: :mad: X| 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 cou
-
What do you see as the main difference(s) between the older (let say 30+ years in the filed) and younger (less then 10) 'generation' of developers? What are the main reasons? (The reason I'm asking - beside pure curiosity - is that I was asked about building a course for future developers...)
"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
-
Kornfeld Eliyahu Peter wrote:
Today you do not move without a few GB of installation before you try to write a single command..
That's true: You could figure that a C# "Hello world" is a minimum of 4.5Gb: .NET Framework system requirements | Microsoft Docs[^] whereas you could fit it easily into well under 100 bytes in my early assembler days ... :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
On the other hand... Sometimes, I want to yell at youngsters who spend hours and days on proving how super clever they are to save half a microsecond on writing obfuscated code: "We are not living in the 1980s!". Some of the tuning tricks we learned in my education were obsolete before we got our degree, e.g. we evaluated at least three or four disk scheduling algorithms, assuming queues of dozens of entries, only to learn that any disk subsystem with 3+ queue length more than 5% of the time is severly overloaded. Optimizing the ordering of one or two queued entries is a waste of resources (and fortunately, disk scheduling is out of the curriculum many years ago). There is no discussion that the "Oh, we'll just throw in more hardware" approach has gone way too far. I guess the saving of half a microsecond is a counter-reaction to that. We really should be more resources-aware, but with a thorough understanding of where the resource hogs are, and the cost of optimizing it. (E.g. obfuscation of code to save a few percent in initialization code, or optimizing a 2-element disk queue, is crazy.) Surprisingly many youngsters have "strange" ideas about what slows down the code, usually due to lack of understanding of the underlaying mechanisms. E.g. you have an executable (with umpteen dlls) where you never use 95% of the code: The huge size of the code does not put a heavy load on RAM: The unused disk pages are never brough into memory. It does not lead to slow startup: Setting up a hundred extra page table entries is done in microseconds. ... This is trivial, but I have explained it several times to developers who know nothing about memory mapped files. Similarly, they "know" that if the disk is 99% full, it will slow down the machine. Sure: For an extremely file create/delete heavy application, it might be possible to measure, but these guys consider it a law of nature that any application will run significantly slower. In my studies, we read a hardcover textbook on software performance and optimization, studying what is worth it. What has the most effect. Various criteria: Space or time, average or worstcase, ... This required an understanding of underlaying mechanisms (which we had obtained in earlier classes). Today, the problem is often that it is no use trying to talk with the youngsters about tuning, because they have no idea about what is going on behind the curtains.
-
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 a
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.
-
What do you see as the main difference(s) between the older (let say 30+ years in the filed) and younger (less then 10) 'generation' of developers? What are the main reasons? (The reason I'm asking - beside pure curiosity - is that I was asked about building a course for future developers...)
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
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 _why_s 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.
-
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 :omg: :wtf: :doh: :sigh: :mad: X| 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 cou
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
