Along similar lines to the last post, there is a schism between objective and construction that makes completing tasks very difficult. You have to know what the client (or instructor) wants, which is very rarely the case. It's about designing a system of questions designed to work through the mass of information (relevant/irrelevant, existing/missing, etc.) that comes up in an effort to complete a project.
Theoretical understanding of the concepts and the language of a program means nothing if you can't outline what the objective is and create steps to accomplish that goal. The biggest challenge for me is being able to work through exactly what it is that is wanted versus what is given (also a challenge in the labs--took maybe ten minutes to figure out the code they wanted, but an hour and a half to figure out that the two and a half pages of text, with strong wording towards the way we've been working with classes, had absolutely nothing to do with classes and would, in fact, glitch constantly if you tried to call the function inside of the class.
It's almost guaranteed that leaving the CS world, there will be clients that don't even know what they want. Perhaps it would be easier to start from scratch with a world of knowledge and build from the ground up--which is the way I work; big picture and breaking it down into smaller tasks and eventually individual methods and variables. It's the reason I get so confused working with assignments where some code is given and some is required to be written (very vaguely outlined); I have a hard time discerning what it is that I need to do.
If you have problems understanding the labs tell the prof. Courses later on will give you a better idea of how to deal with clients.
ReplyDelete