IMO the concept of projects should change as you (the general “you” here, not anyone in particular) increase in skill level.
First, the number of projects isn’t important, but the kinds of projects that you’re doing.
When you’re a beginner starting out, projects like the FCC assignments are fine, and indeed are a good way to build skill and confidence.
But once you get to a certain skill level, getting to “job ready” becomes a lot more about the types of projects and other things that you can build. I see too many people in general settling on doing projects that don’t really have much interactivity. More people should have more ambitious projects that do more. As in, full SPAs with authentication that consume from an API for front-end. Or the API itself for back-end.
Essentially, too many people build projects that don’t solve a business problem, which is a mistake. The majority of companies want to see projects that show you can hit the ground running, and the “toy concept” projects don’t do anything to show that.
Yeah, I think it’s reasonable to start off your portfolio with simple projects - that’s all you have in the beginning. As you get better projects, you put them at the top of the list and the simpler things get pushed back. Yes, eventually you should have 1-3 “full” projects that show you off well and those go at the top. If it’s your resume, maybe eventually those are all you list there (because of space considerations.)
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.
Yeah, but I would rather you move onto other projects and show off on those. Rather than make an amazing weather app or todo list or whatever, I’d rather you just leave those and move onto something else, something bigger and more original.
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.
Right, but I think you can show that on your lastest and greatest project. They’re probably only going to look at your latest projects anyway. I wouldn’t worry too much about cleaning up old code. If they see that you write clean code now, they aren’t going to care that you didn’t a year ago when you were still learning. I think the time lost going back over those old projects could be spent learning some cool new libraries or conceiving some better show-off project.
I’d only focus on the “one single project” route if and only if you are short on time.
Software development is large, and the idea that you must be a web developer and you must have a good portfolio and you must check a bunch of boxes to get a job misses a key point of the entire job search, that is don’t specialize if you don’t have to.
What I mean by this is if your starting out, you might start with web development, but that doesn’t mean thats your only option and final option. What if there are bunch of mobile developer, Java Developer, C# developer, jobs of which none have to do with web development? Yea web is accessible, but maybe its too accessible, hence why you gotta sell yourself so well as there is a lot of competition.
Learning a multitude of concepts and the core fundamentals and just plain playing around with what interests you ends up being a better path most of the time, rather than forcing yourself thru a single “web developer path”. Being a jack of all trades doesn’t just stop at web development, even if that means you can’t have a fully finished fancy full stack app. If web development was the be all end all, then yes it makes sense to go all in. However it isn’t, it never is and never will be the only developer domain looking for people to apply.
Another way to stand out is having a breadth of experience, rather than a lot of specific “job ready” experience. Yea job ready experience is more hirable, but a person with a wide breadth of experience in and out of a specific domain shows a person can learn, grow and is curious.
Both approaches have their merits in terms of getting employed. I usually say if your already doing the work asked for your have a better chance. At the same time, if you don’t even like the work your doing whats the point? Expand your horizons to find what you like is just as important as getting hired in the first place, IF you can afford to have time to find what you like.
I’m not against people having multiple projects. But a) you should guide employers to your best work and b) if you have limited time focus your efforts on making 1 really good portfolio piece.
And by the way, I never did this and I still managed to get a dev job eventually. But if I could go back and redo it, I think it would have been easier if I had taken this advice.
Absolutely agree with the notion of playing around in different stacks.
I also don’t think my suggestion is by any means the only way. You can certainly get hired with a bunch of micro projects in your portfolio.
However, if you know for sure you want to get into web application development, and have gone through the FCC curriculum, taken Udemy courses, done the Wes Bos JavaScript30 etc and you just can’t get interviews, then one reason is likely that the people looking at it just aren’t impressed enough by your portfolio compared to the other applicants.
Obviously there is a lot more to being “the right fit” at a company, but if your portfolio can communicate that you are undoubtedly job ready, then that’s one less risk the employer has to think about.
If you’re coming in, not having gone to college for this stuff, and not having past work experience in the industry then you’re coming in really cold. Your lucky if someone even checks out your portfolio or even looks at one of your projects even if they’re hiring juniors at the moment they’re likely not looking for people with zero experience.
I might need to edit the original post so it’s not implied, but my opinion on the one vs many projects thing is intended for people who are “job ready”.
I’ve come across a lot of self-taught devs in person and online who are more than job ready. They know how to do so much, and in some cases are more disciplined and better at what they do than some people who’ve been doing this for more years than you probably want to to know. It’s the lack of experience that is preventing them from getting a seat at the interview table and if they could just get that interview they’d probably get the job.
But then you look at their resume and they don’t have even one project that ties all the skills they have together in one place.
Pretty much agree with most of what you’re saying!
I’m only saying you do this after you’ve probably already built dozens and dozens of projects and have learned most of what anyone would expect a junior (and some seniors don’t know if we’re being honest … that’s a whole other thing) to know.
I don’t think people need to go back over their early FCC projects and redo them or clean up code.
But I also think picking any one of them is a good place to start for your main portfolio piece. My thought is that you should focus on demonstrating your technical skills not your ability to invent original ideas. Not that the latter is bad if you actually have that ability. But most of us aren’t awesome at it.
Thank you for listening to me think through my thoughts out loud by the way
Really appreciate all the feedback you and everyone is giving me!
I am quoting the first from Jessica to say I completely agree. I was doing my first project and was supposed to do some things but I did not know why and this irritated me to no end. I don’t want to copy and paste just to have a checkmark on the project. I have to know WHY something does what it does (among so many other things), and I also believe this is the only attitude that will enable a self-learner to grow.
I am quoting the second to Danny (with the great last name… as I very much enjoy reading what you have to say, and I want to be subbed and come back and read this in 4-5 months.
It really comes down to each commit message being meaningful.
That means a message should very clearly describe the work it references and all the file changes associated with that message should look like they belong.
Another key is for the commit messages to have a consistent style.
There’s a great article from 5 or 6 years ago that I read on this and I’ve been following these rules ever since:
I would also add that having a good commit message will save you a lot of headache.
Naming all of your messages “working on js file” is going to bite you in the butt later if you have to revert back to a particular commit and can’t find it because of poor commit messages.
When my client or HR asks me for some examples of projects, what is the best posting option? Is it a GitHub account or a link to the top one or two projects?
Github, with a really obvious link to the live version + clear instructions for running it locally (which is not likely to happen, but it is important to ensure that following the instructions results in a running app regardless of platform)
… that’s a whole other thing) to know.
as I very much enjoy reading what you have to say, and I want to be subbed and come back and read this in 4-5 months.