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.