A Personal Code

Do you have a personal code of honour? I’ve been giving this some thought and I feel like I’m at a stage where I’d like to write my code down.

I’ve been thinking a lot about a personal code of honour, lately. Large organizations take culture-fit interviews and like to ask questions that showcase that prospective employees have a code of their own that confirms.

What is my code? What are my values?

Note that this is in a pure sense of “Values” in a technical space. However, these bleed into my private life as well.

I Teach

I constantly seek to empower those around me, through trust and camaraderie.

My primary objective is to teach and help others through my work and actions. I love teaching people, but what I love even more is learning from the experience.

I’ve held trainings in Python for all sorts of people, but the ones who’ve amazed me the most are those who weren’t developers. I once worked at an organization, where I trained mechanical engineers who hoped to learn Python and use it in their day-to-day work. Their excitement to learn constantly helped me keep my journey in perspective, and it helped me understand better ways of teaching.

Oddly, it was at another organization that I realized that teaching Software Engineers is no different. I’ve always been a part of a crowd which was constantly churning out side-projects. I’ve grown up around friends who were far more technologically savvy than I am. However, I would be wrong to make that assumption of everyone, even those who are developers. In the end, teaching is an exercise in acceptance and trust. If I am not trusted, I will not be accepted as a teacher.

I also believe that this belief pushes me to build better software. I’m a person who loves automating things, and my very first software project was for a bunch of writers and their team leads. I had great fun building the tool for them, but what I learnt was again an exercise in trust. I had to be trusted for my work to be trusted.

I had to be accepted for my work to actually empower others around me.

It was no different when I began speaking at conferences and meetups. I had the best time speaking at events where I’d already spoken, but I also found it interesting to speak at events where I was new. It is constantly surprising to me, that when I deliver the same talk, I have to constantly know that the reaction will not always be the same. I have to make the audience a part of the talk for my talks to empower them.

I Serve

I am constantly cognizant of the customer and their needs

When developing a tool, I am always in the customer’s shoes. I’m constantly trying to put things in their perspective. Indeed, my series about writing documentation bleeds with that belief.

At my core, I know two things: the customer wants what they want, and; the customer may not always be right. Sometimes, the customer doesn’t know what they truly want. It’s not that they’re fools. No. It’s that they might not be looking at it from the perspective of their fellow customers. It is my duty to blend all of those things. I need to remember what the customer wants, and be able to build tools, systems and interfaces that give the customer a way to achieve their plan.

I Include

I abhor bullies. I hate them with my very core. It doesn’t matter to me if you’re a genius. If you are a bully, your net addition to the team is a negative.

It doesn’t matter to me who a question comes from when I’m in a team. We are a unit. We function as one. Not one question is out of place, and no voice is unheard.

There is something to be said about divas. But, there is nothing good that comes out of being one.

I Learn

I am learning and curious to a fault.

If there is one quasi-fictional/mythological person I relate to, it is Faust. Given a chance by Mephistopheles, Faust asks for wisdom, at a great price. The phrase selling your soul originated there, after all. I have the flaws of Faust. I will constantly learn, with every waking moment.

So much so that I have a discord bot to collect things I learn every day and post them on this blog.

I Write

I’m constantly writing things down. Case in point: this post itself.

I’m driven to think about documentation and how users perceive them. I’m always structuring talks that I give in a way that both entertains and educates.

This philosophy of mine is why I maintain this blog in the first place.

I Act

I do not wait to be told to build something. I build things the moment I see a void where it should exist.

I’m an owner of designs and tools. I like thinking about how things work, and how to take things apart in case something went wrong. I built my own mechanical keyboards, and I also built scripts and bots for my own need. I built my own Raspberry Pi cluster, and I built a speaking bookshelf that can tell me where my books are.

I own these things, and I talk about them to educate people about the joy of building things. I don’t wait to be asked to build them, I don’t wait for someone to say “you should build this.” I maintain long todo lists and I ensure I get around to the things that matter in due time.

Problems exist, and I yearn to solve them. I don’t seek to write software. I seek to eliminate problems through the art of software.

I Wait

This point exists to teach me that I need to exercise patience. It is a constant reminder that waiting helps. It is not what makes me happy, but it is a thing I am working on.

Endnote

Do you have a code of values? Do you think an individual should seek to have these?