How to make sure your first project as a Junior Developer goes smoothly.
I wanted to share with you some of the points I learnt from designing, creating and deploying my first ever project as a Junior Developer. I was fresh into the job, had barely got my laptop set up and I had been asked to create a website that would be seen by potentially thousands of people a day. I was worried. I was anxious. But excited at the same time! It was a kind of internal project, dealing with one of the managers who wanted to setup a new landing page for capturing information about potential authors to write books for us. I was the only developer on the ‘team’ and I had to deal directly with the manager who was my client / stakeholder. I learnt a lot in terms of both technical and professionals skills that I think you’ll find useful. In this first post i’ll share with you the tips for working with stakeholders and managing your project. In the next post i’ll focus on the technical things I learnt.
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 }); }); });
How you should deal with stakeholders
If you’re not sure what a stakeholder is - it’s just someone you’re working with in order to complete your project. I was working for a quite high-level manager who wanted a landing page where new users could complete a contact form to get in touch. I remember that it was quite vague at this point as to what the stakeholder was actually after and I wasn’t really prepared for that! Learning point: I would recommend, before going in to meet with your stakeholder(s), of having a list of questions that you might need if you don’t have enough information provided to you about the project. These could include:
- Who will be the users of the end project?
- Where will this project be available (online, desktop, mobile)?
- What would be a minimum viable product (MVP)?
- What is the project deadline?
I’m sure you can think of some others and you might be able to come up with a bigger list when you have some idea of what the project is.
Trying to work out requirements
Requirements gathering might not be your job as such but as a Junior Developer, it might be left to you to get the specific information from your stakeholder. As was the case with my first project. Let’s assume it’s been given to you as a task to work out the requirements for the project. You’re going to want to get some details about what the end result of the project should do. Learning point: Requirements gathering might be a separate meeting or lumped in with your initial meet with the stakeholder(s). Either way, if you’re the one doing this you’re probably going to want to write the requirements up as user stories in JIRA (or similar software) so that they can be managed throughout the project.
Doing a design when there isn’t a design
As I said, the project was a bit vague at this point and we didn’t have anyone that had created a design. Now, I don’t know if it’s just me but I think design and development are two quite different things! I can knock up a website but it might not look the most visually appealing unless I have something to work from. Learning point: If you don’t have a design, show your stakeholder some other websites / apps that you think fit in with the project you’re working on. Do a bit of research, perhaps take some inspiration from www.awwwards.com or dribble.com. If you can show something that’s structurally and visually similar to what they have in their head then it gives you a starting point to get going. Alternatively, get them to show you some sites they like the look of.
People just ‘want it done’ and they don’t really care how
Whilst in these initial meetings I was discussing with my stakeholder certain things like technologies (e.g. Bootstrap) and where to get images from. Guess what? They didn’t care. Looking back, i’m not surprised - the stakeholder just wants to get the project done. They don’t really care how. Learning point: Unless you have someone who has an interest, don’t waste time discussing tech requirements or how you are going to approach the project. At the end of the day, the stakeholder just wants it done.
It’s gotta have ‘wow’
The one real concrete requirement I got from my initial meetings with my stakeholder was that they wanted it to have ‘wow’ factor. That’s still a bit vague but you can imagine what this means in terms of a web page’s design; animated elements, sexy transitions, video, rollovers, awesome CSS effects. I had to realise my limits as a Junior Developer and recognise that this was probably the first ever proper web page I had built. I found ways to add some ‘wow’ factor without making things overly complicated. Learning point: Again, maybe take some pointers from web design inspiration sites but realise what you can and can’t do. Maybe try some simple jQuery plugins (if you are able to use them) or add some simple CSS transitions. Ultimately the ‘wow’ shouldn’t take over the design and usability of your site / app.
Get feedback early and often
This is a hot tip. I was quite lucky because early on in my job I got quite friendly with our internal UX designer. He was very helpful in pointing out potential user problems on the site in terms of navigation and the contact form they had to fill in. I also gave out the link to the project to several senior staff members and although this was a bit scary, they did provide some useful feedback. Learning point: Show your work to as many people who will look at it! The more feedback you get the better your end product - simple as. Be prepared for some complaints or criticisms about your work. But recognise this as constructive feedback and part of your path to becoming a better developer.
Don’t design by committee
It’s good to get everyone’s feedback. But what you don’t want is a design by committee. If you haven’t heard the term before it basically when everyone puts their thoughts in to a project and it then becomes a mish-mash of everyone’s ideas and has no unifying plan or design. This happened to me on my project a bit; I was keen to get feedback but everyone had strong opinions on how a particular section should look. Learning point: Whilst good to get feedback, you need to moderate it. That is, make a list of everyone’s suggestions and see if they align with the project’s requirements. At the end of the day, you will need to make the decisions as to how the project should look / work.
Only capture essential user information
My project was centered around a contact form which generated an email when a user filled it in. One of the important bits of feedback I had from our UX designer was to not only make the form logical and easy to complete but also to keep the length to a minimum. It makes sense right? You know yourself that filling in a super long form on a web page is a massive pain. The shorter the better. Capture only the essential information. Learning point: If your project has a form for capturing user information, work with your stakeholder to eliminate any unnecessary fields.
There comes a time when it’s just got to go live
So you’ve got your feedback, made your changes, sent out a new version for feedback, got your feedback, sent out a new version, got your feedback, sent out a new version, got your feedback… See where i’m going with this? One of the mistakes I made (or maybe the stakeholder for the project made) was not to not have a specific deadline or go-live date. This led to a repetition of revisions which got to the point of feeling like we were going round in circles! Learning point: If you haven’t been given a completion date, set one for your self. Disregarding any unforeseen circumstances, do your darnedest to push your project live by this point. Otherwise, strap yourself in for a possibly unlimited number of revisions. Remember: nothing is ever perfect.
Be prepared for feedback once your project is live
Even when you’ve taken massive amounts of feedback you’re still going to get comments after your project is live. In my case this was from people who hadn’t bothered to look at the project whilst it was in development. But even worse, my colleagues who had given feedback chimed in again with new things they had thought of! Learning point: Easier said than done but you’ll need to grow a thick skin and be prepared for the comments to come after you’re live. They may be constructive or they may be unhelpful. Categorise these comments and if they’re constructive, consider making the changes for version 2. If they’re unhelpful, toss them in the bin.
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
I’m not saying my first project was typical of a Junior Developer. Other Junior’s at my place of work take a chunk of the work of a project and don’t get involved in the planning and design processes. A lot of other projects I have seen already seem to have designs and user stories in place so it’s clear from the get-go what’s expected. However, you might find you’re given a smaller project like this to do on your own as a Junior Developer. Also, a lot of the points about getting feedback and committing to a live date are relevant no matter what your role is in the project. In the next post, i’ll give you my tips from what I learnt from my first project from a technical point of view. Check out the next part here