The backstory to this video
I currently onboard a team responsible for overtaking a project of ours. And the process made me aware that there are things that aren't found in documentation or tutorials. One of those things is "How to work with legacy code". We all hate it (if we're honest), but nonetheless we will always have to deal with it.
What's the one trick?
What I also noticed it that people tend to request time to be shown a walk-through of the code-base. This wouldn't be unusual if it happened once, but if team members show a unanimous and frequent tendency of wanting to look over your shoulder while YOU are doing something makes you wonder. But then again, the way the adult learns is still based on the very principle that applied when we were little kids: Show me! Not "explain to me" or "is it documented?", it's "show me".
So the one trick to follow when it comes to teaching/mentoring is to add the "show"-component into the material.
But what if ...?
But back to today's topic: legacy code
There are some abstract topics and mental processes you can't really show. Certainly not when you have to abstract the very project itself; So how can I "show" the team the way of thinking when having to backward engineer our own code? I can't. But what I can do is the next best thing:
Let's take a random repository from GitHub
So this video shows how me picking a random repo I have recently looked at to answer a question on Reddit. And without any knowledge of the code jump into staging the project (including some cursing as I couldn't help myself) including reverse engineering some of the database structure.
Needless to say, it's clumsy and structure-less. But it's real and I guess my question would be if you are
a) Relatively inexperienced: Is this content helpful?
b) Relatively experienced: How do you transfer knowledge on such topics?
Top comments (0)