my journey of “leading” young developers
First of huge props to the students, this story is about. They managed to go from zero-web-development experience to a working Realtime-React app. If anything in this story sounds like it’s offending —I i’m sorry, because actually I’m pretty proud that you guys managed to survive this hell with me. Starting from zero and being exposed to the uncertainty of a young startup the same time is definitely a bad starting point.
Background
Technical University Darmstadt forces computer science students to do a non-payed practical project for a real company before they are technically allowed to write their bachelor thesis. As I’m currently working at a small startup in the need of developers and I had to do this internship myself two years ago I thought it would actually be fun to lead a small team of developers (4 students in their 5th semester) to do a little side project for us — so we applied and got accepted.
I’ve basically been working in web-development since my first semester at university (student job to raise money for my living) and even before I had some courses at school (basics of php, html/css), so I somehow assumed that in the 5th Semester, people should know at least a bit about web-development(html/css).
http://giphy.com/gifs/foxtv-new-girl-wrong-ylyUQngtu3CjajjGy4
After the first meeting with the group I realized I was wrong… and in retro perspective I should have known —since I was at the same university :). TU-Darmstadt is proud to be very theoretical, so you can manage to get your B.Sc. basically without programming a single “hello world” (there are a few exceptions where you have to do programming in group work — a bit of racket, java and bluespec/verilog <20/180cp — but reading a good book will bring you through the paper exercises in the exam).
https://twitter.com/iamdevloper/status/748201714440900610
Getting started
So now we have a super nice, motivated group which had to work 250h per person. What to do in 1000h? Our plan was to get a running prototype of an authenticated real-time sensor-charting application with a public and private rest api.
We choose node.js + react as a stack beforehand, and gave all the other decision over to the team, as I thought it would be nice if they could choose something they are interested in and not requiring “complicated” stuff like global state management. They decided to go with create-react-app + firebase — which i thought and still think is/was a good choice. Basically it provides anything we need(auth/soft-realtime via subscriptions/hosting/node-admin lib for building the custom rest api).
The sad truth
All the things which make me love Javascript are actually pretty confusing when you’re just jumping in.
Choices: The variety of choices is overwhelming and if you have never worked with it before you end up with an awkward Frankenstein code with libraries which you think have “enough” stars on github.
Javascript Evolution: Javascript/node.js is evolving incredible fast. This is definitely a good thing, but also has its down sides: You can find code examples dated a year ago which use deprecated stuff. This is especially true in regards to React and e.g. Mixins.
Browser Madness: Imagine you’re new to web-development and suddenly you have to learn dom/vDom html css js… and then when you finally have enough knowledge to build something which works for you — it most definitely isn’t working for you mac❤-safari hipster coding buddy and you have to start learning about browser support and polyfills.
Lessons I have learned
Leading a junior dev team is far more complicate than I initially assumed. I like trying new stuff and reading docs a lot, so I was scared of reducing their joy by forcing them to use specific libraries. I though I could just bomb them with tickets and requirements and review code and give them suggestions when things could be done better… which is basically right, but we faced a lot of problems like:
- jumping from SO answer to SO answer and so mixing up all possible Javascript syntax of the last few years(e.g. var/let/const or react-classes)… later solved via stricter eslint rules
- pretty banal things like a proper git flow seemed impossible. Multiple people working on the same stuff. Merge conflicts at about every commit and no experience with git or svn yet.
- using different awkward routers before finally switching to react-router… v1 and than switching to v4(which is great, but more or less all the SO results are 2/3 which resulted in awkward errors for them)
- they didn’t know popular packages like moment.js, so they tried to roll their own solution for about everything
- lack of knowledge in html/css wasted a lot of programming time with learning basic things — later switched to material-ui which actually helped a lot
Next project
Usually I agree with, what Eric Elliott describes here: https://medium.com/javascript-scene/why-im-thankful-for-js-fatigue-i-know-you-re-sick-of-those-words-but-this-is-different-296fae0c888f#.5l945ktfd — it’s a far better article than mine, make sure to read it!
My takeaway: Everything is awesome — just decide on your subset of awesomeness and stick to it.
For future projects, I’ll probably force the team to go with my subset of awesomeness, to make decisions easier and not overwhelming themby the variety of choices.
If I had created a base project including e.g.: moment.js, react-router@v3, mobx, eslint@airbnb, firebase-nest, mobx-firebase, jest… a lot of problems probably would never have happened.
Also I’d probably force a specific git-flow and nag the team if it doesn’t stick to it.
Another, kind of annoying, thing I noticed is, that people tend to google for results even if there are awesome docs/apis and end up with awkward/outdated implementations from SO or private blogs/forums. Next time I promised myself to ask “why” every time a notice such a thing, so that the students also learn to properly read API docs and end up being better developers.
Thanks for reading, I hope you enjoyed reading about my experience and do better yourself :) I’ll keep you updated and eventually even post the end result — if the student group is giving me permissions to do so.