Building an Effective Dev Portfolio
Josh Comeau · Self-published · 2020 г. · 72 с.
#dev#portfolio#inspiration#book#read
http://library.hazadus.ru/books/80/details/
Abstract
As a junior developer, your portfolio of projects is the greatest asset you have. This 70-page e-book shows you how to showcase them for maximum impact.
About the book on author’s site
Quote
This is a lot of information, and people often won’t spend that long reading. Because of that, you need to be strategic: avoid long paragraphs. Make use of many headings, and use lists within those headings to break up chunks of text. In essence, make it easy to skim. Some people will get drawn into our narrative and read every word, but we want to make sure the core messages come across even if someone browses quickly.
Project description template
Introduction
- High-level summary of what the project is
- List of core functionalities / interesting features
- Your role in the project. were you exclusively doing development, or did you do design? If you worked in groups, what parts did you tackle?
- Technologies used
- Links to live demo + source code (if applicable)
Purpose and Goal
- Why did you build this project? Why is it important to you?
- What was the expected outcome of the project?
- What were the initial designs?
- Any other preliminary planning that you did which helps build a narrative
Spotlight
- What is the “killer feature” of your project? What feature does it have that took the most work, or was the most technically impressive? Some possible examples:
- User authentication
- A feed of items fetched from a database
- A particularly tricky UI element (eg. autocomplete, calendar, drag-and-drop)
- Anything you’re proud of!
- What were the technical hurdles that got in your way? Any major problems you hit during development?
- How did you solve those problems? What was the solution? Go deep here, and write with a developer in mind.
Current status
- This section is optional. If the project is actively being used by real people, talk a little bit about the current status, who uses it, why they use it, what they say to you about it, stuff like that.
- If the project was contrived specifically for the portfolio, omit this section.
Lessons Learned
- What did you learn doing this project? Feel free to list multiple things. Also feel free to cover non-technical lessons. It’s great to talk about how you learned to use an advanced feature of a framework or library, but it’s just as valuable to talk about project-management experience, or things you learned about shipping projects.
- If you used a framework or other libraries/tools, was it a good choice? How did it help? In which ways was it insufficient?
- Is your project accessible? What did you learn about accessibility, while building this project? Describing how you tested your project using keyboard navigation or a screenreader can make for a really compelling story!
- How has this affected the work you’ve done since then? Real examples of how this project built your knowledge for future projects is fantastic.
Quote
==If you only take one thing from this book, make it this: no matter how cool your project is, it cannot be summarized by a screenshot and a short paragraph. Guide the reader through your work!==
We want to be completely honest, but we also want to highlight all of the details that make our project cool. Things that might seem trivial or mundane to you can actually be very impressive to potential employers!
Your home page should include:
- A brief “About Me” section that highlights your background and personality.
- A list or grid of projects you’ve worked on.
- Contact information (ideally an embedded form, but a mailto link also works. Don’t just include links to social media
Each project in the list/grid should link to a “Project Details” page, which describes the project in greater depth. This is absolutely critical.
Case study
Most companies hire junior developers based on potential, not based on your current level of expertise. In fact, when a senior developer reviews your portfolio, they’re hoping to see that you’re eager to learn, humble, and looking for guidance; folks like that tend to be easier to mentor, and make for better teammates.
What to include in project description
- Why is this project important to you? What inspired it? Why did you choose to build this?
- What are the major features that make it unique? How does it compare to existing products like it?
- What did you start with? Was this built from scratch? Did you have a team? If so, which parts did you do? Where did the design come from? Was there any collaboration?
- What was the hardest part of building this product? Where did you get stuck along the way?
- When you did get stuck, how did you resolve it? How did you overcome the obstacles you faced?
- What did you learn from doing this project? How has it affected the work you’ve done since then?
Unlike HR hiring managers, developers generally aren’t very interested in what languages or frameworks you know. In fact, for junior roles, developers care much more about your potential rather than what you happen to know already. They want to know if you’ll be easy to mentor. They want to know if you have the grit to work through tough problems, and the humility to admit when you don’t know something.
In fact, if you’ve spent many hours on a project, there’s a very good chance that you’ve faced and overcome significant technical challenges. Projects often have hidden complexity, and employers are eager to hire developers who are good at solving problems. The main purpose of a portfolio site is to show prospective employers how you ran into technical challenges, and overcame them. Your projects don’t need to be flashy or feature-rich.
Ultimately, a portfolio site is only useful when you have projects to highlight. If you don’t have at least 1 significant project and 1 minor project, consider spending some time filling in your portfolio.
If you have an unfinished project, list it anyway, and note that it’s “still under development”.
If you have a dozen projects that you feel are worth including, it’s likely that you’ve gone too wide and not deep enough. Pick the 5 projects that best represent your skills and the work you want to do, and (if possible) consider spending a few days extending your largest project to be even larger.
Nobody will spend time looking at more than 5 projects. Most people will only look at 1 or 2.
If you include 12 projects, a potential employer might only look at your least impressive one! Portfolios are meant to highlight your best work, they aren’t meant to be an exhaustive set of all of your work.
If you really want to include more than 5 projects, tuck the other projects behind a “show all” or “view archive” link. That way, you’re setting a clear distinction between the “topshelf” stuff and everything else.
HOW MANY PROJECTS TO INCLUDE?
At least 2. No more than 5.
Something which can be surprising: It’s better to have 1 large polished project than 5 small projects.
You want to show that you can complete a non-trivial project from start to finish. Depth is more important than breadth, because it shows that you have the grit and determination to stick through the hard parts and finish a large project.
PROJECTS NOT TO INCLUDE
- Don’t include projects that were created by following a step-by-step tutorial. Same thing goes for workshops or exercises assigned by a bootcamp.
- If you made significant extensions to the project, it might be alright to include.
- Confidential Work
- The Portfolio Site Itself
- The exception is if you invested time into parts of the site that are non-obvious from a user perspective. For example, did you build an “admin panel” to manage the content, like a mini home-built CMS? Did you code an analytics page to learn about traffic? Absolutely include it in this case!
In my experience, certain kinds of projects are especially high-impact:
- ⭐ Did you build a project to solve a specific niche problem you had, like Levi’s invoice-scanning app? Employers love to hear about projects like this, because it shows that you’re able to apply your skills in creative ways, and tackle a project from start to finish.
- Is your project “alive”? Is it shipped, and are people really using it for its intended purpose? It’s better to have a living, breathing project with real users (even if it’s only a handful) over a project that was built exclusively as a demo / for the portfolio.
📂 Reading | Последнее изменение: 06.12.2023 15:33