What it is like to be a fullstack developer in a French startup — part 2
This is the second part of the article. The first talked about my personal experience in the startup, you can read it here. This part will focus on what it requires technically to be in a startup as a fullstack. I will assume that you are familiar with the technical terminology (be assured I won’t go into details, we’ll save that for another article).
Getting the right tools
In this phase, the mindset is like: every choice we make today, will or will not create our technological debt in the future. You should consider your ability with languages and framework, the size of the communities, the maturity and its attractiveness for new employee to make your decision. But you should also keep in mind, that no one has ever scaled without changing a lot in their stack.
We ended up using Python as it is very popular, and you can basically find anything you need in it. For the web part, we would use Django for the REST API and React with Redux.
Creating the foundation
At this stage, you only have a rough idea of what the software will look like. You know things will change, often. But we were not here to make a proof of concept, we were here to make a Software As A Service that clients could confidently use.
To handle this, we frame the big picture with sketches. Not to pave the way but to have in mind the ultimate direction we should be headed towards. Then we started prioritizing things to create stories which could fill a one-week iteration. We were (and still are) conducting Test Driven Development, even though we were short on time, and that is a huge gain in the middle to long term.
As a developer, your main objective is to manage expectations and communicate clearly about what is happening. If it gets late, you should limit overtime work, as this is often counterproductive. You should stay productive in the long run, working hard but not too long, up to 60 hours per week (in France we work 35 hours per week, and this is a privilege we don’t want to lose!). It is preferable to see what you can change or withdraw to obtain good enough results. Doing this, you end up realizing that the things you wanted to add were not needed that much and you don’t develop useless features.
Taking up new challenges
The most interesting part, in my opinion, as well as the most excruciating, is when you should develop a feature and you have no idea of what to do.
To resolve this, here are the following steps I make:
- Explore: Have I already seen something like this before? What does it make me think of? Have people already encountered the problem and how did they solve it?
- Appropriate: How does it work? What I am currently missing that will allow me to use it? How will I manage this in the future?
- Plan: In which order should I proceed? What is the minimal step I could take to prove it works? Do I create it by myself or do I use this open source project? This company solution?
- Develop
- Repeat all the previous steps until you have found the solution that will be improved in a later step.
There is a lot of useful information over the internet for this, although I regret that sometimes the tutorials are too simplistic and do not really fit my cases.
You should never hesitate too long, better sorry than doing nothing. But keep in mind “If the implementation is hard to explain, it’s a bad idea. If the implementation is easy to explain, it may be a good idea.” And always be clear about where you are in the process and the confidence you have about solving it on time.
Care
At anytime of the development you should be caring. Caring about the person who will use the results of your code, the one who will be maintaining it (probably your future self) and your team.
Try to see beforehand the problems that will arise, where your users lose time. Do the right things even if it is not easy. Not having enough time is no excuse to not deliver something, even minimalist, that will please your users.
For your team, you should make yourself available to help. If you are the only one moving, then you are not. And when you require help, you should make it easy for the others to understand where and/or with what you are struggling.
Conclusion
What you need to remember is communication is the most important thing. I can’t stress this enough. If your teammates do not know what is happening for you, how could they find a way to help you? Do not fear what they might think, if your team is solid you will be safe and sound, even if you make mistakes.
Then comes your ability to understand and concretize your request. That comes with experience, and experience comes through trial and errors. Always take some time to realize what you did and how to improve.
And last but not least, always put some loving in what you do!
One good book to read that further explain this is: Extreme Programming Explained: Embrace Change, 2nd Edition
