Forem: German Rodriguez Ortiz

Making a case for english codebase to my boss

German Rodriguez Ortiz — Wed, 17 Jun 2020 16:01:12 +0000

Hi people :)

I wanted to ask for your advice on a thing that I'm currently struggling with at my job.

For a little context, I'm a web developer from Chile, and currently, I'm in charge of maintaining a very old vanilla PHP codebase. (How old you say? It still has a JSON.php and a PHP4 HTML parser libraries on its assets that I just can't bear to delete from pure nostalgia. Lucky for me the code was barely refactored previously so It works on PHP 7)

At the moment I managed to free some time so I can migrate this codebase to a Symfony project, but I'm having trouble trying to find "solid good reasons" to have the codebase entirely in English.

Before this job, I was pretty much used to have my both my code and comments completely in English, and now having to propose this change to the "brass" I find myself without a reason to make this language change other than the classical:

"It´s the standard way"
"It kinda makes sense, since the framework is in English"
"No need to think on tilde characters" (My heart dies little by little every time I see a agno variable because we should not use año

To me, due to the circumstances, these reasons that make all the sense to me seem more like "aesthetic reasons" for this case, mainly because:

It's very likely that the code won´t be made public.
It's even more likely that the dev team will be all "Chilean Spoken Natives" (Mandatory "Chilean Spanish is a different Spanish" reference xd).

But still, deep in my heart, I know that at least the codebase should be in English :(

So I ask you, dear dev community :)

Have you ever had to make this choice?
What reasons drove you to start/change to an all English codebase?
has anyone failed on a similar issue? Why?

Thanks for taking the time to help me with this thing :)

Lessons learned by quitting both my jobs in the lapse of a week

German Rodriguez Ortiz — Tue, 24 Sep 2019 14:05:02 +0000

So, I wanted to write this because when facing the whole "quitting my job" process I had many misconceptions that I didn't know I had, and I don't know if it's just me because of the lack of experience doing it. I hope this helps someone who might be struggling with it.

To give a little background, when I talk about 2 jobs, I used to work in two companies, a Project Management SAAS platform, and a "Quiz Management" Web App, I'm a co-founder of the latter and I came to work for the first one when they bought shares into my web platform, five years ago.

At that time I was just starting my career as a developer, I learned a lot during these five years, but slowly I started to realize that some things weren't feeling right for me, then I started to see some red lights, but I resisted even when I started seeing things that at least to me were outright bad. And then two things happened that made me realize what was happening to me.

A couple of friends had to prepare for some interviews, and we got together to review the process and solve some coding problems. After that, and an ungodly amount of beers later, I asked them why and how did they come to the decision of leaving their current jobs. Both told me it was about growing, on how sometimes where you are working you'll hit a ceiling on how far can you keep going, or trying to look for something better. To me it came as my first lesson:

There is nothing wrong with wanting to keep growing. And if you can't do it where you are currently working, maybe it's time to leave.

The second thing happened at a party, I was talking to another friend and he offered me to come work with him.

In the past, I've received some offers (mild humble brag) but I've almost instantly rejected them because I didn't see myself working in another place than where I was. This time I seriously gave it a thought, in the end, it didn't go anywhere, but the fact that I was considering it was enough for me to realize the truth.

I didn't want to accept it but I resisted because I was scared to start all over again. I was afraid because I didn't know how to quit my job and I wasn't sure what was going to happen, I thought people would get angry, that I was betraying some "trust thing" between me and the bosses because we had a very personal treatment between one another, I actually thought that I would end fighting with someone over my reasons to leave.

And so during the last months of the past year I finally made my mind and started to look for another job ( I probably will make a lessons learned from looking for a job when you've never done it article) and luckily through tips friends gave me I managed to find and land a new job in early January.

I don't know how it works in other countries, but here in Chile, the normal thing to do is to give a month's notice to your boss when you resign. And so there I was walking to my boss's office after asking to meet with him to present my resignation letter (he didn't know I was going to do that). I walked through the door and I sat in front of him, we start talking and I lay it on him, I say "this is probably the most adult thing I've done so far, but I'm here to present you my resignation".

Little did I know, this was his first gig as a head developer, and never had to be on that situation, his surprise to it was something I was not expecting, and it actually felt more like I dropped a severed head on the table and no one knew what to do with it. We talked and I explained my reasons to leave, that I felt that during this five years with them I wasn't in the place where I wanted to be, I've hit a ceiling and felt I couldn't grow anymore. I was nervous and didn´t know what was going to happen, and then he talked.

He told me he was glad that I found another job, as a friend and as my head developer. He understood my reasons and was really proud that I landed something better. There I got my second lesson:

All those things you have in your head about what might happen are probably excuses for not doing it. It's not going to be the end of the world, be respectful and speak the truth and things will result in the only way the could result.

After some small talk, he called the "big boss", after all, he handles all the HR things and should be notified of this. He came, and we talked, but I saw something different this time, he was really calmed, but I mean like really really calmed, I realized then that he has done this many times and they're still here. Cue my third lesson:

A resignation is a big deal, but not that much. Many companies go through this and will survive you leaving. We are not that really important to the company, as a business.

He took it like a champ, he thanked me for the time I've worked and said he will miss me :(. Then we started to plan the rest of the month so I can finish the most important things that have to be finished before my departure.

And just like that, I did something I thought would be much much harder than what I thought and I had to do it again.

To make things short, I called for a meeting with the rest of the board of my web app, I used the lessons learned and I respectfully explained why I was stepping down from the company and thanked them for everything. We talked and also planned what and how we were going to complete the process, but I was out. I finally made it, and it left me with yet another lesson:

It's going to be weird every time you have to do it.

But that's it, I hope this can help anyone struggling about leaving their job. If could, I certainly believe you can do it. I believe in you :)

I do have to say, It was a weird week, but in a good way :) . Thanks for taking the time of reading this.

A journey of self-discovery... and also how I learned how to use Git

German Rodriguez Ortiz — Mon, 26 Nov 2018 05:14:57 +0000

For my very first post I wanted to tell a story about how I learned to use and love Git, but I'd like to start much earlier on, when I was just learning about VCS tools.

While studying I was exposed to SVN as my default VCS, we struggled with a couple of friends trying to understand its mysteries while developing the prototype of some forgotten web application.

Our young and unworthy minds could barely grasp the very concept of trunks, branches, commits, and everything else in between. We would finally set on a single trunk and issue related branches to separate our work.

Actual picture of me and my friends preparing to merge some feature into the master trunk - circa 2008

But our poor understanding led us to make several mistakes when merging our work, with a mixed set of problems, varying from methods getting scrambled, to complete classes being overwritten. Many "accidents" later we gave up on the idea of a VCS, we weren't capable of both handling its components and understanding how did that tool fit into our workflow. Thus I gave up entirely, that early on, on even using such tools.

So I kept to my studies and from time to time developing, somehow, without any form of VCS, until I landed my first serious job (and to the date of this article, my current one). It was December 2013, and I was to join a small team of developers that had been using Git for just over a year. I was blown away when they explained to me what it was, how they used it and how simple it felt over my previous tragic experience with SVN.

The inside of my head as I realized for how long I had lived a sinful life without using a VCS tool

Back then the development workflow was centered around two main Git branches: master that hosted all of the verified and stable code deployed to our production environment and test, a branch that contained all the code that had to be reviewed by our QA team, this branch was deployed to a special "testing" environment. Also, each developer would create a feature/bugfix branch to solve particular issues, these branches were to be deployed on local instances of the system for every developer. Once each developer finished their work they would immediately merge it into the test branch.

At certain times during the day, our head developer would deploy the contents of the test branch into the testing environment. Once the testing was done and all of the content of the test branch was considered as "approved", then our head developer would merge the test branch into our master branch and proceed to deploy all of its contents into the production environment.

Our fearless head developer waiting to merge the test branch into the master branch

Please consider that at that time I thought that was the most awesome thing I had ever seen ...

This workflow had many problems, among them:

No feature or bugfix branch was updated with the changes added to the master branch in between deploys. This caused massive conflicts for older features that sometimes implied making the whole thing again.
All merging was done with fast-forward (at that time we had no idea what that meant) making the logs barely readable for tracking groups of changes made to the system.
To accomplish the production deploy our head developer would have all of us stop merging our features and fixtures into the test branch until he was done. Occasionally a developer would forget this and merge something into it causing what in my country slang we would call a "midfield goal" (mandatory soccer reference from a Chilean ... check) effectively deploying code straight into production without anyone from the QA team giving it a simple AOK.

As a graph, it looked something like this:

On this graph new commits are closer to the right

Somehow we managed to grind through with this workflow up to mid 2014 when we finally hit critical mass, the poorly solved conflicts and the many "midfield goals" placed us on a really bad place, missing deadlines and not being totally capable of guaranteeing stable-ish code on our production environment, we needed a change and we needed it fast.

Enter Gitflow, descending upon us from the hands of our fearless head developer, a "new-to-us" way to organize our work and reclaim control of the mess we had on the master branch. We were to add the development branch to separate the lifecycles of our feature and bugfix branches and use the release branches to gradually add features to the system in a controlled and, hopefully, planned manner. Tags were to be used not only as flags to indicate the given status of the application in the git history but also as specific points to perform deployments to the production environment.

How we saw our head developer, as he told us about GitFlow

We had the added challenge that our test branch had to stay, because it was still the only way we had to deploy code so it could be tested by our QA team, so in practice, we ended up with two Gitflows, one for test branch and one for the master branch. Bugfixes and releases would get merged into either branch given its current status.

As a graph this new workflow looked like this:

On this graph new commits are closer to the bottom

We were also told that we would no longer have to wait to deploy merged code to the test branch for bugfixes. If a developer finished, in addition to from immediately merging the branch into the test branch they would also deploy that code into the test environment.

And for a while this was ok.

You see, we thought that just by changing the branching strategy would solve all our problems, when we should have also reviewed our handling of the branches, specifically:

We still weren't properly updating old branches.
We still weren't sure what this "fast-forward" strategy was.
Conflicts were resolved without really paying much attention to what was really happening. At that time we weren't using diff tools to resolve merges, and a popular strategy in the office was just accepting the changes currently being merged into the target branch as the "correct" ones, instead of having to read and manually accepting either set of changes.
The test branch started to "clutter" with all the issue related branches we were constantly merging, causing many unnecessary conflicts and false positives on issues that weren't really solved.

17 releases ... that was all it took us to crash and burn again. A year and a half had almost passed since we adopted this modified Gitflow and that last release took at least a week and a half to fully solve every single conflict it had.

average production deploy during our GitFlow period

We had to fix this mess and we weren´t sure what to do, we started by dropping GitFlow altogether, going back to our "2 main branch workflow", and slowly trying to identify what went wrong. From there we started addressing each problem detected, one at a time:

We learned about the different strategies to keep our development up to date.
We established a proper channel to discuss the resolution of conflicts.
We agreed to use non fast-forward merges so our code would be easily grouped an read.

With that in mind, we designed a workflow model, based on both our past experiences and things that we found from articles online, that could be adapted to our learning process and to the reality of our development process lifecycle.

We ended up setting on a workflow that required:

That each branch that hasn't been merged into master must be updated relative to the last pushed tag.
The branch update strategy was through rebasing.
Any merge done into the master or test branches is done in "non-fast-forward" format, leaving an additional commit, properly identifying when an issue related branch was merged.
The test branch must be as close as possible in content to the latest pushed tag on master.

We also dropped the immediate test merge and deploy of any issue related branches and opted for a "wait until we really need this on the test environment" approach.

Also, we adopted a procedure where whenever we push a new tag to master, we would delete the test branch and started a new one by branching from the newly pushed tag.

As a graph our new workflow looked like this:

On this graph new commits are closer to the bottom

With these changes we managed to:

Almost completely eliminate big conflicts on either main branch. And reduce small conflicts from a "daily frequency on the majority of the issue related branches" to "a once a month on a couple issue related branches".
Create a simple and readable git history, where all the work performed for each issue could be easily identifiable.
Almost completely eliminate false positives during the testing phase of the issues.

We've continued to tweak this model up to this very day, the last thing we've done is introduce Gitlab to the mix hoping to use Merge Requests and CI/CD in the near future. We hope to continue to grow and establish a more robust workflow with each passing day.

As I look back on this story, I almost can't believe how much has passed and how much we had to work and learn to get to where we are. I'll try not to forget this as I continue to learn.

Thanks for taking the time to read this :)