Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@DerMinze I think in some cases because they lack in the technical knowledge. Or in some cases because they need to please their bosses.
When they make choices that could end bad. I mostly try to explain why this might not be good idea. Deadline to soon, try to point out the dangers of no propper testing or other reason why. In your case with the branches I would contact the developers working on the branches. Or ask management if they are sure.
When I get a job, I always spend some time checking if this is smart/right thing to do. Most of the time this is done in a few minutes of critical thinking and doubting every choice. If I find problems at this stage I explain them to the person that gave the task.
Most of the time they then realise thats indeed the better thing to do. And if not you tried. Dont try to make it sound like they did something wrong. People get defensive really fast and reason goes out the window then.
WHEN YOU DON’T LISTEN TO THE PROGRAMMER...
The transition from developer to manager.
I was about to implement a new feature (which I will call feature X), but I was not sure which branch feature X should be implemented on. Because of different products, there are a lot og branches around.
I was going to implement feature X on branch A, but that branch was currently not working, and someone was working on fixing it.
I was told by my boss to branch out from branch B as feature X would be merged in there later anyways.
And so I did.
After I am nearly finished with feature X I discover I need feature Y from branch A. Feature Y is not yet on branch B, but is scheduled to be merged in some time soon.
So I can't really finish feature X before that point, and I am told by colleague 1 I should have implemented feature X on branch C, because feature Y is there and branch C will be merged into branch B soon.
However, I found out that this has happened before.
First, colleague 1 was told to implement feature Y on branch A. This is the real implementation, the one I need. After he had spent a week implementing feature Y, he was told by colleague 2 that the feature should be implemented on branch C, which is branched off from branch B (I think). So he had to spend a day or two to move feature Y to branch C, but he still kept feature Y on branch A, because all branches will eventually be merged into branch A.
After a week or so, colleague 3 asks about feature Y and is told that the feature is on branch C. But colleague 3 need the feature on branch D, which is branched off branch B for some weeks ago.
I don't know all the details here, but colleague 3 ends up implementing a version of feature Y on branch D and he is happy.
I don't know how much time was wasted because of wrong information from management, but I have no intentions of wasting more time. I'll wait for the merge of branch C into branch B.
If this rant makes no sense, that's just my reflection of management some times.
I love management.
undefined
branches
management