Why I just wrote developer guidelines

Assembling a new team is tough business. Everyone’s used to their own way of working and the company itself does not have any momentum yet.

How you lay your bed, that’s how you are going to sleep.

When you are starting from scratch, decisions have to be taken about all aspects of development.

If you don’t define them, they will get defined by the people.

The trouble is, everyone will have their own definition and a lot of them won’t be to your liking.

Processes and tools

How and what do we communicate, how often. Daily meeting, or not? Are we sending video updates?

How do we organize the work? What process are we following?

Which tech stack do we choose and why? What coding standards do we want to follow?

Are we writing tests? Integration tests? Unit tests? Are we doing TDD?

Do we require code reviews? Are we doing pair programming.

GitHub or GitLab?

You get the point. There are thousands more of these mini decisions.

And then there is the big picture. The attitude.

The mindset

I want to work with people who are curious, professional and hold themselves to a high standard.

I want to work with people who communicate really well.

With those who seek solutions, not just bring up problems.

With people who are proactive and not just reactive.

With people who take ownership of their tasks and responsibilities and are accountable for meeting deadlines we set and respecting the quality bar that we have.

The silver lining

I don’t want that ambiguity. Here are the rules we follow. I want people who share the same values.

The framework that I’m setting are not the ten commandments. It’s a living document that will be changing as the team is evolving and we learn about working together.

But I have to set the bar high.

If I drop the bar right from the start, the only way left to go is down.

Yours,

Taj