I have just started taking some classes on programming and I had a couple of questions... They keep drillin' us with flowcharts and pseudocode - So I asked a few programmers at work (lockheed) - NONE of them use or have used either one. Is this the norm in the "real world"??
I just hate to waste valuable time on that stuff when there is plenty of other stuff that I need to focus on in this class. So far it is not that hard (week 4) but I am sure it will get tricky later...

Anyone have any tips?

The flowcharts and pseudo code teaches you good program building. It trains your thought process. You can't just hack at it right off the bat. It's like building a house. You have to plan the house first. You can't just start putting door knobs on doors.

Well to be honest with ya - I want to learn to do it by the books with pseudocode and flowcharts etc. I just haven't talked to anyone who actually uses this stuff. The majority of those people were also "veterans" who most likely think it is a waste of time too and maybe just keep notes to themselves.

Were you the one who slowbrick was telling me that worked at Lockheed?

Hmmmm..... Everyone uses different forms of the same tool. Although Pseudocode is the most used Flowcharts help ensure process flow are there. I would highly suggest you read up on UML, Process Diagrams and then learn how to write comments. A majority of my code starts with a flowchart and GUI then turns into UML and Pseudocode into comments. I use mainly Java so Javadoc is my friend, it becomes a way to become more efficient and allows fellow coders to understand what I did. With other languages you have header files that are another great place for high level documentatio nand then the code file actually hasdetailed algorithm and internal notes.

But then many programmers have issues with Job Security so they forget to put that stuff in there or they do not allot enough time in their evaluation to provide good documentation.

I would say your class is right on the mark in this case.

Good luck

Been programming for 20+ years and I can honestly tell you I have never used psuedocode nor flowcharts. Ever.

What has that gotten me? 2 PC Mag Technical Excellence awards for products and a couple of best at shows and some bullshit Canadian awards.

UML is interesting. Certainly more useful then psuedocode or flowcharts. I can't believe they still teach psuedocode and flowcharts in school. Actually, no, I'm not suprised.

It is one of the reason when I interview for programmers I give them 2 tests that have been modified over the years. It use to be a 3 hour in house test, we had to modify over the years to be "take home tests" because no one was finishing in 3 hours (back in the late 80s early 90s programmers were finishing it in office in 3 hours).

Tell you the truth, I don't care if you can psuedocode or flowchart your ass off, it's all about production code.

Now, of course, I'm coming from a different era where assembler and one line=one instruction was king.

It is very easy to do Psuedocode, and flowchart, but when I was programming in school, I would just go straight into code, then do flowchart, and such. I dunno, just the way my mind worked.
But i don't do that anymore, changed majors.

You have to realize in school, they dont always teach you stuff you'll use in real life, but they teach you problem solving and other really good basic skills that you can fall back on in a real life programming job, or another field for that matter. If you're not a natural, its bad ass to be able to fall back and be really strong on the basics as some times thats is better than experience, so dont brush the knowledge aside.

Exactly. These are learning tools. They train you to get your thoughts in order. In the real world, you may not need them. You may be assigned to something really small and contained that you don't really need to flowchart it first. Sometimes you will have other people assigned to the software design that you just implement it (i.e., write the code).

Comments are always good. I had an instructor say "The worst code in the world is the one that was just handed to you to fix."

Yes, I work at Lockheed and I've met slowbrick a few times.

Thanks everyone for the input. I am just getting started and it appears there are alot more knowledgable people on this board than I expected. I am sure there is a pretty steep learning curve ahead.Tonight I have my first test I think I am pretty well prepared for it - I just am not sure what the instructor expects for pseudocode or how specific she will be.
I dont know exactly where I want to go with my education but I am fascinated by programming. I just wish that there was someone closeby that I could pick there brain..but none of the people I hang out with are tech savvy.

Another good way to think about it... Remember Karate Kid part I, where mr miagi had him do all the shit chores, daniel got all pissed off and was like, You're not training me, you just have me doing all your shit chores! Then mr miagi was, daniel son, show me paint the fence, then he showed him how paint the fence was actually a blocking move.. etc...

I really dont mind doing it the "right" way. I just didn't want to focus on something that was not widely used.

I appreciate all of the input. I am sure I will have plenty of questions for you guys in the future.

Design work is still done, but in my experience more modern tools & methods than basic flowcharts are used. In my current contract the customer is quite heavy into using the RUP process. While I can see that this process does work it's far from my favorite and seems exceedingly time consuming. I've used many other design methods as well over the years; some as simple as laying out some screens in a text editor and going from there. Your customer's/employer's time, money, and standards will dictate how they want you to go about doing the work.

One of my favorite projects was done in 6 months with two developers and NO up front design work. We were in a "race" to deliver some software and we used RAD tools to prototype screens and workflow. The customer looked at and approved the screens and we then wrote the code to go behind them. We met the schedule with working software. Is this my recommended way to create software? No way. But it can be done with the right people on the project, and it's what the customer wanted.

As others have said you are being trained into how to visualize and decompose a programming job into smaller pieces. You write the smaller pieces and then combine smaller pieces into bigger and bigger ones until your task is complete. Get the small pieces at the lowest levels "wrong" and the entire program will be in trouble.

This is also not the last BS task you'll be given while you're in programming school but stay the course - you'll be better for it.

So how did all of you people get into the jobs you have? It seems that most programming jobs require a lot of experience. Or do you just work your way into something at the place you are at?

I started out working in a 24x7 call center answering the phone. Of course the call center had computers which seemed quite interesting to me so I started taking computer courses at northlake. My dad was a shift supervisor at this company, and the owner of the company happened to be chatting with him, knew I also worked for the company, and happened to ask about "me". Dad told him I was studying "computer stuff". The company happened to be about ready to fire the midnight shift computer operator for sleeping on the job, and the owner wanted to know if I was interested in the job.

For ya'll that don't know - being a midnight shift computer operator is just about as low as you can start in "the industry". I even took a sizeable pay cut to take the job, but I could see that the upside was greater than answering the damn phone.

So, I did my operator stuff and on the side began writing programs for fun and learning since I was taking programming courses and had the time late at night to play. These programs eventually made it into production during the daytime and of course problems happened (aka I sucked ). My boss promoted me to "programmer" and hired another person to replace me as operator.

They say that success = preparation meeting opportunity. In this case this is certainly true (taking programming courses), and in fact in every major advance i've made in my career that's also been true. It's hard to say what preparation will enable you to move forward in this industry; it's gotten quite brutal with the pace of change and the outsourcing that's been going on. Still, there is a demand for qualified programmers/technical people.

I see that being properly prepared to take advantage of future opportunities is your major obstacle. It would be nice if we all had a crystal ball and could see what we need to do to seize opportunities that come our way. This is your biggest challenge to getting into this industry, as well as is mine in remaining a valuable resource.

hahahahhahaha @ Cruz's analogy!

SCRUB TEH FLOOR!

Programmers do not design software, they just write what they are told to write. Software Engineers, Software Designers, they design software and in many cases also implement (write) the software. So, if you really asked Programmers then it isn't surprising they have never used it in real life. I also wouldn't be surprised if the "Programmers" turn out to be Software Engineers/Designers.

If you want to be good at software design, then doopie already suggested the tool for you. Unified Modeling Language, UML. They won't teach it at school until you get into object oriented world. Right now I wouldn't worry about it too much, go with what they teach you at school and be good at it. Once you have that in control, learn stuff on your own but be careful not to confuse yourself.