My FeedDiscussionsHeadless CMS
New
Sign in
Log inSign up
Learn more about Hashnode Headless CMSHashnode Headless CMS
Collaborate seamlessly with Hashnode Headless CMS for Enterprise.
Upgrade ✨Learn more
Lessons learned from a closed PR

Lessons learned from a closed PR

Alexandre Juca's photo
Alexandre Juca
·Jun 11, 2021·

4 min read

I enjoy solving problems and learning about how other people have solved their own, especially when it comes to software engineering and programming. This is one of the reasons I invest a chunk of my time to reading and writing open source code. To me, good quality open source code can teach you so much about how to create software that is beautiful. You can also see how others designed their applications and which patterns they use to solve a specific problem and that, I think, is really powerful.

Because of the power that open source provides me I provide back by means of contributions to open source, be it improving documentation, ideas, features and so on.

Recently I have used a little bit of my time by contributing to the Elixir ecosystem. One of the most interesting so far was adding a linear algebra primitive called Triangular Solve for lower triangular matrices to Numerical Elixir.

Elixir is a dynamic, concurrent and functional programming language that I have used in a couple of projects recently at Next Solutions (The company I currently work for). We used it to build vPOS a payment gateway for Angolan businesses to use to get paid online.

We chose Elixir because it posseses properties like fault tolerance, potential of high scalability on multi-core systems and it's based on the BEAM, the same technology that helps WhatsApp scale to billions of users. It was a good choice for the problem domain, which is payments. Thousands to millions of people could be paying at a given moment and you want to scale easily and use all the computational resources at your disposal to make things faster.

Let me start

So, today I wanted to take some time to discuss a couple of things that I have learnt from a specific PR that I made to a project called LiveBook.

LiveBook is a a web application for writing interactive code notebooks, similar to Jupyter notebook in the Python ecosystem that is heavily used by data scientists, machine learning engineers and researchers.

So what was the purpose of the PR? It was to add the ability for someone to take a screenshot of a specific code section of a livebook and this is it in action:

CPT2106112022-1024x2134.gif

Clicking the camera button would result in a tab being opened and a screenshot of that specific section of the code to share online or send to someone. Here is an example:

download.png

Initially the PR was well accepted:

1.png

I also received valuable feedback from the authors of the project that allowed me to acquire some more knowledge about how things were working under the hood so I that I could apply it to creating a better implementation. Interestingly enough, the PR did not contain any Elixir code, the functionality I planned to add was focused on the client so I used JavaScript (Which I don't use much). The next day after the initial PR was made everything looked good and code was of the expected quality...

But...

But there is an awful lot one can learn from my interactions with the project's authors and this is where the lessons lie.

The functionality worked well, the implementation was okay on most platforms besides safari but at at the end the question was of this functionalities superiority to native tools for screen capture which are more flexible, meaning you could always use your native tool to take the screen capture for you.

Another issue was maintainability and dependencies. The implementation required a library html2canvas which had a bug in safari. So Safari users could not use it as of yet and and that brought up the question: Would it be a good idea to add this dependency since this feature would need to be maintained across platforms? Is it really worth it?

I myself believe these are valid questions and the interactions between myself and the authors really taught me a lot about what makes contributing to open source so powerful.

You learn to:

  • Read others code
  • Communicate effectively
  • Work as a team
  • Learn
  • Write concise and clear code
  • Learn good programming style (Depending on project quality of course)
  • And so many more things related to software engineering.

Conclusion

Hopefully this serves as an example of how powerful open source contributions can be to your career. Remember, this is not the only way you can learn. You can learn these things by working at a company with a great team and a knowledge sharing culture.

In the end, the PR was not accepted and hence closed but the lessons I learnt will never be forgotten. I wanted these collection of bits that are being rendered to you right now to be an artifact that could teach someone something new.

Hopefully you did.

Take care Hans Solo!