Better to have one solid project or many simple ones?

Career Advice
1

I have an opinion on this topic but I want to hear other people’s thoughts on this. Especially if you happen to be in a position where you review candidates for a job.

Edit

I just want to preface this so there’s less confusion. This whole spiel applies to people who have completed dozens of projects along their self-taught journey. At some point you have built up the skills necessary to be considered “job ready” but you haven’t built anything to tie all those skills together in one place.

I’m not saying people shouldn’t build a plethora little projects. That’s part of learning!

I’m saying once you’re tired of feeling more than capable of work but you’re not getting any calls back or interviews, focus your efforts on making a fully polished app or website or whatever makes sense for the jobs you’re applying for.

End edit

I don’t necessarily believe there’s anything wrong with having a lot of simple projects on your portfolio. The more things you build, generally speaking the more skills you’ll learn.

However in my experience people who are skimming resumes including myself, really just want a link to the one project you’re most proud of.

I’m certainly impressed when I visit a portfolio site and see lots of projects but without clear direction to which project I should be paying attention to I’m also overwhelmed.

I feel strongly that new developers who are struggling to get that first job because of lacking work experience need to have one project in their portfolio that covers enough skills to show off they are job ready.

It’s not only beneficial to them as it would require going deeper into there skill sets, but also make it easier on employers/hiring managers because they don’t have to go sifting through a dozen apps to see their full skill set demonstrated.

I see a lot of emphasis on the idea of making more projects and not enough on improving the professionalism, quality and completeness of existing projects. If you want to stand out from the crowd as a new developer (who doesn’t have a degree or past work history in the field) I really believe you need to show something that meets professional standards.

What other thoughts do people have on this?

4 Likes
2

I agree with you on this. I think one or two or three really good projects would be more beneficial to you than to have every project you’ve ever made on your portfolio. It does get overwhelming and it is hard to know what to look at. But I would also say that you may need more than one project so maybe having like 3 medium projects instead of just 1 very big project that way you could show maybe more skills than if you have only one project. :smile:

1 Like
3

Why not both?

I don’t think its something that has a pure right answer. I’d hope lots of simple projects means someone went into multiple different topics and learned a little about a number of different things. Having at least one project with a lot of bells and whistles means they know how to put complex stuff together.

I do think only having a lot of small projects probably doesn’t help. As then, the most complex thing built is small.

4 Likes
4

Why not both?

Good question!

I think it comes down to limited time and what to focus on. I understand to learn, you have to build a lot of small very focused projects. But in terms of stuff that’s portfolio worthy I think a lot of newcomers trying to get that first job would benefit by focusing on just a single project.

It’s not just about complexity and size either.

It’s about demonstrating professionalism. I see a lot of “portfolio projects” that are well done and all, but they look like school projects.

There’s a big difference between a website or application you build for a paying customer and one you build for a school assignment or to tick off the requirement of an FCC certification.

Performance, accessibility, localisation, having proper meta tags for link sharing, favicons, offline functionality, progressive enhancement, and not to mention all the pieces in just delivering the software from deployments and testing to your git flow; your branch management.

And then of course after all of that, including enough features to be able to demonstrate skills related to actually building software is important too.

I don’t see very many portfolio projects that take the extra steps required to communicate that they were built by a professional. And to be honest a lot of full-time devs already in the industry don’t have projects like that either. But that’s the whole point. To stand out and seriously increase your chances of being the one people hire despite not having professional experience.

Just something I’ve been thinking about a lot lately. I know there are a lot of people who are absolutely job ready but are struggling to just get that first break and the opportunity to prove it. In my opinion the key they are missing is that they don’t have that ONE project to show to employers that ticks off all the boxes from that list they keep in their head of what counts as “professional”.

1 Like
5

Hi @dannyjamesfletcher!

One thing I have noticed in my 6 months of coding is this idea of throwing a whole bunch of class projects into the portofolio.

I don’t think there is anything wrong with doing class projects for learning purposes. I have learned a lot by doing the fcc, odin project and udemy projects.

But a lot of people do those same projects and I feel like employers can tell when they see the same projects over and over again.

Calculators, tic tac toe games, to do lists, drum machines are good projects for learning. But in my opionion, lots of people build those same projects so you are not going to stand out.

I don’t think there is anything wrong with having a bigger project with smaller projects but I do think they need to be little original.

I don’t think it needs to be the next billion dollar app or some super complex project that would usually be created by a senior developer.

I think it is best to create projects that demonstrate coding abilities expected of an entry level developer that is not the same old projects that everyone else does.

Those are my thoughts :grinning:

4 Likes
6

Thanks for sharing your thoughts Jessica!

To be clear, I’m not saying people shouldn’t build a lot of projects (I don’t think that’s what you were reading from my post anyway). You definitely have to build a lot to learn.

My thoughts is that at some point, you are job ready. Unquestionably job ready. Maybe you don’t feel job ready due to imposter syndrome or whatever, but I’ve seen a lot of new coders who have done FCC and various other Udemy courses etc and have been learning for well over year or even longer and still can’t get that first job.

My opinion differs from yours slightly, and it may be biased towards my observed experiences but I actually think the simpler the app the better. A todo app is perfectly valid for a portfolio. But most people don’t finish it. Add the final touches and polish and go the extra lengths that are just part of the job once you’re working professionally.

  • Don’t leave exposed API keys just because the service is free.
  • Don’t skip testing even if you’re not that good at it yet.
  • Have a clean git history to the best of your abilities.
  • Use consistent code styling and formatting
    • Bonus if you have it automated
  • Don’t just fake your API talk to a real one
  • Write unit tests that mock/fake your API
  • Write integration tests that talk to the API for real
  • Don’t leave console logs littered throughout your code
  • Don’t skip accessibility
  • Decouple and DRY your code even if it doesn’t seem like it makes sense because “it’s a small app”

In terms of actual feature even something as simple and generic as a “todo app” can be fluffed up a lot (there are real-world, paid todo apps out there after all – sky’s the limit).

Most people aren’t hiring junior developers for the ability to come up with new product ideas. They’re hiring them for their ability to build other people’s ideas. Show that you can actually do that.

Build a real todo app, with user accounts, payments (even if it only accepts fake CC’s), subscriptions, notifications, release toggles, roles and permissions, web sockets, teams. There’s so much you can do with a concept that is already very well understood. This way you don’t have to waste time and energy coming up with something new and original and instead focus on executing the tasks and responsibilities you’ll actually have to do in the real world, and demonstrate that you have the ability to do so.

And I don’t want to knock people who are original!

Some people are naturally creative or are even coming to code from a design background. It also depends on what you’re trying to apply for as well.

If you’re trying to get a job building apps as a consultant or at a product company though, I really think having one very complete app is all you need to stand out.

2 Likes
7

Really appreciate your insight!

What would be considered a really good project in your eyes?

8

Hello,
Thank you very much for this very, very important topic.

If no client has accepted that I build a web application for him yet, what is the alternative project to the paid project?

1 Like
9

Yeah I can definitely see your point about the to do app.

I guess from my limited experience I have seen much simpler to do apps then what you have described. Those are the ones that I don’t think would impress potential employers.

I built a very simple one when I was first learning javascript but it was very simple styling and basic javascript. Maybe 50 lines of html,css and javascript code, if that. So I wouldn’t put that on my portfolio.

But if I went back and fluffed it up a bit then there would be nothing wrong with adding that to the portfolio.

2 Likes
10

Actually, I am planning to start building javascript30 projects do I start or is there a better option?

1 Like
11

Great question!

I think the alternative is to create an app or website to the standards you would expect from yourself if it were a paid gig.

I can give more details than that if you’d like just let me know!

12

I hope you give me the details …
When I read your words above, I felt that your words express a lot of programmers overwhelmed with learning and waiting, about myself as if you were speaking what is in my head.

1 Like
13

I have heard good things about javascript30.
So, I would do it.

They look like cool projects

14

Absolutely, I agree with that completely!

15

The mechanism is very simple to build, but I don’t know how to start!
For example, do I attend the video and build, or do I bring the video and then start building myself …?

16

The JavaScript30 projects are a great way to build a ton of hands-on experience and skills!

The best part is that you can take any one of those projects and turn it into that one big project that you’re really proud to put on a resume. Same goes for all the FCC projects too. Start with something simple and take it all the way to a professional piece of software.

2 Likes
17

And also when you finish a project don’t be afraid to play around with it a little bit.

Mess around with the code.
Try a different approach.
Break the code if you have to.

You are not hurting anybody.

I think building class projects is great for learning.

But I have definitely built some udemy projects in the past and had no clue how or why it worked. I just coded along with out asking any questions.

That is where you get into trouble in my opinion.

3 Likes
18

I found great suffering in Udemy projects, due to updates or changes, and I often get bored while building a project because I cannot finish it.

So I’m planning to build Javascript30 projects and come back to follow the FCC curriculum.

2 Likes
19

I was in a very similar situation myself when taking the self-taught path to this career.

It took me almost 5 years of learning (I wasn’t constantly disciplined with it the whole 5 years) before I got my first job, but I had felt job-ready for a long time.

5 years later, I moved up quickly, have been at 4 different companies, and the last 3 years has been at a consultancy where I work on a massive variety of projects and clients at varying scales. I also filter resumes and conduct interviews now, and so I find myself thinking a lot about what I would say to that past version of myself who felt job ready but just couldn’t get interviews.

I would say this.

Build an app that you already know the rules of. It’s ok if it exists already, you’re not starting a company you’re building a portfolio.

Don’t design it from scratch dumb dumb, you’re not a designer. Go look at existing apps and use them as a starting point, or even just use a component library.

Regardless of what that app is you should have these features:

  • User login/management
    • password resets
    • user settings
    • roles and permissions
  • Notifications
    • Email notifications at a minimum
    • (optional) push notifications
    • (optional) sms notifications
  • Websockets
    • Every app has at least one thing where the UX can be improved at least slightly by real-time updates
  • Handle payments
    • Can be configured to not allow real payments, but you should be using an actual payment processing platform like Stripe or PayPal
  • CRUD on at least one resource
    • A user should be able to create, read, update and delete at least one thing. This could be a blog post, a comment in a forum, a task in a todo app – doesn’t matter. Just CRUD on anything that’s not a user so that you can demonstrate your roles and permissions working

Not everything has to be tackled all at once. Be iterative about it.

There is also all the non-feature stuff. Some of these details can be considered “Dev/Ops” depending on who you ask, but a lot of it is just tooling, processes, and developer experience (DX).

You should have the following:

  • Git
    • Clean git history (no “did stuff” commit messages)
    • Consistent format to your messages
    • Any branching strategy but choose one that’s recognized by the industry
    • Bonus points if you can automate your git standards
  • Localization
    • At a minimum you should be using lang files for all static messaging even if you only support 1 language
    • Bonus points for supporting multiple languages
    • locale should be configurable in user settings, fallback to browser settings
  • Linting/Formatting should be automated
    • Use ES-Lint for linting, and Prettier for formatting
    • Linting should run in your CI
  • Have a CI (continuous integration) step in your PR process
    • With GitHub Actions and other similar offerings setting up CI has gotten so much easier. The only excuse to not set it up is you haven’t learned it yet. If you’re job-ready, you should be able to figure this out in a day or less.
    • This should at a minimum being running a linter
    • If you have tests, this is where you run them
  • Have CD (continuous delivery)
    • Deployments should be done automatically either by clicking a button or merging a branch into a long living branch like main/master or develop
  • Testing
    • Even if you’re an entry-level developer there are lots of options out there to get tests into your app that don’t require you being a seasoned veteran. Don’t worry too much about what’s “best” and focus on coverage and easy setup. Cypress is definitely most people’s friend here.
  • Database migrations
    • Only applies if you have a backend

This might not be 100% complete, but if an entry-level applicant sent me a resume and had a project that ticked 90% of what’s in that list, they’d be one of the best applicants I’ve seen. I’d have to bring them in for an interview regardless of their lacking work history.

Where you focus your efforts is going to largely depend on what your goals are. If you want to be a frontend developer you want to try and avoid building the backend yourself. Use 3rd party services as much as you can. Your “backend” can just be proxying calls to these 3rd party services (to hide your API keys) or even explore serverless options (which would be huge bonus points). Put all your effort in making the frontend super awesome (not just visually, but keep performance and architecture in mind as well)

Or if you think you want to be fullstack or backend, then build the API with only as much focus on the frontend as you need, or build a MPA in an MVC framework like Adonis, Rails, Django or Laravel.

Point is, whatever you build, you want to demonstrate that you know how to do the 90% of what’s common between almost every application out there. The team you’ll be working with can teach you how to do it better, as well as how to handle the last 10% that’s different.

8 Likes
20

On my portfolio, I highlight 1 big project and 2 small/medium ones with images , description and links to live & code. Then I provide a handful of text links to other projects.

Do you think this is a good approach, especially for a junior dev?

2 Likes