What Should I Teach?

I've been thru just about every goddamn modelling process there is for verifying your design with the requirements. Everything from flow diagrams to the Vienna Development method.
The best thing about it isn't the technical aspects, after all OO developers have very different ideas how that should be done. It's because, it's the way our customers think and the extensibility means you can cope with ambiguity in the detail, and even the odd out right snafu.

Obvious in retrospect, but damn clever.

I use OO models and then translate them to a classical design, it's easier to present and verify and it gives you a very clean foundation, the one you were trying to aim for with traditional concepts.

I'm out of date. But the only logic I was taught in my courses was boolean. Business logic was something I learnt at work. Which was my real point, one without the other and you aren't a developer.

Good one, I've done a fair bit of mentoring of graduates and trying to get them to understand what the priority was, is very hit and miss. Had one spend two out of the three days allocated designing bitmaps for his buttons, every time I'd asked him how it was going, he told me, 'Brilliant', so I learnt a lesson there too as well. Now I'm never too busy to take the time to make sure they've understood what I want.

I wouldn't call what you were doing twiddling. There's always a place for R&D in a software house. Also there is always a percentage of this effort which turns out to be impractical to implement, for one reason or another. If there weren't some wrong paths, it probably means there was no research at all.

99% of by business appreciation has been on the job as well.

As for social imbecile well I'll hold my hands up on that one, it's a fairly prevalent assumption in some circles and I shouldn't add to it. I've met about two guys who'd qualify, but it's a very small minority. Adapt or die is a given in our industry.

P.S. Do you get to choose goal of your work, or are these set by the business. For instance I got asked to research the best hardware dongle to buy and use, not the best method of securing the software against piracy.

structural methodologies meant to me. But I didn't want to continue disagreeing with you when we were talking about different things.

Probably because it's the way I learnt and a more logical progression I'd treat structural methodologies as a mandatory not a nice and as an underpinning to OO methods. Not so much the what as the why.

As I've said elsewhere I've had to go back to non OO code, fortunately for me I didn't even bump into OO until 1996. I've a feeling that someone without the foundation would have a very difficult time going back from OO. Now you can argue that reverting to non OO principles is a dying skill, but OO was an outgrowth of the older stuff and encapsulates it's ethos if not some of the more outre methods of presentation and analysis us old folks have had to cope with before the pentium magically materialized on our desks.
The basics of relational database theory is a must as well, as an underpinning to SQL.

Can't help feel there is so much to IT that to try and teach it all in a single course is madness. Some large lumps have got to be ommitted dependant on what sort of course it is. The fact that we are all professionals from varying IT disciplines is muddying the water a bit. But I think any course should have a 'History of IT' section with possibly a bias towards whatever the eventual discipline is.
Any general course would amount to an apreciation of technology in business, which is not a bad idea, but would not be something a tech could build their career on. For a business head it would be as useful as a business theory course would be for us. Gives us a common foundation to communicate through.

Out of the sky, perhaps we ahould suggest to Bill his next O/S is called Meteor
'because it smashes windows to bits'
LOL

Teaching troubleshooting yes, however it sounds like your documentation problems are a system failure to me.
I've done years in this environment as a tech and no one had to tell us we needed our knowledgebase, indeed we brooked no interference from management in running it ourselves. It made our jobs easier, one manager was nearly lynched for taking it out of the office, to show a colleague how clever he was.

If you want a description of how we did it, by all means post back.

Most of it is commonsense engendered by an irate production operative losing his bonus being stood next to you.

I've noticed, remote support staff don't have this incentive.
LOL

Seriously what you want can and will be done, but your techs aren't seeing the benefits of your current system. The only other resistance I can imagine would be job security, resolve calls quicker = more calls per body = less bodies required.
Not an issue where I was was because we did both development and support so less support meant more interesting work.

LOL
You are a bad boy James, though simplifying an issue until it loses any apparent relation to the issue is indeed unhelpful.

While budget is the reality check, and there is a cost to a lifecyle.
So is the engineering cost.
Far too many times engineering is given the order to go ahead when the budget is what can be afforded as opposed to what is required. In those cases the first casualty is always quality. 20M of well written but undocumented code is far from a total success.
I always try to have content sacrificed in these situations, do a smaller amount of good work not a large amount of bad work. The latter always costs more than you planned.

Being a foolish optimist by nature I'm still waiting for this to happen more than once a year.

Wow, you're digging way too deep. My head hurts just reading your reply. I'm not easily frustrated nor do I lack patience or fortitude. As a matter of fact, I don't really care much about the whole thing. I'll just let all you other guys figure it all out. I think I'll just forget typing anything else and go back to my leisure life as a consultant. Thanks for the advice, I'll pass it on.

ok, life is never fair, if you come right down to it (read John Steinbeck's Animal Farm). Whatever the doers do, the takers take away, such is the basis for empires or enterprises; the wise is always poor, and the rich is never wise. In many projects, I deliver what the analysts document and the management report up, but these documents and management reports are usually started after the projects have been signed off after the final pre-production testing ! Sort of like Larry King instead of being project analysts or managers you'd say ? Trying to tell that to budding tech newbies is considered a no-no . Well, hail Caesar.
Most of my clients start setting project goals after I have crystalized the business scenarios thru prototying (process and data mining) to nail down all possible realities. By the time I have figured out every aspect for the project a series of "goals" are then produced by me and then I get briefed of these goals in the formal project meetings. Hey, nobody can be perfect without some kind of cheating, right ?
By the way, remember what the term modeling really means, far too many folks take the models as reality which usually turn these folks into "emperors without clothes", and it can worsen when these naked emperors parade themselves in front of foreign dignities and/or other naked emperors.
How can you teach that to anyone ?

Sorry pal, but things are seldom what they seem at first, or even when they manifest as recurring problems, especially when there are many possibilities and dynamics. Cheers.

Actually several of my client management had conferred worries over and are designing strategies to solve this particular problem of having too many great listeners who just come out short on values through actions, deliverables and commitments, notably from under-performing employees and some failing outsourced ventures. Majority of my system integration work come from requests to right these wrongs.

An item that has bothered me with new recruits from college is their lack of ability to debug software. In the classroom, software development is not exercised the same way it is in "production." When subtle interaction between modules show up in production, the new recruite will often look at his modules as black boxes, not stepping through the code to see what might be impacting the output.

If you have a software contract and the manuals in whatever format are one of the deliverables then people from both sides crawl all over them to make sure they are right. Two readmes and some obvious crap under F1 is dcoumentation, but it's not costed and the first man over the top in a cost fight.
I mean a labelled edit box called invoice number and the help is "This is the invoice number". Waste of time, space, effort, cuticle and photons.

Like seeing fully commented code

Int NumberOfInvoices // The number of invoices

drives me wild that one !

No. It was so critical to us, we considered it integral to our task.

The team I was part of took a continually tweaked, and continuously failing manufacturing system and increased it's availability with a combination of techniques by almost 25% in a year.
None of that could have been done without an eternal drive for accurate descriptions of the faults, the methods used to correct them and their level of success. Seeing as we were in the best position to do all three and we got the most benefit professionally out of doing them, well I'll leave the rest to the class.

What we did was very specific to the technology in place, the methods however were common sense, buy in, ownership and an appreciation from management that there was value in bringing us in to the development / implementation cycle as early as possible.

If YOU need to keep your technical staff in tune with what's happening under their noses, then either they are failing you very badly or you're stuffing things up their noses about the time they get used.

P.S.
I'd probably read your book , I might learn something and that's an opportunity I personally do not like missing.

P.P.S Aside from a bit of professional banter, where else do you think I have not contributed to this thread ?

I believe the point at which he was aiming was that servers should not be tampered with continuously. Set one solid configuration from the start and then leave it alone...

I also teach at a two year school. Our official degree is an AAS as a Network Technician. I agree with all the posts on teaching "soft" skills and documentation. I try to incorporate these into every class I have, weave it into the technical skills they are learning. Have you ever noticed that most books based on the A+ have a section on customer service? When they learn how to manage an OS they also learn how to manage the process and work with the users to create a workable solution, and so on.

My students also take a variety of business, communication and other general education classes. All of these help with the thinking and problem solving skills as well.

But if you want another source of good information contact the ACM at www.acm.org. About 4 years ago they finished a project on what should be included in 2 year, 4 year and advanced degrees. They just came out with an update last spring. The nice thing about it is they break IT down into many different areas so you aren't trying to teach everything in just 2 years.

Clearly a communications skill, but certainly one that's not 'soft'.

Teach your students to communicate with their technical and business counterparts with their counterparts preferred vocabulary.

So often, I've heard 'tecchies' describe a simple change or adjustment using terms & jargon that baffle or terrify a business user. Important changes aren't authorized because the client is overwhelmed (and scared to admit it!)

Similarly, I've seen the ubiquitous 'It's Broken!' skillfully translated in a clear, organized, technical plan which ultimately prevented a costly problem.

And I've seen programs resulting from a developer not being clear on the difference between 'credit' & 'debit'; 'deposit', 'withdrawal' & 'transfer', address & mailing address. Sounds pretty fundamental, doesn't it? That's what the client thought, too.

Sorry for the delay, I don't check these posts often.

Basically, the difficulty of switching amounts to the same difficulties of switching between any careers, plus a few more for the teaching area specifically.

You have to decide at what level you want to teach (high school or college; if college, 2-year or 4-year) and learn what the credentials required are. In my area (NY), in order to teach at the high school level in a public school, you have to be certified. I found that I would need a master's degree in my area (which I had) and 12 graduate-level credits in education courses (which I didn't have) to be certified. Private schools don't have to require certification, but public schools pay better than private. Any college will let you teach at least part-time with a master's degree in the appropriate area. Four-year colleges like Ph.D. degrees, particularly for full-time positions if they are accredited or want to be. So, with a master's and no education credits, my best option was to try 2-year colleges. In my experience in my area, private 2-year colleges don't pay well and public community colleges pay much better, but it can be difficult to find a full-time position. Because they're publicly funded, full-time positions in general are scarce (part-time people are cheaper) and the bureaucracy is what you would expect of a local government-run organization.

What I did is that I began part-time at a private college, getting experience, went full-time there for a brief period, then managed to get in part-time at my local community college. At this point, I earn part-time only slightly less than what I earned full-time at the private college.

So, what I would suggest is first determining at what level you want to teach. If high school, find out the requirements -- call the human resources department at your school district. If college, call the department chair of the appropriate department and talk to them. If it's a computer science department, the student numbers are down slightly recently. They may or may not need you, depending on your specific skill set. If not, be patient and keep in touch.

Second, try teaching first at least part-time before you completely commit yourself. It's not for everyone. It can be difficult to explain the topics if you aren't used to it and some of the students can really try your patience. Personally, I had done customer support and training, so had some experience explaining how computer systems worked and patience with users. It was still a transition period working with students, however.

If you anything further specific that this doesn't address, please feel free to contact me directly at my listed e-mail address.

Toss it off for two weeks, assignment due in tomorrow. Pull sicky, wonder why no one believes you, when you hand in a piece of mis-spelled garble on Modnay. LOL
Good job there wasn't a probationary period in college.

Good thing to teach, If you don't finish, we can adjust, if you don't start, we will adjust.

In UK schools you rarely got anything that took more than a lesson and maybe homework. Except if school equipment was required. Be a good adjustment that. Especially if they had to plan it first and then document how the plan worked out.

New Technologies are arriving everyday in the IT world. Keep abreast with with the hot spots and keep moving. This is what is relevant! Don't forget everything started from 0 and 1 now we are talking OOP.
Have a nice day.
Agbons David.

I think as a instructor a sound knowledge on the subject is very important to teach in the class. The doubts raised by students should not be prolonged to the next class. The students should gain confidence in you teaching them. The body language is very important in the classroom because sometimes students see as role model. The ability to study students mind is very important. So, that the way of teaching can be done according to the students in there in the class.

Hi guys!
i'm new in this site.
I have a project which consists of a class routine builder. i'm developing it in vb6.
Is any one there who can help me?
Bhas

I got a solid Computer Science degree from Michigan Tech a long time ago, (back in 1979). I think that I was in the second graduating class of full time Computer Science students. Prior to that, our courses were computer coursee in the Math department. By the time I graduated, it was the Department of Mathematical and Computer Sciences, and we had our own legitimate Computer Science degree.

We had excellent theoretical classes and some good, solid programming classes. The one thing the main program lacked were some group projects. There were a few classes in the simulation laboratory that emphasized individual projects, but at the time, the only group programming project was in the business department, where an advanced Cobol group project was taught.

Two or three years after I graduated, I visited the university during their famous Winter Carnival, and I got a chance to speak with the first full time professor in the Computer Science department. He asked me what the most helpful course was for me. I had to tell him that the Advanced COBOL project in the business department was the most useful class for what I had to do on the job, even though all the theory we learned was also useful. He sighed, and said that he had been making that argument to the curiculum committee for several years but had little success. The business department put their course together because that was a need they saw in business. They were right.

You have to know some theory because you have to understand the principles of computing, but you also have to know how to effectively work on projects, both individually and as a team. You have to know how the pieces of a project fit together, and you have to communicate about the details.

I think the language is most important part in which IT field is positioned, hence being yourself well equipped in popular language can really help one to grow and suceed...

I work with teens and the people who train them...mind if I quote you?