Ditch the macho politics (Who Dares Wins etc.) and new-age stuff (7 Habits).
Ditch even those books that are very good books, but really not relevant to management (Machiavelli, Sun Tzu) - these are just flogged to managers to flatter them. They don't tell you about managing people, they just make you paranoid and up-tight (unless you're really high up in the politics).
Read Peopleware by DeMarco and Lister, Debugging the Development Process (yeah, its an MS book but its well written and gets to the points clearly), and one or two SHORT books on software process management. Maybe read The One Minute Manager (but not all the followups) to get a good base on how to tell people "you did good/bad" in a way that doesn't confuse them or you.
Then try to apply what you've learnt so far, before going on to learn more. Don't try to get to jump straight to SEI Maturity Level 5 in one step. Don't try to be a complete manager on day one. You'll be busy trying to do work without reading 75 odd books.
Most importantly, gradually release the "I'm the chief developer here" role, as a manager you must let other people know more than you, be smarter than you, be closer to the implementation than you (it will happen, so you might as well encourage it rather than fight it). Groom your replacement for the role you had. Give your team chances to impress you, and tell them when it happens. Remember "If I treat my team like idiots, I'll only get a team of idiots". Remember that the project plan is only a picture of what you thought the future would look like, it's not reality. And relax...
We (an IT consultancy) used the Fractal Image compression quite a bit in the early days, paid for a compressor board etc. and it was great. The people saying it produced bad artifacts ?? I never saw any unless you pushed the compression right to the limit (say 150k image down to 3k) at which stage JPEG was just a multi-coloured checkerboard anyway.
But this was in DOS days. When we wanted to develop Windows 3 software, there were no decompression libraries, so we had to use something else as a stopgap JPEG for large images and simple RLE for small images (this was for an Image Database on CD-ROM project).
And then when the Windows software finally came out it was terrible - images that used to decompress in memory in a fraction of a second now took 10, 20 or 30 seconds to decompress ! This was no use whatsoever - so we just gave it up as another good technology gone bad, where the later developers they hired after the initial startup just had no idea....
Either way does me fine (I prefer a hybrid of positional and named a paremeters usually), the point was that side-effects of what makes one language good, don't always give the same benefits in other languages.
Try taking a C++ program and re-writing it in Prolog (or vice-versa), to quote a Larry Wall-ism "the trick is to use the strengths of a tool, not its weaknesses". Quote also Stroustrup on people implementing SmallTalk like classes in C++: "if you want to use SmallTalk, please do so; don't try and re-write it in C++". If you give me time I can probably find quotes to support the similar attitiude by Kernighan, Stallman, Torvalds et al.
My motto used to be "Never attribute to malice what is explained by ignorance", but its now "Never attribute to stupidity what is explained by a different, but internally consistent, value system".
Not so snappy, but it makes for great dinner party conversations
Bollocks. I have never come across a language
that put more barriers in the way of "high-
falutin' theory" than Perl. For God's sake, it
doesn't even have named parameters. Perl is
kind of sub-lambda calculus that way.
Maybe you should look at a few more languages.
And think about a few different ways of doing things.
Perl already has a "name these values" system, the builtin hash type, that applies to all its data. If you want to name your paremeters you pass them as a hash, if you want to just use the order you pass a list... what's so hard about that ??
Now, that wasn't so hard was it ??
I think maybe you mean you don't like loose-typing, but it has its place.
Choose the appropriate language for what you're doing, and use it the appropriate way. Don't bitch because your screwdriver is a lousy hammer.
Cheers
Tim
Slashdot Mirror
Ditch the macho politics (Who Dares Wins etc.) and new-age stuff (7 Habits).
Ditch even those books that are very good books, but really not relevant to management (Machiavelli, Sun Tzu) - these are just flogged to managers to flatter them. They don't tell you about managing people, they just make you paranoid and up-tight (unless you're really high up in the politics).
Read Peopleware by DeMarco and Lister, Debugging the Development Process (yeah, its an MS book but its well written and gets to the points clearly), and one or two SHORT books on software process management. Maybe read The One Minute Manager (but not all the followups) to get a good base on how to tell people "you did good/bad" in a way that doesn't confuse them or you.
Then try to apply what you've learnt so far, before going on to learn more. Don't try to get to jump straight to SEI Maturity Level 5 in one step. Don't try to be a complete manager on day one. You'll be busy trying to do work without reading 75 odd books.
Most importantly, gradually release the "I'm the chief developer here" role, as a manager you must let other people know more than you, be smarter than you, be closer to the implementation than you (it will happen, so you might as well encourage it rather than fight it). Groom your replacement for the role you had. Give your team chances to impress you, and tell them when it happens. Remember "If I treat my team like idiots, I'll only get a team of idiots". Remember that the project plan is only a picture of what you thought the future would look like, it's not reality. And relax...
We (an IT consultancy) used the Fractal Image compression quite a bit in the early days, paid for a compressor board etc. and it was great. The people saying it produced bad artifacts ?? I never saw any unless you pushed the compression right to the limit (say 150k image down to 3k) at which stage JPEG was just a multi-coloured checkerboard anyway.
But this was in DOS days. When we wanted to develop Windows 3 software, there were no decompression libraries, so we had to use something else as a stopgap JPEG for large images and simple RLE for small images (this was for an Image Database on CD-ROM project).
And then when the Windows software finally came out it was terrible - images that used to decompress in memory in a fraction of a second now took 10, 20 or 30 seconds to decompress ! This was no use whatsoever - so we just gave it up as another good technology gone bad, where the later developers they hired after the initial startup just had no idea....
Tim
Either way does me fine (I prefer a hybrid of positional and named a paremeters usually), the point was that side-effects of what makes one language good, don't always give the same benefits in other languages.
Try taking a C++ program and re-writing it in Prolog (or vice-versa), to quote a Larry Wall-ism "the trick is to use the strengths of a tool, not its weaknesses". Quote also Stroustrup on people implementing SmallTalk like classes in C++: "if you want to use SmallTalk, please do so; don't try and re-write it in C++". If you give me time I can probably find quotes to support the similar attitiude by Kernighan, Stallman, Torvalds et al.
My motto used to be "Never attribute to malice what is explained by ignorance", but its now "Never attribute to stupidity what is explained by a different, but internally consistent, value system".
Not so snappy, but it makes for great dinner party conversations
Tim
Maybe you should look at a few more languages. And think about a few different ways of doing things.
Perl already has a "name these values" system, the builtin hash type, that applies to all its data. If you want to name your paremeters you pass them as a hash, if you want to just use the order you pass a list... what's so hard about that ??
$result = myfunc( $first, $second, $third );
$result = myfunc2 { subject => $first, day => $somevalue, other => "xyz" };
Now, that wasn't so hard was it ??
I think maybe you mean you don't like loose-typing, but it has its place.
Choose the appropriate language for what you're doing, and use it the appropriate way. Don't bitch because your screwdriver is a lousy hammer.
Cheers
Tim