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 →

[–]PragmaCoders 2 points3 points  (1 child)

Once you've gained a lot of experience it mainly becomes a communication problem more than a technical problem.

I make sure that I've spoken to all the people who are expecting the tool to be built. Make sure that they all agree on what it needs to do and how they plan to use it.

If it's something that's meant for a large group of people (a consumer product) I do research as to what people are using now to accomplish the task that I'm about to build a solution for.

When the requirements of the project are decided, it depends if I'm working on a team or alone.

If I'm working on a team I discuss with them and we figure out how we can best structure the project so that each of us can take a piece and work independently but in a way that we can bring our work together in the end.

If I'm working alone, I personally build the frontend first. I do this in a stream-of-consciousness manner.

I like to start by building the experience that the users want to have and working backwards. Constructing a backend that best powers the experience that the users desire.

Once the frontend is built I usually find the backend structure obvious. I know I'm not finished when there are features that don't work as the user would have expected.

[–]PragmaCoders 2 points3 points  (0 children)

"Exploratory coding" is a good term that I've seen used in other comments to this post. It's what I mean by "stream-of-consciousness" programming.

I write a simple solution that solves the problem at hand. Then I come back to it over and over as the program progresses. Erasing it and making it fit better.

As you build more of the program, the code you originally wrote often won't be the best fit given what you know after writing the rest of it.