Anyone looking for a Lisp/AI job in Pennsylvania?
Software Scavenger
monster.com today. You can do a search there and find it easily.
Steve Long
Software Scavenger
> Jeez, man; we're looking for Lisp jobs ANYWHERE!
For a competent programmer, who also knows some popular programming
languages, it shouldn't be hard to get a good Lisp job. First get a
job using something like C++ maintaining a large and messy legacy
application. Then rewrite the application in Lisp and show your
employer how much better it works that way. Then you have a Lisp job.
The only reason it seems hard is because most programmers who try it
do it wrong. They start off trying to convince their employer to use
Lisp, before they rewrite their employer's software in Lisp. If we
want to tell people we can fly high in the sky like a hot air balloon,
we should not just stand on the ground and say "look at us, we're full
of hot air."
Andrzej Lewandowski
Scavenger) wrote:
>Steve Long <sal...@hotmail.com> wrote in message news:<3C8A2AB5...@hotmail.com>...
>> Jeez, man; we're looking for Lisp jobs ANYWHERE!
>
>For a competent programmer, who also knows some popular programming
>languages, it shouldn't be hard to get a good Lisp job. First get a
>job using something like C++ maintaining a large and messy legacy
>application. Then rewrite the application in Lisp and show your
>employer how much better it works that way. Then you have a Lisp job.
In your dreams?...
A.L.
Thomas Bushnell, BSG
> >For a competent programmer, who also knows some popular programming
> >languages, it shouldn't be hard to get a good Lisp job. First get a
> >job using something like C++ maintaining a large and messy legacy
> >application. Then rewrite the application in Lisp and show your
> >employer how much better it works that way. Then you have a Lisp job.
>
> In your dreams?...
I've done the equivalent. Not with Lisp vs. C++. Maybe if you're in
the kind of job that requires gobs of reports and progress reviews and
charts and meetings and stuff, it can be hard to have the freedom to
get anything useful done. But there are lots of jobs that actually
reward *real* work instead of makework.
Some people really buy into the whole employer-employee relationship.
They think they have some real serious moral obligation to do whatever
the boss says....At best, one has an obligation to do what is in the
boss's real interest, even if he's clueless. I've been in that
position before.
Often people are unaware of how much leeway "doing the right thing"
can earn you. Where I worked once, I had the motto "fait accomplis
win". The point being, *doing* the task, the right way, has a
striking ability to put to rest all the arguments about how it *ought*
to be done. It's often faster than fighting the argument too.
So my advice is:
If you're in a job with any kind of freedom, that respects your
engineering ability, then do the right thing, and play politics to
keep clueless managers out of it. (Not all managers are clueless--the
one's with clue should of course be respected and their helpfulness
courted.)
If you're not in that kind of job, then get into one that is that kind
of job.
Oh, and the meta-advice is: yes, this strategy may get you fewer
dollars. Dollars are relatively unimportant, however.
Thomas
Erik Naggum
| In your dreams?...
I have done just that, except it was C--, not C++.
(If C++ is "a better C", then you know what C-- is.)
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Alain Picard
> Some people really buy into the whole employer-employee relationship.
> They think they have some real serious moral obligation to do whatever
> the boss says....
Don't be silly. You have a LEGAL obligation to do whatever
the boss says. The opposite is known as "breach of contract".
Now, if you have a pointy haired boss who doesn't
know what's good for him AND refuses to learn, you can
leave your job, but refusing to do what is officially
requested of you is NOT morally right, in _my_ book.
If the original poster is going to re-write the C++ mess
into lisp ON HIS OWN TIME, and show it to the boss, that's
great; if he does it ON COMPANY TIME, he's either
a) in a job with freedom and leeway, and showing the
company how to improve (he deserves a gold star)
b) going around the boss' back (he deserves to get fired)
You see the difference, I hope.
p.s. I've introduced Lisp into my workplace by being in
category a) above. I was VERY up-front about it.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Software Scavenger
> In your dreams?...
What happened when you tried to make that "dream" a reality? Or did
you deem it not worth trying?
Software Scavenger
> the kind of job that requires gobs of reports and progress reviews and
> charts and meetings and stuff, it can be hard to have the freedom to
> get anything useful done. But there are lots of jobs that actually
> reward *real* work instead of makework.
You don't have to be rewarded to have freedom. A makework job implies
very low productivity. Using Lisp you can get the same real
programming done hundreds or thousands of times faster. Therefore you
can rewrite your employer's software in Lisp in your spare time
easily. By simply sticking to it, keeping your version up to date,
keeping it always in sync with your employer's version, but of much
higher quality, you will find plenty of opportunities to use it as a
tool for company politics. The more makework the job is, the faster
you can advance up the corporate ladder using such a tool.
The real obstacle, for most programmers, to having a Lisp job, is
simply that they don't really care enough about Lisp, and haven't
really put in enough time to learn it and use it.
In the past I used to interview applicants for C++ jobs, and found
that most of them did not actually know C++. These people were lying
on their resumes in the hope that they could learn on the job and not
have to put in the time to learn it on their own before applying.
That attitude won't work with Lisp. Lisp rewards work, by amplifying
it. Those who only pretend to work will seem even more full of hot
air when talking about Lisp than C++.
Erik Naggum
| In the past I used to interview applicants for C++ jobs, and found that
| most of them did not actually know C++. These people were lying on their
| resumes in the hope that they could learn on the job and not have to put
| in the time to learn it on their own before applying. That attitude
| won't work with Lisp. Lisp rewards work, by amplifying it. Those who
| only pretend to work will seem even more full of hot air when talking
| about Lisp than C++.
So _this_ is the reason why Common Lisp does not win a huge market share.
It has no commercial value to lie about knowing it _and_ people can tell
that you are lying. How sad is that?
Thomas Bushnell, BSG
> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > Some people really buy into the whole employer-employee relationship.
> > They think they have some real serious moral obligation to do whatever
> > the boss says....
>
> Don't be silly. You have a LEGAL obligation to do whatever
> the boss says. The opposite is known as "breach of contract".
Hardly! I have never worked for an employer who forced me to sign a
contract that obliged me to do whatever the boss said. I probably
never would.
Steve Long
is very often chosen for you ahead of time for non-technical reasons, and
no amount of justification of an alternate solution will make a
difference. We have developed several Lisp-based design-automation
applications that will soon be replaced be the preordained solution that
will not provide the same level of functionality. Moreover, those who have
participated in creating the Lisp applications find themselves highly
experienced in a skill with little marketable [sp] worth. The arguments
for using Lisp as a development tool are sound, but sooner or later even
the most zealous advocates of the language get tired of fighting what
seems to be a hopeless battle.
sl
Software Scavenger
> At one of the last big aerospace companies in North America, the solution
> is very often chosen for you ahead of time for non-technical reasons, and
> no amount of justification of an alternate solution will make a
> difference. We have developed several Lisp-based design-automation
> applications that will soon be replaced be the preordained solution that
> will not provide the same level of functionality. Moreover, those who have
If the original applications were developed by a large corporation
using normal large corporate development processes, they probably
suck, even in Lisp. The kind of Lisp application I was talking about
would be implemented by a Lisp programmer working alone without the
overhead of design by committee etc.
In any case, most programming jobs are with smaller companies, and
those are the jobs most easily converted to Lisp jobs. In large
corporations, where a very small minority of programmers work, you
might be worth many times your salary, one of the superstar
programmers they can't do without, but you might still get laid off,
because the person making the layoff decisions might not be aware of
your superstar status. So it's probably not worth the risk to invest
any of your own time in such a company. You could start your own
company in your spare time instead. Do Lisp at home as a hobby which
might evolve into the next big "killer app" or something like that.
But my original reasoning still applies to the vast majority of good
Lisp programmers, those whose employers are companies of more ordinary
size.
Will Hartung
"Software Scavenger" <cubic...@mailandnews.com> wrote in message
news:a6789134.02031...@posting.google.com...
> You don't have to be rewarded to have freedom. A makework job implies
> very low productivity. Using Lisp you can get the same real
> programming done hundreds or thousands of times faster. Therefore you
> can rewrite your employer's software in Lisp in your spare time
> easily. By simply sticking to it, keeping your version up to date,
> keeping it always in sync with your employer's version, but of much
> higher quality, you will find plenty of opportunities to use it as a
> tool for company politics. The more makework the job is, the faster
> you can advance up the corporate ladder using such a tool.
This is very important. If the result is the desired outcome of a task,
rather than the process in creating the result, then writing tools that help
you create the result will almost always be a big win. The trick is making
sure that the tool creation doesn't interfere with the schedule for the
result.
I'm a big tool fan, and when I see some kind of task that appears to be a
long term task (e.g. several weeks), I start on the task with the back of my
mind considering how a tool can help, and then work on the tools in the lull
areas.
In the end, I have a tool automating a lot of the redundant crap and busy
work that lurk at the edges of all projects. For example, a C++ code
generator that converts a XML DTD into resulting C++ classes that self
validates the schema. A few lines of sed(1) transforms the DTD into a form
perfect for Lisp. Now, when the schema changes (as they always do in
development), a quick flick of the wrist brings me up to date. And the
deliverable is the same, C++ code. "We need to really revamp the main
schemas" "Be my guest!"
The tools are crude, stone axes of the software world, but they beat the
pointy soft wood sticks we're given to dig our ditches with.
Lisp is a fantastic language in the large with huge projects, but it's also
wonderful in the small when used to craft tiny bits that helps make the
computer a tool for my use rather having the computer use me as a simple
data input device.
Mind you, it's more that simply a scripting language. It's a philosophy.
Keeping data in forms that are easily manageable by Lisp means it is easy to
convert those forms into pretty much anything else. It's easier to do
wholesale changes that you can't easily do with a global search and replace.
GS&R can't take semantics into account. It's hard to reorganize data with
GS&R. All this it pretty simple to do with Lisp expressions. Writing a rough
Lisp->C++ translator is maybe a days work. How long would it take to go the
other way around?
Regards,
Will Hartung
(vft...@cox.net)
Steve Long
Software Scavenger wrote:
> Steve Long <sal...@hotmail.com> wrote in message news:<3C8CD62...@hotmail.com>...
> > At one of the last big aerospace companies in North America, the solution
> > is very often chosen for you ahead of time for non-technical reasons, and
> > no amount of justification of an alternate solution will make a
> > difference. We have developed several Lisp-based design-automation
> > applications that will soon be replaced be the preordained solution that
> > will not provide the same level of functionality. Moreover, those who have
>
> If the original applications were developed by a large corporation
> using normal large corporate development processes, they probably
> suck, even in Lisp. The kind of Lisp application I was talking about
> would be implemented by a Lisp programmer working alone without the
> overhead of design by committee etc.
You don't know that. In fact, much of the software we've been doing lately is better
because it was created in an organization that could afford the time for us to use a
systematic development process in lieu of a cowboy-programming style which has many
advantages in a very small group but doesn't scale to large projects needing some sort of
discipline in order to maintain the application(s) through the entire project life-cycle.
You design by committee whenever you have a customer.
One other reason that individuals, teams, or companies don't move to Lisp is the cost of
buying yet another programming package. I certainly cannot afford to buy my own copy of
ACL or its equivalent if I don't know that a customer will buy into the idea of a
Lisp-based solution.
SLong
Greg Menke
> >
> > If the original applications were developed by a large corporation
> > using normal large corporate development processes, they probably
> > suck, even in Lisp. The kind of Lisp application I was talking about
> > would be implemented by a Lisp programmer working alone without the
> > overhead of design by committee etc.
>
> You don't know that. In fact, much of the software we've been doing lately is better
> because it was created in an organization that could afford the time for us to use a
> systematic development process in lieu of a cowboy-programming style which has many
> advantages in a very small group but doesn't scale to large projects needing some sort of
> discipline in order to maintain the application(s) through the entire project life-cycle.
Oh software built that way will almost certainly suck too, but perhaps
from the rigidity and dogmatism which frequently pervades systematic
development processes. After all, any code that uses 4 spaces to
indent instead of the Blessed & Canonical 3 spaces must be suspect.
Even so, I will agree that consistency and an actual relationship to a
meaningful design can sometimes also be present.
> You design by committee whenever you have a customer.
Or when you have sufficient budget, time & political flexibility to
allow the questions to arise.
> One other reason that individuals, teams, or companies don't move to Lisp is the cost of
> buying yet another programming package. I certainly cannot afford to buy my own copy of
> ACL or its equivalent if I don't know that a customer will buy into the idea of a
> Lisp-based solution.
If its a question of team & company, the reasons are probably more of
a religious nature than anything particularly associated with cost to
the developer or the user. Rational Rose & UML seem to be the current
theology of the well-heeled, I'm sure the next one will also be
interesting to observe. With respect to the individual, I imagine
Harvard's Law will hold as well as most others. With respect to a
customer, it just depends.
Gregm
Alain Picard
> I don't know that a customer will buy into the idea of a Lisp-based
> solution.
Interesting. My customers don't seem to care in the slightest,
they just want something that solves their problems.
> You design by committee whenever you have a customer.
Do you mean, when the software is being constructed for
precisely ONE customer? In that case, I might agree; and
the reason you do so is to protect yourself in a contractual
situation. i.e. "See, you SAID you wanted X, even though we
know/told you X was going to be useless", etc etc.
In that situation, you design by comittee even though you know it
sucks and doesn't produce good software.
Is that what you meant?
Tim Bradshaw
> At one of the last big aerospace companies in North America, the solution
> is very often chosen for you ahead of time for non-technical reasons, and
> no amount of justification of an alternate solution will make a
> difference. We have developed several Lisp-based design-automation
> applications that will soon be replaced be the preordained solution that
> will not provide the same level of functionality.
Might this kind of thing be related to the fact that there are less
aerospace companies than there were, and the remaining ones seem to
live mostly on government handouts to keep them alive so they can
produce the required military aircraft?
--tim
Eric Moss
> One other reason that individuals, teams, or companies don't move to Lisp
> is the cost of buying yet another programming package. I certainly
> cannot afford to buy my own copy of ACL or its equivalent if I don't know
> that a customer will buy into the idea of a Lisp-based solution.
Here's a dumb question, esp. since I've seen the same phenomenon--why does
the customer care what something is written in unless they are directly
maintaining it? Most customers don't know anything and therefore make
ridiculous technical decisions. That doesn't mean they don't try to tell
the experts how to program, but it's still a seemingly irrational thing to
do. I must assume it's something about "safety in numbers".
Eric
Coby Beck
"Eric Moss" <eric...@alltel.net> wrote in message
news:86sn715...@kirk.localdomain...
It is absolutely a (feeling of) safety issue. People fear what they don't
understand. If you add that with distrust or feeling insecure about your
software contractor it is natural to look for something to cling too, some
way to feel like you are making a good decision. So faced with the choice
between someone using unusual technology or methods and some MS
certified(tm) they choose MS certified. "If your unusual technology is so
good, why isn't everyone else using it?" Going with the pack gives people a
false sense of security and allows them a feeling of having saved face if
there is a failure. "At least I'm not the only who went down that road"
Humans are a herd^H^H^H^H social animal.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Software Scavenger
> between someone using unusual technology or methods and some MS
> certified(tm) they choose MS certified. "If your unusual technology is so
> good, why isn't everyone else using it?" Going with the pack gives people a
One possible solution would be to use proprietary technology instead
of unusual technology. It's easy to build your own proprietary
programming language on top of Common Lisp. Using your proprietary
technology gives you a big advantage in quality and speed of
development vs the herd. The herd doesn't use yours because it's
proprietary, and is how you stay ahead of them.
Frank A. Adrian
> Rational Rose & UML seem to be the current
> theology of the well-heeled, I'm sure the next one will also be
> interesting to observe.
UML may well bee the "end of history" WRT modeling methodologies (at least
for another ten or so years :-). This is because new Large Scale
Devlopment Oriented (LSDO - I get first brag rights on this new acronym :-)
languages and systems, like C# and .NET are not being very "adventurous" in
their conception of system modeled objects, their control, or their
interactions Until someone brings forth a language that cannot be modeled
well in UML and that gains a significant market share, there is no reason
for the herd to move away from UML - it describes what's out there quite
adequately. It's sorta like flow charts were in the 60/70's until SASD
came along, and SASD and DFD's were in the 70/80's until UML came along -
until someone boings up another level, no one has impetus to change. This
is a shame because stasis is death.
Functional languages might be able to do provide such systems/languages but
I'm holding out for good multi-paradigmatic languages. Luckily, Lisp fits
this bill well...
faa
Andrzej Lewandowski
Scavenger) wrote:
In your basement?...
A.L.
Matt Curtin
> Then rewrite the application in Lisp and show your employer how much
> better it works that way. Then you have a Lisp job.
I believe that Erik Naggum titled this the Nike approach to Lisp
programming.
No Excuses. No Apologies. Just do it.
--
Matt Curtin, Founder Interhack Corporation http://web.interhack.com/
Author, Developing Trust: Online Privacy and Security (Apress, 2001)
Knight, Lambda Calculus | Certum quod factum. --Giovanni Battista Vico
Eric Moss
Not to pee in the punch bowl, but...
I would agree, except for the "no excuses" part. There are so many
institutional barriers set up to prevent just this kind of thing--at least
in big companies where the lone programmer with lisp could do something
good.
For example, just TRY to get a bank to put Lisp on any machine or to let
you take any work home they might consider proprietary. It's hard to get
institutional IT groups to install a new version of Perl, or even fix the
one they screwed up the first time.
Not even those trusted to have no imagination get root privileges on their
own machine. So any guerillia action is a non-starter.
In a small group situation, if one has enough time and the project is tractable
for a solo effort, then by all means "just do it". At least that's the
only chance you will likely have of getting to try.
Eric
Nils Goesche
> >No Excuses. No Apologies. Just do it.
>
> Not to pee in the punch bowl, but...
>
> I would agree, except for the "no excuses" part. There are so many
> institutional barriers set up to prevent just this kind of thing--at least
> in big companies where the lone programmer with lisp could do something
> good.
What are they going to do against it?
> For example, just TRY to get a bank to put Lisp on any machine or to let
> you take any work home they might consider proprietary. It's hard to get
> institutional IT groups to install a new version of Perl, or even fix the
> one they screwed up the first time.
So put it on the machine you are working on every day, without
asking anyone. Or have you /still/ not figured out its root
password? :-)
> Not even those trusted to have no imagination get root
> privileges on their own machine. So any guerillia action is a
> non-starter.
Hm?
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
Alain Picard
>
> For example, just TRY to get a bank to put Lisp on any machine or to let
> you take any work home they might consider proprietary.
Those are what I call "zero hope" environments; the only winning
move is not to play. You realize your mistake and start looking
for a better job.
Software Scavenger
> Not even those trusted to have no imagination get root privileges on their
> own machine. So any guerillia action is a non-starter.
I know exactly the kind of situation you're talking about. It took me
months to get the root password to my own machine in that kind of
situation. It takes a lot of patience and careful playing of company
politics. I would have left that company as soon as I found out how
hard it was going to be, except that they had paid my relocation and a
startup bonus and I had agreed to stay at least a year.
But in any case that's a very small minority of programming jobs.
Most programmers do not have that kind of problem, so that excuse
doesn't apply to them. And even those that do have such problems can
find plenty of ways to work around them if they really want to.
"No excuses" doesn't mean there aren't any excuses. It just means
none of them are going to stop us.
If all else fails, a good programmer can always find a better job,
where it won't be as hard to get started converting it to a Lisp job.
Eric Moss
> you take any work home they might consider proprietary.
So put it on the machine you are working on every day, without
asking anyone. Or have you /still/ not figured out its root
password? :-)
I never even tried--it was considered a firing offense. :(
It's great that everyone here is a great hacker (in the subversive sense),
but when you get told "you will be fired if you subvert the security
measures on this machine", it's just not a workable solution. Can they
catch me? I don't know, but getting fired for breaching security, and
losing 401(k) vestings is too much of a punishment to risk.
I said "Not to pee in the punchbowl, but..." to indicate that I think it's
great if people *can* get root and do "the right thing" and so on.
However, it would be a mistake to think that everyone can and will and
*should* risk it.
I have seen this discussion before. Someone asks "how can we get into
the corporate world?" Someone else says "Stop whining--just do it",
thinking that will work for everyone. It will not, and short-circuits
meaningful discussion about what could be used as ammo in a corporate
environment.
(end peeing)
Eric
Eric Moss
programmers can escape the corporate "lockdown" mentality.
Eric
Erik Naggum
| It's great that everyone here is a great hacker (in the subversive
| sense), but when you get told "you will be fired if you subvert the
| security measures on this machine", it's just not a workable solution.
| Can they catch me? I don't know, but getting fired for breaching
| security, and losing 401(k) vestings is too much of a punishment to risk.
I think you misunderstand the mood here. Only one person has argued that
one should disobey direct orders and defraud their bosses, but that is
not what this is about. This is about proving that something you would
like to do but need experience with before you can get permission to do
it officially. If phrased properly, you will get permission to do this
in any environment.
| I said "Not to pee in the punchbowl, but..." to indicate that I think
| it's great if people *can* get root and do "the right thing" and so on.
| However, it would be a mistake to think that everyone can and will and
| *should* risk it.
I think you take this "risk" out of thin air. Nobody has asked you to
_risk_ anything like you think, but if you are good at what you do, and
you work in a reasonable place, competence will be rewarded with trust.
If you are not trusted to be constructive in your creativity and have the
company's best interests at heart, not being able to use Common Lisp is
such a minor problem.
| I have seen this discussion before. Someone asks "how can we get into
| the corporate world?" Someone else says "Stop whining--just do it",
| thinking that will work for everyone. It will not, and short-circuits
| meaningful discussion about what could be used as ammo in a corporate
| environment.
Please, if you think "just do it" means violate your current trust, you
have precluded yourself from understanding and appreciating the options
that lie before you.
However, if you are in a position that only involves coding and you think
you will not be promoted, a promotion is usually only given to people who
show initiative and the ability to make decisions and take risks within
the framework of the company's structure.
Please realize that using or investigating to use a different programming
language is a managerial decision. You have to maneuver yourself into a
managerial position to make such a decision. This is impossible if you
just sit on your ass and think you have no chance of such a position.
I have always read "just do it" to be a self-esteem-boosting "mantra", a
"take charge" attitude. If you think it means to do something _without_
the self-esteem, breaking the law or violating somebody's trust or taking
a destructive risk simply follows from the premises. But you cannot ask
someone who does not even trust himself to "just do it", because what
they will do is not good for _anyone_.
Erik Naggum
| I agree mostly--the only caveat being that as companies merge, fewer
| programmers can escape the corporate "lockdown" mentality.
Mentalities are all in your head. You must accept responsibility for your
own mentality before you can ever hope to change it.
Marc Battyani
> For example, just TRY to get a bank to put Lisp on any machine or to let
It's possible. I've recently done a Lisp web service + web application for a
(big) bank.
Marc
Nils Goesche
> * Eric Moss
>| It's great that everyone here is a great hacker (in the subversive
>| sense), but when you get told "you will be fired if you subvert the
>| security measures on this machine", it's just not a workable solution.
>| Can they catch me? I don't know, but getting fired for breaching
>| security, and losing 401(k) vestings is too much of a punishment to risk.
>
> I think you misunderstand the mood here. Only one person has argued that
> one should disobey direct orders and defraud their bosses, but that is
> not what this is about.
Hehe, if you put it that way it sounds as if I had suggested doing
something criminal. That was not my intention. Every company defines
for itself what's regarded as criminal in that company and what not.
In the companies I have worked at so far, doing something criminal
means doing something that's bad for the company. Everybody is
expected to do whatever is best for the company, but rules are not so
important. Rules come and go, from lots of different people on lots
of different levels, for many rules you'll find another one directly
contradicting it. When a worker sees a way to do his work better,
he is expected to do so, even if it means breaking a rule, without
bothering his manager. Installing a program without permission would
be fine, unless you indeed compromise the corporate's network security.
Then you have screwed up, and are likely to be fired. But as long
as you deliver the work you are ordered to do, nobody cares what you
do else.
That's how I know it. I have heard that there are companies
where this is viewed differently, but never seen one from inside.
Can't say I regret it :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Erik Naggum
| Hehe, if you put it that way it sounds as if I had suggested doing
| something criminal. That was not my intention.
That is the second time you think I was referring to you when I was not.
If I were, I would refer to you buy name -- I have no compulsions about
such things ordinarily, but when a particularly hostile jerk has spent a
large number of messages attacking me out of the blue, I do not want to
give him the opportunity to think he is "defending himself" when I bring
up something he has done.
| Every company defines for itself what's regarded as criminal in that
| company and what not.
Actually, this is not so. "Criminal offences" are defined by your
country's government, not your company's. Violations of many other kinds
are subject to company regulations, but your government may well have
made it criminal to consider some such regulation criminal.
| But as long as you deliver the work you are ordered to do, nobody cares
| what you do else.
Precisely. And if your managers do not trust you to do this, why did
they hire you in the first place, and why did you start working there?
This always puzzles me about people who complain about insane bosses and
hating their sucky jobs. I tend to think someone is trying to blame
someone else for their own decisions.
Nils Goesche
> * Nils Goesche <car...@cartan.de>
>| Hehe, if you put it that way it sounds as if I had suggested doing
>| something criminal. That was not my intention.
>
> That is the second time you think I was referring to you when I was not.
> If I were, I would refer to you buy name
Aargh, seems there is a little paranoia bug I gotta fix here. Deal: This
won't happen again.
>| Every company defines for itself what's regarded as criminal in that
>| company and what not.
>
> Actually, this is not so. "Criminal offences" are defined by your
> country's government, not your company's. Violations of many other kinds
> are subject to company regulations, but your government may well have
> made it criminal to consider some such regulation criminal.
I agree; although you frequently see news pictures of managers of new
economy firms in courtrooms who seemed to have quite a different view
on that :-)
>| But as long as you deliver the work you are ordered to do, nobody cares
>| what you do else.
>
> Precisely. And if your managers do not trust you to do this, why did
> they hire you in the first place, and why did you start working there?
> This always puzzles me about people who complain about insane bosses and
> hating their sucky jobs. I tend to think someone is trying to blame
> someone else for their own decisions.
True. But then - people do make mistakes. And when you already are
in such a company and would lose a lot of money if you left, I can
see the dilemma...
Thomas Bushnell, BSG
> It's great that everyone here is a great hacker (in the subversive sense),
> but when you get told "you will be fired if you subvert the security
> measures on this machine", it's just not a workable solution. Can they
> catch me? I don't know, but getting fired for breaching security, and
> losing 401(k) vestings is too much of a punishment to risk.
My response to such employers is "you want me to work for you? Get
real!"
thomas
Eric Moss
>real!"
Good philosophy. I agree. It's too bad they weren't up-front about how
they would really act. During interviews it was all "We support
innovation. We are going to 'do things right'. We're <blah blah blah>."
I was even told "We're going to experiment with lisp." by the one who ended
up my supervisor.
After I left I found out that at least one person there was *not* allowed
to interview me alone for fear he would be honest with me. I guess there's
not much defense (besides the talent to leave on the spot) when everything
is a lie.
I *hope* we can all (myself included) treat this as a statistical outlier
that is vanishingly rare.
Yeah, right but we can *try*, can't we? ;)
Eric
Erik Naggum
| Good philosophy. I agree. It's too bad they weren't up-front about how
| they would really act. During interviews it was all "We support
| innovation. We are going to 'do things right'. We're <blah blah blah>."
| I was even told "We're going to experiment with lisp." by the one who
| ended up my supervisor.
Well, it is basic self-protection to ask for such promises in writing.
People tend to be a lot more honest when they have to write things down,
for the simple reason that you present a credible threat to the them if
you have that document and you challenge them later on. There is no such
credible threat if you only have someone's spoken word. Some people are
not really big on honesty unless they can be seriously hurt if they are
dishonest -- and even then they calculate their losses. You need to hone
your skills in detecting such people if you have been hurt by them, not
think they are the kind that runs the world and give up, which it sounds
like you believe.
| I *hope* we can all (myself included) treat this as a statistical outlier
| that is vanishingly rare.
If you cannot defend yourself against bad people, you are an easy mark.
If you think somebody "should not do that to me", you have already lost
and will be screwed again and again. Bad people exist. Good people need
to identify them, prevent them from causing (more) harm, and be prepared
to defend themselves when they try. This is not taught by "turn the
other cheek", but there are ways to avoid getting slapped on both cheeks.