Managing Einsteins 345
Managing Einsteins: Leading High-Tech Workers in the Digital Age | |
author | Dr. John M. Ivancevich and Dr. Thomas N. Duening |
pages | 249 |
publisher | McGraw-Hill |
rating | 7 |
reviewer | grumpy |
ISBN | 0-07-137500-7 |
summary | Good information for managers of IT workers |
This book doesn't use terms like "nerd" or "geek" to describe IT workers: the authors hold that the stereotype of pocket protectors and coke-bottle glasses just doesn't fit any more. This is a book written for managers, and so the terminology and style (almost) always refers to Einsteins as "your workers," to the point that with the summary at the end states:
Referring to super-intelligent, curious, passionate, often introverted, talented individuals as "geeks" is outdated. Although Einsteins can call colleagues "geeks," it is not appropriate or cool for non-Einsteins to refer to computer, technology, systems or software geniuses as geeks. (page 217)
These are the difficult to work with, yet life-saving employees who can come up with answers when most people don't understand the question.
Several themes run through the book, so it can be summarised in a few simple statements. Many of which (to Einsteins) may seem pretty obvious. The book is written by "Management Professionals," though, so there's hope that managers may actually accept some of its wisdom.
The book is divided into three parts:
- Realities of the Twenty-First Century - a brief summary covers the basic themes of the book and introduces the concept of an Einstein, the nature of Einsteins and how they fit into the work environment and the world.
- Managing Einsteins: Challenges and Actions - this section, the bulk of the book, covers everything from recruiting Einsteins through to managing them on a daily basis, by paying attention to communication, teams and tribes, remuneration, etiquette and discipline.
- Building for the Future - includes humour and fun at work, telecommuting and a final summary.
The book describes IT workers as highly motivated, intelligent (often more intelligent than their managers), introverted, tribal and independent.
The mains themes throughout the book are:
- Managers should be honest with their workers about the company's successes and failures
- The point of management is to guide and suggest not to be autocratic (the metaphor of herding cats was used to illustrate this)
- Let the Einsteins have freedom in work environment (location - there is a whole chapter on telecommuting, hours and style)
- Einsteins are project-focused, not job-focused
- They value training and education highly
- They require a stimulating and fun work place.
The issue of remuneration is covered -- and expanded to include the idea that Einsteins are not solely motivated by money (as sales people may be), and that other considerations should be taken into account (such as training, location, work conditions). Also that the traditional notion of promotion does not always work. An Einstein may not want to become a team leader, or move any higher in the management hierarchy. A manager should be wary of their Einsteins burning out, a temporary demotion or other measure may be in order to take the stress off an Einstein for a while.
The book includes short examples and case studies from various workplaces, and excerpts from newspapers and trade journals to help illustrate points. There are also highlighted points categorised as "Influence Tips," "Black Holes" and "Einstein Wisdom." which emphasise important things, such as:
Managers should be very cautious not to introduce projects that have a low likelihood of getting started. Einsteins abhor routine and crave novel projects. But they abhor being misled and crave honest leadership all the more. In staff meetings, when managers talk about upcoming projects, they should attach a probability of launch along with the projected launch date. The common term for this is "managing expectations." (page 70)
One good description of the nature of how Einsteins work is the concept of flow.
Flow is reported by individuals as a satisfying state they reach when they are completely absorbed in challenging yet achievable projects. (page 54)
Flow is an important concept for managers to understand. Once an Einstein starts a project, and becomes fully involved, there is nothing worse than being pulled off to attend a sales meeting, or other time consuming function. It interrupts the flow.
One pitfall: the book seems to have been started before the tech slump of 2000-2001 really started to dig in. So the book wavers between promoting how IT workers are highly mobile, but also that the job market is not that strong.
The other major shortcoming is the chapter on Etiquette and Manners. Now, I can understand the mannerisms and habits of Einsteins can be a little unpleasant at times, but it begs the question, why would a manager take one of these people out to a client dinner in the first place? If the client needs to meet the tech people to be convinced that a company can do the job, why not at the place of work? Or, take an Einstein who you know you can trust to behave and present well.
As this is the only book at the moment that deals directly with managing this class of workers, also get your manager to read Jon Katz's Geeks. Managing people is no longer about direct, micro-management or process line working. The nature of work has changed with the influence of new technology and so a new way of managing people should also be introduced. These books together will help management, or anyone, understand the mind set and working modes of IT workers.
You can purchase Managing Einsteins from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
4 Posts in one! (Score:5, Insightful)
Important point (Score:5, Insightful)
In a department I used to work for, the best programmer is now riding herd on all the programmers. He's a great coder but not a great manager. But, the culture is that you have to keep getting promoted or there must be something wrong with you so up the ladder he went.
Now, when he fails as a manager what happens? He can't really go back to being a coder - too much like a demotion.
The root of the problem is the concept of a salary range for a given job. People can't get a raise because they are max'd out for their job. Want to make more? Leave the job you're good at and move to management. It ain't right but that's the way it is.
Elitism, oh so tasty (Score:2, Insightful)
There was nothing that was targetted specifically at said employee subset. Not a thing was said that wouldn't apply to every employee.
On the plus side, this book doesn't even have to be read to be helpful. This book is a standard management text with the marketing built into the title of the book and nowhere else.
Re:What tech workers want? (Score:3, Insightful)
All I ask from my manager: (Score:5, Insightful)
Training and Education? (Score:2, Insightful)
While I can agree with some of the themes, I generally view training and education as worthless most times. I'd much rather have a piece of software dropped in front of me and give me 2 days to play with it than go off to some training course somewhere else to have it explained to me like I'm a toddler.
Am I the only one?
Re:Disgusting arrogance (Score:2, Insightful)
It's like karma-whoring on
They only listen to each other (Score:3, Insightful)
Managment types don't listen to geeks. If they did, we wouldn't need books like this in the first place.
the best managers (Score:3, Insightful)
Just because you _can_ doesn't mean you _wanna_ (Score:4, Insightful)
I dont think you'll find many construction workers that like to build useless buildings (where the mgmt. in this scenario would cry, "Why not! You're building stuff! You're a builder!". In my mind, management tends to ignore the social aspects of project planning. I always like to say that I could write a scalable distributed inventory management solution in binary, if I really had to, but because of how utterly soul sucking and unfun that would be, I promise no matter how self-disciplined I might be, it will suck. Simply because I won't believe in _what_ I'm building, and thus my work will reflect that.
Management needs to do a better job of understanding why programmers and techies often seem to resentful when being assigned projects - as the
Now, much of the IT industry is about spurring people against their will using rewards such as high salaries and job perks (nerf guns anyone?) to entice them to building things that businesses want. Programmers and techies can spot and sniff the 'empty promises' in technology (and there are tons), and it is a sign of bad management that ignores those types of hesitations and flies on the basis of what is 'techically possible' alone.
What about reverse? (Score:5, Insightful)
Where's the book "Working for PHBs"? Seriously, isn't that the other half of the problem? The word "Einstein" is used derisively, I think, to say IT workers are arrogant asses that assume all those above and around them are idiots. So, "Managing Einsteins" would be a book about appeasing these Einsteins while getting them to do what you want (e.g. herding cats).
On the other hand, the Einsteins derisively refer to management as PHBs because they don't completely understand technical issues and make decisions on loose technical-ground. Sure, we could blow this issue off as management being stupid, or we can learn, for example, how better to comminucate the issues so the PHBs can make better decisions. It might also enlighten us to the fact there is more to a decision than just the technical side, such as marketing, customer acceptance, product portfolio, etc.
Bottom line, its two different cultures. To get them to work together requires efforts and respect on both sides.
Only IT workers? (Score:4, Insightful)
1)Patents. The company gets a patent with the Engineer's name on it.
2)Money. Our new ideas could potentially save tooling costs, material, or cycle time, all of which means we can save our customer money, and make more money.
Slashdot may be "News for Nerds", but I think people need to be reminded that all nerds aren't computer nerds
just an opinion
Those who read it area already clued in (Score:5, Insightful)
Most managers, however, are not necessarily trying to become better managers. In organizations both large and small, management training often consists of a 30-minute exit interview with the person you're replacing (if you're lucky).
Someone's a good accountant? Make them head of accounting. Got a really kick-ass salesperson? Make her head of sales. One of your Java programmers knows more than the rest of the team? Make him your CTO. After being promoted to such a position, with no real leadership training, how could you not assume that you're just a natural born leader?
Unfortunately this approach just doesn't work. Cultivating leadership in any organization is difficult, time-consuming, and doesn't offer immediate dollars-and-cents results that the bean-counters can quantify. The fact that there is so much literature on leadership shows the very real dearth of good organizational leadership training in the corporate world.
The managers who read this book are likely improving their management skills, but they're not the ones who need to read it. Unfortunately, the ones who do need to read such books never will, because they know they've already got that "management thing" all figured out.
Managing technical people (Score:5, Insightful)
1) Treat people the way you want to be treated. Nobody likes working for a taskmaster or driven to the point of burnout. Treat people (especially people you are responsible for!) with respect and they in turn will respect you and the organization.
2) Make goals, plans, project, expectations, etc clear. Vague, mushy, "changing target, shifting paradigm BS" does not encourage or motivate people.
3) Be flexible in what you do and your people will be as well. If you want someone to fix something at 2 AM, offer them the opportunity to work business hours from home, or from another suitable remote location on a regular basis.
4) Train, educate, teach. Send people to offsite classes. Buy them books and software if they request it. Subscribe to magazines and journals. Send people to conferences and conventions. Invest in your people and they will bring back knowledge and stay for more. If you are worried that CCNA you just paid for will leave after certification than you either hired the wrong person or you have a crappy workplace. Good people stay at good places for more good training and investment.
5) Be honest. If things are bad at the company and there will be layoffs or bancruptcy, let your people know as soon and with as much information as soon as possible. People have mortgages, families, bills. Show some respect.
6) Remember personal lives. Tech workers are no different than other people. What we have all found out in the past few years is that tech workers don't want to sleep under their desks for 10 years. Send them home. Let them spend uninterrupted time with friends, family, and other non-work beings.
7) Free cokes, toys, games, and other fluff is just that - fluff. In today's "Enroned", recessionary times, people want stability, reliability and honesty more than a foozeball table, rollerblade court and hiking trips. Tech workers (for that matter all workers) should not have to worry if paychecks will bounce or be non-existant, if their 401k or pension scheme is solvent, or if their payroll taxes are being filed correctly.
8) Finally, have technical people with leadership qualities lead. I was a sysadmin and network admin before being tapped for a management role. I understand what my people are talking about from experience, not from a book or training class.
Just some thoughts from the last few years. All lessons learned from experience.
Re:I'll tell you how to keep us happy (Score:5, Insightful)
I don't want free sodas at work (I do like the subsidised canteen to be decent quality though), I don't want junk food, I don't want trash all over cubicle, I don't obsess about [Monty Python|Star Wars|LoTR], I don't want to fire Nerf Guns at fellow employees - I want to be treated like a mature professional doing a professional job.
I want money not some novelties scattered around the room. I want a quiet office, not a playpen. I agree that I want to know when the business is on the slide. I want influence and respect from people in suits. I want to be understood when I talk at project meetings. I want an understanding in the manager's head of why what I'm telling matters.
Tricking out your cubicle with action figures etc is just begging to be treated like a child. No wonder your boss seems like the PHB; to him/her you probably seem like a child. Or worse, a social misfit, a weirdo. Someone who's useful but fundementally unreliable.
Secondly, I don't see much "geek attitude" or reviews of Episode II trailers in mainstream trade journals (Dr Dobbs, Appication Development Advisor, Software Development) or in more seriously coding forums. In my experience, and I know this is pressing buttons, those who most loudly beg for ping-pong tables in work are those with the most inflated egos and least developed skills. Lets face it
Don't lie to me about deadlines (Score:5, Insightful)
If you say "I absolutely have to have this by such-and-such a date," I'll sacrifice my mind and body to make the deadline.
But if I turn my work in and discover that you weren't serious about the deadline, it'll be a cold day in hell before I do it for you again.
It's relative (Score:3, Insightful)
In reality, your manager may be just as smart as you, or even smarter. But because of the technical nature of our work, we often get the "witch doctor" mystique to go with the job. That's useful, because it can give us the leeway we need to get the job done.
Don't abuse it.
Re:Einsteins defined (Score:2, Insightful)
Need a raise? (Score:5, Insightful)
Where I work, junior developers work with senior developers on a project. Both groups get their timesheets signed by and assignments from the tech lead, who is a programmer. The tech leads report directly to the president of the company. Project managers exist, but as a support function (and they earn their keep by shielding developers from the customer). Our R&D team spends about 8 hours a week writing proposals (on average). For a 50 person company, this seems to work.
That said, I feel obligated to point out that we didn't build this hierarchy first. We had a director of development who was a micromanaging PHB. We had a CTO who did absolutely nothing. That was our analogy to the promoted programmer you had. First he was promoted to Director of Development, but he sucked. So they promoted him to CTO. Then he sucked. The DoD they replaced him with was terrible. Now the DoD is gone, and the CTO is a developer again (at the same CTO salary), but because he was out of the loop for too long, we have him writing VBA in MS Excel. Aside from the fact that a programmer who is effectively a junior developer is making more than the tech leads, we seem to have reached a nice equilibrium.
Re:All I ask from my manager: (Score:4, Insightful)
"What do you want from your manager"
The actual answer to this question is not all that important. What is important is that the answer is not a cliche (that what they want is something that the candidate _will_ be able to get from the person in my organisation who will manage them) and most of all, it must show that they have some idea of what a manager does that helps them.
In other words, if someone cannot see something of value in the role of their manger then they will be difficult to manage, geek, einstein or asshole. The "value" that shows the most insight is the filtering of the mundane (or inconvenient)so that they can get on with the "work", whilst accurately reporting progress to cheque signers.
$0.02
how managers control einsteins in real life (Score:1, Insightful)
1) Massage the ego. Vanity is definitely my favorite sin. Nothing gets that brain beating like a little ego masturbation
2) Give him a title and "responsibility". Call him Chief Technical Officer or "Lead Architect". Give him a list of "new" responsibilities.
3) Never let them feel successful. Always (gently)remind them of flaws and problems. This works together with one, you want to make them feel intelligent, but ineffectual all at once.
4) Remind them when they get angry, that "it's like this everywhere".
5) Divide and conquer. This is extremely important. When you have one great architect, you need two. Fighting each other for power and fame, they will do your job for you.
---
Now, some may say I sound bitter, I am. But these lessons are the Absolute Thruth. They work absolutely. With the sick power I have wielded, I really have been successful. But there is still good in me, the dark side has not yet taken me.
Throw off your pride, and vanity. Remember that no matter how great you can code, make circuits, design XYZ that you are making SOME ONE ELSE wealthy. Your lifes work, your genius, your dreams and creations are not yours, they belong to your company. Remember that no matter how smart you are, you can be replaced and your ideas taken.
Who's the F***ing genius, really?
being smart != better person (Score:1, Insightful)
Woop dee doo doo! Being smart, dumb, fat, skinny, tall or short all have good and bad sides. In the end, when you're burried six feet under, the only thing that freakin matters is how did you live your life? Were you a selfish bastard, or were you a kind and caring. Everything else is freaking BS.
Re:Important point (Score:3, Insightful)
I know a great way to manage "prima dona"s (Score:5, Insightful)
Or don't hire them to begin with and instead hire a compitent engineer or two who can can stick to the most important schedule. The managers.
As rude as I may come off. Einsteins or whatever you want to call them are NOT dependable. They do what the want, when they want, and how they want. Most of the ones I've had the displeasure of meeting are so self absorbed and into self-gratification so much that it makes working TOGETHER AS A GROUP with them in a structured development environment unbearable. They often work ALONE and the work that they do which others depend on go by their clock, not the companys.
The few I've had to work with whom are considered "oracles" did not have the ego tripping the others and could work well with groups but alas their communication skills where lacking. While they could do anything you asked them to. Ask them to describe something acute to you that would normally take a few moments and you could end up being there 15x longer than expected. OMG forget about meetings.
While the later I can bear and bridge the communication gap to achieve OUR goals because it is worthwhile. The former can take a hike. There is nothing any compitent engineer cannot accomplish given a reasonable amount of time and resources. The rest are wildcards which begs the question. Would you bet money on that schedule or better yet, your job?
Peter
Mutual Respect is Needed (Score:2, Insightful)
That's the problem. The solution is to have your managers be tech people. A lot of tech people are not giong to make good managers due to lack of leadership ability, social skills, etc. However, some tech people will make good managers. Also, teams should be 4-5 people at most, with one of the team members managing the project. That is, the person managing the project should still be writing code.
One other thing I've noticed
When I run the world, things will be different
Re:What tech workers want? (Score:1, Insightful)
'Tis a breath of fresh air to see a comment that is actually Insightful and Interesting on this message board.
This is an old problem, IT is just a new context (Score:5, Insightful)
Intellectual egos have long been extant - look at Rutherford. I'd be doomed if I worked anywhere near him! We have tons of experienced, genuinely brilliant PhDs in our organization, and they range from the pleasant humble mannerism of Einstein to the brash obnoxiousness of Rutherford. Yet as a member of the management community, I need to help drive all these folks towards common goals while sharing the same resources and space. Sure it's not easy, but I think the right route to address this for IT folks is similar to what we do in science. Waving my magic wand, I'd make these recommendations for what most IT related workplaces need to learn:
1) Management and promotions are two different things.
2) Managers DON'T have to make more than those they manage.
3) You cannot and should not treat everyone 'equally'.
4) There are others, but I'm lazy
To be more verbose (okay, really verbose):
1) Management and promotions are two different things.
We have three career tracks in our R&D community - Technical, Project management, and Leadership (an aside - being a leader and being a manager are two very different things - there's overlap but not anywhere near as much as most companies treat the roles and everyone uses the words interchangeably - but we shouldn't. I feel my own company falls short on this one).
-Technical is just that - at the top of the game, you're one of the world's authorities on Boise-Einstein-Pies, and get both recognized (and compensated) as such. You're encouraged to educate yourself to stay that way.
-If you move up the project management chain, you may coordinate projects across divisions involving dozens if not hundreds of people to pull a program together, basically exercising responsibility with no direct authority over the managers - this involves a lot of leadership skill.
-Finally, the 'leadership' track is the classic managerial path that leads towards the corporate management food chain and business practices. Note that this take you OUT of that techie/science chain if you go far enough up. Setting aside the discussion of overcompensated CEOs, each of these paths can bring both strong job satisfaction in the role and financial recognition, INDEPENDANT of the actual managerial structure.
2) Managers DON'T have to make more than those they manage - I certainly don't make more than some of the folks on my crew, and I shouldn't. They're more skilled technically, they have much more experience, and they have far more education. A lot of companies seem to have some problem with this, and that really prevents them from focusing on the right skillsets for a given job.
3) In our litigious society we're encouraged to apply the same rigid standard to everyone - unless they fall into a large collection of legal categories. As a result, it takes a little more courage to publicly say 'sure, you can always have Friday afternoons off with comp time' without offering it to everyone. Or giving very different pay raises to people based on the work that they've done, and then explaining to someone why they've gotten a below average raise. Some people can be very self sufficient, and others need a great deal of guidance. This means different people need different tool (one needs a PDA while the other needs some 3x5 cards and a crayon (ala CoyboyNeal)). Companies need to foster an environment where petty bickering (usually through envy or jealousy) isn't an issue. In the above example, if someone's upset because someone has a PDA, it's usually not because they want a PDA, it's because they want some form of recognition or visible acknowledgement for themselves - comes back to that whole ego thing. If they're just petty, you may want them to find a job elsewhere.
Enough! If you're still reading, then I'll make a suggestion. I'd look at Buckingham and Coffman's books from the Gallup organization (First, Break all the Rules and Now, Discover your Strengths) if you're interested in tech management yourself, or want to help your PHB (euthanasia is usually out). The books are chock full of interesting data, which the authors use to derive their philosophy from. Sure some of the stuff they say is obvious - but I think it's the first decent explanation of why TQM usually fails other than 'management screwed it up'. TQM is a nice idea, but the practice is based on some assumptions about organizations that are often false. There are lots of good examples that apply to every environment whether you're looking for excellent people in a dynamic (read: chaotic) environment or mediocre people in a rigid bureaucracy. Even if you don't agree with everything they suggest, it's good brain food.
Re:Just because you _can_ doesn't mean you _wanna_ (Score:4, Insightful)
Actually, builders seem to have absolutely no problem with that. They get a contract, they do the work, they get paid, they move on, without obsessing over whether the project is interesting or challenging or sexy like programmers do.
Let's not rewrite history, OK? The techies were in the vanguard for that debacle. They were the ones leading the way, yammering about new economies grumbling about how those old-school types just didn't get it, yadda yadda yadda. They were rampant optimists. The skepticism was coming from above, and turned out to be well justified.
Sounds like a pretty fucking good business model to me. Much better than building things that nobody wants, that's for sure.
No, it's the people running the businesses who've learned to spot empty promises, like the "if you let us build it, they will come" promise of the dot-bomb era. The techies are more often the ones making the empty promises.
Happiness==not being treated like company property (Score:2, Insightful)
GJC
My personal experience & opinions (Score:2, Insightful)
I was hired for a development dotcom as team-leader for the internal IT-group, but since we had no IT-manager my role more or less shifted into that of a IT-manager.
One of the things I came to realize is that being a manager, whether for smart och not-so-smart people, is a rather difficult thing which should be viewed as any other discipline which requires high skills and strong people skills.
This didn't exactly come as a shock to me, but I hadn't really thought that much about how much it would tear me down personally.
I think my problem was that I lacked good management skills and insight into what motivated my staff. While I realized this quite fast I really tried to do a good job and keep everyone happy.
I got pretty mentally exhausted after this period and I'd probably think twice about taking up any job which involves managing peolpe again, but I'll probably do it at some point in the future since I got the feeling that it can be a highly rewarding job, and not just in terms of economic compensation (I could probably earn more as a database developer than manager anyway).
Coming from a tech background my personal belief now is that tech jobs, while often demanding strong intellectual skills, usually deal with logical problems with tend to have logical solutions, but management (at least of human resources) deal with highly illogical humans and therefore is a much tougher discipline to master. Another thing that adds to the difficulty of management is that managerial positions often demands you to be proficient in multiple disciplines (much like developers...)
For all you people who're dissing managers and sales people (and all other non-cool positions) I only have one thing to say:
Treat them with the same level of respect as you want to earn yourself and by all means, if you think you can do the job better give it a try!
Re:"I'm a pwofessinul!" (Score:1, Insightful)
- Why work in an environment where you have superiors with no concept of the business in general? Such companies are bound to find themselves listed on the http://fuckedcompany.com and true professionals can always find a job within a company where managers got a clue, anyway.
- Do you really think that having a Comdex poster on the wall is going to give you any additional credibility?
- Why waste energy on trying to convince people to understand your professionalism by hanging posters on the wall when you could use the time to elevate yourself from the masses by doing something that would a) benefit the company and b) gain you some real credit?
- Why does it have to be Us vs Them? I strongly feel that in order to accomplish something truly great, a company/division/team/whatever will have to function as an unit and managers are the ones who do the things that you would not want to do anyway (budgeting,PPTs,meetings,licensing,...) but are still required to be done, why not give them some credit for that? Or is credit somehow only reserved for the "worthy"?
Re:"I'm a pwofessinul!" (Score:2, Insightful)
I don't want IT to be populated by my version of "profs", and anyway, I find the "props" comment weird. Why shouldn't I work with people of that calibre? I work with several PhDs. (And yes, I know, there are several people with BScs who're just as good, and/or better to work with).
Next up, I didn't major in MIS. It was BSc Astrophysics & Computer Science, PhD in Astrophysics. I don't think those are "token exams". I also don't think they're that useful for my current work though, which is why there are 103 technical books in my cupboard. And no, I don't have an MCSE or similiar one-vendor "qualification".
Next, I'm not a yes man. Trust me, those who work with me would laugh at that comment! I don't see myself on the rung to middle management, and don't make a point of playing politics either.
Next, I'm not a system admin. I'm a software designer. Not all IT staff fit the MIS profile.
However, I *agree* with you in regard to "I'm doing my job" and "I am a professional". That's what I was trying to say! Why would I want, as another poster said, a climbing wall at work? I'll go and pursue my leisure pursuits when I'm not at work. I don't care if you think Star Wars is best film ever made (and yes, I do have the videos) - I might agree, I might disagree, doesn't matter. It's got nothing to do with work! Decorating your cubicle with tradeshow posters - fine. Decorating your posters with one or two personal affects - fine. Annoying the shit out of co-workers trying to concentrate by firing nerf guns, and playing novelty tunes on your latest greatest mobile - not professional!
I've a love of a certain type of "geek" culture, the old fashioned tradition which originated in scientific labs and ham radio shacks. I like the idea of playing with the new toys to see what they do, I like the idea that if I want to know something I put the effort in and eat the books and specs, I like the idea of freely releasing what I've learned to help others. I like the iconoclastic ideal of being interested in interesting things and scorning those which are just to make money (ideally, the interesting things ARE those which make money). What I don't like is the recent trend of replacing the fiercely independent back room engineer image with the favoured self-image of
I think I just ranted again...