+ 24
Assignment Procedures - How relevant are they?
As a university student in the field computer sciences, I've been through quite an amount of programming assignments and tasks in which a report has to be completed after the coding task. My question is, how relevant is the paperwork when it comes to working in an organisation as a programmer? Do I have to do desk-checks with all kinds of test data and draw UML diagrams, flowcharts for every project I would be involved in? Is it a requirement in the industry?
10 odpowiedzi
+ 18
As someone not working in the industry, I don't know much 😕 But I've heard/read that newer companies are using more modern methods like Agile, Scrum etc.
Using UML diagrams and others, helps to document your project. Not only will this make the project easier to create and manage, it also makes sure the project sticks to the requirements.
Ultimately, it depends on what the organisation likes to do. This could all be wrong, cos like I said, I don't work in this field.
+ 19
Thanks for the input, Jafca. I'm asking this purely because I'm working on an assignment right now. Deadline is 10th of March and I've completed on the codes, but I'm typical programmer-lazy to finish off the report paperwork. =^=
I used to think that the end product, your program is everything. Turns out the process is what people want to keep track of in order to maintain a healthy programming practice in correspondence to fulfilling specific organisation rules. :x
+ 11
@Elfren Authorlee
I guess this mean that I can escape from documentation and paperwork if and only if I have a good manager. Thanks for the input, it's surely good to know! =^=
+ 8
UML Diagrams?You guys are really go so far -_-
+ 8
Hey Hey! This question is gonna be trending question I guess
+ 6
It all depends on the field and project management. I personally (and professionally) like to stick to high documentation/artifact standards because it helps tremendously in development for finding faults and areas for improvement [quickly]. It also helps when creating proposals for people because UML [style] diagrams are much easier for them to understand if they don't code. Take a look at The Open Group's (TOG) Enterprise Architecture for a perfect example. They are the best!
+ 6
Honestly...you know what really tends to drive this? Money (loss risk), reputation (don't show up in the news) and lawyers (protection of 'pick something').
A startup wants to go fast...we'll document later, maybe, if the sale depends on it...and a bohemoth puts in entire systems to guarantee 'procedures were followed (click here, upload your docs/steps/checklists, 'have you read the policies?', legal sees no liability, great). In a middleweight company, self-documenting code and reasonable check-in comments suffice...and in some places you delete everything as soon as you do it...no trail.
But try getting anywhere with 'free and open' (especially if money plan is your 'buy in') without EXTENSIVE documentation (or showstopping services...*). There's no support phone number for free users, yet they need your buy-in to be dead simple.
* People are more expensive than help pages. See the docs for successful 'free' products like Gimp, LibreOffice, and free->pay like AWS (unbelievably detailed and gigantic free service) etc. Google's got terrible docs around the mouth-slavering new services (startup mode) but great docs when you dig into the things that make them money (gigantic mode; free to try ads, and here's our amazing API docs).
And one more thing: Those docs prove you can effectively, accurately communicate. Some people really can't get that done.
+ 5
While programming is the core work of programmers, it is undeniable that paperwork and documentation is important in any workplace. You literally won't find an office job which has no documentation work whatsoever, no matter which field you are in. Harsh truth.
"If it's not in writing, it didn't happen."
+ 3
I have been in the industry for 6 weeks now and have completed 4 assignments, zero documentation, company is worth $130 million, that's just to give a rough size of the company. Each company as different methodology as to how they handle documentation. My manager deals with all UML and documentation then hands it off to me and I handle all the code. Once the code is finish he over looks it to make sure I applied in house APIs correctly and its on to next assignment. The only documentation I touch is descriptive comments in VS. Hope that helped.
- 2
I used to think that the end product, your program is everything. Turns out the process is what people want to keep track of in order to maintain a healthy programming practice in correspondence to fulfilling specific organisation rules. :x