Slashdot Mirror
Perth Game Company CEO Takes IP By Night
snicho99 writes "A US owned gaming company has fled Australia, leaving unpaid employees and a massive tax bill. Apparently many staff have been working unpaid for months to allow their game to ship and hopefully the company to recover. Interzone's Perth (Western Australia) office was created with the assistance of a state government grant. Last week Interzone's (American) CEO
entered the building at night and removed all the servers and IP so that Interzone could continue production at a new company they have opened in Ireland. The staff caught him on camera. More background here."
Er, no, RTFS - he removed the servers.
This is the one time that referring to "IP theft" actually makes sense. He stole it, removing the original rather than duplicating.
Do people who commit piracy do so by going to the record companies at night, sneaking in, and removing their CDs?
Anyhow, where does anyone accuse him of stealing? Or are you just making up a straw man?
But that's retarded. They had little reason to do that other than some profoundly misplaced loyalty
The only reason the loyalty was misplaced was because the CEO screwed them. Had he honored their commitment and worked as hard as possible to save the company and then paid them back dues + bonus/stock their loyalty would have been dead on. Unfortunately they worked for a douchebag. I'm the first person to have no loyalty for a large mega corp but small shops require it. We can't function without the employees giving a damn about the company and the company can't function without giving a damn about their employees.
The Goal: A long simple life filled with many complex toys.
An increasing number of programmers over the years have started calling themselves engineers, and it truly bothers me. This source of ire came to a head 2 years ago when I needed to hire engineers that also knew how to program. Being in Seattle, 99% of the applicants advertised themselves as engineers, and while many of them were intelligent and very well versed in programming principles and practices, not a single one of them knew anything about what would be learned in engineering school.
Here are some examples of interviewing questions I made to lend understanding of the distinction I had to make between programmers and engineers:
What is a Fourier (or Laplace) transform?
What is a convolution?
What is an RMS mean compared to an average?
What is a duty cycle?
How do you apply Kirchoff's law to a circuit?
What is the time constant of an RC circuit, and what does it mean?
What is the resonance frequency of an RLC circuit?
What is the nyquist frequency?
What does a PID controller do?
What is a normal force?
What is Colomb's Law?
What conditions are needed to change 2 sandwiched diodes into a transistor?
Explain what a conduction band is.
What is a triple point for a material?
What happens to the orbitals of atoms as they are brought closer together?
How can you make steel conduct heat better, and what are the drawbacks?
What is metal fatigue on the micro or nanoscopic level?
What is Newton's Law of Cooling?
What does the Reynolds number tell you?
What is a Carnot engine and why is it special?
What should the flow velocity be directly on a surface experiencing laminar flow?
Programmers had a higher chance of answering the few questions at the top compared to the bottom, but one thing was painfully clear: those who had learned engineering knew most of the answers, and programmers calling themselves engineers usually knew none. This particular list covers many disciplines, but this list actually covers what you'd need to know as a COMPUTER ENGINEER to pass the fundamentals of engineering exam. Computer Scientists simply do not learn an engineering background to have this kind of knowledge.
As a practicing engineer that has seen programmers severely injure people, blow up objects, and burn circuitry due to their lack of engineering knowledge, the fundamental distinction I draw between an engineer and programmer is that a programmer mostly deals with concepts and ideas entirely created by humans, where engineers are forced to understand and deal with nature itself on an everyday basis.
To clarify this point, I usually liken programmers to mathematicians: Good ones are usually scientists and have to constantly utilize the scientific method to get their job done, and their work is constantly invoked by the world on a regular basis, but generally their work routinely deals with abstractions and hierarchies, and they can do their job quite well without understanding how the physical world works. Indeed, some of the best programmers I've ever known have built amazingly efficient "engines" without ever knowing how the physical components they rely upon are designed or operate on a physical level.
I will grudingly admit that there clearly is a fuzzy line between engineer and programmer, but it falls squarely within the Computer Engineering discipline. Some of us "code" in hardware, where the chip physics is our syntax, making us much more in the engineering camp, and some of us move entirely into the machine/instruction language regime, where an understanding of the computer science of creating an abstract algorithm and less of the physics come more into play, making those of us closer to computer science. By the time you get beyond chips reading machine language, the man-made abstract meaning of the 1s and 0s are what fill your mind entirely, leaving the physics to someone else, and that science of crafting a decently run representation is called programming.
The fact that you could go on to craft entire systems using black boxes that operate as you command means that while your efforts are certainly complex and necessary, it is not engineering.
AccountKiller