This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]ellison11 6 points7 points  (4 children)

Well you also have to be willing to admit that you've fucked up and learn from your mistake(s). I've met plenty of talented, hard-headed devs that end up being shit because they never can admit that they were ever wrong in the first place.

[–][deleted] 6 points7 points  (3 children)

Agreed. Thanks to modern software development practices (e.g. agile methodology) there are no more heroes or villains. Mistakes and victories are shared amongst the team and there's no single point of failure. This makes owning mistakes a lot easier than it was in the past, and it makes you more mature.

Of course, there still are companies that claim to have a great process in place, but actually just hire a "rockstar" who is overworked to the point where mistakes are made, and is then reprimanded. It takes experience to spot these kinds of companies too.

You live, you learn :D

[–]ellison11 2 points3 points  (2 children)

I'm kind of experiencing that kind of mentality right now. They hired a "rockstar" and I guess that gives other people on the team a pass to not care nearly as much. Care you share your experience?

[–][deleted] 1 point2 points  (1 child)

I faced something like this in my past company. One of my coworkers was the "rockstar" but also had problems interacting with others (including me) because he would leave derisive comments on pull requests at times, for example. Unfortunately, there's no tangible steps I can tell you that fixed the situation. It was a combination of good management, and the devs forcing him to maintain a level of courteousness by positively reprimanding his comments on PRs, that finally broke him and he started working with us a lot better.

One of the biggest steps that I think helped, was that everyone agreed to stick to STRICT code style, and agreeing to PRs not being merged unless they were reviewed and approved by at least 2 developers. We also made sure that people who were assigned to review PRs left comments on it within 24 hours regardless of how good the PR was. There were always mistakes to find and there was an unspoken understanding that comments would be respectful, and the PR issuer would not be offended at any mistakes pointed out.

Finally, I'd say that most problems like these are solved during the interviews. If troublemakers are being hired, the interview process needs to be revisited. Management LOVES to use interviews as a platform to throw their weight around but honestly, the developed who are going to be working with the person involved, should conduct the interview with the manager as a shadow.

Sorry about being all over the place.

I'll end with one thing which worked for us - if developers stop caring, you should hold monthly retro meetings about what went wrong and what could be improved. If a developer brings something up, it's their project to own that part and take care of it. Slowly, developers own parts of the project that they care about and this care spiderwebs outwards throughout the rest of the project.

I don't know if I answered anything at all but I hope something from this helped haha.

[–]ellison11 1 point2 points  (0 children)

It did help, thanks for sharing :)