Lesson Wednesday

Now that you have been a student at Epicodus for a little while, and have turned in several independent projects for Fridays, you may be wondering what that “Project is in a polished, portfolio-quality state.” objective you see on every project really means.

As former Epicodus students ourselves, we know that not every objective on every project is necessarily one you want to keep working on. (After all, how many pizza price calculators do people really need?!)

But nevertheless, many of these projects will become part of your portfolio, and some of them will be projects you will want to develop further—which is why we emphasize that each project you turn in should be as “Polished and portfolio ready” as possible.

That said, we know time is limited, there isn’t always enough of it to polish each project as much as you may like or even as much as you think is appropriate for your portfolio. That may leave you to wonder: 'Why bother? It does the job and it passes". This attitude may have served you well in High School or college, but when it comes to competing for jobs, you should always try to display your work at its absolute best, even when time is short.

We are simply encouraging you to take pride in your work, and spend time considering the value of what you are presenting. Polished and portfolio-ready—given the circumstances!

Polished and portfolio-ready isn’t just about how a project looks, or whether it has beautiful styling, but how the project is presented in its entirety. After all, many of you are not working towards employment as designers or even frontend developers. And even if you are: While you may not have time to tweak your CSS to perfection, there are many simple, concise, quick-to-implement things you can do to enhance the presentation of your work. You do have 30 mins to vet and correct all of the above.

Here is a non-exhaustive list of factors we consider when evaluating how "polished and portfolio-ready" a project is:

"Polished and Portfolio" ready can mean...

  • Work is submitted free of punctuation, spelling errors, grammatical errors, or typos
  • Page titles and text are accurate for the work presented
  • Project description has been read through clearly and every attempt has been made to meet all objectives
  • Work has clearly not been copy/pasted from the curriculum but created from scratch
  • Readme is complete with ample, correct setup instructions and a clear description
  • Commits are done regularly with the correct commit messages. Commit messages are unique
  • Apps clearly communicate with the user (meaning: if you delete something, a status message is presented, such as “Entry deleted”
  • Forms are clearly labelled and / or use placeholder text to make it clear what they should be used for
  • Forms are validated - user cannot submit empty or incorrect form information - ever!
  • App has clearly been thoroughly tested; Known bugs are mentioned in the readme
  • The app does not crash, display 404 or 500 errors when being used
  • Work features easy to read layout with large enough fonts to be readable, and backgrounds that do not obscure the content of the app
  • Apps with multiple pages or screens have a UI flow that is intuitive and easy to understand
  • Care has been taken to create at least some basic custom styling
  • Excessive commented out code, logging and debugging statements have been removed
  • Code is indented and spaced correctly, with comments used sparingly to illustrated complex code sections

...and many, many more. Remember, you are the project, and you set the bar.

So. Before you submit a project, take time to review your handiwork, and consider whether you would be happy to receive this project from a junior employee at your future company!