In school? Meet with your professors often.

I had a meeting with my instructor for Programming Systems, where my project partner castlez and I discussed our project with him: a Dungeons and Dragons app. castlez and I have been working at this project for a few weeks now, but haven't made huge leaps of progress (side project, in any case), and we were hoping to get some advice about general workflow, source-code management, object orientation and cohesion, and design tools.

What we got out of it was great advice that is going to help us keep motivated to work on this project: use CRC cards to design, code as late as possible, take on working roles that suit you best, and keep coding!

Dr. Trigoboff, about whom I've written for work, is a pretty great guy. He agreed to meet us after class, and we discussed plans for our project while he ate his lunch and thought about what we had to say. Here are some rough transcriptions of the three big questions we asked.

We asked: "How much code can we expect to get done in, say, a week?"

He answered: "You know, that's not a good judge of what you're getting done. An expert programmer might spend two weeks working on a task that winds up taking 300 lines of code, because he gets it done efficiently. A novice programmer tackles the same problem a little faster in 1000 lines, and it's not as good and full of bugs. Who did the better job?"

What I heard: "Instead, try to focus on milestones for the number of working features in your system, but remember that some problems are very complicated and take a lot of time, but not many lines of code. Just focus on working."

CRC cards have the class name on the top, the
things the class has to do on the left, and the things
with which it has to interact to fulfill those responsibilities,
on the right.

We asked: "How can we brainstorm our project? Right now we're sort of doing exploratory coding."

He answered: "Use Class Responsibility and Collaboration cards. They'll help you brainstorm how your classes should look and behave, and more importantly how they interact. And it's good to use real index cards, so you have something to physically move around. Exploratory coding is good as long as it's done in the right spot. Typically it's best to start coding as late as possible, like when you've got a great idea of how a given process will look."

What I heard: "Use CRC carts. Also, exploratory coding is something that should be done on a separate branch in your Git repository. And measure twice, cut once: it's gonna suck if you write tons of code and then have to turn around and fix or change it, later on, when you realize it's a dud."

We asked: "What should our workflow look like, in terms of time management and deadlines? castlez wants to get to coding more, while jnickg tends to focus on things like making sure our Git repo works, and the project in general is on track"

He answered: "It sounds like castlez is more of the software engineer, and jnickg is more of the manager. Both roles are pretty important for getting the job done, so keep doing it that way if it's working."

What I heard: "Play your strengths. If you're more concerned that the entire project comes together, keep it up, and let those who want to code more focus on actual coding."

We asked: "How can we get this project done?"

He answered: "Keep coding!"

What I heard: "Keep coding!"

I get the feeling that last one is very important.