More tips on how to ensure your first Junior Developer project goes well.
In this second article exploring what I learnt from completing my first project as a Junior Developer i’m going to focus on the technical takeaways. If you haven’t already be sure to read part 1 where I talk about the more business like learning points. Just to recap, I was building a web site for our company where users could sign up via a contact form to express their interest in working for us.
Exclusive bonus: Download my Junior Developer project checklist to ensure your first (or next) project as a Junior Developer is a success!
Send me my free checklist
Success! Check your email in the next few minutes for your checklist.
jQuery(function () { jQuery(‘#project-checklist-top’).submit(function (e) { e.preventDefault(); jQuery(‘#project-checklist-top’).fadeOut(function () { jQuery(‘#result-top’).fadeIn(); }); // Show success var data = jQuery(‘#project-checklist-top’).serialize(); jQuery.post(‘https://www.juniordevelopercentral.com/receive.php', data); }); jQuery(‘#firstprojecttips-optin-open’).on(‘click’, function (e) { e.preventDefault(); jQuery(‘#firstprojecttips-optin’).modal({ fadeDuration: 100 }); }); });
Free images are good (paid is better)
There’s no doubt that there are some quality resources for free stock images out there. However, we were looking for that ‘wow’ factor with the site I was building and even though there is some impressive stuff on the free sites, we were prepared to pay for quality. Luckily, it wasn’t hard to convince the stakeholder to give us a bit of a budget to buy a few stock photos for the site. Also, this was awesome because I could purchase some icon sets so we didn’t have to rely on Font Awesome. Learning point: Free stock photo sites are great for small or hobby projects but for professional work, you’ll get a huge choice and a lot more quality if you pay for images.
Don’t be afraid to use some plugins (just don’t over do it)
It was my first ever project. I wanted to prove to myself that I had the coding skills to create something totally from scratch. Using a plugin seemed like cheating. Yes, i’d chosen to use Bootstrap but that was more of a suggestion to make it easier for someone else to look at the code in the future. But when the requests for carousels, animated images and other visual eye candy started coming in, the time and effort required started to mount up. I therefore decided to use a couple of plugins (like the Bootstrap responsive menu and Slick for carousels) to speed things up. Truth be told, i’d probably still be coding up a responsive carousel if I hadn’t used some plugins! Learning point: Don’t be shy to use a plugin because you think it will make you look less professional / more like a beginner. It seems mad to create something completely from scratch when there is a perfectly good version already made! The only thing to remember is not to go nuts with this; yes we want to give our project that ‘wow’ factor but too much can spoil the site.
Don’t forget about navigation
This seems like a bit of a no-brainer; yes of course your web project should be easy to use and navigate. But with my project I had some good feedback from the UX expert who was working with me. He pointed out that some of the links on the site took the users to unexpected sections or external pages. This was valid. For example a user would click to learn about other authors and it would take them to an external page unrelated to authors - what’s that all about?! Learning point: Although you might think your site / project is easy to use, try and think of it from the perspective of someone using it. Even better, if you can ask for feedback on this sort of thing from your test users then you can get other people’s fresh views on whether or not your navigation works.
Cross browser testing? Absolutely!
Again this might be pointing out the obvious but you must, must, must test the site on every browser you can get hold of! I made the mistake of not testing on Chrome on a Mac as the site was developed on a Windows PC. There was a small little glitch that needed fixing after the site went live which wasn’t a massive problem but it could have been avoided if I had made sure my browser testing was a bit better. I think I fell in to the trap that, because I was using Bootstrap and jQuery, it would work on every browser. Make sure you double check. Learning point: Don’t assume just because you’re using a certain technology that this will make you immune from cross browser issues. Do as much testing on different browsers as you possibly can. Also, it might be worth agreeing with your stakeholders the browsers that will be supported; for example does the site still need to work on IE version 8?
Make it responsive (don’t just rely on Bootstrap)
I’ve already mentioned this that I was kinda relying on Bootstrap to make the site work on all browsers. I also made a bit of an assumption that the site would be fully responsive just because I had used Bootstrap. But when you’re adding plugins, customising CSS and adding extra JavaScript there’s a chance that your site might not look the best on every device. This goes back to the cross browser testing to identify these issues but it’s worth remembering to make adjustments to anything you add extra to your project to maintain it’s responsiveness. In my project, I had adding the Slick slider which caused an issue. Whilst the slider itself is responsive, it seemed to jump around and resize poorly at the different Bootstrap breakpoints. I can’t remember how I fixed it in the end to be honest but I recall it was another media query that needed to be added in addition to Bootstrap. Learning point: If you’re adding additional elements to front-end frameworks (like Bootstrap) then remember to test if these work responsively too. Don’t just rely on Boostrap to make your website look nice on all devices.
Getting email setup ain’t easy
Part of the project was to generate an email when a user completes the contact form on the site. If you’ve used PHP before you migh think “Simple, just use the mail() function, put in your message, from, to address etc. and you’re good to go”. Sure, if we were hosting on a shared hosting environment this would probably be already setup and ready to use. But we weren’t using shared hosting. We were using a server running in AWS. And I quickly found out that PHP’s mail() function has a lot of magic hidden behind it! Cut a long story short, unless your using shared hosting a mail service has to be specifically setup (or use a 3rd party one). With AWS we had to request that they whitelist the domain that we wanted to send emails from and this involved filling out a form with details of how the mail service (SES) would be used. Luckily they approved us pretty quickly and they have some pretty good documentation on how to get this working. Learning point: Email is a tricky beast and you’ll need to check if this is something that is available in the environment where you will be hosting your project. If delivery is critical too maybe think about using a 3rd party email provider to maximise your chance of delivery.
Going live isn’t as simple as FTPing your files
So we were ready to go live and I needed to get my local project to the remote Amazon server. I must admit i’m a bit old-school when it comes to web hosting but i’ve moved on from using FTP to upload files to using secure copy (SCP) mainly because it means I don’t have to worry about creating an FTP server! But there are other tasks to do as well like:
- Configuring environment variables (like email service provider keys)
- Creating user accounts
- Ensuring file permissions are correct
- DNS changes to be made
- Hunting down errors that occur in a production environment
One thing I hadn’t accounted for in my project was the site should have been secured with an SSL certificate. This was a learning experience for me as I had no prior knowledge of configuring a web server to use an SSL certificate and then there were the ports to open in AWS … and so on. Learning point: When it’s time to deploy, make a checklist of things that need to be configured in advance and do as much as possible before transferring files (however you do it) to the production environment.
Version control helps with your releases (even for simple websites)
This project was a simple website and as i’ve mentioned previously, I had some feedback for changes even AFTER we’d gone live. Being unaware of how to properly deploy a live production site I went on my merrily little way just SCPing the files to the server. So when I had these small changes to make, what was the best way to push them live? Which files had I modified? Do I overwrite anything if I change this? The idea behind version control isn’t just for your development process - it’s also really useful when you’re pushing changes to a live environment. Using Git, I could make the changes to the project’s repository and then push these to the live environment (I did this by SSHing to the server and then pulling the changes from the repository into the production site). Learning point: Keep using your version control system even when you’re making those changes to the site once it’s gone live. Keeping everything within Git enables you to track what has changed and prevents accidents of overwriting stuff you didn’t mean to on the live server.
Keep your code clean and manageable
Yes, yes, yes you should be doing this already but just to prove a point I want to tell you about a problem I encountered when I needed to make an update to a bit of JavaScript within my project. Part of the contact form I designed retrieved data from an API and then built a list of suggested projects that user’s might want to get involved in. I needed to make a change to how the suggestions got created and displayed. But how did it work now? Why does it append all that HTML to an element when probably doesn’t need to? I’d fallen into the uncommented code trap! Even with a timescale as short as a week or a few days and i’d forgotten how part of my code worked (and add to that it wasn’t written the best so trying to work out what it was doing wasn’t easy - even though I wrote it!). I had to spend a bit of time working out what the function was doing and then I made damn sure I put some comments in to make it clear to other developers (and myself!) what was going on. Learning point: Just because you’re the only developer on a project then don’t think you don’t need to comment your code and/or write well thought out, easy to read code. It’s likely that another developer will need to look at your code at some point in the future and if you can’t work it out when you wrote it then they have no chance.
Using a build tool helps
Following on from the last point, you can configure a build process within your development enviroment to spit out a ‘distribution’ or ‘build’ version of your project. I hadn’t really used a build tool before but I ended up setting up Gulp to minify my JS, concatenate my CSS and squish the images for the project. This gave me a folder with just a few assets which needed to be uploaded which I still kept under version control so I could pull this into the remote server. I’m not saying it’s essential but you also have the benefits of saving a few KBs of bandwidth that can mean the difference between a good and a bad experience on a poor network connection. So I think it’s worth the effort. Learning point: Don’t think that build tools are just for reducing file sizes, you can streamline your process for setting up your deployment process by creating a folder full of things that need to be sent to the server.
Filter your analytics
Once we’d gone live with the project the first thing the stakeholder wanted to check was how much traffic we were getting. When I looked at the Google Analytics we’d had several hundred views over a period of a few days which looked pretty good! But then when we dug a bit deeper in to the audience demographics and found there was a large number of views all coming from Birmingham, UK. Oh right, yeah. That’ll just be people from our office checking out the new site! Google Analytics (and probably other providers) give you a way to filter traffic from a particular IP or set of IP addresses. This effectively doesn’t register any views from your office locations and therefore skew your total visits. If that’s what you want :) Learning point: Decide whether or not you want to filter internal traffic. If you go ahead, this will give you a clearer picture of the traffic coming to your site.
Exclusive bonus: Download my Junior Developer project checklist to ensure your first (or next) project as a Junior Developer is a success!
Send me my free checklist
Success! Check your email in the next few minutes for your checklist.
jQuery(function () { jQuery(‘#project-checklist-bottom’).submit(function (e) { e.preventDefault(); jQuery(‘#project-checklist-bottom’).fadeOut(function () { jQuery(‘#result-btm’).fadeIn(); }); // Show success var data = jQuery(‘#project-checklist-bottom’).serialize(); jQuery.post(‘https://www.juniordevelopercentral.com/receive.php', data); }); jQuery(‘#firstprojecttips-btm-optin-open’).on(‘click’, function (e) { e.preventDefault(); jQuery(‘#firstprojecttips-btm-optin’).modal({ fadeDuration: 100 }); }); });
Conclusion
There were a lot of technical learning points from my first project. Probably the overall theme was understanding and developing a work flow for developing and deploying. Your first project will most likely be different from mine but I hope you’ve found some useful things you can take away and put in to practice when you get there. Have you already completed your first project as a Junior Developer? What were your learning points? Share them in the comments below.