How Not to Screw Up Deadlines

No one likes tight deadlines.

I try to offer such a deadline, so that by the end of the period my work is ready. Not the initial development, which requires a lot of tweaking and debugging, but the final desired result.

Two people can’t understand each other with precision. We communicate with words, and words are code. There are errors and inaccuracies in the code. That’s why I try to establish such deadlines so that I have time to make the first version, submit it for review, get comments, and complete the job.

This does not mean that the projects should drag on for weeks. That is why I have tried to adjust the “progressive JPG” method. If the project is big and has a lot of small details, I try to work with it iteratively. First I make a basic layout to give the project a coherent look. The content can be replaced by pictures for now.

Then I work with the main blocks. Here I can spot the main mistakes of the previous iteration, correct the layout, set class names more correctly, etc. Then I add details if needed, active and hover states.

While I’m creating the layout, I’m thinking about a structure for future components. Usually, by the end of the second or third iteration, the page is ready.

This method may seem to take more time. I thought so too, but it turns out to be the opposite. This way there is much less chance of making a mistake and more chance of finding a simpler solution.

This non-linear system allows you to keep in mind not individual pieces of pages, but the future site as a whole. And, of course, there is always something to show, even if it is still a work in progress, and the details have not yet been worked out.