1. Any time you want to prove warranty coverage. 2. Anything you carry through Customs (and believe me, you'd better have GOOD receipts). 3. Anything required for various kinds of tax returns and filings.
Would you consider a Birth Certificate, Death Certificate, or Marriage License a kind of receipt?:P You need to hang onto those, too. "Gee, honey, I lost our marriage certificate. I guess that means I can go boink the cute new sales rep."
This is wrong, law varies by state and locale
on
Worst Buy
·
· Score: 2
Several states, counties, and municipalities have item-pricing laws that give consumers certain rights when the price charged doesn't match the price displayed. In Michigan, for example, "the seller must give you: (1) the difference between the amount charged and the affixed price, plus (2) additional compensation of ten times the difference, with a minimum of $1.00 and a maximum of $5.00 for each different item for which you are overcharged or be subject to a lawsuit. If the seller refuses your request, you may bring a lawsuit to recover actual damages or $250.00, whichever is greater, and reasonable attorney fees not to exceed $300.00. Similar protections can be found in Albany County, Massachusetts, and Connecticut. Similarly, the finality of a sales contract varies from place to place. Certain transactions are subject to a "buyer's remorse" period during which the buyer can return the item for a refund. Most auto sales are subject to this protection, for example.
Bottom line: as usual, if lawyers get involved, the situation gets complicated.
...most missing kids haven't actually been abducted, they're just lost -- wandered away at the mall, followed the wrong adult, etc., and are scared shitless that they can't find their parents. As the other comments in this thread point out, like most technologies this has upsides and downsides, depending on whether the parents are morons or not.
This may sound like a nasty employer practice but it's actually in the interest of the employee. (Obviously there should be a way to add items during the year -- there usually is.) This is like a prenuptial agreement -- you spell out in advance what is yours and what isn't. That way there's no confusion later about what had been agreed and understood. In fact, even if your employer doesn't have such a form, you should create one on your own that lists any outside-of-work projects that might potentially be seen as overlapping with your work assignments. Then they can never say "if we'd know we would have stopped you."
This has been my experience from 25 years in the software biz. Are you saying you don't think there's good engineering being done by any software vendors?? I'm certainly *not* saying that there aren't great developers in end-user organizations, in research labs, and in the academic world -- of course there are. But there are lots of strong developers working for software companies. Remember that many vendors offer great salaries and working conditions, and therefore have attracted impressive talent. Good engineering is what good engineers do, in the same way that science is what scientists do. Therefore if you have a lot of good developers working for software vendors, there should be a lot of good engineering being done.
I dunno, perhaps this is a troll, it never occurred to me that folks who develop software products for a living might be suspected as a class of being inferior engineers or as belonging to inferior teams. My observations have been the reverse. If I poked into twenty development organizations, ten end-user and ten software vendors, and ranked their general competence and experience levels, I'd expect to find more of the software vendors in the top ten, because Darwinian selection destroys bad software vendors more quickly and completely than it destroys bad in-house development teams.
In fact, through the years I've had several consulting assignments that consisted of helping an end-user organization run its development groups more like software vendors. A structured release process, rigorous version control and distribution management, bug tracking, support protocols, beta testing, regression testing, investment in development tools -- these have all historically received more serious attention by software vendors. Again, many non-vendors have good practices as well, but I've always found that the specialists have taken the lead.
Well, I doubt there's much more to be said in this thread, this seems to be sliding into ontology. At the end of the day, all I was really trying to say was: there are good developers working for good software vendors, and I believe they would contribute more to open source projects if we didn't put unnecessary barriers in their way. Leave the necessary barriers, but remove the religious ones.
Why, exactly, should the 'open source world' try to find ways to let the 'closed source companies' into the tent?...Are you trying to give 'em open source welfare or something? -- Chris Johnson
Put that way, I admit it sounds silly. But look at it this way. Consider two classes of organizations: those that develop software as part of their core business, versus those that develop and use software in support of their (non-software) core business: manufacturing, services, distribution, whatever. Although it's axiomatic that some of the strongest development teams and best engineers work for software-driven businesses, it's ironic that we make it much more difficult for such businesses to participate in the open source community. Few people would seriously say "They should get out of the software business so that they can benefit from open source" -- that's what they are and what they do. But shutting down the business seems to be the price of open source admission.
Should such organizations fundamentally be isolated from open source? Perhaps, since there would always be some conflict between their core business and the open source concept. But what a waste! Often, these are our best bastions of good engineering.
Imagine a small, high-quality development team, working in a traditional-model software business on an interesting problem -- financial analysis, restaurant POS systems, automated mapping, database design, whatever. The company and the team are funded by license revenues. But they're good guys. They use and support open source development tools, and they choose open source components for internal use. Their accountants have Linux desktops. Their web server is Apache. They don't use commercial products if good open-source alternatives exist. And they *don't* try to steal open source components from others to distribute as their own products. They have good engineering practices. They never comingle their product with open source components, in the same way they would never steal software from a customer. Employee morale is high.
In the course of building their products, they make rational decisions about whether a particular component should be built within their proprietary framework, or released as open source. On a case-by-case basis, they decide whether that component is more appropriate to be community-maintained or privately-maintained. The stuff that represents their core business, they keep secret and sell to their customers; the stuff that is more generally applicable, they share, getting the benefit of a wider support community and the other open source advantages.
Such companies do exist, and they provide a great work environment. I believe that this is the *right* model for a software company. But at the moment, it is relatively hard for such a business to integrate open source into its operations. It's relatively easy for a non-software company to use open source: just share everything. But it's hard to use open source selectively within a software company. We give some of the best teams of developers insurmountable legal and political barriers to open source.
I think it would be to everybody's advantage if right-minded software vendors could participate in open source. They have some of the strongest resources and are in a better position to help than many others. I don't know *how* to make this happen, but I believe it's better for all than dismissing this large class of professional developers.
Many of the comments here essentially say "software companies should base their revenue model on support and services." Setting aside all the questions about the obligations and advantages of GPL and LGPL and other licenses, let's just look at the "software companies ought to be support businesses" argument.
There are some business plans that work very well with a services model, and can leverage the strengths of an open source infrastructure to provide good value for customers. But there are other businesses where this just won't work. A relatively small, specialized market niche requiring sophisticated software is often unable to sustain an open-source community robust enough to address its technical problems adequately. Instead, some bunch of high-powered wireheads needs to work full-time on those problems, and somebody has to pay their salaries. Support/services revenues are often simply not an adequate way to recover the R&D costs of running a team like that. If you sink a few million on a project, how can you recover your costs through distribution charges and manuals? Never!
For such problem spaces, proprietary licensing schemes prove more practical -- licenses are an easier and better-understood way to get a group of user organizations to chip in the $50-200K a year or more, each, needed to run the development group. Companies are familiar with the idea of buying a license from a software vendor, and expect a bunch of contractual benefits as a result that they couldn't get through open source strategies. It would be riskier (and more politically dangerous) to pay comparable fees to a support organization that isn't contractually obligated to develop and maintain its own product, but instead is promising to work earnestly with a bunch of public-spirited open source volunteers to get the code written.
A strong engineering group is simply easier to build and run when one company controls the checkbook. With a big, diffuse problem space, like an OS or a DBMS, this isn't so important, and the open source advantages are more pronounced; but with a specialized need, the open source route can be more problematic.
The bottom line is that it's fine to say "you shouldn't be a software vendor, you should be a service vendor" but some companies really ARE and SHOULD BE software vendors -- they do a good job at it, they keep their customers happy, the business model pays for the R&D work, and at the end of the day the guys who founded the company WANTED a software company, not a services company. If you've worked in both environments, you know how different they can be.
Some of these closed-source companies are in fact Good Guys, and the open source world should try to find ways to let them into the tent. Locking them out, and just saying "proprietary is evil," limits open source to those problems that lend themselves to group solutions. Not all do, IMO.
To my eyes, the (serious) comments here fall into two classes: naming strategies that are appropriate for a monolithic, centrally managed domain (i.e. one geek 'owns' the name space and can assign names like 'Fred' and 'Barney'); versus strategies that are appropriate for a large heterogeneous environment (i.e. subgroups of machines are managed independently, and named systematically like 'NY02TC23').
I think we can all agree that for a small- to medium-sized environment, themed names are fine because they're highly mnemonic, they're easy to distinguish when written, and you can probably see the nameplate/poster/whatever that's displayed near the chassis. But in larger contexts, like the multi-thousand server farm described, this approach quickly becomes unworkable. Instead, a systematic taxonomy is easier to use, in which names are predictable based on well-defined characteristics. This model is used by every large organization I've encountered (except for workgroup-level components, which are sometimes named and managed locally). Various good suggestions for structured naming are made here, all fairly similar, and all requiring as a first step identification of the key factors within your organization that are most useful for distinguishing your systems -- factors that won't tend to change over time as systems are upgraded, moved, etc. This varies from place to place.
It's important to remember that this is an attempt to map a complex name hierarchy into a small flat namespace. (I'm reminded of mapping long self-documenting variable names into old 6-byte or 8-byte names. Always painful.) So I liked the suggestion that perhaps individual machine names (as known to the OS, and subject to the worst restrictions) don't need to be globally unique, so long as their public representation always includes enough higher DNS-type qualifiers (e.g. "DFW02.admin01," distinct from "NYC04.admin01"). Again, it all depends on who will be maintaining and accessing these boxen, and, perhaps most importantly, who will be responsible for and gatekeeper of "the list" that defines the state of your universe. (But I'd say that calling up Fred in IT to get a server name, and having to live with whatever lame theme name he chooses, won't fly too well in many shops.)
The heart of this problem, for me, is a fundamental problem in the US legal system. The UK has a huge advantage over the US. There, the loser typically has to foot the legal bill. Here, only in very limited circumstances is there any chance of getting the loser to pay for the cost of litigation. Therefore, the party with the deeper pockets can nearly always intimidate the other into settling or dropping the matter. This situation is not likely to change. Our legal system is founded on the principle that each side pays its own way.
I've recently been in one of these situations. I was wronged by a big company. My first reaction (after failing to resolve the matter through earnest negotiations on our part, and lip service on the other) was to grab our litigators and look at forcing a legal remedy. But here was the problem: we would be suing for $200-400K, but my legal costs would be somewhere in the $100-200K range. So the best I could get would be fifty cents on the dollar; and of course there's no guarantee I would win. And I wasn't crazy about reaching into my bank account for six figures worth of a gamble. The other party had a squadron of in-house litigators, and (we found later) had already put a $250K budget in place for outside counsel, with the instructions "drive them out of business." They were loaded for bear. We were right, but like straws in the wind. So we were facing a very tough battle, and the best up-side for us simply wasn't good enough. There was absolutely no legal basis under which we could sue to recover our litigation costs. So we caved in, backed away from litigation, and kept negotiating. (At the end of the day, we might finally resolve the matter, which is good news; but it's no thanks to the big guys.)
With a more civilized legal system, there would be a stronger incentive to find a fair solution, because neither party could wear the other down simply by the weight of legal expense. But it ain't gonna happen.
Easy to say, and one supports those who can do it fearlessly and consistently. But it's hard to judge somebody who, instead, caves in to the reality of superior force and deep pockets. People's lives are complex, as are legal quagmires, and so we all have to pick our fights. Choosing to fight a protacted legal battle is not a simple decision, and such a choice can affect the lives of other people -- family members, colleagues, employers, employees. In some situations, standing up for one's rights could be irresponsible -- it depends on how egregious the violation, and how important a principle is at stake.
You might say "what could be more important than free speech?" I might personally agree, and might take the plunge. But I couldn't condemn a parent for choosing not to divert family college funds into a legal battle. And I couldn't condemn somebody who weighs the chances and costs of litigation success versus those of failure, and makes a pragmatic choice. I've had to do this. Many of us have. It hurts to back down, but it could hurt less than fighting and losing, and sometimes even hurts less than fighting and winning.
Isn't this what Toyota did in the 60s and 70s? -- F. of E.
Yeah, but they could only do it because the Big Three were so incredibly FUBAR. It's a bit harder today -- no industry today is safe from paying the price for inefficiency and competition; at least not the way it was back in the days of Fortress America and lifetime employment. It's of course a good idea to manage and execute well, and many US industries had to learn this painfully from foreigners...but my point is that it's too simplistic to conclude (as many of the posts here seem to) that every US manager is an idiot who couldn't be trusted to lock the door on the way home at night, and that somehow if you could just shoot them, then all the techies would create a better world. There is a lot of bad management, true, but often good, smart people with the best motives are responsible, to their embarrassment. Successful technical management turns out to be black magic. Nobody really knows the secret.
Few small businesses spring for the cost of an SLA (Service Level Agreement) for their connections. Even if you do, normally you'll just be able to get back the cost of the connection for the period when it wasn't working. Getting a service vendor to pay for your lost time is a pretty unusual agreement. Normally this kind of protection is obtained via an insurance policy -- think of it like the cancellation insurance that a concert promoter buys. As you might imagine, buying a policy to protect against comm outages and other things usually viewed as force majeure situations (i.e. 'acts of God') is not cheap.
Moreover, in most places business customers subsidize home customers. So if you really want your home account to be treated like a business, plan to pay 2-4 times as much for the same service, with no guarantees.
At least that's been my experience in several different locations with a variety of providers over 22 years in business.
I believe Pong was the first successful commercialized game (1972) (created by Atari founder Nolan Bushnell after his unsuccessful Computer Space in 1971). A home TV version of Pong appeared around 1976. MIT Space War, the game cited here, ran on "The" PDP-1 a decade earlier. It was the coolest.
You're not my mortal enemy -- <blush> -- born in Cambridge and live in the US, and no Scottish blood...but my heart's in the Highlands and the Islands.
There are strong fears that Scotland's traditional "no crime of trespass" will go the way of the Dodo. The two main culprits: a cadre of obnoxious, litigious, wealthy landowners, many of whom are newcomers to Scotland; and foot & mouth disease, which is the justfication for the change. Let's hope these efforts fail, though the last I heard it was looking kinda grim.
From reading the posts here, it's clear that (nearly) all managers are idiots and (nearly) all companies are mismanaged. Therefore, to make a bazillion bucks, all you need to do is put together a business with smart managers instead of dumb ones, so that all the techs will be tickled pink to go to work, and product quality will soar. Right?
Well, basically that's true, but if this were easy to do, everybody would be doing it. Companies don't deliberately make themselves inefficient. As a few posts have reminded us, management is not a precise science. Training can help but only to a certain extent (and the best training is probably running a Boy Scout troop rather than going to B-school). It's hard to be a good manager, hard to measure management performance, hard to balance the competing priorities that most managers face, and hard not to wind up shooting yourself in the foot.
Which is not to excuse stupidity nor to discourage you from ridiculing morons; but just remember that if YOU were doing that job, you'd probably screw it up just as much, and maybe more.
All the other attributes of managers you discuss derive from this primary interpretive function and, indeed, without it, all those other attributes are rendered without business value precisely to the extent that they are independent of business reality.
There's no real disagreement here, and certainly not about the importance of understanding business needs. But since the original request was for career advice, I thought it was useful to point out that, in all but small development organizations, the first- and second-level development manager is first and foremost a RESOURCE manager rather than a PRODUCT manager. The company expects that person to serve as a technical coordinator, forecaster, troubleshooter, and mentor, but typically NOT as a business analyst or architect. The new manager will typically be judged in terms of technical results -- what was done on time, what was late, how many bugs appeared -- rather than business results, which are the responsibility of people in a different chain of command. Furthermore, although the new manager may and should have input to questions of design/functionality/business purpose, in many organizations what filters down to the technical level doesn't leave a lot of wiggle room. The specs are the specs. It's an advantage to understand them and be able to explain them; but at this level, it may not be practical to challenge them or reinterpret them, and it's often more important simply to stick to them as written.
This division of responsibility is not actually as unreasonable as it may seem, because these low-level technical managers typically do not have the business experience to understand the underlying business needs that you (correctly) identify as being vital to long term company success. You can't go overnight from being a JAVA hacker to being a business planning or reengineering expert.
This being said, naturally it is in everybody's interest to strive to understand the user perspective and try to relate technical priorities to business needs -- no question. But to prepare yourself for a switch to management responsibility, I'd say the most important thing is to focus on 'management' and 'responsibility' -- getting good at making lists, following schedules, conducting walkthroughs, constructive brainstorming, and above all basic interpersonal skills such as how to critique without insulting, how to negotiate competing priorities, and how to resolve conflicts.
Again, this is less true in smaller organizations where a direct connection to user requirements pervades the entire staff. In those situations, the first-line manager is heavily involved in the interpretive function you describe, as is (or should be) every technician as well.
So I don't discount the importance of the communications role you mentioned; but in my experience, technicians who move into their first management jobs are most challenged by management problems, not by design problems.
I might add that it may sound like I'm advocating a kind of old-style programmer-in-the-closet approach to development. I'm not. It's ALWAYS good to have close links between developers and users, and the more a technician understands about the business environment, the better. (In fact, if the original question were "how can I be a better developer?" I'd say your advice would be right on the money. Who would I rather had a close understanding of the application -- the person doing the development, or the one who manages vacations and budgets? The developer, absolutely.) But companies are the way they are, not the way we wish they were. And so, IMO, to prepare for a technical management career in a mid- to large organization, learn the business by all means, but plan to focus on and be judged by your management skills.
A programming manager must, first and foremost, be able to translate the business needs into language the programmer can understand. -- Baldrson
Uhh, good concept, but not usually the programming manager's job. What you're describing is typically the job of an analyst or product manager, or perhaps an architect -- somebody who understands (and is responsible for) the overall business model. In most organizations, the programming (middle-) manager's job is to accept the business model from 'outside' (i.e. from a business plan, a product plan, consultants, whatever -- 'revealed truth') and then ensure that the project priorities are consistent, and that the programmers aren't fucking up. This is not to trivialize how important such a role is (and naturally, you should try to understand the business framework as described by Baldrson; but it's not truly your job). Most failed projects have at least one bonehead who should have seen what was going wrong at a technical/managerial level, and why -- and though the problem is often at the design end, it's often at the implementation end, where days are being wasted on a stupid source management tool, or the lead programmer is spending too much time in the sack with the lead analyst.
The key thing here (the difference between long-term project failure and success) is whether the middle manager can distinguish between a) a really good technician who gets caught in a cleft stick because of bad specs, versus b) a bullshit tech weenie who gets over his head and can't figure out his tools, or c) several good folks who just waste time and can't cooperate because of divergent assumptions.
So at the bottom, a good tech middle manager never loses touch with current technology, and never loses the respect of the first-line troops, and, most importantly, can NEVER be buffalloed by a new techie who pretends to be up-to-date but who is in fact just coasting to Friday night. (Though protecting Friday nights is also pretty important for the long haul.)
Let me try to put it differently, and see if anybody disagrees. Being a GOOD middle manager is fundamentally a harder job than being a good entry-level coder. (The proof is that: most managers fail to deliver the goods; but when you DO have a good manager, you can't believe how lucky you are.) So to succeed, you need to stay even MORE up to date than you were as a heads-down coder, and you need to learn/invent/absorb good leadership skills to transform 'herding cats' into 'leading a team.' You might try joining the Boy Scouts (no kidding, they have really good adult leadership methods).
At the end of each day, you should see how your work has a) helped the techie do a better job, and b) reduced the risk of an apocalyptic failure for the PHB's upstairs.
it also makes you more likely to think outside the box, if you know where the box comes from and why it was created in that way.
...especially when you reflect that, at one time, punch cards were WAY COOL technology, and if you could punch a program (drum) card or do binary punches without checking the manual you were a computer God. Of course, at the time, CDC card reader/punches were way superior to the cheesy IBM products. But IBM won. So when you look at C# and WinXP and snicker, just remember what happened to all that lovely walnut and blue glass, and Seymour's vision of computers.
From my reading of the current material, and of other sources:
1. Heisenberg took a substantial risk visiting Copenhagen and discussing secret and dangerous information with Bohr. We don't know exactly what was on his mind, but he wasn't doing this lightly.
2. Heisenberg didn't like his fascist government; but he was still a patriot and wanted to do what was good for his people in the long run.
3. In 1941, it was a very reasonable conclusion that Germany would win the war. Most people feared this. It would not be unreasonable to plan accordingly.
4. Heisenberg was very, very smart.
5. Bohr was troubled by what he saw as inconsistent and inexplicable behavior. He was surprised and concerned, at the time and later, and he sought in vain to understand his friend's words and actions, which seemed clear but inexplicable to him.
6. After the war, Heisenberg felt bitter and misunderstood, and avoided discussing wartime events after having received censure from many sides.
Assume, for the moment, that in 1941 Heisenberg a) thought Germany would win the war, b) hoped Bohr was aware how serious a threat was posed by nuclear weapons, c) wanted to prepare for good humane postwar German physics, and d) deliberately but secretly focused German research efforts on avenues leading to peaceful applications. How would his behavior have been different? Who would have been aware of this lonely struggle, at the time or later? And, assuming this were all true, how bitter and frustrated would he feel after the war, being blackguarded for actions that (if all were known) should be seen as heroic?
The historical record is clearly ambiguous, and there are certainly valid interpretations of events that show him in a bad or foolish light. But this was an extraordinary man, dealing with titanic issues at an extraordinary time. I am more inclined to give him the benefit of the doubt. The great scientists I've known have tended to share a common trait: intellectual honesty, to the point of ruthlessness and even self-destruction if necessary. The great thinker is rarely petty of self-deceptive about important issues. So I have a hard time picturing Heisenberg conducting decades of revisionism to whitewash over bad behavior. I find it more likely that Bohr misunderstood his brief exchange with a troubled and tortured man, a man who was trying to do what he thought was right in a difficult situation. Bohr's own mystification with Heisenberg's actions is clear in the draft letters.
We won't ever have a certain resolution to this question, because letters and recordings only reveal certain kinds of information. The truth was hidden in Heisenberg's inner beliefs and motivations, but he chose to close the door on discussing such issues, after receiving what he perceived as unfair rebukes.
For me, it all comes down to a question of emotional and intellectual plausibility. Which 'plot' makes the most human sense -- Heisenberg as shallow, self-interested, incompetent, venal Nazi bureaucrat? -- or Heisenberg as an heroic, solitary, tortured visionary? Each version of history has problems, but look at the stature and reputation of this man before the war. He was larger than life. I hate to see him made so small in today's debate.
My favorite, or at least one of my favorites, is the "C Puzzle Book", which demonstrates essential principles without trivial crap ad nauseum. If you're writing a book on a complex topic, assume your readers have the necessary basic skills (or else your book will be useless, regardless of the level of exegesis). Then exploit those skills as a platform for presenting new information.
In the case of the C Puzzle Book, C syntax is presented in the form of "figure out what this does" examples, a great and actually fun way to absorb the essential information. This editorial concept applies in other types of books -- you don't need to use the puzzle metaphor, so long as you assume your readers are starting from a particular level of skill/experience.
The trick is to know what to take for granted, of course. There are many intermediate-level books that assume the reader already knows most of the material -- wrong approach. Assuming that you're addressing an advanced technology or concept: Pretend you are presenting the concepts to a really smart, interested person from a different discipline; a linguist, say, or a physicist, who doesn't mind structured presentations and concise definitions, but doesn't need to be led by the hand through endless narrative.
Give the big picture, by all means, but skip the fluffy screen shots. Use good abstract diagrams and clear simple examples. Provide references, but assume these and many of the details will be obsolete within 6-12 months, when many of your run's copies will be sold, so be sure to focus on the important concepts and data sources, things that will transcend today's specifics. That's how you create a classic. And that's why K&R is still a good resource.
It's always best to get the straight poop. (I especially liked the idea:) that OpenGL=id proprietary!) Your plans sound great. As a misanthrope, I'm particularly glad that there will be less teamplay emphasis and more plot. Escapism is best when there's some discovery and surprise.
Slashdot Mirror
1. Any time you want to prove warranty coverage.
:P You need to hang onto those, too. "Gee, honey, I lost our marriage certificate. I guess that means I can go boink the cute new sales rep."
2. Anything you carry through Customs (and believe me, you'd better have GOOD receipts).
3. Anything required for various kinds of tax returns and filings.
Would you consider a Birth Certificate, Death Certificate, or Marriage License a kind of receipt?
Several states, counties, and municipalities have item-pricing laws that give consumers certain rights when the price charged doesn't match the price displayed. In Michigan, for example, "the seller must give you: (1) the difference between the amount charged and the affixed price, plus (2) additional compensation of ten times the difference, with a minimum of $1.00 and a maximum of $5.00 for each different item for which you are overcharged or be subject to a lawsuit. If the seller refuses your request, you may bring a lawsuit to recover actual damages or $250.00, whichever is greater, and reasonable attorney fees not to exceed $300.00. Similar protections can be found in Albany County, Massachusetts, and Connecticut. Similarly, the finality of a sales contract varies from place to place. Certain transactions are subject to a "buyer's remorse" period during which the buyer can return the item for a refund. Most auto sales are subject to this protection, for example.
Bottom line: as usual, if lawyers get involved, the situation gets complicated.
You need to drop the other boot on this one. :)
Methinks they charge a little more for their hardware than we're paying for our RAM.
...most missing kids haven't actually been abducted, they're just lost -- wandered away at the mall, followed the wrong adult, etc., and are scared shitless that they can't find their parents. As the other comments in this thread point out, like most technologies this has upsides and downsides, depending on whether the parents are morons or not.
It's dumb ass, but it has to be done. -- g0rath
This may sound like a nasty employer practice but it's actually in the interest of the employee. (Obviously there should be a way to add items during the year -- there usually is.) This is like a prenuptial agreement -- you spell out in advance what is yours and what isn't. That way there's no confusion later about what had been agreed and understood. In fact, even if your employer doesn't have such a form, you should create one on your own that lists any outside-of-work projects that might potentially be seen as overlapping with your work assignments. Then they can never say "if we'd know we would have stopped you."
Maybe the jaz drive *was* the backup? And he just lost his backups? It could happen. (Though your analysis is probably right.)
This has been my experience from 25 years in the software biz. Are you saying you don't think there's good engineering being done by any software vendors?? I'm certainly *not* saying that there aren't great developers in end-user organizations, in research labs, and in the academic world -- of course there are. But there are lots of strong developers working for software companies. Remember that many vendors offer great salaries and working conditions, and therefore have attracted impressive talent. Good engineering is what good engineers do, in the same way that science is what scientists do. Therefore if you have a lot of good developers working for software vendors, there should be a lot of good engineering being done.
I dunno, perhaps this is a troll, it never occurred to me that folks who develop software products for a living might be suspected as a class of being inferior engineers or as belonging to inferior teams. My observations have been the reverse. If I poked into twenty development organizations, ten end-user and ten software vendors, and ranked their general competence and experience levels, I'd expect to find more of the software vendors in the top ten, because Darwinian selection destroys bad software vendors more quickly and completely than it destroys bad in-house development teams.
In fact, through the years I've had several consulting assignments that consisted of helping an end-user organization run its development groups more like software vendors. A structured release process, rigorous version control and distribution management, bug tracking, support protocols, beta testing, regression testing, investment in development tools -- these have all historically received more serious attention by software vendors. Again, many non-vendors have good practices as well, but I've always found that the specialists have taken the lead.
Well, I doubt there's much more to be said in this thread, this seems to be sliding into ontology. At the end of the day, all I was really trying to say was: there are good developers working for good software vendors, and I believe they would contribute more to open source projects if we didn't put unnecessary barriers in their way. Leave the necessary barriers, but remove the religious ones.
Why, exactly, should the 'open source world' try to find ways to let the 'closed source companies' into the tent?...Are you trying to give 'em open source welfare or something? -- Chris Johnson
Put that way, I admit it sounds silly. But look at it this way. Consider two classes of organizations: those that develop software as part of their core business, versus those that develop and use software in support of their (non-software) core business: manufacturing, services, distribution, whatever. Although it's axiomatic that some of the strongest development teams and best engineers work for software-driven businesses, it's ironic that we make it much more difficult for such businesses to participate in the open source community. Few people would seriously say "They should get out of the software business so that they can benefit from open source" -- that's what they are and what they do. But shutting down the business seems to be the price of open source admission.
Should such organizations fundamentally be isolated from open source? Perhaps, since there would always be some conflict between their core business and the open source concept. But what a waste! Often, these are our best bastions of good engineering.
Imagine a small, high-quality development team, working in a traditional-model software business on an interesting problem -- financial analysis, restaurant POS systems, automated mapping, database design, whatever. The company and the team are funded by license revenues. But they're good guys. They use and support open source development tools, and they choose open source components for internal use. Their accountants have Linux desktops. Their web server is Apache. They don't use commercial products if good open-source alternatives exist. And they *don't* try to steal open source components from others to distribute as their own products. They have good engineering practices. They never comingle their product with open source components, in the same way they would never steal software from a customer. Employee morale is high.
In the course of building their products, they make rational decisions about whether a particular component should be built within their proprietary framework, or released as open source. On a case-by-case basis, they decide whether that component is more appropriate to be community-maintained or privately-maintained. The stuff that represents their core business, they keep secret and sell to their customers; the stuff that is more generally applicable, they share, getting the benefit of a wider support community and the other open source advantages.
Such companies do exist, and they provide a great work environment. I believe that this is the *right* model for a software company. But at the moment, it is relatively hard for such a business to integrate open source into its operations. It's relatively easy for a non-software company to use open source: just share everything. But it's hard to use open source selectively within a software company. We give some of the best teams of developers insurmountable legal and political barriers to open source.
I think it would be to everybody's advantage if right-minded software vendors could participate in open source. They have some of the strongest resources and are in a better position to help than many others. I don't know *how* to make this happen, but I believe it's better for all than dismissing this large class of professional developers.
Many of the comments here essentially say "software companies should base their revenue model on support and services." Setting aside all the questions about the obligations and advantages of GPL and LGPL and other licenses, let's just look at the "software companies ought to be support businesses" argument.
There are some business plans that work very well with a services model, and can leverage the strengths of an open source infrastructure to provide good value for customers. But there are other businesses where this just won't work. A relatively small, specialized market niche requiring sophisticated software is often unable to sustain an open-source community robust enough to address its technical problems adequately. Instead, some bunch of high-powered wireheads needs to work full-time on those problems, and somebody has to pay their salaries. Support/services revenues are often simply not an adequate way to recover the R&D costs of running a team like that. If you sink a few million on a project, how can you recover your costs through distribution charges and manuals? Never!
For such problem spaces, proprietary licensing schemes prove more practical -- licenses are an easier and better-understood way to get a group of user organizations to chip in the $50-200K a year or more, each, needed to run the development group. Companies are familiar with the idea of buying a license from a software vendor, and expect a bunch of contractual benefits as a result that they couldn't get through open source strategies. It would be riskier (and more politically dangerous) to pay comparable fees to a support organization that isn't contractually obligated to develop and maintain its own product, but instead is promising to work earnestly with a bunch of public-spirited open source volunteers to get the code written.
A strong engineering group is simply easier to build and run when one company controls the checkbook. With a big, diffuse problem space, like an OS or a DBMS, this isn't so important, and the open source advantages are more pronounced; but with a specialized need, the open source route can be more problematic.
The bottom line is that it's fine to say "you shouldn't be a software vendor, you should be a service vendor" but some companies really ARE and SHOULD BE software vendors -- they do a good job at it, they keep their customers happy, the business model pays for the R&D work, and at the end of the day the guys who founded the company WANTED a software company, not a services company. If you've worked in both environments, you know how different they can be.
Some of these closed-source companies are in fact Good Guys, and the open source world should try to find ways to let them into the tent. Locking them out, and just saying "proprietary is evil," limits open source to those problems that lend themselves to group solutions. Not all do, IMO.
To my eyes, the (serious) comments here fall into two classes: naming strategies that are appropriate for a monolithic, centrally managed domain (i.e. one geek 'owns' the name space and can assign names like 'Fred' and 'Barney'); versus strategies that are appropriate for a large heterogeneous environment (i.e. subgroups of machines are managed independently, and named systematically like 'NY02TC23').
I think we can all agree that for a small- to medium-sized environment, themed names are fine because they're highly mnemonic, they're easy to distinguish when written, and you can probably see the nameplate/poster/whatever that's displayed near the chassis. But in larger contexts, like the multi-thousand server farm described, this approach quickly becomes unworkable. Instead, a systematic taxonomy is easier to use, in which names are predictable based on well-defined characteristics. This model is used by every large organization I've encountered (except for workgroup-level components, which are sometimes named and managed locally). Various good suggestions for structured naming are made here, all fairly similar, and all requiring as a first step identification of the key factors within your organization that are most useful for distinguishing your systems -- factors that won't tend to change over time as systems are upgraded, moved, etc. This varies from place to place.
It's important to remember that this is an attempt to map a complex name hierarchy into a small flat namespace. (I'm reminded of mapping long self-documenting variable names into old 6-byte or 8-byte names. Always painful.) So I liked the suggestion that perhaps individual machine names (as known to the OS, and subject to the worst restrictions) don't need to be globally unique, so long as their public representation always includes enough higher DNS-type qualifiers (e.g. "DFW02.admin01," distinct from "NYC04.admin01"). Again, it all depends on who will be maintaining and accessing these boxen, and, perhaps most importantly, who will be responsible for and gatekeeper of "the list" that defines the state of your universe. (But I'd say that calling up Fred in IT to get a server name, and having to live with whatever lame theme name he chooses, won't fly too well in many shops.)
The heart of this problem, for me, is a fundamental problem in the US legal system. The UK has a huge advantage over the US. There, the loser typically has to foot the legal bill. Here, only in very limited circumstances is there any chance of getting the loser to pay for the cost of litigation. Therefore, the party with the deeper pockets can nearly always intimidate the other into settling or dropping the matter. This situation is not likely to change. Our legal system is founded on the principle that each side pays its own way.
I've recently been in one of these situations. I was wronged by a big company. My first reaction (after failing to resolve the matter through earnest negotiations on our part, and lip service on the other) was to grab our litigators and look at forcing a legal remedy. But here was the problem: we would be suing for $200-400K, but my legal costs would be somewhere in the $100-200K range. So the best I could get would be fifty cents on the dollar; and of course there's no guarantee I would win. And I wasn't crazy about reaching into my bank account for six figures worth of a gamble. The other party had a squadron of in-house litigators, and (we found later) had already put a $250K budget in place for outside counsel, with the instructions "drive them out of business." They were loaded for bear. We were right, but like straws in the wind. So we were facing a very tough battle, and the best up-side for us simply wasn't good enough. There was absolutely no legal basis under which we could sue to recover our litigation costs. So we caved in, backed away from litigation, and kept negotiating. (At the end of the day, we might finally resolve the matter, which is good news; but it's no thanks to the big guys.)
With a more civilized legal system, there would be a stronger incentive to find a fair solution, because neither party could wear the other down simply by the weight of legal expense. But it ain't gonna happen.
Stand up for your rights. -- nn9doors
Easy to say, and one supports those who can do it fearlessly and consistently. But it's hard to judge somebody who, instead, caves in to the reality of superior force and deep pockets. People's lives are complex, as are legal quagmires, and so we all have to pick our fights. Choosing to fight a protacted legal battle is not a simple decision, and such a choice can affect the lives of other people -- family members, colleagues, employers, employees. In some situations, standing up for one's rights could be irresponsible -- it depends on how egregious the violation, and how important a principle is at stake.
You might say "what could be more important than free speech?" I might personally agree, and might take the plunge. But I couldn't condemn a parent for choosing not to divert family college funds into a legal battle. And I couldn't condemn somebody who weighs the chances and costs of litigation success versus those of failure, and makes a pragmatic choice. I've had to do this. Many of us have. It hurts to back down, but it could hurt less than fighting and losing, and sometimes even hurts less than fighting and winning.
Isn't this what Toyota did in the 60s and 70s? -- F. of E.
Yeah, but they could only do it because the Big Three were so incredibly FUBAR. It's a bit harder today -- no industry today is safe from paying the price for inefficiency and competition; at least not the way it was back in the days of Fortress America and lifetime employment. It's of course a good idea to manage and execute well, and many US industries had to learn this painfully from foreigners...but my point is that it's too simplistic to conclude (as many of the posts here seem to) that every US manager is an idiot who couldn't be trusted to lock the door on the way home at night, and that somehow if you could just shoot them, then all the techies would create a better world. There is a lot of bad management, true, but often good, smart people with the best motives are responsible, to their embarrassment. Successful technical management turns out to be black magic. Nobody really knows the secret.
Few small businesses spring for the cost of an SLA (Service Level Agreement) for their connections. Even if you do, normally you'll just be able to get back the cost of the connection for the period when it wasn't working. Getting a service vendor to pay for your lost time is a pretty unusual agreement. Normally this kind of protection is obtained via an insurance policy -- think of it like the cancellation insurance that a concert promoter buys. As you might imagine, buying a policy to protect against comm outages and other things usually viewed as force majeure situations (i.e. 'acts of God') is not cheap.
Moreover, in most places business customers subsidize home customers. So if you really want your home account to be treated like a business, plan to pay 2-4 times as much for the same service, with no guarantees.
At least that's been my experience in several different locations with a variety of providers over 22 years in business.
I believe Pong was the first successful commercialized game (1972) (created by Atari founder Nolan Bushnell after his unsuccessful Computer Space in 1971). A home TV version of Pong appeared around 1976. MIT Space War, the game cited here, ran on "The" PDP-1 a decade earlier. It was the coolest.
You're not my mortal enemy -- <blush> -- born in Cambridge and live in the US, and no Scottish blood...but my heart's in the Highlands and the Islands.
There are strong fears that Scotland's traditional "no crime of trespass" will go the way of the Dodo. The two main culprits: a cadre of obnoxious, litigious, wealthy landowners, many of whom are newcomers to Scotland; and foot & mouth disease, which is the justfication for the change. Let's hope these efforts fail, though the last I heard it was looking kinda grim.
From reading the posts here, it's clear that (nearly) all managers are idiots and (nearly) all companies are mismanaged. Therefore, to make a bazillion bucks, all you need to do is put together a business with smart managers instead of dumb ones, so that all the techs will be tickled pink to go to work, and product quality will soar. Right?
Well, basically that's true, but if this were easy to do, everybody would be doing it. Companies don't deliberately make themselves inefficient. As a few posts have reminded us, management is not a precise science. Training can help but only to a certain extent (and the best training is probably running a Boy Scout troop rather than going to B-school). It's hard to be a good manager, hard to measure management performance, hard to balance the competing priorities that most managers face, and hard not to wind up shooting yourself in the foot.
Which is not to excuse stupidity nor to discourage you from ridiculing morons; but just remember that if YOU were doing that job, you'd probably screw it up just as much, and maybe more.
All the other attributes of managers you discuss derive from this primary interpretive function and, indeed, without it, all those other attributes are rendered without business value precisely to the extent that they are independent of business reality.
There's no real disagreement here, and certainly not about the importance of understanding business needs. But since the original request was for career advice, I thought it was useful to point out that, in all but small development organizations, the first- and second-level development manager is first and foremost a RESOURCE manager rather than a PRODUCT manager. The company expects that person to serve as a technical coordinator, forecaster, troubleshooter, and mentor, but typically NOT as a business analyst or architect. The new manager will typically be judged in terms of technical results -- what was done on time, what was late, how many bugs appeared -- rather than business results, which are the responsibility of people in a different chain of command. Furthermore, although the new manager may and should have input to questions of design/functionality/business purpose, in many organizations what filters down to the technical level doesn't leave a lot of wiggle room. The specs are the specs. It's an advantage to understand them and be able to explain them; but at this level, it may not be practical to challenge them or reinterpret them, and it's often more important simply to stick to them as written.
This division of responsibility is not actually as unreasonable as it may seem, because these low-level technical managers typically do not have the business experience to understand the underlying business needs that you (correctly) identify as being vital to long term company success. You can't go overnight from being a JAVA hacker to being a business planning or reengineering expert.
This being said, naturally it is in everybody's interest to strive to understand the user perspective and try to relate technical priorities to business needs -- no question. But to prepare yourself for a switch to management responsibility, I'd say the most important thing is to focus on 'management' and 'responsibility' -- getting good at making lists, following schedules, conducting walkthroughs, constructive brainstorming, and above all basic interpersonal skills such as how to critique without insulting, how to negotiate competing priorities, and how to resolve conflicts.
Again, this is less true in smaller organizations where a direct connection to user requirements pervades the entire staff. In those situations, the first-line manager is heavily involved in the interpretive function you describe, as is (or should be) every technician as well.
So I don't discount the importance of the communications role you mentioned; but in my experience, technicians who move into their first management jobs are most challenged by management problems, not by design problems.
I might add that it may sound like I'm advocating a kind of old-style programmer-in-the-closet approach to development. I'm not. It's ALWAYS good to have close links between developers and users, and the more a technician understands about the business environment, the better. (In fact, if the original question were "how can I be a better developer?" I'd say your advice would be right on the money. Who would I rather had a close understanding of the application -- the person doing the development, or the one who manages vacations and budgets? The developer, absolutely.) But companies are the way they are, not the way we wish they were. And so, IMO, to prepare for a technical management career in a mid- to large organization, learn the business by all means, but plan to focus on and be judged by your management skills.
A programming manager must, first and foremost, be able to translate the business needs into language the programmer can understand. -- Baldrson
Uhh, good concept, but not usually the programming manager's job. What you're describing is typically the job of an analyst or product manager, or perhaps an architect -- somebody who understands (and is responsible for) the overall business model. In most organizations, the programming (middle-) manager's job is to accept the business model from 'outside' (i.e. from a business plan, a product plan, consultants, whatever -- 'revealed truth') and then ensure that the project priorities are consistent, and that the programmers aren't fucking up. This is not to trivialize how important such a role is (and naturally, you should try to understand the business framework as described by Baldrson; but it's not truly your job). Most failed projects have at least one bonehead who should have seen what was going wrong at a technical/managerial level, and why -- and though the problem is often at the design end, it's often at the implementation end, where days are being wasted on a stupid source management tool, or the lead programmer is spending too much time in the sack with the lead analyst.
The key thing here (the difference between long-term project failure and success) is whether the middle manager can distinguish between a) a really good technician who gets caught in a cleft stick because of bad specs, versus b) a bullshit tech weenie who gets over his head and can't figure out his tools, or c) several good folks who just waste time and can't cooperate because of divergent assumptions.
So at the bottom, a good tech middle manager never loses touch with current technology, and never loses the respect of the first-line troops, and, most importantly, can NEVER be buffalloed by a new techie who pretends to be up-to-date but who is in fact just coasting to Friday night. (Though protecting Friday nights is also pretty important for the long haul.)
Let me try to put it differently, and see if anybody disagrees. Being a GOOD middle manager is fundamentally a harder job than being a good entry-level coder. (The proof is that: most managers fail to deliver the goods; but when you DO have a good manager, you can't believe how lucky you are.) So to succeed, you need to stay even MORE up to date than you were as a heads-down coder, and you need to learn/invent/absorb good leadership skills to transform 'herding cats' into 'leading a team.' You might try joining the Boy Scouts (no kidding, they have really good adult leadership methods).
At the end of each day, you should see how your work has a) helped the techie do a better job, and b) reduced the risk of an apocalyptic failure for the PHB's upstairs.
it also makes you more likely to think outside the box, if you know where the box comes from and why it was created in that way.
...especially when you reflect that, at one time, punch cards were WAY COOL technology, and if you could punch a program (drum) card or do binary punches without checking the manual you were a computer God. Of course, at the time, CDC card reader/punches were way superior to the cheesy IBM products. But IBM won. So when you look at C# and WinXP and snicker, just remember what happened to all that lovely walnut and blue glass, and Seymour's vision of computers.
From my reading of the current material, and of other sources:
1. Heisenberg took a substantial risk visiting Copenhagen and discussing secret and dangerous information with Bohr. We don't know exactly what was on his mind, but he wasn't doing this lightly.
2. Heisenberg didn't like his fascist government; but he was still a patriot and wanted to do what was good for his people in the long run.
3. In 1941, it was a very reasonable conclusion that Germany would win the war. Most people feared this. It would not be unreasonable to plan accordingly.
4. Heisenberg was very, very smart.
5. Bohr was troubled by what he saw as inconsistent and inexplicable behavior. He was surprised and concerned, at the time and later, and he sought in vain to understand his friend's words and actions, which seemed clear but inexplicable to him.
6. After the war, Heisenberg felt bitter and misunderstood, and avoided discussing wartime events after having received censure from many sides.
Assume, for the moment, that in 1941 Heisenberg a) thought Germany would win the war, b) hoped Bohr was aware how serious a threat was posed by nuclear weapons, c) wanted to prepare for good humane postwar German physics, and d) deliberately but secretly focused German research efforts on avenues leading to peaceful applications. How would his behavior have been different? Who would have been aware of this lonely struggle, at the time or later? And, assuming this were all true, how bitter and frustrated would he feel after the war, being blackguarded for actions that (if all were known) should be seen as heroic?
The historical record is clearly ambiguous, and there are certainly valid interpretations of events that show him in a bad or foolish light. But this was an extraordinary man, dealing with titanic issues at an extraordinary time. I am more inclined to give him the benefit of the doubt. The great scientists I've known have tended to share a common trait: intellectual honesty, to the point of ruthlessness and even self-destruction if necessary. The great thinker is rarely petty of self-deceptive about important issues. So I have a hard time picturing Heisenberg conducting decades of revisionism to whitewash over bad behavior. I find it more likely that Bohr misunderstood his brief exchange with a troubled and tortured man, a man who was trying to do what he thought was right in a difficult situation. Bohr's own mystification with Heisenberg's actions is clear in the draft letters.
We won't ever have a certain resolution to this question, because letters and recordings only reveal certain kinds of information. The truth was hidden in Heisenberg's inner beliefs and motivations, but he chose to close the door on discussing such issues, after receiving what he perceived as unfair rebukes.
For me, it all comes down to a question of emotional and intellectual plausibility. Which 'plot' makes the most human sense -- Heisenberg as shallow, self-interested, incompetent, venal Nazi bureaucrat? -- or Heisenberg as an heroic, solitary, tortured visionary? Each version of history has problems, but look at the stature and reputation of this man before the war. He was larger than life. I hate to see him made so small in today's debate.
My favorite, or at least one of my favorites, is the "C Puzzle Book", which demonstrates essential principles without trivial crap ad nauseum. If you're writing a book on a complex topic, assume your readers have the necessary basic skills (or else your book will be useless, regardless of the level of exegesis). Then exploit those skills as a platform for presenting new information.
In the case of the C Puzzle Book, C syntax is presented in the form of "figure out what this does" examples, a great and actually fun way to absorb the essential information. This editorial concept applies in other types of books -- you don't need to use the puzzle metaphor, so long as you assume your readers are starting from a particular level of skill/experience.
The trick is to know what to take for granted, of course. There are many intermediate-level books that assume the reader already knows most of the material -- wrong approach. Assuming that you're addressing an advanced technology or concept: Pretend you are presenting the concepts to a really smart, interested person from a different discipline; a linguist, say, or a physicist, who doesn't mind structured presentations and concise definitions, but doesn't need to be led by the hand through endless narrative.
Give the big picture, by all means, but skip the fluffy screen shots. Use good abstract diagrams and clear simple examples. Provide references, but assume these and many of the details will be obsolete within 6-12 months, when many of your run's copies will be sold, so be sure to focus on the important concepts and data sources, things that will transcend today's specifics. That's how you create a classic. And that's why K&R is still a good resource.
It's always best to get the straight poop. (I especially liked the idea :) that OpenGL=id proprietary!) Your plans sound great. As a misanthrope, I'm particularly glad that there will be less teamplay emphasis and more plot. Escapism is best when there's some discovery and surprise.
Keep up the great work!