Code is for People!

This is a re-post. Originally posted as 'Team Guidelines - Musings by Sameeri' @ eblog.telogical.com

​Dearest Engineers, my brothers!

In the midst of societies.. rebels like me, are not too infrequent.

They question, doubt, protest, fight, and may be give up, get sad and leave.

We have a set of highly quality oriented, highly knowledgeable.. technical thought leaders..

When i say thought leaders..... i mean everyone of you..

Each time, i pair with someone new,  i learn their opinion of good software..and they are correct in their own way.

And i leave amazed..

Yet another opportunity to learn from another skilled engineer.

A team, in my very humble opinion.. should have and follow guidelines..

Outside Telogical,  we can write code as it pleases our heart..have tests .. no tests.. have good names.. nah, whatever!

These guidelines can be based off discussion and be democratic..

Code written inside the team, the products we help develop.. should be consistent.. and today, they mostly are..

When an engineer, say, Sameeri.. comes across a new code-base, already in production..

he should NOT be greeted with new ways of thinking, and lose himself,to quickly come to the point of issue/feature..

The developer is the most.. feared USER of them all.. he has no mercy!!!

I call the developer a USER, cause he reads our code, maintains it, and also uses it(as a library user)

He would swear and criticize the code that has been previously written..

She would throw fits cause the API exposed by another developer..is not as she had expected it would be..

The kids like me would be scared to touch the code, cause they doesn't know the expected behavior(as they were no tests), unless they talk to someone who has already worked on the project.

The developer.... is the most 'CRUEL' of them all users...NO forgiveness..whatsoever..

I stand in the shadows of such developers..grinning away at my chance to show my frustration of life..

We are extremely fortunate. Since, most of our products are JavaScript based. End to End.

It gives us a unique opportunity to think about these things, which are difficult otherwise, and would need too much discipline.

With the recent separation of gulp based process tasks out of the way into it's own repository as 'glomp', thanks to Jesse's extreme hard work..and the notion of having modules and the to be put on our private server, 'npm.telogical.com' and the ideas of 'component based architecture', 'theming' and 'microservice based architecture' in place, it's high time we give a thought about some of these guidelines..

• ​Naming Conventions
• Code Organization
• Unit tests
• XRs
• API's (how our API's/Microservices) are to be developed
• UI Component development
• Common code smells (JS) and how to refactor
• Issue creation & Issue resolution..
• Wiki documentation guidelines

And anything else that you guys can think of.

Some of these might be out there. For example, the recent guidelines set up by our dramatic wizard Joe,.

But the "thinking" behind such guidelines(especially those of component/module/service development) should be explained to all and should be transparent.

This is highly important, as it demonstrates to the world..(whoever it is...) that we think, believe and act as a team, and as ONE. 

Oneness is crucial, and our strength lies in our "thought processes.."

Having a set of guideline(not entirely in stone, cause of our beautiful thought process of 'Continuous Improvement'.. these are bound to change..)  offers the following advantages.

•  ​Code looks like it's been written by the same guy/lady
• Code reviews are not 'stylistic' based.. they are more intelligent, pertaining to the extraction and representation of domain concepts and to that of pattern oriented code.
• Code is beautiful, consistent, easy to read, write and maintain.

Code should then, be looked upon with reverence.. not spite..

Code is for people..

It's easy to write code. Anyone can do it. It's extremely hard to write code for people.

Code that is simple, elegant, clean, easy to read/understand, maintainable, flexible and ready for change,

testable/tested, doing what it says, self documenting, written to domain concepts, consistent, written to design principles and patterns is extremely extremely hard. It requires conscious effort and a great deal of discipline and energy.

We are indeed extremely fortunate to be working in an environment, where we are shielded by other members of our team, the PMs/Interaction Designers and our extremely skilled account managers .. to ward off the talks.. and decision making..

These people are kind, patient,  supporting and understanding.. and they share our dream of having good/quality software..

One unique blessing, is the presence of the 'zen master' on our boat. Ray.

Ray in his exhaustive knowledge space, would call the Software Engineering process as a 'Craft'.

I take his words blindly, for i consider him, my guru, in the art of software development.

I always, have the question for myself, are we treating/training ourselves as craftsmen..

Yes, in the industry, the whole process is broken apart, and they give titles.. 'coders', 'testers'...

But at Telogical, it's not that.. 

Ray considers each one of us as Craftsmen.. and would like us to grow into one.

I am highly optimistic for the bright future for Telogical. 

We have extraordinary leaders, who are making sacrifices today, because of temporary ripples.. 

And usually, sacrifices made, never go waste.

So we have to prepare ourselves.. to the future..where each one of us would have our own team to take care of..

Each one of us would be architects, and make important decisions.. just as Ray, Saurav, Jesse, Te, Rupesh, Ben and Joe do today.

On the second page of one of the books that sits atop Ray's shelf(Applying Domain Driven Design Patterns), these

words are inscribed. These are the words of Eric Evans, the guy who coined the term DDD.

"The best way to learn how to do Domain-Driven Design is to sit down next to a friendly, patient, experienced

practitioner and work through problems together, step-by step." 

At our place, a learning/teaching platform already exists, which i'm so thankful for.

It's not too uncommon.. for people to think.. "Oh! These engineers.."

But Engineers at Telogical, are amazing. 

They are human beings with a great set of qualities.. that you can't find easily in the wild. 

​It might seem like Engineers are crazy people, with no respect for fellow human beings.. this is so entirely wrong..​

• We care for people. We spend  a lot of time discussing over a variable name that might help a developer see the concept being expressed easily..
• We do not hesitate to discuss, comment, politely criticize.. and question one another the way of doing things.
• We collaborate , and learn, teach. Seekers of the truth, and wisdom and warriors fighting problems, some simple, some complex. 
• We love to fiddle, discover, have AHA moments.. and create something that matters.
• We are artists, and lovers.  We get inspired so easily and just love the art.
• If Engineers, in general, did not care for continuously improving things, putting a lot of thought and energy, software industry would be dead.. and we would be doing some other lovely thing in life.​
• Engineers@Telogical, care for each other so much, that they buy lunches to one another..every other day. This my friends, i call, in worldly language, LOVE. :) <3​

"In Team work, there's no place for Ego! Team = We, Not I"

Best,

Sameeri

Saibaba Vinayakaya namaha!