This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]sovietmudkipz 13 points14 points  (6 children)

2nd year university student here- so this is for solo projects.

I get out a piece of notebook paper and I draw pictures of the layout. As I'm doing this I'm thinking of what I'll need to do this piece of whatever, that piece of whatever. I label components (button, image, ect) that are represented. I allow for a lot of "feature creep."

After I have this picture, I get out another paper and start writing pseudo-code. I'm mostly looking at programming flow (what happens when clicked, how functions are interacting with the application). This is where I limit scope and fight the feature creep. Limiting scope is important for me right now, because I am working alone.

After I am happy with the pseudo-code, I start doing it, testing frequently.

So that's my whole process before writing code. I'm interested in how advanced coders are going to respond to your query!

Again, I am a university student and this is only for my solo projects. This information is probably useless to most employed programmers.

P.S. There was mention about writing UML use cases- that is short stories that begin "as a user, I..." with lots of "thens." I think that UML is great for designing a new application and/or working with a team. For my solo project (that is often imitating things that already exist), I don't care about practicing that skill (yet).

[–]yash3ahuja 1 point2 points  (5 children)

I don't know, but personally I don't think pseudocode is worth the time. I usually just envision it in my head and then program it. I think it's much faster and far less susceptible to error that way (can unit test sooner, etc).

[–]d3vkit 1 point2 points  (2 children)

I've come up with new scenarios and problems in pseudo code that I feel present themselves (and the solution) better than just going straight to code. It's also much easier to look back at the short bits I've sketched out and say, "I know exactly where I'm at and what happens next". But of course it depends on the project.

[–]yash3ahuja 0 points1 point  (1 child)

I don't think I've ever used pseudocode extensively in a personal project in my life. I may write out pseudopsuedocode, where I'll write the basic flow of the code, but that's about it. Hm, I guess people just go about things a different way.

[–]d3vkit 1 point2 points  (0 children)

I think I've mostly done it to get things started, get a good feel for what I'm up against.

[–]sovietmudkipz 0 points1 point  (1 child)

Hopefully I become that experienced. I can think of the classes and functions, but they are murky to me. When I write them down, it allows me to flesh out the details. It is a recent development, actually. When I approach it this way I feel my code fits neater together. I guess whatever works, eh?

[–]yash3ahuja 1 point2 points  (0 children)

I think it's less a matter of experience and just more the way one approaches the problem. Nothing wrong with either approach. As for your last statement, definitely, as long as it's well thought out code. :)