I occasionally get questions about being a developer in Japan from readers of this blog, and recently got an interesting one:

I’m looking for a web development job in Tokyo. I majored in English, and currently teach English in Tokyo (with a humanities visa). But during college and after, I’ve always been doing freelance web development on the side.

I don’t have a Computer Science degree. Is it possible for me to get the appropriate visa should I find a programming job in Tokyo?

When I had to renew my visa after founding mobalean, I received a lot of conflicting information about what visa I should be on. To ensure my renewal went smoothly, we engaged Nakai Immigration Services, who were kind enough to also respond to the reader’s situation:

A suitable solution provided he finds the new job may to remain under “Specialist” type and pursue engineering related work by mainly using English language skills. The emphasis should not be too much on technical development, as for this he would need suitable educational and/or professional background for a certain amount of years.

As you can see, there is a lot of ambiguity with regards to immigration law. If the reader was to have explained his situation to Japan’s Immigration Bureau, they would have told him that, no, he can not get a programming job without having an engineering background. But this doesn’t mean he cannot get a job that involves development.

If you have an unusual visa situation, I’d recommend getting help from a professional with handling the renewal, as their job is to look for possibilities for you to get the proper visa, whereas the Immigration Bureau’s is to look for a reason to deny you one.

The first pair programming event of Tokyo Rubyist Meetup went event better than I expected it to. The event was hosted at HatchUp’s TechBuzz space, and started with an introduction to pair programming by Johnny Mukai, where he talked about how Pivotal Labs does pair programming, and answered questions about how pair programming works.

After Johnny’s introduction, I assigned teams and then revealed the first programming challenge. Immediately, people began working together to solve the problem, and as the video below shows, the atmosphere was very lively.

Tokyo Rubyist Meetup originally set out to bridge the gap between the international and Japanese Ruby communities. From this perspective, the event was the most successful one yet, as by pairing Japanese and international people, it gave people who would not normally communicate with each other an opportunity to do so.

Based on the success of this event, I plan to hold another one. If you’re not already part of the Tokyo Rubyist Meetup community, you can sign up below to get an announcement about future events.

After years of living in a cramped Tokyo apartment, I’m going to move to a slightly more spacious one. Finding an apartment went smoother than I could have imagined, and in half-a-day, I had found a new apartment. The following day I set out to take care of the tasks surrounding the move.

First up is finding a mover. After some searching, I come across 価格.com’s moving company estimate site.

価格.com is a price comparison site, which I’ve used in the past to find deals on electronics. I decide to try them out, and fill out their form with the details of my current place and the place I’m moving to.

Within a minute of submitting my information, my phone rings. I answer, and it is a moving company calling to confirm my details. I spend about ten minutes going through my details, and receive a quote.

When I hang up the phone, I notice that I have four missed calls. It hits me: all the estimate service does is submit my information to all the companies that have registered to it.

The companies are like sharks that have just smelled fresh blood, and are swarming on me. The moving companies must have people ready to pounce on any lead that comes in, racing to make the call before their peers. I wonder if these ferocious companies will really give me a good deal, or will try to fleece me.

I realize I don’t want to deal with these companies. But it is too late, as they have my phone number already. Ignoring email is a lot easier than ignoring a ringing phone. By the end of the day, I’ve received fifteen calls from different moving companies.

The moving company estimate site provided me with a horrible experience. With the internet, we are used to it being a passive experience. We can browse at our own pace, stopping at any time. This service broke that paradigm, making me fend off different moving companies. The only thing that they automated was the submission of my information to more companies than I would have ever wanted.

The user experience here is broken for everyone. The potential customers get overwhelmed by the companies calling them. The companies waste time calling people who don’t want to talk to them. 価格.com’s service shouldn’t exist as it stands.

If you are someone wanting to do a startup in Japan, there’s a great opportunity here for you. The experience of finding a moving company could be made infinitely better. There is already a market, and a clear path to monetization. It might not be the sexiest startup, but it has a real chance of success. Let me know if you want to talk more about it.

Oh yeah, and while I was writing this post, I got yet another call from a moving company.

The other day I was contacted by a member of AIST, who was looking for advice on where to post a job offer for an English-speaking web developer in Tokyo. The position itself doesn’t require previous work experience (though programming experience is required). When I first came to Japan straight out of university, I was lucky enough to get a job like this, so I am posting it here in the hope someone else can similarity benefit from it.

The project itself is in the area of personalized health, and although it is starting as a research project, the goal is to spin it out into a company. The combination of disciplines, and the hybrid of academia and business, makes it an interesting position.

The main reason why they are looking for an entry level developer is that the initial contract is only six months (though if the project goes well, it will be continued). This means it is not going to be a stable position. However, this may conversely make it more interesting to some people - it will be a startup-like atmosphere where the developer’s contribution will have a great effect on the success of the project.

They want someone who can start as soon as possible, so although they are open to hiring someone outside of Japan, someone who is already here with a valid visa will be preferred.

Although the team itself communicates in English, the application is for the Japanese market. If you are Japanese, and wanting a chance working in a more international environment, this could be a great experience for you.

You can find the job posting here. 日本語もありますよ。

RubyKaigi and more recently Sapporo Ruby Kaigi have been providing realtime translation services. The way this has worked is that volunteers listen to the speakers presentation, and simultaneously translate it to an IRC channel that is broadcast next to the main screen, like the photo below.

At RubyKaigi 2011, I tried to help, but my Japanese skills were not up to the task. When I was asked to help doing the same thing for Sapporo Ruby Kaigi, I initially refused, but after some persuasion, I agreed to do “backup” translation. However, when the conference actually started, I realized that if I didn’t step up, many of the Japanese presentations would go untranslated. So I ended up doing a lot more translation then I anticipated. For less technical presentations, it wasn’t as bad as I thought it would be, and as the event went on, some of the audience also helped out with translation (my thanks especially to @sora_h and @lchin).

During and after the conference, I was grateful for all the thanks I received for my translations. Having bilingual RubyKaigi are very important to encourage the exchange of ideas. However, the process we are using to do simultaneous translation needs to be improved as it suffers from many issues:

• Too few translators
• No opportunity to understand the presentation material before hand
• Often hard to quickly come up with a translation
• Typing is slower than speaking, so even in the best case, content goes untranslated

On Saturday morning, before Ryunosuke Sato’s presentation, I had the opportunity to review his slides. Because the slides were only in Japanese, but were quite verbose, I decided to translate them. Then as he did the presentation, I pasted the translations into IRC, occasionally quickly adding something on the spot when he strayed from them. This process worked a lot better for me, and got me thinking about how if we did more preparation in advance, we could make it easier at the conference itself.

The Proposed New Process

1. After the schedule is published, a translator will choose a couple of presentations that match their interests and abilities.
2. The translator schedules a Skype call with the speaker before the conference (say a week in advance)
3. The speaker does the presentation over Skype (screen sharing could be useful here), and the translator makes translation notes
4. At RubyKaigi itself, the translator broadcasts translation based on previous notes (exact method still undecided)

This process would require more effort per presentation (I estimate 2-4 hours per 30 minute presentation), but would then be less demanding on the day of the conference itself. Because of the extra time, translators could produce higher quality translations, and people who might not have the ability to do something in realtime could still help out. Because the job of translating would become easier, we could recruit more translators. This would allow us to divide up the work better, meaning that translators would have less responsibility during the conference. The idea would require the cooperation of the speakers, but the one speaker I did talk to about it was enthusiastic about it.

This is just a skeleton of the process, and I think there is still room for more improvement, but I wanted to get my thoughts out while Sapporo Ruby Kaigi is still fresh in everyone’s mind. I’m happy if you have any thoughts or suggestions on the idea.

I’m writing this from the Starbucks in the Sapporo Grand Hotel. When I arrived, there was already another Rubyist here. Five minutes before, I met another one walking down the street. Last night, I went into a Sapporo bar, and a speaker was there, and soon after, I saw yet another Rubyist passing by, and called him to join us. This kind of serendipity is what made Sapporo Ruby Kaigi 2012 such a wonderful conference.

My first Sapporo Ruby Kaigi was in 2010. With only about 120 participants, it was much smaller in size than Ruby Kaigi’s 700+ people. Despite its relatively small size, the organizers put together a top-notch programme. I felt very fortunate that I could participate in it, as I thoroughly enjoyed being part of a community of such passionate people.

When Sapporo Ruby Kaigi 2012 (sprk2012) was announced, the announcement was in both English and Japanese. This was the first time a Regional RubyKaigi had provided bilingual information, but at the time, I didn’t think much of it, besides being excited to attend myself. Later, Kazuya Numata reached out to me for help with improving the English communication, I was more than happy to help, both because I had enjoyed the previous one so much, and that it aligned with my goal of making the Japanese Ruby community more international.

The Japanese Ruby community has traditionally divided Ruby conferences into international bilingual ones (the Ruby Kaigi), and domestic Japanese only ones (Regional Ruby Kaigi). A big part of this is the language barrier. As most Japanese Rubyists are not comfortable in English, they want to talk about Ruby in Japanese. Because they worry that non-Japanese Rubyists would not enjoy a Japanese language conference, all previous Regional Ruby Kaigi have had no English information.

With sprk2012, the organizers went all out with internationalization. Two of the three keynote speakers were from outside of Japan. About a third of the other speakers were. Ten percent of the attendees were. As much as possible, the conference was bilingual. I’m really glad that people from all over the world were able to enjoy sprk2012, and am thankful to the organizers for making it an international Regional Ruby Kaigi.

I hope other Regional Ruby Kaigi are inspired by sprk2012 and try to be a bit more international. There are many non-Japanese Rubyists who are looking for an excuse to travel to and around Japan, and Regional Ruby Kaigi are a perfect opportunity. However, without any English information, even those who speak some Japanese are unlikely to find out about Regional Ruby Kaigi, so even having a little bit of English would go a long way. One good example of how this could be done is Tokyo Ruby Kaigi 10, and I would be happy to help any other Regional Ruby Kaigi similarity accessible.

The international nature of the conference seemed to tie in with one of the themes that emerged at sprk2012: diversity. Presenters encouraged technical diversity (Matz’s “One size does not fit all”), involving more women in the Ruby community (Rails Girls), and more cross cultural communication (Yoko Harada’s “Why Don’t You Go To Conferences In US?” and try :english). Diversity is one thing Japan has traditionally lacked, so I’m glad to see that the Ruby community sees it as a priority.

Thank you to all the organizers of Sapporo Ruby Kaigi, you made it a really memorable experience. I’m already looking forward to the next Sapporo Ruby Kaigi.

One area I’m interested in is how people find jobs. The “traditional” way to find a job of sending out your resume to lots of companies and hoping for the best is clearly broken. Despite this, people all around the world, but especially in Japan, cling to it. So I got excited when I heard about Forkwell, a service that is trying to change this

Forkwell is a aims to be the LinkedIn for geeks. Although most of the users are currently in Japan, the service has a global focus, offering it in both English and Japanese.

At the core of the system is the ability for user’s to register skills they are proficient in, such as git or ruby. The peers of the user can then indicate that he is infact proficient by +1’ing the skill. This way, users can show off their skills.

Yuka Ouka, one of the directors of Garbs, the company that built Forkwell, is also a frequent participant of Tokyo Rubyist Meetup. I interviewed Yuka last week about the service, and translated it from Japanese to English below.

How did you come up with the idea for Forkwell?

Originally, Forkwell was going to be a social recruiting service. Recently in Japan, companies looking for engineers ask their employees to recruit their friends, and if the friend is hired, the employee will get a bonus of say three hundred thousand yen. So, we thought we could do this as a social networking service.

In America, there’s a similar service called Top Prospect. With the service, you login using Facebook or LinkedIn, get a list of jobs, and if you introduce someone to one of those jobs successfully, you will a bonus. We wanted to do something similar to that in Japan.

However, Top Prospect turned out to be unpopular, and the idea of sending job introductions out of the blue didn’t seem appealing at all to the people I talked to. Instead of being so direct about it, we thought having a social networking service more like Facebook or LinkedIn, where job information could be introduced in a more casual manner would be better.

While originally we’re going to focused on facilitating employee referrals, which we are still planning on doing, we thought it was important to start off by having something that was fun for engineers to use. So that’s why we started off by releasing features like skill tags and +1 for skills.

Why did you decide to release Forkwell in both English and Japanese?

We wanted to make a global service, not something that was used just in Japan. Recently we’ve seen the release of lots of SNS services targeting geeks, like coderwall and geeklist. In Japan too, services like hat.io by Recruit have come out. Geeks don’t use LinkedIn much, because it feels like it’s just for suits, so I think everyone sees that there is an opportunity to make a LinkedIn for geeks. We want to be a part of this, and have people from all over the world use our service.

How are you planning on promoting Forkwell abroad?

Right now, Akira Matsuda [Japan’s top Rails contributor and director at Garbs] is at RailsConf, and he’s giving out stickers. We also received investment from a venture capital firm, so we’re considering hiring a company to promote it abroad.

How are you planning on monetizing Forkwell?

Companies looking for engineers will post jobs. Forkwell’s users will then be able to add a comment to the position and share it with friends. For instance, if a company posts a job looking for a Ruby on Rails engineer to help them make games, I might share a posting within Forkwell saying that I’ve worked for them before, and it’s a good company, so if you’re a Rails developer, why don’t you apply. If one of my friends then applies for the job through Forkwell, I can write a reference for him. If my friend is hired, I’ll receive the reward offered by the company, say 300,000 JPY, and garbs will get thirty percent, so in this case, 90,000 JPY.

What motivation do companies have to use Forkwell?

Recently, Japanese companies often ask recruiting agents to introduce employees. These agents collect people who are looking for a job, and will introduce those people to companies, regardless of whether or not they are actually skilled for the position. So it’s up to the companies themselves to decide whether or not a person is skilled enough. I’ve heard from companies that only about one out of a hundred people that agents introduce are skilled enough. Despite this, if the companies hire that one person, they still need to pay 30% of the first year’s salary. So the cost-performance for these agents is really bad.

We saw this problem, so we’re focusing on introducing skilled engineers. Additionally, Forkwell is a lot cheaper than these agents.

Why would an engineer use forkwell?

For talented engineers, it is important to see what kind of environment they’ll be working in. For instance, for a Rails developer, he’ll want to work at a company that is using git and the newest version of Rails, and do development in an agile fashion. But it’s hard to see what a normal company is like. If they use Forkwell, you can see that your friend, or friend of friend works at that company. If a skilled engineer is working at that company, then the company is probably a good place to work.

In Japan, it seems like engineers don’t recruit their peers so much. Why do you think this is?

I think they are apprehensive about taking on the responsibility of recruiting someone. For instance, if they recruit a friend, and then the friend quits soon after, they feel responsible for it. In Japan, there isn’t a culture of going through people when applying for jobs. In America and Europe, rather than directly sending your resume by email, you might ask your peers if they know of a good company. Once someone introduces a job, then you’ll apply for it. With this method, because the introducer is thinking about both parties, I think it is rarer for people to get hired to a position that doesn’t match their expectations, or a company to hire someone who wasn’t as skilled as they thought he was. We want to encourage this method in Japan, and thought by building Forkwell we could help make the process smoother.

Compared to before, the culture of changing jobs in Japan is changing…

Companies like Gree and Cookpad, who are making their own web services, are recruiting people who used to work as “SIers” [System Integrator - a generic title for engineers who work at a company that does outsourced projects]. Right now, its just the top engineers who are changing jobs, but starting from this year or next, I think we’ll see this trend spreading downwards. We hope that Forkwell will add momentum to this movement.

What’s been the biggest challenge for you with Forkwell?

There aren’t any services like Forkwell in Japan, and even abroad, services like this aren’t so common, so people don’t readily understand it. It has been especially challenging to explain it to people who aren’t engineers, as I need to explain how geeks think, and what kind of service appeals to them.

My first job was for a Japanese startup. The company had a stellar development team, and in a couple of months of working there I learned more about developing software than I did in my entire computer science degree.

The rest of the company was, well, it was hard to tell. You see, even though the company was only about thirty five people, we had a development team, an operations team, an operator team, a sales team, and a human resources team. Furthermore, there wasn’t much collaboration between the teams. Part of this was language issues (the development team was filled with English speakers, whereas the rest of the company was Japanese), but I also remember a manager telling me something like “it’s my job to insulate you from all the chaos outside the department so you can concentrate on coding”. At the time, I didn’t think too deeply about the implications of that statement, because I was grateful that I could do a job I liked, surrounded by other professionals I respected, and although I was a bit disappointed I didn’t get to interact more with the rest of the company, I coded on in happy oblivion.

Meanwhile, the company wasn’t doing so well. It’s telling that almost every party we had at the company was a going away party. Slowly our numbers dwindled. As the company struggled, it decided it’s new mantra would be “cut costs”. Measures like having the employees clean the toilets instead of paying for a janitor (so everyone could pitch in!) were put into place. Frequent all-hands meetings were held and we were presented with reams of financial data in incomprehensible formats. But the organization structure remained the same, and day-to-day life remained largely unchanged.

At the same time, the company decided to create a new product. I first heard about it by being asked to develop the server side component (a client application had already been developed by an outside contractor, but that’s another story). Looking at the effort create the product, plus the cost of running the service, the product didn’t make sense to me. So I came up with a spreadsheet that had a user growth model in it, and calculated the potential revenue. It appeared to me that even ignoring all the sunk costs up to that point, it would take us years to recover the additional costs we would incur in completing the development. I shared it with the president, but was shrugged off, and didn’t ever get a response to it.

Although I was never directly told “that’s not your job”, I also wasn’t encouraged to pursue my interest in the business side of things. This just frustrated me even more. Here I was wanting to make to help the company more money (or at least not loose money), and yet the only thing I was allowed to help the company with was coding, and it was clear to me lack of coding talent was not the source of the company’s problems. Soon after that, I left to start my own company.

As a startup, your top priority must be innovation, and innovation in today’s startups comes not from deep mastery of any one domain, but rather the coming together of many skill sets. By not encouraging your employees to broaden their horizons, you will fail.

While I was initially a bit aprehensive at the classroom like setting for the last Tokyo Rubyist Meetup, thanks to all the great people who attended, we were able to turn it into a lively event. Anchoring the night were presentations about Heroku and Travis CI.

First up was Ayumu Aizawa, who gave a talk about Heroku’s latest and greatest features.

For me, the most interesting part was the question and answer session (starting at about 17:20), where among other things, he described how he got hired by Heroku. Basically, it boiled down to that he just asked if Heroku needed an evangelist in Japan. This is a great lesson for developers everywhere: if there’s a job you want to do, don’t let the lack of an advertised position stop you. Conversely, the lack of other applicants will make you all the more likely to get it.

Next up was Randy Morgan, who introduced Travis CI and talked about how he got involved with the project.

As I was telling Randy later, I think Travis CI has the potential to be as revolutionary for developers as GitHub or Heroku, so check it out if you haven’t yet.

Thanks to RedHat for providing the venue, and nekop for helping to get everything set up.

One of the biggest challenges in moving from a software developer to entrepreneur has been changing my perception of the value of software. As a developer, the underlying assumption was the more functionality software had, the more valuable it was. This proposition was comforting, as it meant the value I was creating was directly proportional to my effort creating it. Unfortunately, it was categorically wrong.

Instead of being intrinsically valuable, the value of the software to customers dictates the value. If we were to express it as an equation, we could do so with the following:

bc. software value = value to a customer × the number of customers

By looking at value in this way, when we have a goal for the value of our software, we can then plot our possible routes to success. For instance, if we set the value to one million dollars then we get the following.

The most important thing to note is the scale of this graph: both axis are logarithmic, so if we increase the value of our software ten times, we need ten times less customers, and vice versa.

The Relationship Between Software Value and Difficulty

High value software is intrinsically more difficult to create than low value software, as is obtaining a large number of customers more difficult than a small number. If we construct a naïve model for difficulty, where the total difficulty is the sum of the difficulty of creating value and that of increasing the number of customers, we can add an arbitrary measurement of difficulty to our graph.

Although the value of the minima depends on the ratio of the two difficulties, it lies somewhere in the center of the graph.

Implications on Funded vs Bootstraped Startups

One fundamental difference between funded and bootstrapped startups is how they approach risk. The primary goal of a funded startup is to maximize return on investment. In exchange for this, they can take large risks, and don’t need to see immediate returns. However, bootsrapped startups need to focus on minimizing risk over maximizing return, and should see a return on investment as soon as possible.

Following from this, a bootstraped startup should focus on striking a balance between customers and value. This is exactly the advice we’ve heard time and again from the likes of 37signals, one of the most successful bootstraped software startups.

Your value proposition is at the core of your startup. By being aware of it, and the implications of it, you can dramatically increase your chances of success.