Joining a development team: a pet project to acquire knowledge and skills

Here is the story of the journey I shared with a colleague that joined the company the same day that I did. Our process begun with little concepts, little practice.

Preparing the ground: promises, streams & clean code

We had to learn concepts such as promises and streams.Carefully curated online workshops are a great tool to begin with. You get a little information, make a little exercise, repeat. Of course it’s not enough, but this was just the first step. We had to prepare the ground for bigger things, such as the quality of our code and communication.

Clean code is about focusing not only on implementing functionalities but on writing quality code. Working with other developers is about understanding and being understood. It is about being clear about not just our ideas, but our code. Clean code is essential for the rest of the team of course, but for your future-self too!

This preparation wouldn’t be complete without a way to put it all together. That’s how “Twotter” was born

Developing a full app from scratch

Twotter. It’s not a typo. We called it that way because it was our little version, our little pet project, our little blue bird pet. “Twitter” was aiming too high, and it would never be ours.

Developing in a secure environment

This idea was really rewarding, every little concept that we had seen was useful. We didn’t just have the theory with us, we also had the confidence that this was a safe place. If there was a time to make mistakes, and to learn the most of them, it was this little “Twotter”.

We faced changes of technologies from one day to the next, even if that meant learning , new stuff we had only heard of. Actually, this is not far from the reality of a developer’s life. As we all know, it is all about facing new challenges every day: New technologies, new requirements, the need of improvement, everything makes you go out of the box.

Being prepared to step out of this box is something everyone should learn, the earlier the better.

But really, what is Twotter?

I know this will come as a surprise, but guess what? the project was based on Twitter. The idea was to develop a web app that would handle different users who could write short messages called Twots, and who could follow each other to see what they were saying.

Focus on tech: Node.js and AngularJS

Taking advantage of the workshops we did, Twotter would be implemented with NodeJS. As many would disagree, Javascript is a great programming language once you get to understand it’s not just a front-end complement.

To get started with this project, we tried levelDb for the database. This was an interesting way to face the project. We had learned about non-relational databases but had not worked with them as part of a project. It was necessary to adapt to these tools we had.

Once we had the back-end logic, we had to show it to the world. So we started using AngularJS framework,and soon grew from zero to… almost heros!

Database migration: from levelDb to MySQL + Sequelize

We came across technical difficulties when the amount of users started to grow in our little experiment. The migration to a more robust database was necessary. MySQL + Sequelize was the choice. A fortunate one. The application responses improved considerably as you can see in this little graph:

This change also gave us the possibility to use pagination on queries, and implement infinite scroll.

Tackling security issues with JWT

Finally, there was an elephant in the room. We had deliberately ignored it for a while but were left with no choice other than face it at last: the security issue. For this we used JSON Web Tokens (JWT) that gave us what we needed, handling tokens, handling sessions.
Twotter was ready to fly.

Using scrum methodologies: twotter’s sprints in a nutshell

First sprint – Baby bird steps

The beginning was smooth. Preparing the backend of the application was pretty systematic. The biggest challenge in this part was to define a structure in a non relational database. Once we had it set, development was flowing.

The other challenge was to get along with Git! It was a little hard at first, but we got it right by the middle of the week.

I think for our first sprint, the hardest point was to prepare a demo at the end. We didn’t fully understood the importance of this part at first. Anyway we didn’t figured it out until the next sprint.

Second sprint – Angular hell

We hit a wall with our faces here, we hit it hard. After creating a few endpoints, we needed to give a frontend implementation to show this better. The problem is that we had not worked with angular before. So, it took us a lot of time to do the simplest things. We got it running at the end, but it cost us the time to prepare ourselves for the demo…

We had a catastrophic demo with our colleagues in the roles of product owner and client. Almost everything that could go wrong, went wrong. This was an inflection point. Fortunately, it was the perfect moment to make mistakes.

Third sprint – Getting better at this

After those rookie mistakes, we got ourselves back on our feet. It wouldn’t happen again. At this point communication improved, planning improved, and we got to breath a little because we had to separate client from server and add few functionalities. This turned out to be a good time to settle all the previous concepts.

Fourth sprint – Bigger data, bigger problems

We had users, we had tweets, we could follow each other. But there were 3 users. This was not a challenge for our database. There was a need to push it to the limit. Making a script to add plenty of users. And I mean a lot. When we reached about 3000 users, things got ugly. Responses were too slow. Now we had to look for a solution. Database migration to MySQL was the answer. And paginated queries was a necessary measure. This transition was pleasant because we used Sequelize ORM, and there was no need to write raw SQL queries.

Fifth sprint – Final touches

Twotter was running, we could tweet, we could make a user follow another one. Handling big amount of data was no longer a problem.

But we were facing a security issue. Actually we weren’t managing sessions nor permissions. So anyone could tweet or follow as anyone, just selecting the user they wanted to be. This was useful to develop the app, to try different functionalities fast. But there wasn’t any authentication or authorization. This was the moment when JSON Web Token (JWT) came in to save the day. It wasn’t difficult to incorporate, so we had time to do some refactoring as well. After this our code was shorter, clearer and even more efficient.

The final demo: looking back on our work

Developing Twotter was a great opportunity to practice the Scrum methodology. There’s no better time to learn the ways of working, the track of tasks, the communication with the team, etc.

After all the development work and all the demonstrations were finalized, we finally got to present our work to the rest of NaN. This was a great occasion to look back and realize all the progress we had made. I personally think that summarizing every step we made to achieve our project was the best way to end it. Actually, this wasn’t only a good practise, but a necessary one. To know where you are standing is vital to keep going.

What we learned: tools & good practices

To sum up this experience, I could personally say that we learnt a lot, in such a short time. And this came from practice. If you don’t try it, you won’t actually get it.

We learnt to keep track of our activities using Trello in order to establish tasks’ priorities and be aware of the work to be done in the time we have.

Git usage was an important thing in this process. To separate tasks in different branches, to keep the habit of reviewing someone else’s code, because sometimes the smallest mistakes are difficult to see for the author.

We learnt the importance of planning the week, setting up a deadline to add features and taking the proper time to plan the demo.

We debugged with the correct tool to find any problem. We could identify when our code was smelly, and a refactor was needed.

Finally, one of the biggest things we learnt, is that sometimes the best way to get through a problem is not banging your head against the wall all day, your team is always ready to help you if you really need it.

It wasn’t only a technical and practical experience, there’s also personal and team growth.