I
just realized that the vocational path I'm beginning is
ALMOST EXACTLY like the vocational path I
was on. (
this gets fairly dorky, read on only if you wanna get dorkified; you have been warned)
So I was previously a software developer, almost exclusively in the Java language. Say I was writing a program to mimic and predict classroom behavior. The way Java works is that you write code to
define a child: what kinds of properties they have-- they have hair of a certain color, they're a certain height, a certain weight, these interests, those needs, etc., etc.-- and also in what ways you can interact with entities of this sort. This definition is called a 'class', and it acts just like a blueprint. Then you create many
instances of that class to make
objects. Each object will be defined by the blueprint, just as a single construction blueprint can be used to make many instances of buildings that all function exactly alike. But the thing is that each object can have it's unique (not necessarily so) values for each property defined in the blueprint, and those may modify how it behaves, just as two building with the same blueprint may seem totally different. Say the blueprint calls for a child to have a hair color & a height. I can make two instances of my '
Child' class, which will be two objects called Jack & Jill. I'll give Jack brown hair and 4.5 feet in stature, and make Jill a fiery redhead at 5 feet tall.
Now what has just occurred to me is that
this is what I'm in school for-- to learn the attributes and properties that make up the 'Child' class. More than just hair color & height, also items about their needs, etc.-- and I'm not learning about
actual children, I'm learning what
I
might find as I get to know the children. So I'm not learning to deal with
objects of the Child
class, I'm learning the Child class itself, what a child's needs
might be, etc.--- the 'Child' blueprint.
And here is the difference between computer science and the education field-- in computer science,
I was the architect: I'd first define the Child class, which is made of what composes a Child and what they're capable of, and then I'd make two objects of the Child class, name them Jack & Jill, and give Jack brown hair & give Jill red, etc., as I desire. That is a
designed approach, which implicates there is a
designer, which was me as the software engineer.
BUT in a classroom, I'm not choosing the properties that make up a child-- "defining the class"--
OR the values for those properties that make up each individual child-- "instantiating an object of the Child class"-- I'll be trying my best to discover what those values are. So instead of me making a Child class, which is the definition of a Child, and then making many instances of my Child class to form my classroom and giving each Child their own unique attributes,
NO, it's that I'm learning in school now what the definition of the Child class
is, and then later, I'll be presented with many instances of the Child class.
If you aren't totally dorked out by now, it has MUCH to do with this concept:
a top-down approach vs. a bottom-up design. Huh! And given that Java is object-oriented, and o.o. languages are bottom-up designs, and a kindergarten is
clearly bottom-up, I may have already spent 5 years in training to work in a kindergarten! Cool thought...
I'd like to introduce a new term: replace "teacher" with "educational engineer." Once you buy in that each child represents a collection of
processes, then working in the field of education isn't a way to churn out finished products that will forever stay statically in the state they were in when I was done, it's a way to
modify the processes already in place, and help new ones get started right. Wow... I'm mildly intimidated... this is starting to sound like it's going to be a harder field to work in. (
quit talking, Jeff, you're scaring Jeff) All right, bring it on! I can meet the challenge! I think they oughta start making a 4-year C.S. degree a
prerequisite to the Early Child Development 101 class... ;-)
