The first month
It's the last day of September, which means I have been a gainfully employed software developer for one month. What are five things I've learnt so far?
This will come as a surprise to exactly no developer, but setting up an environment for a massive project is hard! Especially when it's so large that there are more things that can potentially go wrong. I'd only ever used a
requirements.txt file, but it turns out that for bigger projects,
setup.py is more suitable (more details on that here).
Getting to grips with using
pyenv instead of my go-to for the virtual environment,
virtualenv, was a bit of a stumbling block. Even once I'd completed installation of the hundreds of necessary modules for the project, once I started work it turned out there were things that were missing, which for now I am having to work around and clear up later because they're not germane to the task at hand.
So you think you know Git
I knew this was coming, and it was actually one of the things I was dreading about coding in a team. Sure, when I'm just working on my own projects that I commit to my own, single-branch repository, Git is fine. Maybe if I epically mess something up, I'll need to do a bit of googling, but it's fine.
But when collaborating, there are all kinds of other Git things you need to consider. Which branch are you working on? How are you going to name the branch succinctly? Is there anyone else working on the branch with you, meaning you should in no way even think about running
git push -f (which, up until now, may or may not have been your get-out-of-jail-free card)? And before, I didn't really understand what
git checkout meant (to be fair, it is vague); having never had recourse to switch branches, I'd always assumed it would be "git switch" or something. Also,
git rebase sounds like something out of an FPS game.
All this is to say that there are so many things in programming that are not self-explanatory! It seems that very often, whoever invented them just thought, "Yeah, this'll do" when naming them!
Working with Git in a team has also alerted me to how, as a mostly self-taught person, I'd developed certain non-optimal practices (whatever the opposite of "best practices" is; I don't want to outright say "bad habits", because we're all on our own journey). Before I started this job, I'd always write my commit messages in the past tense, like "added xyz". Now it's all about the imperative, i.e. "add xyz". There are things like this that don't always make sense to me at first, but which I ought to adopt anyway because the team has to be on the same page.
Code reviews & critique
It is just too unfortunate that one of my most dreaded words in the English language (and indeed, the German one) is "feedback". When it pertains to me, anxiety rises in my throat; I'm about to be roasted, and I know it.
It seems that getting your code through CI/CD — also a new concept for me! — just the first part of this gruelling process. Only after all pipeline tests have passed is it ready for code review.
I wrote to the colleague I'd been pair-programming with, who was the first to review my code, that I was nervous. Here's a translation of what he wrote back:
'First of all, I'm certain that you did your best — and you can't do better than that, anyway. Secondly, in every code review, both the person who wrote the code and the reviewer learn something from it. In other words, a code review isn't some sort of exam, but just an exchange on equal footing about how the ticket requirements can be implemented so the code works correctly and everyone in the team can understand it.'
So, that's encouraging and certainly flips my perspective.
What is a finite state machine? Something that NASA uses, probably?
In all seriousness, it is a mechanism in which an object can only be in one state at a time, and only if it has fulfilled certain conditions or received certain inputs. For example, a book cannot be in a published state if it has not been in the state of having been written (see, it's almost philosophical). Django even has the
django-fsm third-party package for more efficient FSM implementation in an application.
Personally, my immediate reaction when coming across something like this is "welp, this is where a CS degree would come in handy right now". But you don't have to be intimidated when these kinds of things come up. Boil them down to their essence, learn them and practise them. I have been coming across so many new things in the past month and have made sure to note them down in the documentation I keep for myself on GitBook, so that I can look back at them later and consolidate the concept in my mind.
This is quite embarrassing to admit, but I've been waking up in the middle of the night thinking about the code at work. Not worrying about it, necessarily, but it's like I've devoted so much energy to pondering and puzzling over it during the day that I can't get rid of it just like that. I'm thinking about what I could try tomorrow, what I could do better.
Currently, I'm making the most of still being able to go into my company's office (COVID-19 cases are rising in Berlin again, so who knows how much longer I'll be able to do that). I work much better there, not least because I have a big desk and all the equipment I need. During the months I was quarantined and working from home, I really was unable to switch off for the day, and this is one of the main things that led to me getting sick. I really think there is something awesome about leaving work behind at 6pm knowing you did your best, going into Feierabend mode, and if something little that you forgot that might "improve" your work does occur to you during the evening, you're physically incapable of doing anything about it. For me, that is good training for the mind.
I actually wouldn't say I'm at that point yet where I can just forget about work as soon as I'm out the office door, since I always feel the need to be doing homework so that I can learn and improve faster. But being able to do that is a target I'm working towards, both professionally and personally. It's true that learning is a continuous part of the job, so there's no real obvious milestone. However, I'm setting myself my own benchmarks for when I'll know that I am okay; this is just my job.