How I created my GitHub profile and how it relates to good coding standards
A few of you might already know that GitHub recently released a special type of repository. In your account, if you create a repository that matches your account name, the README.md file of this repository will be shown on your GitHub profile page. If you haven’t seen it, check my profile.
With a simple exercise of trying to describe myself in code style, showed how important it is to write code that someone else will read, instead of writing code that machines can read.
You will find the model that I used to describe myself at: https://github.com/arleypadua/arleypadua
Since I found it quite interesting, and I suddenly gained the capacity to show a little bit about who I am, regarding my profession and passion, I started thinking, ok… what can I put in here? something a bit boring like LinkedIn profile summary? who will read it?
I wrote a couple of words, but nothing seemed to match the purpose of the platform, when I decided to code my own profile summary.
I established a couple of rules for it:
- Use my main programming language
- Has to be easily readable
- Although it is code, anyone has to read it and understand it!
From the summary that I have through out a couple of social media platforms out there, I was able to draft what it would look like:
Developer arley = Developer
.BornIn(Countries.Brazil, year: 1991)
.LivesIn(Countries.Netherlands, since: 2017)
.CodesIn(language => language
.Interested(@in => @in
.Found(at => at
// todo: find out what is next 😅
I even showed it to my wife, which she is not into coding at all :), and then: SUCCESS! She understood the message.
This reminded me of a nice quote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. — Martin Fowler
This fits a lot in a developer’s daily life, as in, machines will always understand instructions, but as we are always having to adapt business code into a reality that is always changing, it is very often that people have to refer back to the instructions, and change them.
If the instructions are non-readable, good luck on trying understand an issue and give stakeholders a clear message of what’s the current status of things. On the other hand, if you have a good, readable codebase, call your stakeholder, and talk what is written down.
The take away of this simple exercise was: If you are really looking forward to be a better developer, stop developing code that will work and start doing code that means something.
Short article, long time I don’t write something, but valuable lesson.
If you want to get in touch, I’m available on Twitter @_arleypadua.