
Sign up to save your podcasts
Or
I learned so much from my first software engineering job. Some of the lessons make me squirm a bit.
When I joined this company circa 2010, they were using subversion.
If you weren’t around then, subversion is a version control tool that predates git. Indeed, git and github were still new kids on the block, and there was a competitive version control tool called mercurial that was compelling to many people as well.
Anyway, this team I had just joined was using subversion, hosted by a tool called Trac (another ancient history bug tracking and code repository system). And while my memory of the time is a bit hazy, I remember thinking that it was just crazy that a modern software team would be using subversion instead of git.
When I reflect on this experience later, there is actually no bad reason they had stuck with this tool. It’s just when they had used forever.
Well, I made it my mission from god to switch this team’s codebase over to git.
It was a python web app that had several years of history, and it spoke with a separate API and, if I recall correctly, a custom sort of data store. All hosted by subversion.
To my surprise, the team wasn’t immediately on board with this. And I was totally blind to this fact. I just could not understand that there was a reasonable perspective representing the view that staying with subversion was the right call.
I was not making a business case to anyone, I was not speaking with my manager (I don’t think they had hired a manager for the engineering team yet), and I was not really making an argument of any kind; I was simply doing what I thought was best for the team, based solely on my own judgement.
Well, after many badly run meetings, I got it done. I dutifully switched the codebase over to git and github. And I naively lobbed git tutorials over the fence into my colleagues inboxes.
(I say naive because, as we all know, git is so famously easy to learn.)
I will leave many of the lessons of this story for you to ponder. But I will note that this one has had a big impact on my career and I think of it more often than I care to admit when I see developers go off on a mission in their teams based solely on their judgement and without any real argument.
Anyway, this one affected my karma. Because of this experience, my name was attached to the initial commit for this git repository. So for years after, possibly even today, my name is attached to the entire codebase as original author (even though I was not). So for a long time, I would sometimes get messages from later engineers who joined the team asking me about why a piece of particularly hairy code was written so poorly. Justice was served.
https://thedailydeveloper.substack.com
I learned so much from my first software engineering job. Some of the lessons make me squirm a bit.
When I joined this company circa 2010, they were using subversion.
If you weren’t around then, subversion is a version control tool that predates git. Indeed, git and github were still new kids on the block, and there was a competitive version control tool called mercurial that was compelling to many people as well.
Anyway, this team I had just joined was using subversion, hosted by a tool called Trac (another ancient history bug tracking and code repository system). And while my memory of the time is a bit hazy, I remember thinking that it was just crazy that a modern software team would be using subversion instead of git.
When I reflect on this experience later, there is actually no bad reason they had stuck with this tool. It’s just when they had used forever.
Well, I made it my mission from god to switch this team’s codebase over to git.
It was a python web app that had several years of history, and it spoke with a separate API and, if I recall correctly, a custom sort of data store. All hosted by subversion.
To my surprise, the team wasn’t immediately on board with this. And I was totally blind to this fact. I just could not understand that there was a reasonable perspective representing the view that staying with subversion was the right call.
I was not making a business case to anyone, I was not speaking with my manager (I don’t think they had hired a manager for the engineering team yet), and I was not really making an argument of any kind; I was simply doing what I thought was best for the team, based solely on my own judgement.
Well, after many badly run meetings, I got it done. I dutifully switched the codebase over to git and github. And I naively lobbed git tutorials over the fence into my colleagues inboxes.
(I say naive because, as we all know, git is so famously easy to learn.)
I will leave many of the lessons of this story for you to ponder. But I will note that this one has had a big impact on my career and I think of it more often than I care to admit when I see developers go off on a mission in their teams based solely on their judgement and without any real argument.
Anyway, this one affected my karma. Because of this experience, my name was attached to the initial commit for this git repository. So for years after, possibly even today, my name is attached to the entire codebase as original author (even though I was not). So for a long time, I would sometimes get messages from later engineers who joined the team asking me about why a piece of particularly hairy code was written so poorly. Justice was served.
https://thedailydeveloper.substack.com