How to get a Distinction

Getting through a coding bootcamp is a challenge: It’s an intensive experience requiring dedication, hard work and patience.


For some students that may seem a little overwhelming, but with the right approach, finishing the course – and even getting a distinction – is absolutely within your reach.
Firstly, it’s important to have the right attitude and to remember that the intensity won’t last forever: Try not to panic, and try to visualise the end result. As we type (and you read!) this, there are Code Institute graduates with no prior experience or training, who are working in software development jobs for cool startups, tech multinationals and for themselves. They, like you, were once students with daunting coursework and projects ahead of them.
Secondly, and on the practical side, we’ve talked to some of our mentors and tutors here at Code Institute for their tips on getting a distinction. This blog post examines what good work looks like, especially when it comes to project work.
These tips will suit most of our students, but every student is individual and works differently. Consider the following to be guidelines to adapt, augment or even ignore, depending on your own learning style.


Scope and Time Management
A common challenge in bootcamps is switching from learning mode to project mode. In the former, your focus is on understanding, but when working on projects, you need to switch gears and create a finished product.
In the project phase, you’ll need to focus on using what you’ve learned to make good progress and try to avoid getting sucked into trying new things that aren’t relevant or are outside the scope of your project.
Remember that projects should fulfill some purpose and provide a solution for the user. Your own favourite apps and websites are a good starting point when thinking about a project. What makes them useful or entertaining? Why do you choose their website over competitor’s website? The best websites provide a simple and practical solution to a genuine problem faced by the user.
Assessors start off looking at your site as regular users would – if your site solves a problem, that will get you off on the right foot. And if it appears professional and serves its purpose well, they would be positively predisposed. A practical, usable and appealing project will earn some benefit of the doubt at this stage of assessment.  
Remember that there are two key deliverables that make up your project: your deployed or ‘live’ website and your GitHub repository that holds the code that runs your website. Both need to be tidy and clear.


Structuring Your GitHub Repository
Your Repository on GitHub is your chance to introduce the details of your project to an assessor. This is where you can prove and show what it does, what technologies it uses as well as detailing how you tested and deployed your project.
Give assessors an understanding of why you built the project in the way you did – like a maths student showing their work.
Make it tidy, structure it and try to avoid typos! Think of it from the assessor’s point of view.
Use the capabilities of markdown to nicely format your ReadMe. (As some of you know, a GitHub repository holds the project, and one document within the project is the ReadMe.)
There should be a logical structure to your folders and files, and within your files, there should be comments at the relevant points to explain what the code will do.
Regarding file structure: Make clear the separation between code you’ve written yourself and external libraries you’re using.


UX/User Experience
It’s important that your finished product elicits a positive user experience. Think of your assessor as an end user, someone who will use your site to fulfil a specific purpose. And consider how your user will access your site – this may be through using a mix of mobile, tablet, desktop devices. Challenge yourself to make your site responsive so that your site remains user friendly on any device – big or small.
UX is about the user journey and how intuitive it is. Keep in mind the user stories – think of the tasks they’d like to achieve and the steps they’ll take: For example, browsing a product, adding it to a cart, filling in payment and delivery details, and finalising payment.
From a content perspective it’s tempting to use lorem ipsum (text placeholders). It’s a good idea to use that text during development, but before submitting we recommend that you replace it, as it can make your product look unfinished and unprofessional. If you don’t have time to write original text and don’t want to use lorem ipsum, simply use text from a favourite Wikipedia page or maybe a passage from a classic novel.
Bugs are a common, unwelcome part of life for every software developer. However, if a site is an overall enjoyable experience to use, small bugs will be forgiven, especially if those bugs are documented. This brings us to…


Testing
As we mentioned, bugs are a natural part of the development process, so don’t panic, even if you can’t get rid of the bug. Create your project, test it, document the bugs you find and try to fix them. Even if you don’t fix all bugs, you can recover marks by including a description of any remaining bugs. It’s better to have complex functionality with documented bugs than an overly simple project.
There are two types of testing – manual and automated. At the very least, carry out some manual testing. So act as a user and go through all of the possible tasks on the site, checking if the code throws up any warnings or errors.
Automated testing is worth looking at too. It allows you to automate the process and run your tests again should you make any changes.
Don’t forget to document your testing at this stage (either as a section in your ReadMe or in a separate file): Structure it in a way that your assessor can understand what you’ve tested, how and why. If there are tests that have failed or have highlighted bugs you need to work on, don’t shy away from showing this in your testing documentation.
You might notice a theme emerging in this article. Like a lot of this advice, testing should be looked at from the assessor’s point of view: Try to make it as easy as possible for them to see the logic of your work. (Think of it as another way to improve your user experience or ‘assessor experience’!)
Even if you don’t have a fully formed solution, it can be valuable to include your ideas of why the test might be failing or potential solutions in future. Writers often say that no word they put on a page is a waste – even if it’s deleted – because the writer gets better with every word. Coding bootcamps work on a similar principle: Every mistake you make, obstacle you face and bug you encounter has value because every single one of them is a teachable moment, and an opportunity to show your assessor what you’ve learned.
Nothing you work on – or even consider working on – is a waste.


Deployment
After weeks or months of putting effort into building your projects, you want to be able to show them off. It’s disappointing (for you and the assessor) if you fall at the last hurdle when your project hasn’t been deployed successfully.
As part of the course, you will complete sample projects: So if you run into issues with your own projects, go back over your earlier coursework. You might have encountered the solution when you were working on those sample projects.
Pay attention to your logs on Heroku (a site where you can deploy your applications) as this will help you anticipate and pinpoint any deployment issues.
Don’t forget to test it on different browsers, and ask friends or family to look at your site and give feedback. They are the users and testers after all! See if they can figure out how to use your site – if they can’t, maybe take a look at adding instructions or even changing the site’s structure.


Use your Mentor
When approaching the finish line and final deadlines, remember that “perfect” is the enemy of “done”. Some students might find it difficult to tell what project’s flaws to focus on and which problems are minor enough to ignore.
Your mentor is there to support you. Before you submit, it’s worthwhile speaking to them and getting their advice. They’ll help you strike the balance and guide you on where to focus.


A final note about Assessors
In any exam situation, examiners, testers and assessors can make the student nervous. In the fog of panic and pressure, it’s easy to forget that assessors are on your side! They want you to pass and (if possible) get a distinction. So make it easy for them to do so. Clear, attractive and user-friendly project work is a pleasure for them to examine.
Many of our students have earned distinctions. Earning one requires graft, being fully engaged with the material and strong and clear project work. It’s not easy, but it can be done. Good luck! 

What Does a Web Developer Do?

 What exactly does a web developer do? With so much consistent growth in employment figures in the ICT sector as of late, it can be easy to confuse the very many job titles that exist today, particularly when you’re trying to explain to your less-than-tech-savvy aunt that your position as a UI Developer is an […]

7 Signs it's Time for a Career Change

 A few of us out there knew exactly what we wanted to do for a living since we were young adults. We set our sights on the goal and made it happen. But for the majority of us, this wasn’t the case. It’s more about trial and error and discovery over time. Many of us […]

Ask an Employer: A Q&A with Accenture

Ask an Employer: A Q&A with AccentureCode Institute’s Industry Advisory Council exists for a few reasons: The IAC advises Code Institute on what they look for in employees, we collaborate on what languages we should include in course material, and Code Institute and the IAC sometimes work together on recruitment drives. We talked to James […]