The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
On one project I worked on in the past, the PM requested access to the machine of a team member who was out of the country on holiday. The tech support team reset his password and gave it to the PM who was able to find the files she needed.
She then sent the user an email to tell him the new password.
When he returned, for some reason he could not access the email system. I wonder why?
I'm an optoholic - my glass is always half full of vodka.
I was looking at the catalog from my old State U, and I noticed that it has a minor in CS that requires:
- intro programming (2)
- data structures
- computer organization / assembly
- discrete math
- upper level electives
While I certainly agree with the other 4 lower-level stuff, I have to question the need to do computer organization & assembly. Yes, it is important in some realms of CS, but I think that the study of CS has by now completely abstracted out that part of the body of knowledge of CS so that someone could consider himself well-prepared to do CS work (including the fancy-shmancy stuff at the graduate level) without knowing this. Sure, there are some folks studying CS as a minor that might want to learn this, but I don't think it's essential anymore. I could even make the argument that it should be an elective for a CS major.
I reckon it's important. I've worked with developers who had studied courses centered around web development - they get stuck not being able to think below a certain layer of abstraction.
Anything not in the accepted high level formats is horrible unreadable gobbledygook.
Sure you don't want to always operate at that level of thinking but it's infuriating to work in an environment where everything has to be serialized and sent over HTTP otherwise they can't understand/troubleshoot configuration of some infrastructure that operates at the TCP/IP level.
I think that the study of CS has by now completely abstracted out that part of the body of knowledge of CS so that someone could consider himself well-prepared to do CS work (including the fancy-shmancy stuff at the graduate level) without knowing this.
Sure. Perhaps we can abstract away some more and hand out the degrees in every corn flakes package.
So go ahead. Let's produce more fools who can't write a simple one line method or property to set or check some flag bits. I can show you a nice, idiotic error that exists since .Net 1.0 that probably has been built in by someone who could not grasp the concept of enumerating bit flags. It will never be fixed to keep compatibility and makes an otherwise very practical thing almost useless to me because I constantly have to work around this tiny mistake.
And let's invent something that manages memory for those that would be thrown out of every library because they can't understand the simple concept of bringing back what you have borrowed. Let's make them believe that even thinking about managing memory is a very bad thing. This way we can produce idiots who can't understand the absolutely simple concept of a pointer and give me job security forever. Let's make a religion out of it and put it on the list of sins they will have to confess and atone for in code reviews.
Don't you dare to take away the joy of finding out that someone programmed an instant server crash with this simple line:
No error checking or exception handling, just a setup to let the server's memory hop out of their sockets instantly. And the idiot insists on having done everything 'as required' and absolutely unable to imagine that memory is not available in unlimited amounts. Nor was he able to estimate the memory requirements of what he did or understand why it's better to make such an estimate in the code before executing that one simple line.
Abstracting something away does not help those who are still learning. You only deny them any chance to understand what's happening and only few ever become aware that there is a little more to all they know or ever get around to learn about these things. Indeed, they are discouraged to do so by people who mindlessly repeat what they have been preached. Teaching students to rely on abstractions and not equipping them to understand them simply sets them up to fail.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
Remember, this is a computer science course.
Computer science is not necessarily about programming computers although programming and development skills will form part of it.
I remember recruiting a young chap who had just come off some IT course who had a 2.1 and he looked at me with a blank face when I mentioned how understanding the basic mechanics of how a hard disc works and how data is stored on it will make you a better DBA.
“That which can be asserted without evidence, can be dismissed without evidence.”
It is vital, now more than ever. Embedded computing as everywhere, high performance low consumption low cost systems are spreading like butter under the Sun... and being able of tracing faults down to the hw level and fixing one's own tool (aka the workstation) is a skill that never lost value. In fact it is only gaining, due to the usage of industrial PCs in most applications in places of the traditional built-in systems.
Heh, I had a large international company pestering me for almost a year and offering me an amount usually reserved to managers just because I'm one of the few under-40 that has this kind of experience and knowledge. I'll be moving to them in 10 days.
I first read this as meaning the kids are taught the discrete parts of the hardware, and assembling a computer, but after reading other people's comments, I'm not so sure anymore. "Assembler" (if that's what was meant), rather than "assembly", would've removed all doubt.
In any case - assuming my first guess was right:
Yes, I'd like them to know this stuff. But based on what I've seen IRL, I would NOT want most people anywhere near the insides of a computer.
This first bullet item is key to everything!!! However, many software _geniuses_ don't want to admit it.
John Gall, Systemantics
+ A complex system that works is invariably found to have evolved from a simple system that worked
+ A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system
+ In setting up a system, tread softly. You may be disturbing another system that is actually working
+ A system can fail in an infinite number of ways
+ In complex systems, malfunction and even total nonfunction may not be detectable for a long period, if ever
• In general, systems work poorly or not at all.
• New system means new problems.
• Complex systems usually operate in failure mode
Finally I give you the explanation for people arguing about what Agile Methodology is:
A system represents someone's solution to a problem. The system doesn't solve the problem.
But, managers often believe the system (Agile) is the solution. No, it is a possible path to a solution.
Please note that Systemantics does NOT promote "Use agile methods when building large systems". It promotes "Don't build large systems! If at all possible, do not build 'systems' at all!"
So, I think that your first quote is somewhat misleading for the main spirit of the book. The main spirit is "Don't do it". KISS and blackboxing comes much closer to the spirit of Systemantics than agile methods. But even though three out of four software developers cheer enthusiastically (whether wearing a plaid shirt or not...) when hearing a speech promoting KISS, it is all forgotten when they return to their keyboards half an hour later. Knowing a principle doesn't imply that you live by it.
This is actually the first time for the last 25 years that I have seen anyone but myself refer to Systemantics - the book was a cult text when I was a student, but more or less forgotten ten years later. That's a pity. (Maybe it is different across the pond.)
I just happens that today I am wearing a T-shirt with a Systemantics quote: Fail safe systems fail by failing to fail fail safe.
It promotes "Don't build large systems! If at all possible, do not build 'systems' at all!"
It's funny, because one of my own quotes is..."As a dev, writing code may be the last thing you want to do." Devs so often hear a user describe a problem and then start writing code in their heads. I'm more like, "wait a second, I don't think you even need to do that thing. Just stop doing that and your problem is solved." People need to examine the work process they are following before even thinking about solving things with code.
Member 7989122 wrote:
just happens that today I am wearing a T-shirt with a Systemantics quote: Fail safe systems fail by failing to fail fail safe.
Uh...are you John Gall?
Last Visit: 25-Sep-20 17:41 Last Update: 25-Sep-20 17:41