It’s almost 2019, and what better time to reminisce a bit and remember what I’ve learned the past year. I’ve been wanting to write this down for a while. Different things that I’ve learned while working at a startup in Berlin. These will be mostly work related, not specific things like how to write components in React. Rather professional working life type things. This post may come across as quite scattered. I’m writing down the things as I think of them. I also am writing this mostly for myself to reflect.
Some background: Since June 2017 I worked at a small Berlin startup Wellnow GmbH. The tl;dr; of Wellnow is essentially that it sells massages by coordinating Therapists with prospective clients. I joined the company as a Software Engineer, as part of the very small “tech” team of around three people. I’ve essentially been working both as a fullstack developer, and as a DevOps. At this point I’ve touched most of the platform behind the company, as well as the infrastructure that runs it. Initially the business was focused on the b2c market, i.e. selling to private customers, but we’ve just recently switched the focus completely to only focus on b2b, i.e. selling to other companies.
In no particular order.
Keep a notebook. Quite often there’s just too much to keep track of. It feels pretty natural then to write it down. One of the good things we have in our office is a ready supply of free little notebooks. I use mine daily to jot down ideas as well as to help divide up tasks into subtasks. At the end of the day I often also write down where I should continue the next day. I find this gives me good peace of mind when I leave work as I don’t have to worry about forgetting anything.
Document to save time and thought. I’ve started to write down cheatsheets of commands to run in certain scenarios, e.g. when I need to rotate our Nomad cluster. Since we also run a few microservices in different languages and frameworks, many of which are not touched for months, I try to always ensure now that I keep a clear and concise README detailing how to run, test, lint, and debug the service. I’ve found documentation to be the most useful when managing our infrastructure. Keeping a diagram of the infrastructure helps refresh on how everything works when planning new changes. Having a playbook of commands for the servers helps in those oh-shit moments when something goes wrong.
Take charge of your own projects. Even if a project is assigned to you by a manager, it may be up to you to push for it to finish. Especially at a startup, where there is always so much going on. In some sense you have to be your own project manager for this.
From Autumn 2017 to Summer 2018 I worked on a project to rewrite most of the therapist location data to a new postgis geolocation backend. Even though most of the backend work was finished by the end of 2017, it took a few months more until we even started working on the frontend. Then the requirements changed back and forth until eventually the project was deployed.
Personally I could have stepped up more to push through this project. I could have worked on the frontend implementation myself, or I could have urged more in meetings and planning to focus on the project instead of continually postponing it.
Better to work focused. Perhaps more of an opionion, but I believe it is much better to be able to work focused on a single project, rather than work on multiple at once. Last year I had the problem that I was working on too many projects simultaneously, and I believe it lost me a ton of time as I had to constantly switch my focus between the tickets of these different projects. In the end, we also ended up scrapping a lot of these projects before they were even shipped. Had we instead focused on single projects at a time, we would have at least shipped something. Kind of frustrating. Like the previous point I know now that I need to step up a bit to voice my opinion on this.
Evaluate how much time you should spend on something. Not every project needs the quality of e.g. full test coverage and documentation. I find it useful to weight the amount of effort that should be put into the quality of a software project based on how much it will be used. Is it just a one-off script to migrate data, or is it a new backend API that will handle authentication? The former can likely be written as a quick python script without any formal testing and fanfare. The latter you probably want to give more care and attention to as it will stick around for a long, long time.
Before I joined the startup, I tended to go pretty heavy on the quality of a project. Even if it was just a trivial script that needed to be made. Now I try to keep this distinction in mind when starting any new project, especially in regards to testing.
Preparations for recruiting. Obvious in hindsight and not really a specific learning, but for me it was the first role where I had to be the interviewer as opposed to the person applying for the job. I think we had something that sort of worked. What helped me the most was to during the onsite interview have a clear script to follow or fall back on. I definitely have taken away some things which I’ll be able to use in the future, and feel quite comfortable interviewing other engineers now.
Feel free to take initiative. At our startup it felt like there were always more fires to put out than people available, as such your coworkers will (probably) be glad if you show initiative and take responisiblity for a certain topic. Just be careful that you don’t overextend yourself or you’ll get burned. Of course, this might just be how it was at this startup. I imagine at larger companies there are likely already people invested the different topics and you may need to step more carefully. This is a positive experience which I think I will not find as easily outside of the startup culture.
Pick your battles. As a tech oriented person it’s easy to butt in with your opinion everywhere. However at such a busy place as a startup, you don’t need to be involved in every project. I found it better to not get involved in every tech discussion so that I could focus on my own tasks. I should trust that my fellow programmers can also make the right decisions without me, and if they need my opinion they can ask for it.
Try not to be too grumpy and give positive feedback. I think I can be quite pessimistic sometimes, especially as I spend a lot of my time fixing other people’s code and with the stress that comes from being the inhouse sysadmin. At the same time, I may be affected by my native Swedish culture a bit too, where we can be a bit sparse on positive feedback. So I’m trying to be more positive going forward, being too negative will also bring the team down, being positive and bringing some humor should keep spirits up.