Posted on 2017-08-28
Back in late October 2014, I submitted my final project for the web development bootcamp I was in.
Last week, I attended the demo day for a cohort of students at the same bootcamp, who I mentored.
In the past 3 years, I've gone from student, to alum to mentor, and I've seen my fair share of final projects. After last week though, I got thinking: What makes a good Bootcamp final project?
After the event, I got into a conversation with a student and two teachers discussing that very question. After compiling some thoughts, and reflecting on my own experiences, here's what I think the answer is:
Note: The bootcamp, Lighthouse Labs, is an eight week intensive. I've been most heavily involved with the Web portion, but I'm sure these tips are transferable to similar coding courses
Admittedly, the first point on this list isn't mine. Jeremy, a teacher and mentor, brings up a good point though. If you've spent the last eight weeks learning how to build web apps, don't go building something crazy in a language you've never used or on a crazy platform. Don't build a 3d platformer in unity if you've spent the past two months learning Ruby on Rails. Don't build a robot that fetches the mail for you if you've been learning HTML and CSS. Don't fiddle around with machine learning algorithms if you've been studying reactJS.
This isn't to say that those ideas aren't bad ones or won't make for amazing projects when done correctly. Projects like those absolutely wow the crowd at demo day. Here's the deal. If you go all out on something completely unrelated, there are only two possible outcomes:
Of course, you could get lucky and get a job in the field which you built your project for, but the bootcamp is inviting employers from the relevant field, so that luck is just that. Luck.
You should challenge yourself (see #3), but it isn't worth it to do something so wild it's ultimately pointless.
You should strive to make your project look as good as possible. This includes, but is not limited to visuals; You can make a terrible project look 10x better with just a layer of style. That said, a bad project will still be bad no matter how good you make it look. Other than visuals, you should of course have a good set of cool looking features. Live updating, unique GUI, draggable elements, and multimedia are all cool things that can make a project look good.
Flash and polish are no substitutes for a poor project, so do focus on having a solid execution before you go all out on design. If you manage your time well, you should be able to spend the 2 hours it will take to get something looking good once the bulk of the work is done. If you're looking to go the extra mile, things like hover effects, animations, images, and a personal favourite: video backgrounds, can all add that extra bit of flare that makes your project memorable.
Remember, it's worth it to work through the BS of the design process: asking people "which one is better, A or B?", or "What do you think of this new blue font?" are worth it to make something look good. Don't get stuck on this though: you can waste a lot of time.
On a side note: avoid frontend frameworks such as Bootstrap or foundations as it's painful obvious when you use them, and it shows to potential employers that you might not be great with CSS. With CSS, it's easy to fall into trappings and pitfalls if you aren't adept with it. Final projects are a good place to figure it out. If you absolutely have to a framework, throw on theme to make it look relatively unique.
As I mentioned before, you should avoid using CSS frameworks because you get a chance to use CSS on a larger project – and this is a larger project. Use the opportunity to challenge yourself: don't do things you already know because you will end up with an inherently boring project. This is because you'll fall into your routines; if you face a challenge, you'll be less likely to overcome it and more likely to work around it because by doing it the same old way, you end up in an "I can already do this" mentality that doesn't challenge you. By trying to do something new, you put yourself into the opposite mindset "I can't do this yet, but know I can".
So by challenging yourself, you put yourself into a state where you know what you're doing is a challenge. This change of mindset comes with better results. If you challenged yourself to climb a mountain rather than drive the road up it, you run the risk of meeting new and potentially dangerous obstacles. When you get to the top, not only do you have a better story (one where you overcame great challenges), but you have proved to the world that you are capable enough to do that. If you had driven, you would probably be more prone to driving back down the mountain had you run into an obstacle. The challenges you face along any path you take show themselves in your final project: for better or for worse. If you worked through them, chance are, people will be able to tell. Same as if you gave up, or worked around them.
All of this is to say: try something new, or try something you know you've never done before. It shows, and is impressive to both the public and the employer. At the very least, you'll have a good story to tell.
Try writing your project in a different language, or use a different framework, or do something a little crazy. Challenge yourself. Remember, you aren't doing this to pass a course.
Thanks to Don for this one.
It's easy to get trapped in the mindset that this is just a final project. You're showing off what you can create – and that includes your creativity when it comes to ideas. If an idea seems "good enough", but practically useless, perhaps consider another idea. Mass appeal will help when it comes time to show off your project: something useable will sell itself.
Avoid products for niche markets, as you'll have to convince outsiders on the idea.
And projects that someone would use are just better! Think about it this way: would you rather watch 45 minutes of niche, weird products that only about two dozen people in the world would care about? Or would you rather be captivated by apps that you'd beg to see become full-fledged products.
Oh, and if you have the one project in the class that people would actually use, It'll set you apart in a very, very good way.
The best projects I've seen have always been ambitious. Grand ideas can make for great projects, but there's a catch: being overly ambitious can set yourself up for failure if you aren't careful. So be ambitious, but not stupid.
Stupidity, in this case, will mostly come from vertical ambition. If your quest for a great final project stems from being able to finish one key feature, above which all other features are stacked, you are putting your trust in your team's ability to complete said feature on time and without issue. That's stupid.
Try instead for horizontal ambition, that is to say, cover lots of territory with more goals. This is a lot smarter, not only because you can pair down impossible goals, but you can also divvy up work in a more manageable fashion.
The horizontal/vertical metaphor boils down to this: If you mess up in the vertical model, you can screw up big time with no path to success (and not realize it until it's too late). In the horizontal model, you can easily scale back or cut un-achievable goals.
Go for lots of features (Aim for about 20 - 25). Avoid single, large scale features that your app will rely on.
Of course, rules were meant to be broken, so don't take these as laws. In general, be ambitious with what you set out to do (ambitious but not crazy ambitious), but be flexible enough to fail.
A lot of what I've learned has been reflection on my own two projects: A mid-term, which I was super proud of, and a final project. To this day, I think my mid-term project (Re-Marks a Medium clone) is the project I am most proud of. On the other hand, my final project (Schoolbox, a parent-teacher communication app), left me dissatisfied. Why?
It wasn't ambitious enough, there wasn't enough of a challenge, and it was niche.
On the other hand, our final project was a fairly bog-standard rails app. The one feature that pushed us was real-time chat, which we managed to do. In hindsight, we should have done something more ambitious and difficult to pull off. On top of that, our product was niche, and while it had a bunch of features, it wasn't amazing.
In retrospect, I wasn't super happy about our final project. Don't get me wrong, it was good, but it wasn't the best.
And I've seen other projects that "weren't the best". Helping people along the final-project process is rewarding. You get to see people screw up, plan something boring, try things that obviously won't work. There's a learning going on on both sides. These tips just so happen to be what I've learned, on both sides.
Thanks to Jeremy Holman, Karl Jensen, and Don Burks for their insight on these topics.