Run Linux on the machine, and run Windows as a standalone should you need to use Office instead of Libre. It's not ideal, but, especially for presentation Libre lags Office.

I'm curious what you're using as alternatives?

You mentioned Outlook and not Exchange, and didn't mention Excel, so I'm imagining not a corporate set-up?

I came here for ponies.

Slashdot got bad. The ponies are the stallions of what was right about this place. Yet they still choose not to return.

I will return next year, in seek of ponies.

to

too

Not being a Grammar Nazi, just pointing out how such an error can completely null the point you're trying to make (and null that to any others listening). Some others:

Effect and affect
It's and its
Where and were (this mind boggles me, I suppose it is a West Coast accent thing, I have no idea)

Don't let your argument be straw-manned for the sake of a few basic errors; it happens again and again.

Very much agree here.

the opportunity for every schoolchild to learn one of four "priority" languages- Chinese, Hindi, Japanese or Indonesian.

Learning is surely great in all forms. But I am confused why Hindi is a 'priority language'. Every corporate senior person I've met from India - Director type level - not only speaks several Indian languages, but also has flawless English in terms of grammar and vocabulary mixed with a somewhat local accent depending on where they're from in India, unless, as an in-joke among Indian colleagues goes, they're walked past the US Embassy and are suddenly embroiled with a thick US accent.

Chinese, for dealing with anyone outside the BPO / ITO / major trade companies: government, state owned and specialists yes.

Japanese, things in Japan tend to happen in Japanese despite the speaker's English ability, whatever the industry, so yes.

Indonesian, honestly have no experience.

But Hindi. Seems odd to be a priority.

Thanks for the comment, appreciate it. A question on the BA's role:

If business requirements are written by BA + Business, as I assume, why should the BA be involved in getting between the Developers and Testers as a communication duct? The BA and Project Manager should certainly be involved in T/D communication, but acting as a relay station creates a conflict of interest with the ability to cover up poor Business Analysis. Please tell me where I'm wrong.

Imagine the power of being able to hire a recent college graduate who has been taught how to develop system diagrams, build complex SQL, run log analysis, set up a cloud test environment, and write automation scripts.

If I can do all this, why would I want to remain a tester? Why wouldn't I get into development?

Because a tester is not a developer? While some testers are wanna-be developers, IMHO the author of TFA seems to get some things horribly mixed up, despite her position and experience. Developers unit test their code, and smoke test the product, surely? That's the job of a developer. Testers should have an understanding of development principals to faster nail the bug and help the developer, they mostly need to understand:

• Business requirements: How to translate these to testing scenarios;
• How to identify what's a show-stopper, something major, and something that's an error but doesn't hinder functionality as defined in business requirements;
• How to go head-to-head with a developer face-to-face, via email, or via telephone and motivate the developer to prioritise their fixes; and as testing is typically at the end of the development cycle
• How to project manage a lot of conflict. Communications are more important than knowing how to set up a development environment, though both are useful.

A developer, seeking to do the above, while still in their heart a developer, is not going to enjoy their job or be as good at it as a tester, unless they really like punishing themselves. They'll also be a lot less respected by the actual developers than a sassy tester who just loves doing the above.

The best testing teams I've seen are those with a big mix of varied technical and arts skill. A lot have been in emerging economies: English language majors are increasingly important.

I do not know Beijing. I do know several other cities in China, mainly 1st / 2nd tier, and what I will write below is concentrated on multinationals. This is intended to educate on the market concerning IT and multinationals; other options do exist.

Multinationals - mainly US companies in the IT field:

A lot of multinationals divert development and testing work to China, the most common reason cited is 'concentration risk' which sometimes means China is cheaper than India which it is a bit but for detailed varying reasons I will accept a consultancy fee for. The other compelling reasons is a genuine worry too much is offshored / outsourced to India and therefore is subject to India-specific market conditions, be it attrition which is much higher than China or other risk.

The expected working environment is English language. Office banter happens in Chinese, but international conference calls with India, US and Europe occur in English. And hiring a good local developer with good language skills is difficult. Testers are easier as communication skills are essential with English majors mixed with automation and CompSci majors less interested in development is the usual mix there, testers then get testing methodology training from the company they join. But developers - a strong developer tends to have less strong language skills, one with English language and good development skills are like gold dust.

But one thing turns gold dust to a diamond. That is specific product knowledge. Multinationals tend to have teams working with international teams on implementing large projects lasting several years which also require specific and intricate knowledge of a specific software product - not development environment, actual product being worked on, or related product which said product interacts with. This Subject Matter Expert will be extremely highly sought after.

To platinum plate your diamond, add Linux / Unix shell and some Big Iron experience. The vast majority of CompSci university education experience is Windows, .NET and Java centric, as that's where jobs are on an aggregate level. But university education outside a few exceptions at the top academic institutions is so Windows, .NET and Java centric then outside the largest institutions *nix is rarely taught, leading to a drought of experienced professionals in that area.

If you have all of the above, you will be an exotic, platinum coated diamond headed to a senior developer / manager position in a multinational. If you have some, you will be sought after. SME is the killer for a hiring manager. HR might not know exactly what is sought, but if a hiring manager sees SME skills they will move mountains to ensure you're hired at some kind of specialist or manager - though not necessarily managing people - level. Expect to be expected to spend time coaching others on the team.

Developers are also sought as good SIT / UAT testing managers, complimenting a pure-testing shop with some of 'the other side' experience. That's also an option. Having Project Management experience / ownership / governance would be a boost for a developer wanting to do testing management

Language is not an issue in multinationals. You'll be welcomed, the managers will feel happy to have attracted a well qualified foreign talent and once trust is built probably confide quite a lot. Remember you'll also bring a strong level of cultural diversity, many of the team will not have worked overseas, despite working with overseas so much, and they will have a lot of interest in learning new working practices and ideas, but broker that carefully with existing management.

As for salary - depends on what can be brought from the above. Ideal is working for an existing multinational and getting a relocation and expat package, but the reality is that now only happens at the most senior levels, Director-ish or with extreme specialist skills that simply do not exist locally. Accept a local+ offer. To calibrate what that is, or to get any personal tips, either yourself or anyone else reading this, please shoot this message a reply or send me a personal message.

Experience: Substitute PS/2 for USB, God Cable, PCI-E, whatever. The human aspect.

Will it allow team members, after shift when they think no one is looking, replacing their PS/2 mice and keyboards with the brand new USB mice and keyboards the new desktop units, idle and waiting for imminent arrivals, that are sitting on desks have? The new desktop units do not have PS/2 style sockets.

New keyboards and mice are included with a desktop order. All in one box.

Will it mean a filing cabinet is not accidentally opened a few days later by a team member revealing stashed and perfectly working PS/2 keyboards and mice while the new desktops are robbed bare of their input accessories?

Will it mean that team members pledge full "I have always used this: allegiance to their USB keyboards and mice despite them having their PCs for 1+ years and new desktop model roll-outs with USB, no PS/2, only setup only appeared 3 months ago and before 3 months ago there was not a single USB mouse or keyboard in the entire site? Will it mean team members may cry when one suggests replacing their slightly used USB mouse with a slightly used PS/2 mouse?

Will it mean there is a store room containing 200+ PS/2 keyboards and similar number of mice that have been returned with their PC unit? Accessories still work but PC unit was returned and scrapped because of a critical failure, usually power supply or hard drive. Replacement PC does not have PS/2 ports and comes supplied with USB keyboard and mouse, which are swiftly robbed bare.

That store room contains 2 spare USB key boards and 1 spare USB mouse as a contingency measure.

More are ordered... constantly.

I conjecture costs are hidden at all.

It depends on the size and complexity of the manager's exposure on how to cost everything they're involved with. HR extract their costs by 'allocations' as do all shared services.

Costing is extremely political, with bean counters monitoring all and seeing qualitative in nothing. Is installing a bunch of new PCs normal operations for Desktop Support, or does it become a project? Completely different cost budgeting involved. In global teams, is someone assigned cost code X or cost code Y - in the case of X the ABC head of X is extremely sensitive about variance in X and objects, so a million calls have to be done to find a way to assign them to Y with justifications, despite their function being as it was under X.

If ever getting to manage a decent budget, get ready for losing productivity.

They are also a gold mine.

Anything one-to-one should not be in email or not exclusively so, unless routine or via mail / alt simply because of opacity . Meaningful one-to-one should always be face-to-face.

I've found smoke breaks to be great for 'intimate osmosis' but not for broadcasting the dashboard; and are great for sharing organisation information, selectively. They're also two-way and 1-1 which is great for learning. I certainly have happy eyes when I see a risk, control or security person having a break, as it is an informal atmosphere to grill them for what I don't know.

I think this depends much on the dysfunction of the organisation as a whole.

Regular daily stand-ups are great for dysfunctional organisations, not exclusively but particularly, as much signal can be added to noise. "Dave has X issue yesterday, this is how he fixed it." "We're expecting high volumes over the coming week." "There's a new UAT manager in Y." Absolutely fantastic for these things, but very short and sweet. It ensures everyone hears the osmosis at a high level, and allows the team coordinator to share their daily dashboard highlight view, all to enrich each of their views.

Not in a meeting room, not sitting down, just standing up for 5 minutes face-to-face. That level of information sharing, especially in dysfunctional organisations where an individual's inbox may receive 900+ emails per day, which I have seen and been horrified at, is essential.

Absolutely not saying they're only useful for dysfunctional organisations, but are a necessary daily for dysfunctional organisations.

How to do them well? Empower all; do not dictate; keep to 'team' size which should be 5-10 people, any teams larger than this probably have difficult structural issues, a team larger than 10 cannot empower a stand-up as it will unless with great skill degenerate to a grand town meeting.