Post: #1

I was writing a response to some comments about managing programmers in the "Computer programming lounge" thread and I decided maybe it makes more sense to have a separate thread for this topic. This could be for managers, people thinking about becoming a manager, or even people who just want to talk about (vent) opinions on good or bad IT management. Below I will add the bit from the other thread as a starter.

Post: #2

(03-10-2016 04:54 PM)the Thing Wrote:  

(03-10-2016 05:41 AM)storm Wrote:  Do any of you guys have experience managing programmers? What are the best general practices?

Most programmers you will encounter will fall into the SJW category so all the advice regarding herding that type of crowd will directly apply. Here's a few pointers:

- Make sure one of them is not significantly more skilled than the others. Even though they won't admit it, they will secretly get jealous. One of them being significantly worse than the others won't affect much except he'll constantly nag other developers about his shit not working.
- They'll all have strong opinions on how stuff needs to be done, and they're SJWs so they won't directly come forward with their opinions instead they'll go with a passive aggressive nag-until-you-snag strategy. It will be your job to work this shit storm into synergy in order to avoid tearing the project apart.
- You can always talk with them on their favorite subject: themselves.
- Hold stand up meetings every morning to make sure everyone's got their shit on lockdown.
- Cultural fit is important.
- If you're going to hire a woman, make sure she's ugly, otherwise they'll hit on her, get shut down, then spend too much time crying, getting angry, listening to emo music and jerking their cocks.

They say "managing programmers is like herding cats" and this is completely true. Here's a relevant book:

http://www.amazon.com/Herding-Cats-Prime...1590590171

Godspeed.

Post: #3

As with most management, although you will inevitably end up managing people who know more about the hands-on work than you, it helps a heck of a lot to at least understand it well enough to have a reasonable idea of level of effort that should be expected for different pieces of work. You need to be able to gauge productivity. Don't be one of those who evaluates people based on hours of butt in a seat or dress or ass kissing.

Post: #4

You need to understand best practices, understand that in most cases maintenance work ends up being a lot more expensive than initial development over the long haul and how best practices make things more maintainable. Don't fall into the trap of just thinking the person who gets things done the fastest is your most productive unless you understand what corners are being cut.

There is no absolute best choice on how much to invest in more maintainable design, it depends on the context and is a cost/benefit/risk assessment. Some things are one-time or throwaway, some things will be running for years. Some things involve high-value high-risk processes or data, some not. Some organizations are big, have lots of resources and a lot to lose from mistakes. Startups have a lot less to lose and a lot less resources to invest. So you need perspective.

Post: #5

You need to understand how people on your team need to work together. Some people use a competition style of management where employees are pitted against each other competitively and who performs best gets the biggest reward. That can work when everyone is doing the same type of work in parallel but non-intersecting paths ... so, if you were managing a bunch of salespeople, for example. In my experience that's not the most common situation in IT/programming. (In some cases it might be.) Often in IT you have a team that has different specializations and needs to work together ... so you don't want them to be cutthroat with each other. In those cases you need a team culture of working together and having each others back if you want the team to be productive. If you want to see an inefficient IT organization, big or small, just look at one where parts of the team who need to work together are actually hostile and trying to undercut each other all the time.

Post: #6

Go read works by DeMarco, Constantine & Yourdon.
There are also some excellent books by The Pragmatic Programmers

40 years ago, the single best thing that can be done to improve code quality and reliability is peer review. That is still true today. Real reviews, not just rubber stamp reviews.

Pair programming is a very effective way of educating team members on different parts of a product/system. It is also an excellent way to educate junior level developers.

Post: #7

+1 to pair programming. I learned how to design software by working with other people, because I was able to observe the patterns and processes that came from their instincts, and to view the way they drew upon their own past peer observations.