http://www.coderfriendly.com/2009/04/12/project-management-case-study-on-software/ Writing about software and human behavior... Sat, 21 Jan 2012 21:22:58 +0100 http://wordpress.org/?v=2.8.6 hourly 1 http://www.coderfriendly.com/2009/04/12/project-management-case-study-on-software/comment-page-1/#comment-10 coder-friendly Sat, 18 Apr 2009 12:01:48 +0000 http://www.coderfriendly.com/?p=111#comment-10 Hello, I've just found this subject on StackOverflow and it is directly linked to this post: <a href="http://stackoverflow.com/questions/139228/what-do-you-do-with-a-developer-that-does-not-test-his-code" rel="nofollow">What do you do with a developer that does not test his code?</a> Hello,
I’ve just found this subject on StackOverflow and it is directly linked to this post:
What do you do with a developer that does not test his code?

]]> http://www.coderfriendly.com/2009/04/12/project-management-case-study-on-software/comment-page-1/#comment-4 tismealso Mon, 13 Apr 2009 15:37:48 +0000 http://www.coderfriendly.com/?p=111#comment-4 if you can get over his 'high self opinion'; then use it to move him to a more suited role - prototyping; urgent fixes, firefighting etc. You can fire someone for not being a team player but team play is not a strength of programmers, these are people that CHOOSE to work with machines not people; its up to you to bridge the gap and apply his strengths. Recognition of ability will likely be what he craves and that recognition will build confidence and the high pressure state and lack of cooperation will disapear. also ask him what you should do about process - if he is reluctant to adopt style and documentation he may have valid arguaments. I have worked in organisations where process was dictated by hardware engineers since the organisation was manufacturing biased. The process was rediculous for software (new drawing number per commit to the trunk etc). Also why not try pitch this question to the man in question? he may modify to fit or just fuck off in either case problem solved. if you can get over his ‘high self opinion’; then use it to move him to a more suited role – prototyping; urgent fixes, firefighting etc. You can fire someone for not being a team player but team play is not a strength of programmers, these are people that CHOOSE to work with machines not people; its up to you to bridge the gap and apply his strengths. Recognition of ability will likely be what he craves and that recognition will build confidence and the high pressure state and lack of cooperation will disapear. also ask him what you should do about process – if he is reluctant to adopt style and documentation he may have valid arguaments. I have worked in organisations where process was dictated by hardware engineers since the organisation was manufacturing biased. The process was rediculous for software (new drawing number per commit to the trunk etc). Also why not try pitch this question to the man in question? he may modify to fit or just fuck off in either case problem solved.

]]>