Donate today to keep Global Voices strong!

Our global community of volunteers work hard every day to bring you the world's underreported stories -- but we can't do it without your help. Support our editors, technology, and advocacy campaigns with a donation to Global Voices!

What caused me the most anxiety, working at a foreign company, was having to communicate in English. On the welcome lunch on the first day, suddenly being surrounded by a bunch of foreigners whose names I didn’t even know, then having daily meetings via conference calls, also in English, with teams in China and America. My English listening skills aren’t that great, so it’s pretty hard for me to follow a conversation in English completely, but my coworkers and managers were all really kind in explaining things to me, and that reassured me. I’m someone who takes quite a lot of time to adjust to a new environment, and I’m not yet fully adapted to my new workplace, but slowly I’m learning how things work, and really putting a lot of effort to adjust and become one of the team.

Although I’m not yet at the stage where I can say that I’ve fully grasped the culture of the new company, I’m already sensing very keenly the sharp differences between the culture of my previous job, in the SI (system integration) industry, and the culture of my current job, a global corporation which follows an agile approach.

An agile workplace

This agile approach to software development also required some adjustment:

The first thing that I noticed was really different is that the development team is positioned very close to the heart of the business that directly influences the company’s sales and profits. This naturally means that developers are in close communication with those in charge of business such as the product managers. The business people and programmers are in the same room, and from the point of view of the programmer, this means that every day, proposals to, for example, delete a field to make the code simpler and user interface cleaner are quickly approved and incorporated into next month’s release.

Knowing that even your small contribution to making the system more easy-to-use will lead to increased sales is a big motivator. In the SI (System Integration) industry, with its focus on the waterfall model of development, just adding or removing a field requires writing up an official request and getting approval from various levels of management, and typically takes weeks if not months to finalize. What tends to happen as a result, I find, is that even if a programmer has a good idea, they won’t go the trouble of actually proposing it, and instead simply implement exactly what’s written in the specs, unless there’s some kind of major problem.

Teams [at Amazon] are also small, with people in charge of operations close enough to programmers to interact closely with them, resulting in far less documentation. While this may of course vary from team to team, I’ve found that while wikis are used to document code post-development, there are very few cases of people producing Word or Excel documents prior to implementation — most of our time is spent coding and unit testing in tools such as Emacs, Vim and Eclipse. At my previous job, I probably spent at most 10% of my time on the project actually writing code, so this was a really big change for me. On the other hand, my English isn’t very good, so even when people would try to explain things to me, I often had trouble understanding. This made me sometimes long for clearly-written specifications, but I guess this is a cultural difference.

A dynamic workplace

The business model at Amazon is also different to his previous workplace:

To add to this, my new workplace follows the Business-to-Consumer (B2C) model in which new functions are constantly being released, so even over a span of many years, there are hardly any opportunities to rebuild the entire system. Quite the contrary, there is constant pressure to incrementally improve functionality and fix bugs, and the refactoring is done within any free time that can be found.

In that sense, there are virtually no opportunities [at Amazon] to build a system from the ground up, as a System Integrator (SIer) does. So it might not be the right kind of work for someone who wants to always work with the latest languages and frameworks. On the other hand, system integrators don’t have many opportunities to maintain and administer their own systems, so although their work could be really interesting if they were able to adopt the latest and best development techniques, in reality most end up stuck continuously working with old frameworks.

Asai's earlier blog entry discussed the so-called “retirement age” of 35 imposed on programmers in Japan. But Amazon has no such retirement age:

One thing I was worried when I started my new job was my age, but I’ve found that at a global corporation, there’s no retirement at age 35. At my new job, they seem to focus on hiring people who have some degree of experience over fresh graduates, so for a programmer, my age is nothing out of the ordinary. In fact, there are a lot of very active programmers here who are much older, almost like old men — you could imagine some of them might even have grandchildren. Of course, positions are filled based on skills not age, so there are also lots of younger programmers in higher-ranking jobs. (I wrote “old men”, but of course there are also many women programmers at global corporations.)