Agreed! I have worked with persons just over 20 who were able to walk in to huge, messy projects and clean it out just by personality. Management != technical, it is a clear head and ability to think and to make things work. I have also worked with career managers in their 40's who made big and very expensive mess even in small projects. IT is mostly from one project to another because of the speed things change today, some older managers, even good at their time, can't handle it. Od course, as in business, often the older, more experienced keep the systems running but try to tell Bill G, Jobs, etc that young people don't know how to create value.
Yes - you have to have years to be very good on any of those. Now, they are not very different fields, they all are part of IT. Once you have managed, let's see, a global networked system demo or installation in 48 hours, you probably have touched all of them and a couple more. Of course not all corporations have that kind of IT projects but it starts to be more and more common, be prepared. IT management is much, much more than managing programmers or administrators, look where you jump to.
A perfect advice, just doesn't always work. I have met IT (and development) managers who really have read these books and "Death March", etc - guess what? Ask them "why then you do this or that?" The answer is always, it is not relevant to our company and I know better or whatever.. Yes, it is good to be a troubleshooter (I am), lots of work, but sometimes it is not so nice to people working in those companies. Maybe it is just me but it really hurts when thousands of people are let go and I'm not talking a normal business but a software company which should know better or some SixSigma hardware company want to be software also. But that's life and if want to be a manager in that kind of environments be prepared.
A good answer. Just don't get too attached to your family and/or friends. If those are important these are not jobs you want to do, you have no own time. But really, once you have done these and got the experience to manage sales/implementation/etc projects with customers and customer IT you have already learned a lot what it is to manage IT. And you probably have learned that your own company can be more difficult than customers, nice to know once you have an IT department or organization to manage. There is even more if you can do these jobs, your network will be much more than what you get sitting in an office, you have seen more how different organizations and maybe even how different cultures work so you will be much more valuable.
Yep, a good comment, the black side of IT management. The only way out I see is to make your organization or even department a profit center. It means more paper work but then you will have hard, cold numbers to show. Lately there has been a lot of talk how IT is an utility service, do you know any utility company which is not there for profit? IT people think too much of technology and forget the business, real or implied. You will really be competing with other organizations inside. The company may see IT as an utility but it is no different of other organizations inside or outside so learn some business and negotiations skills. A tough and thankless job but it is a way to go up.
How old is this? I was told that joke tens of years ago, very common in IT. But it actually is not a bad joke. I used to work in a security group for an insurance company where fraud prevention and security were high on the list. We had very old fashioned CEO and board, not as bad thing as you might think! Now, 9 out of 10 we did catch were in outside or inside middle management, 9 out of 10 we published weren't, go figure, especially comparing the number of managers versus non-managers. I did some very interesting statistics, of course confidential, but it did help us on catching the "bad" guys (or girls.) I quit the group after the changes in top, new, younger, more aggressive lead, giving the reason that I'm too busy taking care of my real job. Oh, and when the next CEO did go to jail a couple of years after I had left the company, I wasn't very surprised. This is OT but feels somehow relevant?
I agree that it is (almost) useless to ask in/. but I don't agree the rest, you are not there to help other managers but the company. In utopia the management should really think the business, in reality the middle management thinks headcount. Ask an IT manager of corporate business and you get some very weird answers but ask how the bonuses relate to headcount, etc you get answers to the penny. It is not the managers fault (IMHO) but how most of the corporations work, unfortunately. Easy to see, run some correlations between salary, bonuses and headcount and then try to add profitability over time to that equation. Yes, a good manager thinks business but his/hers job should be to make the IT business wise as efficient as possible. And that means having a good and loyal staff which goes a long way. A manager is there to see that business (the real money business) gets what services it needs the best possible way. Now, too often, because they are kind of low in corporate hierarchy, they are the last to know any changes or new requirements. So, an advice, make friends on business side and keep up to date what really is happening so there are no surprises which will look bad on you.
Yep, happens and has happened to me more times I want to remember. Even I never had any ambitions to take my managers position, you can't help the human nature. Also, when looking a job I have had that from friends who say that they would otherwise hire me but they are so afraid I will take their job after a while? World has changed, dog eat dog, and companies really don't make it easier because if someone higher up thinks you are better than your manager, your friend, they don't understand that it is often the team which makes you looking better. They just blatantly announce the change and if you don't agree, you are gone also. Has happened, we both left that week, I first and recommended my manager who was hired four days later. We really enjoyed working together, he took all the political, corporate crap and I did the technology! Doesn't happen today?? .
An excellent comment, thank you! I had forgotten "Sapir-Whorf" - shouldn't. Actually wiki article of Sapir-Whorf should be required reading for any CS person. I can't count the cases in long working life I have found this to be true. And "So from a contractual standpoint, providing a 'credible effort' is more about obfuscation than actually trying to do the impossible. Apple probably doesn't care if people can work around this issue, as long as the explanation boils down to 'blah blah blah' to aggressively uninformed label executives." - so right!!
A very good comment but the question here is not about good programmers but code slaves. See next, someone used this list as a criteria, well, it works two ways I can tell.
1 Was there any point where the objectives or usefulness of the project itself was questioned?
2 How early on were the end-users discussed in the answer. Were they mentioned at all?
3 Were there reviews of some sort?
4 At what point was documentation discussed?
5 What kind of testing was mentioned? Was it left to the very last?
Yes, I did ask these (basics and some other too) and the answers were :
1 That's not for you to ask
2 Not your problem, you code
3 We use agile methods so no review needed
4 Documents belong to other department
5 System testing? We use agile methods so there is no need
Sorry, can't work with you ( a big sw company ) and they agreed..
What, you don't like 20 lines APL? Seriously, this is one of basics I learned a long time ago, document what is done, not what the code does! Code is easy to read, even APL or Lisp, but why and what needs really to be documented. My sin, I once wrote a program which generated code, easy and nice except even I couldn't figure out later what the $#%^@ it was doing because at that time I was a hot shot coder and didn't document it very well. Lesson learned! It still runs and is used after 30+ years but nobody has changed it since then, many tried. For all who responded to this thread saying "good" code documents itself, I would say you are in trouble. Any language (almost) is easy to read but please, explain me what that line of code does for business or network connection or whatever? No, I don't need what bits and bytes or what fields it manipulates but why and what effect it has to the system? If you can do that, why not to write it to comments so next time you don't have to use a couple of hours explaining it or, in case you are not available, someone using a long time figuring out what the &$#$*(( did you mean with that. That is what a good programmer does.
I would like to second to that "best quote". I really hate when it takes half an hour to find out that the term you are using was last year called this and.. 30 years ago called that but it actually means this. This happens too often with new systems where for marketing reasons new acronyms pop up every day. This was kind of OT so about good programmers : depends ( don't you hate that? ) what is the target. A good driver programmer may not be a good GUI programmer, a good microcode programmer may not be a good business system programmer and so on, totally different mentality needed. That is the beauty and the problem in programming - unfortunately many companies just look what languages or object models you can use, not what is the target. IMHO languages don't matter (much) but the mindset, languages are easy to learn but how to make supportable and coherent code to solve a need is much more important. I have seen products and even companies to die because the original code did work but was not maintainable for next version, requirements, needs, whatever. That's where the real programmers come ( and should be paid for what they do ) but too often it is the next quarter profit which drives some companies to push out their products and whatever works now is more important than what can be done in future. An advice for want to be programmers, think how you would react seeing your code first time - would you like it?
More reactions than to a Linux / Apple / MS article? Seems that he really did hit a tender spot! Now, wake up, IT as we know today is dead. How many IT persons today punch paper tape or cards or where is your data entry department? Or maybe you still take care of tape drives, vaults, etc? It has happened before, it will always happen. Servers etc, you do external business, internet (see Akamai) has more power than you do. Or, maybe you are using external hosting or backed up to some external site, you are not the only customer. Or maybe you are using MS, SAP, Oracle, JBOSS or whatever solutions and consulting/support instead of your own, sorry to ask! Security, maybe you use internet, banking network (a horror, SNA) or Reuter, trust those? NSA not spying? Local users are easy (as long as you can scan what they carry in their head out of work), remote users a small problem. Or maybe the "call home" systems to get updates and, of course, you know all other things they are doing? And the security is so much more what IT sees that it isn't even funny, when was last time your CEO, CIO, CTO walked to the server room without any control - trusted?, more later.. IT departments don't have to die but need to go back in time, be a profit center instead of be replaced by someone offering a cheap service. Take control of I in IT, Information. Forget the technology, it is and has always been easy, changing yes, but it is just technology you can either follow or develop. Information is different, it is your crown jewels, concentrate to that. A little background to this opinion, it is just an opinion! I used to be, a long time ago, a systems programmer (in a very large corporate) who had the authority to sign very large contracts. How many programmers today have an authority to sign $5 million contract or any? I doubt not many. Now, of course I was responsible of the computing infrastructure, any programmers today have that? Or do you have 10 building construction and 5 electrical engineers in your group to take care of the infrastructure? So, times change, titles change, responsibilities change but every company will still have IT.
It's not funny! My McAfee update barfed, IT had remotely turned it on - corporate rules, and after that XP just refused to connect to domain, actually did screw up something in domain authentication. Easy? Maybe, but after three days our IT, two days me, McAfee doesn't uninstall, several Dell checkpoints restored, recovery CD(s) tried, whatever no connection, there was a possibility, to reload XP. Unfortunately this was a development system with xxx number of tools, toys and fixes, from.NET versions to Palm and J2ME emulators, SNMP build and emulation systems with heavily modified Java/Jython engines to very old compilers, register changes over years, estimate rebuild time with reconfiguration at least one week. First a decision, no corporate McAfee updates to development systems and then add a hard drive, boot and build a Linux and, carefully, build a VM/XP of old system, run connections through Linux and problem solved. What I hear, it still runs like champ. It wasn't XP that had been and was very stable and nice until McAfee did something very bad and mean very, checkpoints for example should get everything back, didn't!
Here is the whole list http://www.hs.fi/english/extras/toolong , kind of funny. Yes, I'm a Finn currently enjoying Seattle weather. But really, Apple stores are nice and Nokia stores are dull. I use Nokia phones but don't even think you get any kind of service or support in those stores. Try to get an USB cable for an European model phone in US or try to get them to update your firmware, forget it. My experience of Apple stores have been very good, 3 minutes to buy last MacBook with no sales of "extended warranty", etc. And then waiting my wife to try the Photoshop CS3 on 24 inch next hour.
I miss it, kind of, nice in car, actually a long reach with a long antenna, but portables were heavy! see : NMT ( http://en.wikipedia.org/wiki/Nordic_Mobile_Telephone ). But much earlier than people think, started the problems, instead going home drive to the next customer!
You need points! Not that an administrator couldn't be a security guru I have always wondered this whole paradigm that programs have a a control over security, access rights, etc? Isn't that (shouldn't that) be an external function in a system? Sorry, I'm (still) a mainframe person and it doesn't matter if you set supervisory, root, whatever bit in program, you don't get it because it wasn't allowed by system. I like POSIX because it standardizes a lot of coding but IMHO before there are standard methods to control any program externally it is too easy make mistakes.
Take it easy, it is just a show but there is a real life also. Penetration testing wasn't new even when I hit it in an insurance company(70's). We did it and when we did need professionals hired people from an UK company for that, they were good, very good. They were impressed of our computer / systems security but much less of our physical security (heh, I was responsible of systems security). I still remember our CEO really blowing up when the penetration team presented him a couple of very sensitive business documents they had found, some big changes after that. Our own work was mostly catching insurance cheaters and also some insiders who did use our resources, let's say, not a proper way. It meant installing all kinds of loggers, keyboard / display loggers are nothing new, on their workstations, sitting there in nights watching them to access foreign accounts, normally allowed but.. So it happens.
Thank you, you really had to bring APL to this when I'm having flashbacks! APL was a beautiful language and because we were one of the first AP (attached processor) systems I got to work on that. Who ever wrote that interpreter was good except in assembler so I ended up fixing several bugs in code when we build (mid 70's?, I don't really remember the year) first real applications, not just math but an HR system based on relational ideas(system R anybody?). And once you get the keyboard it is no more difficult than using all the weird ESC, etc sequences in your favorite editor. Actually it grows on you but, agreed, a little math background is needed. At end the system did run well on AP, was fast, easy (the user didn't actually need an APL keyboard) but after one look to the code our developers did run away (screaming!) So, that project didn't catch but it was lots of fun.
You definitely should have more points, if I had.. You answer so many questions so well that there is no point to comment those except because you have FORTRAN there. Kind of related to parallel processing everyone should know how the vector processing and specialized vector FORTRAN did/does it. The problem today compared to earlier systems are the week links, the compiler really can not analyze everything in system, maybe the data used in thread is used by another but because it is not known at the compile time there is nothing the compiler can do. Kind of have to agree with just in time optimization, the programs can learn and the longer they run the more optimized they get. Most relational database systems do that (if you let them), the longer they run, the more efficient they get (to certain point, even they can not fix logic errors.) And some of them span tens of nodes with hundreds of cpus and even more.
Correct and a good answer, can only be used when only certain type of people around. This is one of the basic problems not too often explained to CS students, throughput and response times are only loosely related. Actually latency plays even bigger role today because of networks (any kind) internet, buses, execution path, even SOA between services, etc and often overlooked. Now of course there may be some turnaround (setup) time which comes to play but with computers it's getting faster, I don't know about humans?
Yes and yes. You explained it better than I usually do. Actually there are such things for software also, it is called multi-tasking. One time cost to load and then forever it is just normal call cost (almost, with hw help) any time you give the task more work (or as the name says something to do). If a task or a thread is independent, feeding the system without control once started, not receiving new "orders" like reader tasks, I would call it multi-programming, just schematics. As someone already mentioned it gets even more interesting between SIMD or MIMD machines (AP(attached) and MP(multi) for oldtimers) and if it involves any external resources as I/O, memory, etc which can be shared (and/or cached) between or separated between processors. Or hybrids, 2+2, etc. An interesting subject trying to make it fast in parallel without problems but probably way off from "normal" development just good to remember when trying to make applications running faster. Also, I agree that in "normal" desktop more than two processors are mostly not a big benefit but games, CAD, rendering, statistics, modeling / simulation, pick your own, if done right, can have great benefits of multiple processors. Clusters help but fast connections are not cheap between systems. And an advice to start-up / tear down philosophy, why tear down if it is not one time task? Write re-entrant and reuse. And if you have two processors, why create more than maybe three equal threads, are you sure that the resources they use are not serialized? Even if threads are in pools there is a cost to start / stop.
Right. And right again, you can't change the complexity (even some compilers try) but you can try to design the complexity (simplicity) yourself. See the sorting algorithm and parallelism development since 60's. Not advertising but Syncsort was and maybe still is one very good example. US radar tracking built highly parallelized sorting systems for incoming radar data at that time, still a viable technology, can be found (maybe) in several thesis papers. Parallel processing has been around longer than most think. Now, to get most of parallel processing don't think just one algorithm, think systems. Even a lot of SQL access today can use a lot of sorts and parallel I/O and not always needs the results sequentially but to combine it later when the results are needed, a perfect parallel task while other processing is done. Think compilations, several programs compiled and later combined to one object or library, what's better than compiling in parallel? If you can break a task ( big or small, a report, a transaction, a matrix manipulation, a loop, etc ) to smaller pieces it often can be parallelized. Not easy always because something like XML was not originally designed for that but if you need performance ( and flexibility ) don't design one huge XML but several with references where even if each needs serializing they can be parsed or created in parallel. This really is less a coding problem but a design problem and a little OT because the article was of CPU's but there is much more in computers, systems and parallelism than just number of CPU's.
Source Control / Configuration Management. In a perfect ( an utopia! ) system no code is ever added to anything going to production but to test systems. All code changes are tracked, traceable and documented against set of rules. All changes are are authorized, not by developer but for example lead or architect. Once accepted code changes are locked, can not be modified or deleted. Much what is done for example in Linux Kernel except usually in closed source systems you can (mostly, excluding some for any reason sensitive parts) read but not modify code you don't own. Before the code goes to production it has approvals from leads, QA and in sensitive cases even security. Needs a lot of pre-planning but once running these systems don't really need much human resources. For example in one place we had 18,000 different applications / 400+ developers and only three persons accepting changes to production, I was one and it really didn't take much of my time. It also had the benefits checking the viability of systems, some were OK after changes but would have caused for example performance problems, needed new hw we didn't yet have, was actually released to production a week too early, training for new systems was delayed, another system this needed wasn't ready, etc so we were able to control the production cycle. Trust me, saves a lot of headache and debugging or sudden shortages in resources.
Slashdot Mirror
Agreed! I have worked with persons just over 20 who were able to walk in to huge, messy projects and clean it out just by personality. Management != technical, it is a clear head and ability to think and to make things work. I have also worked with career managers in their 40's who made big and very expensive mess even in small projects. IT is mostly from one project to another because of the speed things change today, some older managers, even good at their time, can't handle it. Od course, as in business, often the older, more experienced keep the systems running but try to tell Bill G, Jobs, etc that young people don't know how to create value.
Yes - you have to have years to be very good on any of those. Now, they are not very different fields, they all are part of IT. Once you have managed, let's see, a global networked system demo or installation in 48 hours, you probably have touched all of them and a couple more. Of course not all corporations have that kind of IT projects but it starts to be more and more common, be prepared. IT management is much, much more than managing programmers or administrators, look where you jump to.
A perfect advice, just doesn't always work. I have met IT (and development) managers who really have read these books and "Death March", etc - guess what? Ask them "why then you do this or that?" The answer is always, it is not relevant to our company and I know better or whatever.. Yes, it is good to be a troubleshooter (I am), lots of work, but sometimes it is not so nice to people working in those companies. Maybe it is just me but it really hurts when thousands of people are let go and I'm not talking a normal business but a software company which should know better or some SixSigma hardware company want to be software also. But that's life and if want to be a manager in that kind of environments be prepared.
A good answer. Just don't get too attached to your family and/or friends. If those are important these are not jobs you want to do, you have no own time. But really, once you have done these and got the experience to manage sales/implementation/etc projects with customers and customer IT you have already learned a lot what it is to manage IT. And you probably have learned that your own company can be more difficult than customers, nice to know once you have an IT department or organization to manage. There is even more if you can do these jobs, your network will be much more than what you get sitting in an office, you have seen more how different organizations and maybe even how different cultures work so you will be much more valuable.
Yep, a good comment, the black side of IT management. The only way out I see is to make your organization or even department a profit center. It means more paper work but then you will have hard, cold numbers to show. Lately there has been a lot of talk how IT is an utility service, do you know any utility company which is not there for profit?
IT people think too much of technology and forget the business, real or implied. You will really be competing with other organizations inside. The company may see IT as an utility but it is no different of other organizations inside or outside so learn some business and negotiations skills. A tough and thankless job but it is a way to go up.
How old is this? I was told that joke tens of years ago, very common in IT. But it actually is not a bad joke. I used to work in a security group for an insurance company where fraud prevention and security were high on the list. We had very old fashioned CEO and board, not as bad thing as you might think! Now, 9 out of 10 we did catch were in outside or inside middle management, 9 out of 10 we published weren't, go figure, especially comparing the number of managers versus non-managers. I did some very interesting statistics, of course confidential, but it did help us on catching the "bad" guys (or girls.) I quit the group after the changes in top, new, younger, more aggressive lead, giving the reason that I'm too busy taking care of my real job. Oh, and when the next CEO did go to jail a couple of years after I had left the company, I wasn't very surprised. This is OT but feels somehow relevant?
I agree that it is (almost) useless to ask in /. but I don't agree the rest, you are not there to help other managers but the company. In utopia the management should really think the business, in reality the middle management thinks headcount. Ask an IT manager of corporate business and you get some very weird answers but ask how the bonuses relate to headcount, etc you get answers to the penny. It is not the managers fault (IMHO) but how most of the corporations work, unfortunately. Easy to see, run some correlations between salary, bonuses and headcount and then try to add profitability over time to that equation.
Yes, a good manager thinks business but his/hers job should be to make the IT business wise as efficient as possible. And that means having a good and loyal staff which goes a long way. A manager is there to see that business (the real money business) gets what services it needs the best possible way. Now, too often, because they are kind of low in corporate hierarchy, they are the last to know any changes or new requirements. So, an advice, make friends on business side and keep up to date what really is happening so there are no surprises which will look bad on you.
Yep, happens and has happened to me more times I want to remember. Even I never had any ambitions to take my managers position, you can't help the human nature. Also, when looking a job I have had that from friends who say that they would otherwise hire me but they are so afraid I will take their job after a while? World has changed, dog eat dog, and companies really don't make it easier because if someone higher up thinks you are better than your manager, your friend, they don't understand that it is often the team which makes you looking better. They just blatantly announce the change and if you don't agree, you are gone also. Has happened, we both left that week, I first and recommended my manager who was hired four days later. We really enjoyed working together, he took all the political, corporate crap and I did the technology! Doesn't happen today??
.
An excellent comment, thank you! I had forgotten "Sapir-Whorf" - shouldn't. Actually wiki article of Sapir-Whorf should be required reading for any CS person. I can't count the cases in long working life I have found this to be true. And "So from a contractual standpoint, providing a 'credible effort' is more about obfuscation than actually trying to do the impossible. Apple probably doesn't care if people can work around this issue, as long as the explanation boils down to 'blah blah blah' to aggressively uninformed label executives." - so right!!
A very good comment but the question here is not about good programmers but code slaves. See next, someone used this list as a criteria, well, it works two ways I can tell.
1 Was there any point where the objectives or usefulness of the project itself was questioned?
2 How early on were the end-users discussed in the answer. Were they mentioned at all?
3 Were there reviews of some sort?
4 At what point was documentation discussed?
5 What kind of testing was mentioned? Was it left to the very last?
Yes, I did ask these (basics and some other too) and the answers were :
1 That's not for you to ask
2 Not your problem, you code
3 We use agile methods so no review needed
4 Documents belong to other department
5 System testing? We use agile methods so there is no need
Sorry, can't work with you ( a big sw company ) and they agreed..
What, you don't like 20 lines APL? Seriously, this is one of basics I learned a long time ago, document what is done, not what the code does! Code is easy to read, even APL or Lisp, but why and what needs really to be documented. My sin, I once wrote a program which generated code, easy and nice except even I couldn't figure out later what the $#%^@ it was doing because at that time I was a hot shot coder and didn't document it very well. Lesson learned! It still runs and is used after 30+ years but nobody has changed it since then, many tried.
For all who responded to this thread saying "good" code documents itself, I would say you are in trouble. Any language (almost) is easy to read but please, explain me what that line of code does for business or network connection or whatever? No, I don't need what bits and bytes or what fields it manipulates but why and what effect it has to the system? If you can do that, why not to write it to comments so next time you don't have to use a couple of hours explaining it or, in case you are not available, someone using a long time figuring out what the &$#$*(( did you mean with that. That is what a good programmer does.
I would like to second to that "best quote". I really hate when it takes half an hour to find out that the term you are using was last year called this and .. 30 years ago called that but it actually means this. This happens too often with new systems where for marketing reasons new acronyms pop up every day. This was kind of OT so about good programmers : depends ( don't you hate that? ) what is the target. A good driver programmer may not be a good GUI programmer, a good microcode programmer may not be a good business system programmer and so on, totally different mentality needed. That is the beauty and the problem in programming - unfortunately many companies just look what languages or object models you can use, not what is the target. IMHO languages don't matter (much) but the mindset, languages are easy to learn but how to make supportable and coherent code to solve a need is much more important. I have seen products and even companies to die because the original code did work but was not maintainable for next version, requirements, needs, whatever. That's where the real programmers come ( and should be paid for what they do ) but too often it is the next quarter profit which drives some companies to push out their products and whatever works now is more important than what can be done in future. An advice for want to be programmers, think how you would react seeing your code first time - would you like it?
More reactions than to a Linux / Apple / MS article? Seems that he really did hit a tender spot!
Now, wake up, IT as we know today is dead. How many IT persons today punch paper tape or cards or where is your data entry department? Or maybe you still take care of tape drives, vaults, etc? It has happened before, it will always happen.
Servers etc, you do external business, internet (see Akamai) has more power than you do. Or, maybe you are using external hosting or backed up to some external site, you are not the only customer. Or maybe you are using MS, SAP, Oracle, JBOSS or whatever solutions and consulting/support instead of your own, sorry to ask!
Security, maybe you use internet, banking network (a horror, SNA) or Reuter, trust those? NSA not spying? Local users are easy (as long as you can scan what they carry in their head out of work), remote users a small problem. Or maybe the "call home" systems to get updates and, of course, you know all other things they are doing? And the security is so much more what IT sees that it isn't even funny, when was last time your CEO, CIO, CTO walked to the server room without any control - trusted?, more later..
IT departments don't have to die but need to go back in time, be a profit center instead of be replaced by someone offering a cheap service. Take control of I in IT, Information. Forget the technology, it is and has always been easy, changing yes, but it is just technology you can either follow or develop. Information is different, it is your crown jewels, concentrate to that.
A little background to this opinion, it is just an opinion! I used to be, a long time ago, a systems programmer (in a very large corporate) who had the authority to sign very large contracts. How many programmers today have an authority to sign $5 million contract or any? I doubt not many. Now, of course I was responsible of the computing infrastructure, any programmers today have that? Or do you have 10 building construction and 5 electrical engineers in your group to take care of the infrastructure? So, times change, titles change, responsibilities change but every company will still have IT.
It's not funny! My McAfee update barfed, IT had remotely turned it on - corporate rules, and after that XP just refused to connect to domain, actually did screw up something in domain authentication. Easy? Maybe, but after three days our IT, two days me, McAfee doesn't uninstall, several Dell checkpoints restored, recovery CD(s) tried, whatever no connection, there was a possibility, to reload XP. Unfortunately this was a development system with xxx number of tools, toys and fixes, from .NET versions to Palm and J2ME emulators, SNMP build and emulation systems with heavily modified Java/Jython engines to very old compilers, register changes over years, estimate rebuild time with reconfiguration at least one week. First a decision, no corporate McAfee updates to development systems and then add a hard drive, boot and build a Linux and, carefully, build a VM/XP of old system, run connections through Linux and problem solved. What I hear, it still runs like champ. It wasn't XP that had been and was very stable and nice until McAfee did something very bad and mean very, checkpoints for example should get everything back, didn't!
Here is the whole list http://www.hs.fi/english/extras/toolong , kind of funny. Yes, I'm a Finn currently enjoying Seattle weather. But really, Apple stores are nice and Nokia stores are dull. I use Nokia phones but don't even think you get any kind of service or support in those stores. Try to get an USB cable for an European model phone in US or try to get them to update your firmware, forget it. My experience of Apple stores have been very good, 3 minutes to buy last MacBook with no sales of "extended warranty", etc. And then waiting my wife to try the Photoshop CS3 on 24 inch next hour.
I miss it, kind of, nice in car, actually a long reach with a long antenna, but portables were heavy! see : NMT ( http://en.wikipedia.org/wiki/Nordic_Mobile_Telephone ). But much earlier than people think, started the problems, instead going home drive to the next customer!
You need points! Not that an administrator couldn't be a security guru I have always wondered this whole paradigm that programs have a a control over security, access rights, etc? Isn't that (shouldn't that) be an external function in a system? Sorry, I'm (still) a mainframe person and it doesn't matter if you set supervisory, root, whatever bit in program, you don't get it because it wasn't allowed by system. I like POSIX because it standardizes a lot of coding but IMHO before there are standard methods to control any program externally it is too easy make mistakes.
Take it easy, it is just a show but there is a real life also. Penetration testing wasn't new even when I hit it in an insurance company(70's). We did it and when we did need professionals hired people from an UK company for that, they were good, very good. They were impressed of our computer / systems security but much less of our physical security (heh, I was responsible of systems security). I still remember our CEO really blowing up when the penetration team presented him a couple of very sensitive business documents they had found, some big changes after that. Our own work was mostly catching insurance cheaters and also some insiders who did use our resources, let's say, not a proper way. It meant installing all kinds of loggers, keyboard / display loggers are nothing new, on their workstations, sitting there in nights watching them to access foreign accounts, normally allowed but.. So it happens.
Thank you, you really had to bring APL to this when I'm having flashbacks! APL was a beautiful language and because we were one of the first AP (attached processor) systems I got to work on that. Who ever wrote that interpreter was good except in assembler so I ended up fixing several bugs in code when we build (mid 70's?, I don't really remember the year) first real applications, not just math but an HR system based on relational ideas(system R anybody?). And once you get the keyboard it is no more difficult than using all the weird ESC, etc sequences in your favorite editor. Actually it grows on you but, agreed, a little math background is needed. At end the system did run well on AP, was fast, easy (the user didn't actually need an APL keyboard) but after one look to the code our developers did run away (screaming!) So, that project didn't catch but it was lots of fun.
You definitely should have more points, if I had.. You answer so many questions so well that there is no point to comment those except because you have FORTRAN there. Kind of related to parallel processing everyone should know how the vector processing and specialized vector FORTRAN did/does it. The problem today compared to earlier systems are the week links, the compiler really can not analyze everything in system, maybe the data used in thread is used by another but because it is not known at the compile time there is nothing the compiler can do. Kind of have to agree with just in time optimization, the programs can learn and the longer they run the more optimized they get. Most relational database systems do that (if you let them), the longer they run, the more efficient they get (to certain point, even they can not fix logic errors.) And some of them span tens of nodes with hundreds of cpus and even more.
Correct and a good answer, can only be used when only certain type of people around. This is one of the basic problems not too often explained to CS students, throughput and response times are only loosely related. Actually latency plays even bigger role today because of networks (any kind) internet, buses, execution path, even SOA between services, etc and often overlooked. Now of course there may be some turnaround (setup) time which comes to play but with computers it's getting faster, I don't know about humans?
Yes and yes. You explained it better than I usually do. Actually there are such things for software also, it is called multi-tasking. One time cost to load and then forever it is just normal call cost (almost, with hw help) any time you give the task more work (or as the name says something to do). If a task or a thread is independent, feeding the system without control once started, not receiving new "orders" like reader tasks, I would call it multi-programming, just schematics. As someone already mentioned it gets even more interesting between SIMD or MIMD machines (AP(attached) and MP(multi) for oldtimers) and if it involves any external resources as I/O, memory, etc which can be shared (and/or cached) between or separated between processors. Or hybrids, 2+2, etc. An interesting subject trying to make it fast in parallel without problems but probably way off from "normal" development just good to remember when trying to make applications running faster. Also, I agree that in "normal" desktop more than two processors are mostly not a big benefit but games, CAD, rendering, statistics, modeling / simulation, pick your own, if done right, can have great benefits of multiple processors. Clusters help but fast connections are not cheap between systems. And an advice to start-up / tear down philosophy, why tear down if it is not one time task? Write re-entrant and reuse. And if you have two processors, why create more than maybe three equal threads, are you sure that the resources they use are not serialized? Even if threads are in pools there is a cost to start / stop.
Right. And right again, you can't change the complexity (even some compilers try) but you can try to design the complexity (simplicity) yourself. See the sorting algorithm and parallelism development since 60's. Not advertising but Syncsort was and maybe still is one very good example. US radar tracking built highly parallelized sorting systems for incoming radar data at that time, still a viable technology, can be found (maybe) in several thesis papers. Parallel processing has been around longer than most think. Now, to get most of parallel processing don't think just one algorithm, think systems. Even a lot of SQL access today can use a lot of sorts and parallel I/O and not always needs the results sequentially but to combine it later when the results are needed, a perfect parallel task while other processing is done. Think compilations, several programs compiled and later combined to one object or library, what's better than compiling in parallel? If you can break a task ( big or small, a report, a transaction, a matrix manipulation, a loop, etc ) to smaller pieces it often can be parallelized. Not easy always because something like XML was not originally designed for that but if you need performance ( and flexibility ) don't design one huge XML but several with references where even if each needs serializing they can be parsed or created in parallel. This really is less a coding problem but a design problem and a little OT because the article was of CPU's but there is much more in computers, systems and parallelism than just number of CPU's.
You are of course right, it is Change NOT Configuration management in this case. My bad.
Source Control / Configuration Management. In a perfect ( an utopia! ) system no code is ever added to anything going to production but to test systems. All code changes are tracked, traceable and documented against set of rules. All changes are are authorized, not by developer but for example lead or architect. Once accepted code changes are locked, can not be modified or deleted. Much what is done for example in Linux Kernel except usually in closed source systems you can (mostly, excluding some for any reason sensitive parts) read but not modify code you don't own. Before the code goes to production it has approvals from leads, QA and in sensitive cases even security. Needs a lot of pre-planning but once running these systems don't really need much human resources. For example in one place we had 18,000 different applications / 400+ developers and only three persons accepting changes to production, I was one and it really didn't take much of my time. It also had the benefits checking the viability of systems, some were OK after changes but would have caused for example performance problems, needed new hw we didn't yet have, was actually released to production a week too early, training for new systems was delayed, another system this needed wasn't ready, etc so we were able to control the production cycle. Trust me, saves a lot of headache and debugging or sudden shortages in resources.