Discussion about this post

User's avatar
Anton Zaides's avatar

I would add to the fifth one - be ready to pivot and throw away work 😅

It happens that you develop something that fails. As long as it was relatively quick, and not a huge project - that’s ok, it’s part of our job. Get something fast in front of the customers, receive feedback, and decide what to do.

Often with engineers are frustrated when a project they worked on is stopped in the middle. This is actually a good sign - it you never had to change plans, it means your product is bloated with useless features

Fran Soto's avatar

It's interesting how all the 5 rules are not tech-specific but communication rules.

- Communicate to ask questions and seek the truth

- Communicate with the product and don't be in a cave

- Keep your communication simple. Clarity of mind -> Clarity of code

- Communicate your achievements

- Understand when things change. Communication is not only talking but listening.

If I were to add one, I'd add learning. Learn to communicate, learn new technologies, and learn the responsibilities of other roles.

No posts

Ready for more?