How do real programmers (I mean people who actually get paid to do it.) plan a program? I mean I sort of make my own ways of planning programs before I start but what is it like in the real world?

Do you use that UML stuff? Do you make a big flow chart and all that?

I'm thinking about studying something like that but I don't know what to study.

The real world? It's whatever works, really. You'll have meetings, and determine what the program needs are, then code for it by handing out different pieces to different programmers. Each of the programmers has their own method of getting stuff done. Some do flowcharts, spreadsheets, etc., some have a wall full of post-it notes.

The company *MIGHT* Try to tell the programmers what to use, etc., but they'll do as they want anyway, and fill in the corporate forms later.

Concentrate on good coding practices...that'll serve you better than any 'management' class you can take.

Really? Thats seems a little too good to be true because according to that I already do it the right way. I'm sort of a combination white board/notebook, plan some stuff, other stuff just code, rework it later, make some diagrams sort of planner.

Everybody think I should just forget about UML and all that and just keep doing it the way I'm doing it?

asically the upper level managment draws up a flow chart and discusses it with the programmers then from then on the programmers are on there own.

I wouldnt say forget about UML. If youre already familiar with UML, then I would say dont worry about learning more (unless required/told to do so). If you dont know UML, then learn the basics--its pretty straight-forward stuff. If you were in a job interview, or talking with (technical) co-workers, and UML was brought up and you didnt know what they were talking about, then that would look pretty bad.

As mentioned earlier, you do whatever suites the program and your skills best. Usually software engineers or architects are the ones doing the very high level stuff, including UML. When it finally gets in the hands of the programmers/developers, then they will probably do whatever they want and know will work best. Also as mentioned, the programmer/developer will also use the UML when required as a formality. Ive had this experience in the past where, after development was complete, I would work "backwards" to create the UML, because it was required. However, I knew the best thing for me to do in the situation was do jump right into the development, then when complete, write the formal UML, etc., for it.

Oh I'm not asking for career reasons. I just want to know what works best for sorting out my own ideas for my own projects where I am the software engineer.

Formal models such as UML are used to generate code templates after an idea is well developed in a lot of academic computer science. This could be because many academic computer scientists are terrible at programming, though. I'm not a computer scientist, but I know some in the academic world. I do program for scientific research, though, and being the guy who can fluently program, people generally hassle me more about not using a language they know themselves.
Kevin Barry

Yeah I'm not a student or a professional, it's just a hobby.

Understood. Just for clarification, I was talking about professional academic researchers.
Kevin Barry

How "professionals" design their code will vary from organisation to organisation, each will have their own specific ways of doing it. When large, mission critical systems are involved more time is spent on the design compared to smaller hobby programs, and in my experience the best design practices include at least one of the programmers in the decision making process.

For you I would say do what you are comfortable with. You probably don't want to over engineer your code but using some of the tools that are available (UML flowchats, module charts) can be useful.

start with the idea first.

create your own version of it in a language you you understand

code
test
recode
test
recode

you know the rest for personal stuff.

One question to consider, when actually coding: Do you code from the bottom up (low-level functions first), or the top down (top-level functions first)?

Code from the top down, except the first time.

http://www.cs.yale.edu/homes/perlis-alan/quotes.html

http://c2.com/cgi/wiki?EpigramsInProgramming

http://c2.com/cgi/wiki?BottomUpProgramming

That's for sure!

If something meaningful gets decided at a meeting, it is a very good idea to write an email right after the meeting giving your understanding of what was just decided. You'd be amazed at how much gets forgotten and needs to be decided again if you don't. In the real world, most people haven't yet figured out such an email is required.

It has been many years since I have seen any programmer do any of those methods.

Some programmers I work with believe in programming "top down" (those aren't the better programmers). I haven't paid much attention to what theorists of good programming believe now. Long ago, they believed in top down programming. They were wrong. Top down only works for very easy projects.

When I was less experienced, I believed in bottom up programming: Figure out the primitives that a project will need and then build on top of them until you have the whole project.

What works for me now is to focus first on the hardest part/level of the project. Figure out how that hard part needs to work: What interface can it reasonably provide to the levels above. What services will it require from the levels below. What data structures does it need access to. Then work outward in all directions from there.

I've seen some very bad work from very smart programmers who take the opposite approach and leave the hardest part for last. Usually they paint themselves into a corner and the hard part has become impossible by the time they reach it.

I joined my current employer years ago before the product had reached a usable first version. I picked up the partially completed work of a supposedly brilliant programmer who had taken many major subprojects of the product and quickly gotten them 95% done before dropping them and switching to another major subproject (then he left the company before I joined). I just needed to do that last 5%. Of course he had dropped each subproject exactly at the point that he ran out of things that were possible to do. Everything in the last 5% of each subproject was impossible because of design decisions made in the easier parts.

If that's how a company does it, I would expect that company to fail....

I am not a programmer, but I've written a few lines of code and I have worked in the company of "real programmers" (some of whom were competent....

The basic rules are not specific to programming:

• Define the overall requirements for the system.
• Partition the system into modules using criteria such as:
  
• ....Simple interfaces
• ....Well-defined functions for the module
• ....testability
  
• Write the specifications for the modules
• As appropriate, generate flow diagrams, timing diagrams, etc.
• Setup a schedule which includes the integration and test of the modules
• And more......

One global principle is that requirements are defined considering how they will be verified (eg tested)

If you want to succeed, all of this will be done with the full participation of all stakeholders---everyone from management to the people actually turning the screws, running the drill presses, or writing the code.