If the program is automating a manual process then you should try--or petition for the right to try performing that process yourself so that you can become what the program is supposed to become. At the very least you should spend time watching people do things the old way, talk to them, ask questions, let them show you pictures of their kids, buy them drinks, get them drunk and provoke them into talking shop.
This is great advice! Programming is the "how" to accomplish a "what". Many of us don't spend enough time on the "what" to do the best job we can on the "how".
OP provides more recipes than theories. Great post!
I strongly agree. I also strongly recommend the flip side, which is to operate the automatic process so you can better understand what will make it even more friendly and effective for its users.
I've always believed this and had the most success when having done it, but I've also worked on a lot of projects where -- when I said I wanted at least three weeks to meet with people, do interviews, observe the task to be automated and perform it myself -- I was told the project was too important to waste time on such things. As you can predict, those projects were so important, they ended up being killed because they were taking so long and didn't sufficiently automate the task they were meant to (even if they followed the requirements--to the letter).
Good stuff. This would apply not only to beginners though. I know lots of programmers who have worked for years that have either forgotten or never learned this stuff.
Depending on the size of the project, step 7 can (and should) easily be the most time and labor intensive part of development. By all rights, this step ought to be called Design, and may well generate the documentation and a plan for testing of some kind.
UML becomes very important if your project generates its code from it, as quite a few companies do. This means you may not be able to start coding at all until the design is in some state of finality.
I used to think UML was a cute, if overused, joke. Then I found out companies were serious about it. Recently I heard that my friend's gf was going for her Level 2 certification in UML. Not Level 1 you see, Level 2. Her UML skillz are literally going to go to the next level!
Meanwhile I still feel that the very idea UML can be useful, at all, is utterly perverse. The whole idea stinks to me.
The real power of UML is harnessed when the model actually generates the code. When that's a part of the process, then the model IS the code, and the model also becomes documentation that's guaranteed to be accurate up-to-date.
This also gives you the great benefit of mandating a comprehensive design phase. Once a model is complete (whatever that means in a given project) and reviewed, the rest of the coding is often trivial.
I also find that the mere act of learning UML is a tremendous education in architecture, even for developers who are naturally good architects.
I have no idea what you are talking about, you may as well be speaking Klingon. Hearing phrases like "This also gives you the great benefit of mandating a comprehensive design phase" makes me want to kill myself. I advise you to quit your job.
UML modeling tools will generate code that fulfills your model. You'll get more-or-less complete headers, with your objects and method prototypes, and you'll get implementation stubs. If your design is sound, then the process of filling in the guts of the implementation can be quick and straightforward (ideally, but I find this usually pans out in practice).
If your project requires code to come from UML, then any architectural changes are made in the UML tool, not directly in code. This means that the model is always accurate. In my company, the models are the primary documentation; if you need to know how a module works, you can look at the model and see every object, attribute, and relationship, both within the module and to other pieces of the project. And unlike every other piece of documentation I have ever seen, these models are guaranteed to be accurate, because they literally write the code.
A process like this requires you to think -- a lot -- about the design of your program before you even open a text editor or IDE. That's what I mean by a mandatory design phase.
I hate to be a cynic, but your first assignment will be to make whatever it is work. As this is your first real programming gig you will probably be given a hopeless assignment with really bad or zero infrastructure to build upon. Lacking development infrastructure or even fellow developers to work with, you will become a pawn in company politics you are totally unaware of.
My advice is : bite that bullet. Work like a demon and spend your evenings building the infrastructure needed to produce a working piece of code. Spend your day time hours building code that is just good enough to demo. Talk to people and get feedback, but avoid giving your immediate superior the idea that you're going behind his/her back.
Working like this blows, but do it for half a year to a year and suddenly you're an experienced developer.
Now move to a different location.
(If you're lucky enough to land your first real-world assignment in an environment where there are experienced seniors to consult and you have an existing build and test procedure, I would give different advice.)
This is great advice! Programming is the "how" to accomplish a "what". Many of us don't spend enough time on the "what" to do the best job we can on the "how".
OP provides more recipes than theories. Great post!