Taking the reins: A Junior Developer’s voyage as a PM
Background
Before I regale you with tales of my team’s voyage, allow me to introduce myself briefly.
I’m a (fairly) young Front End developer from the UK, specialising in Javascript and in a constant state of scrambling to try and keep up with the newest features of Angular as they drop. It sounds awful, but I do love it so..
Before getting my current job as a Front End developer, I bounced around various roles as a Java developer, DBA, BA, Microsoft Office Professional and a load of other vaguely technical things while I was in high school. I always had a passion for front end technologies and have a reasonable eye and hunger for design which back end tools simply weren’t satisfying, so I figured it was time for a move.
Aside/soapbox moment - I got this job with very little real experience and no qualifications, so I’ll take this opportunity to tell you that you don’t really need a degree to get by in the world of tech. Sure it might help you get through the door for the initial interviews but if you’re interested and passionate then that counts for a hell of a lot more, and there are employers who will see that.
So what is this Chingu thing?
In sume, the Chingu Voyages are intensive 6 week bootcamps where you get teamed up with other developers (some more, less or equally experienced than you) and work to produce a real world system or application.
Personally I think it’s probably the best way to learn as you are almost guaranteed to hit the bugs, snags and wrinkles that you’ll see out in the real world but perhaps wouldn’t see if you just learn by following tutorials or, heaven forbid, reading books, where you’ll typically only ever see the best case scenarios.
Over the 6 weeks you’ll normally go through a series of sprints, or iterations, where you’ll be assigned tasks to work through and contribute to the end product, and at the end of each sprint you might do a bit of a retrospective to reflect on how you’ve performed, any issues you had, what you did well, etc. etc. - this is a process that’s very common in the industry.
The 19th Turtle Battalion (my team)
My team consisted of three (originally four, but one member never materialised fully - see working remotely with people you don’t know) people, myself included, from around the world - Lydia is based in Tel-Aviv, Tom’s from Poland, and obviously I’m from the UK, which meant a little bit of juggling and jiggery pokery with our schedules so that we could meet every few days to address any issues and keep track of our progress.
Lydia and Tom had never really done any front end development with the newer versions of Angular, so we agreed to make the voyage more about learning than developing some super complicated and exuberant application. That can come later!
Our process
We made contact quite early on so we actually had a week to fill before the voyage actually started, so I thought it would be a good idea for our Sprint 0 to be spent doing a bit of R&D. We each picked an aspect of the MEAN stack which we’d take a couple of days to research and prepare a presentation to deliver to the rest of the team at the end of the week. This helped to quickly identify any major misconceptions there were around the stack early on so that I could try and clarify before we got started for realsies.
After this R&D sprint, we followed normal practice and had 6 week-long sprints according to our roadmap, and bookmarkIt gradually came to life.
Issues & Lessons learned
Issues
As I suspect is the case for virtually everyone starting out in the development world, we had a few teething problems using Git it’s a wonderful tool once you get to grips with it but the learning curve is more akin to trying to walk up a slide with your legs tied together, and we ran into quite a few merge conflicts in the opening sprint.
Other than getting to grips with the tooling, we ran into very few issues, which I think was in part due to our almost constant communication, and also because we managed expectations very tightly. We thought it better to err on the side of achievability and budgeted our time to allow plenty for learning the features of Angular and then taking the time to build PoCs and eventually implement them.
While I was able to churn out things like some kind of weird code-sausage grinder (in hindsight that’s a horrible sounding metaphor but I’m rolling with it), I had to bear in mind that the others didn’t have the experience or exposure that I did so they were naturally working at a slower pace. I took advantage of this and spent some of the lagtime writing up code guidelines, standards, and even a basic Git workflow for them to follow in order to streamline the process and make their lives a little easier.
Lessons learned
Estimate within your capacity and set reasonable targets.
It became apparent early on that due to the lack of experience in the team, we wouldn’t necessarily be able to make the best app in the world, so I did my best to rein in some of the more extravagant features we were throwing out and focus on delivering a functional MVP before plating everything in gold and jewels.
We did this, and it worked. We deployed our MVP release 2 weeks ahead of schedule and had time to then go through and refactor things that were perhaps not written quite as nicely as they could have been and turn our attention to one of the least popular aspects of development - testing.
Several small commits > One massive one
Granted, this might be a point of contention, but I think it makes life a little easier when fixing merge conflicts (which is especially prudent when working with newer developers, through no fault of their own) if you can tell exactly what each commit does, and it also means that if you need to roll something back, you’re not undoing all the other work they’ve done which might be absolutely fine.
Teamwork
Being new to development in general, Tom and Lydia had obviously never worked as part of a team so they had to quickly get to grips with concepts like standups and take responsibility for their features that they were developing. Thankfully I have the background in the industry and we were almost always in contact with each other so we were all able to bounce ideas off each other which was great.
It’s probably the most productive and cohesive team I’ve worked in which goes to say how well they took to it!
Conclusion - should you sign up?
Despite my more technical background, I think the voyage was very rewarding as it’s given me an opportunity to help new developers learn the basics of the MEAN stack, improve my organisational skills, improve my people skills (which I’ll be the first to admit are a little lacklustre sometimes), meet new people, make new friends and improve my own ability.
I would say it’s probably geared more toward newer developers but it’s definitely an experience worth having, and those less experienced certainly seem to be very grateful for any advice and guidance given.
So yeah, basically, go for it!
