Take best practices as a guideline. If something doesn't work well, adapt to your reality.
For example, the project I've been working for the last 6 months had a chaotic repository. We have old devs that came from SVN and TFS that would create a branch from master for working on their issues and then merge into environment specific branches (such as test and release candidate) and after the user approves the change in the release candidate channel, it goes back to master. No version definition at all, no definition of what is a release, no tags, no nothing.
The issue branches staid there forever and issues were managed through, I kid you not, an excel file the PM has in her laptop.
We have over a hundred applications being developed by people who have been working there for over 15 years. It is difficult to change some minds.
But at some point I were the only developer in this specific project, so what I did was to act first and ask questions later. I murdered all merged branches (thanks GitLab for this magic button) and decided this project was going to be a POC for using a custom version of gitflow and issues on GitLab.
But this kind of conceptual change should be gradual, so we still have master, develop, release_candidate and mirror branches. That's one for each environment because that's what Jenkins is reading right now (mirror is same code as master and the environment has a copy of production database from the day before).
Now testers know what to test and we don't have to send them an email telling them what was done because we have it well documented in GitLab issues.
Testers are not ignored by arrogant developers any more because they now can open issues on GitLab and we can decide the importance of things as a team during a sprint planning meeting every 2 weeks. That's very important because the PM and the system analysts don't have knowledge of the tech used in the project. Refactoring works aren't ignored by the PM any more as well.
All this to say that best practices are very important. Even more if your process is still not very mature. Best practices also work as a way to make the learning curve for new employees less steep because there is a higher chance of them studying about or working with those instead of your very unique practice.
Just don't take best practices like a law. Take them as a guideline is what I say.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Hello, what I propose to do is exactly what you are also doing:
1) First invest time to think about what are the real issues in your particular context
2) Then find out what people finding similar issues have done in the past
I am against "best practices" that start at step 2) and forget the first step.
People end up cargo culting what Google and Facebook and Netflix to solve their problems, forgetting that, well they are not Facebook and Google.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Take best practices as a guideline. If something doesn't work well, adapt to your reality.
For example, the project I've been working for the last 6 months had a chaotic repository. We have old devs that came from SVN and TFS that would create a branch from master for working on their issues and then merge into environment specific branches (such as test and release candidate) and after the user approves the change in the release candidate channel, it goes back to master. No version definition at all, no definition of what is a release, no tags, no nothing.
The issue branches staid there forever and issues were managed through, I kid you not, an excel file the PM has in her laptop.
We have over a hundred applications being developed by people who have been working there for over 15 years. It is difficult to change some minds.
But at some point I were the only developer in this specific project, so what I did was to act first and ask questions later. I murdered all merged branches (thanks GitLab for this magic button) and decided this project was going to be a POC for using a custom version of gitflow and issues on GitLab.
But this kind of conceptual change should be gradual, so we still have master, develop, release_candidate and mirror branches. That's one for each environment because that's what Jenkins is reading right now (mirror is same code as master and the environment has a copy of production database from the day before).
Now testers know what to test and we don't have to send them an email telling them what was done because we have it well documented in GitLab issues.
Testers are not ignored by arrogant developers any more because they now can open issues on GitLab and we can decide the importance of things as a team during a sprint planning meeting every 2 weeks. That's very important because the PM and the system analysts don't have knowledge of the tech used in the project. Refactoring works aren't ignored by the PM any more as well.
All this to say that best practices are very important. Even more if your process is still not very mature. Best practices also work as a way to make the learning curve for new employees less steep because there is a higher chance of them studying about or working with those instead of your very unique practice.
Just don't take best practices like a law. Take them as a guideline is what I say.
Hello, what I propose to do is exactly what you are also doing:
1) First invest time to think about what are the real issues in your particular context
2) Then find out what people finding similar issues have done in the past
I am against "best practices" that start at step 2) and forget the first step.
People end up cargo culting what Google and Facebook and Netflix to solve their problems, forgetting that, well they are not Facebook and Google.