9 Things I Learned During Dell Week

On Monday of week 8 on the School of Code Bootcamp (halfway), Dell EMC came in to present a real industry challenge to us. We had until the end of the week to build a functional application — front and back end — from scratch in our teams. We then pitched our project to a panel of judges on Friday afternoon, here’s some lessons our team learned…

Leigh White
School Of Code Blog
5 min readNov 1, 2017

--

On The LAM with Dell EMC judges David Hanley and James Norman

1. Your time estimations are never accurate

On The LAM started off with grand plans for our time-keeping. On the first day of project-planning we broke down our task into milestones and from there split each milestone into small, manageable chunks which we could then assign story points to. For those that don’t know, story points are units of measure used in Agile teams to make an estimate of how much effort a certain task will require. As a team we found that the story points we assigned tended to be quite meaningless; some tasks we estimated would only take us half an hour took up two hours and some tasks we thought would take half an afternoon only took an hour. Developers need to be able to accurately estimate the amount of time a certain job will take them, particularly those who want to take up freelance work and so in the future when time estimations seem to be wildly off I will take a few minutes to come together as a team and reassess and readjust the story points and the plan going forward.

2. Everyone doing a little bit of everything makes for a well-rounded team

Teams naturally tend to break off according to their strengths. Those who are good at back-end development will want to write the API and work with the database and those who are good at the front-end will want to work on the UI and dive into React. As a team of three it was harder to split off into separate front-end and back-end roles and this actually worked in our favour. There wasn’t a knowledge gap between the two and we made an active effort to make sure each team member understood all of the code we produced.

3. Talking helps

You’ve got to talk to your team mates. Constantly. I don’t recall many quiet moments for On The LAM. We questioned each others’ code and we also talked through things that were tripping us up which lead to a lot of “Okay, so we let this variable equal that and then we come inside this loop here and then… OHHH!” moments. Explaining your code and thought processes to others is really useful not only for the person you’re talking to but for your own understanding as well.

4. Stand-ups are important

Everyday we held three stand-ups (and one lie-down on the last day)! Letting everyone know what you’ve been working on, what you’ll be doing next and any blockers you’re having keeps the team up to date and allows you to keep a track of your progress towards the end goal.

5. Breaks are just as important

If you don’t factor in time to step away from the screens and have a laugh your productivity will decrease — you’ll hit a point in the afternoon where you just can’t concentrate any longer. Take 10 mins and chat about something completely non-related.

6. Get on with your team

Working in teams should never be a chore, try and have fun! It’s far easier to be motivated and excited about a project when you get on well because you want to succeed together, so try not to focus on the work all of the time. Personally I think it’s very obvious when a team are cohesive, and this week I felt a real sense of pride when looking at what we had accomplished together.

7. Pitching

If you’re like me and you tend to find presenting quite daunting it really helps to be proud of what you’re showing! Also make sure you plan. We spent all of Friday morning writing, editing, rearranging and rehearsing our pitch. We practised in front of anyone who would listen and asked for feedback. Rehearsing is the only way you will ensure that you don’t do things like accidentally talk over each other — this makes your pitch seem more professional. Also try and tell a story during a pitch or a presentation. If you’re doing a demo then walk them through it clearly and construct a narrative. Make sure you’ve addressed the following questions: What problem are you trying to solve? How does your solution solve this problem? Is your application easy to use? Really put yourself in the shoes of the user and empathise with them.

8. Do things out of your comfort zone (React is really cool)

We were introduced to React on the Thursday of the week before Dell Week. It was a brand new concept and out of our comfort zone. As a group we decided to use React in our project and learn as we went along. I am definitely a learn-by-doing type and had a lot of fun hacking around and seeing what worked and what didn’t and researching the things we were stuck on. It turns out I really like React. I can see how it has a lot of potential and I can’t wait to build more things with it. If we hadn’t dove in head first then I might never have discovered this. Take on a challenge!

9. Don’t be so hard on yourself

As junior developers there will always be a considerable difference between what you envision and what you can build — I’ll be honest, the app we produced looks nothing like it did in my head. But that doesn’t matter because who’s to say that in six months time it won’t? In three days On The LAM built something that impressed people from Dell. Dell. Eight weeks ago we were learning how to put a basic HTML page together and it was only five weeks ago that we were first introduced to JavaScript. Me, my team and everyone at the Bootcamp have achieved so much in such a short amount of time and I think we should remind ourselves of this often—we should focus on how far we’ve come and not how far we’ve got to go!

--

--