4 ms·

Are you interested in actually developing the software, or building a team of people who will develop the software? If you see yourself in a development role,

by wanderr 17y ago

Are you interested in actually developing the software, or building a team of people who will develop the software? If you see yourself in a development role, the CS path is a good one, as long as it has some Software Engineering mixed in. If you are going more for a leadership role, you can probably skip the CS as long as you know enough to tell the difference between good and bad programmers, and focus your time on Software Engineering primarily. I highly recommend the book Rapid Development for a good starting point (in factg it may be all you need) and Systemantics for an interesting (and humorous) look at the fact that all complex systems operate in a (partial) state of failure, and why.

hga 17y ago
Maybe ... there's still a big difference between a manager/leader who can do the tech involved and one who can't. Earning the respect of those underneath you and being able to really understand what they are doing (or most of what they're doing) is important. Let's put it this way, if two of your programmers are recommencing different approaches and O(whatever) is relevant, you'd best know that and why! (And yes, seriously, I've seen one major software client/server project fail due to a new manager coming from a single user CD-ROM application environment and just not being able to grok scaling, which is after all inescapable for almost all modern interesting projects today). Doing 6.001/SICP plus following up on a few things in it you find interesting might be all the CS foundation you really need, though (well, you should study some systems stuff including security as well). But your point about Software Engineering is well taken; only so much of that is taught in a normal CS curriculum, it's something that needs serious independent study (something I myself started doing a few months into my first programming experience (in high school) and never stopped). Read with attention to detail the 20th anniversary edition of The Mythical Man Month, The Pragmatic Programmer, Peopleware, the Antipatterns book, something that looks relevant by Gerald Weinberg and a methodology book (I prefer The Unified Software Development Process or, now, look for the latest iteration of it (but I suspect you need at least one experienced programmer to make it work), or you could go explicitly agile) and then go from there. (Even Weinberg ancient classic The Psychology of Computer Programming is still somewhat relevant: I still use the anecdote about two people or teams working on a card reading module. One had a slow one that worked, the other was more ambitious but just couldn't get their version to work. When the latter challenged the former on speed, the former said, "Well, if it doesn't have to work I can make our version really fast." :-)

by wanderr 17y ago

hga 17y ago

Maybe ... there's still a big difference between a manager/leader who can do the tech involved and one who can't. Earning the respect of those underneath you and being able to really understand what they are doing (or most of what they're doing) is important. Let's put it this way, if two of your programmers are recommencing different approaches and O(whatever) is relevant, you'd best know that and why! (And yes, seriously, I've seen one major software client/server project fail due to a new manager coming from a single user CD-ROM application environment and just not being able to grok scaling, which is after all inescapable for almost all modern interesting projects today). Doing 6.001/SICP plus following up on a few things in it you find interesting might be all the CS foundation you really need, though (well, you should study some systems stuff including security as well). But your point about Software Engineering is well taken; only so much of that is taught in a normal CS curriculum, it's something that needs serious independent study (something I myself started doing a few months into my first programming experience (in high school) and never stopped). Read with attention to detail the 20th anniversary edition of The Mythical Man Month, The Pragmatic Programmer, Peopleware, the Antipatterns book, something that looks relevant by Gerald Weinberg and a methodology book (I prefer The Unified Software Development Process or, now, look for the latest iteration of it (but I suspect you need at least one experienced programmer to make it work), or you could go explicitly agile) and then go from there. (Even Weinberg ancient classic The Psychology of Computer Programming is still somewhat relevant: I still use the anecdote about two people or teams working on a card reading module. One had a slow one that worked, the other was more ambitious but just couldn't get their version to work. When the latter challenged the former on speed, the former said, "Well, if it doesn't have to work I can make our version really fast." :-)