More from TokyoDev
Over my career, I’ve spent at least one thousand working hours on supporting local developer communities. My current business, TokyoDev, has spent over 8 million Japanese yen (about 53,000 USD) on community sponsorships. What have I received in return? That depends on your viewpoint. From a cold-hearted capitalist perspective, that time and money I invested hasn’t produced enough direct returns to justify the expense. Personally, I don’t see it as wasted—all of it has had a positive impact on society. What’s more, the three businesses I founded have owed much of their success to my community involvement. Those companies are: Mobalean, a technical consultancy that helped companies like PayPal, Match.com, and Estee Lauder build web apps for Japanese feature phones Doorkeeper, an event registration platform that hosted thousands of events per month TokyoDev, a job board that helps international software engineers get jobs in Japan If I hadn’t volunteered for and donated to various developer communities, two out of those three businesses would never have been founded at all, and TokyoDev certainly wouldn’t be the success story it is today. So, despite these “unequal” returns, one of the best strategies for my startups has been to get involved with communities whenever possible. I’ll go over some of the different ways communities have helped grow my businesses, and give specific examples of wins we’ve experienced over the years. Growing through existing communities There are two kinds of communities that can help you grow your startup: preexisting communities independent of your business, and communities you build around the business itself. My companies got their start due to my involvement in existing communities, and I think that is the easier place to begin. Already-established communities not only come with their own networks, but are usually easy to join and happy to receive support. Volunteering This was the origin of Doorkeeper. An industry event, Mobile Monday Tokyo, was registering hundreds of people for their events. Checking those people in at the door was always time-consuming, particularly as some names were in English and others in Japanese, giving no good way to sort the list. Seeing this, my cofounders and I proposed building some software to send out QR code tickets. Back in 2008, that was still a relatively novel idea. Mobile Monday was happy for us to do it, so we quickly built a one-off solution for them. We went further than that though—we also personally manned the doors for their events. I remember the first event where we checked in people using the new QR code tickets. It was quite rewarding to be able to tell the participants, “I built this.” That sense of satisfaction wasn’t the only immediate payoff—because we got involved in the event, it also served as marketing for Mobalean, our technical consultancy. We made connections with people in the industry, and when they had projects related to mobile web development, they started coming to us. Later, after we’d solved all of Mobile Monday’s event registration and ticketing needs, we thought other organizations might benefit from our work. We spent months rebuilding the tool to support multiple communities and launched it as Doorkeeper. Initially, though, it struggled to get users. Meanwhile, we continued to volunteer with other communities we were interested in, such as Startup Weekend Japan and RubyKaigi, Japan’s (and possibly the world’s) largest Ruby conference. We didn’t directly ask those communities to use our software, but after we got involved with them, they decided of their own accord to start using Doorkeeper. Because these events made quite an impact on the tech community in Japan, they helped us grow immensely, leading Doorkeeper to become the most popular platform for developer events in Japan. This wasn’t some sort of coldly-calculated strategy. I don’t think it would have worked if it had been. Sure, we knew that if we were running an event platform, it was a good idea to be involved with events, both to make connections and to personally experience our target audience’s problems. But our main motivation was just to help causes we believed in. I think our sincerity helped motivate the organizers to take a chance on a product that was still rather rough around the edges. Business-wise, Doorkeeper was never a runaway success. We struggled for years to monetize it. The turning point was when we announced we’d go from being a freemium service to an exclusively paid one. A lot of organizers stopped using us, but enough continued that I could finally pay myself a decent salary from the product’s revenue alone. What’s more, there was almost no backlash against the move. I think this was because we’d been socially connected to the organizers for the entire history of the company, and they could see that we were being genuine when we said there was no other way forward. I’ve since sold Doorkeeper, but the lessons I learned still stick with me. Speaking at community events Over the years, I’ve delivered numerous presentations on software development and entrepreneurship at different community events. At least for someone like myself, who doesn’t regularly give talks, preparing for them can be quite time-consuming. While I do believe it has helped keep my businesses in the minds of my target audience, I can’t think of a single example where giving a presentation led directly to a new lead. The closest we came to that was after speaking at a Ruby event about a library for handling subscriptions with PayPal. As part of the talk, we mentioned a new side project we were working on, a web app to make Japanese invoices. One of the attendees, a prominent member of the Japanese Ruby community, tweeted about the new service, effectively launching it. That initial buzz and the SEO-friendly domain name (the Japanese word for invoice), helped us become one of the top search results. The project didn’t end up going anywhere as a business, though, and we sold it around a year later. Starting your own independent community In 2010, I created Tokyo Rubyist Meetup, Japan’s first English-language community for Ruby developers. The goal of the group was to bring together the Japanese and international Ruby communities, and I believe we’ve succeeded. I think my efforts in organizing that community may have been why RubyKaigi chose to adopt Doorkeeper for their event registration. It also helped me connect with some of Mobalean’s best consulting clients. Finally—and most importantly—it indirectly led to developing TokyoDev as a business. The CTO of a local startup said something like, “Paul, I’ve been having trouble hiring developers. I know you’re well-connected with the community. Could I pay you to help hire some?” That CTO, along with others in similar situations, became the first clients for TokyoDev’s job board. Sponsoring existing organizations The methods I’ve talked about so far involve a lot of time but no cost. Sponsoring existing organizations is the opposite: all it requires is money. The cost involved depends on the scale of the sponsorship, and the perceived value of the community. When I saw in TokyoDev’s own data that women software engineers were being compensated worse than men, I wanted to do something about it. The simplest solution I came up with was sponsoring local communities that empower women in technology. I sought out some local organizations and offered to sponsor them, including a few that had never had sponsors before. Since then, TokyoDev has also sponsored local tech conferences, including RubyKaigi. These sponsorships have ranged from 100,000 yen (about 665 USD) on the low end to 1.5 million yen (about 10,000 USD) on the high end. In total, TokyoDev has spent over 8 million yen (about 53,000 USD) on sponsorships. Some of the big-ticket sponsorships have come with booths at conferences, which do provide new opportunities, but also additional costs—staffing the booths, airfare, hotels, etc. The more expensive conference sponsorships have directly resulted in several new clients for the job board, but not yet in any additional revenue (because we take a success-based approach, and those clients haven’t made any hires through us yet). I think for sponsorships to be really cost-effective, the target audience of the community must match your startup perfectly. Part of our challenge has been that many of these communities are primarily composed of Japanese software engineers, who aren’t the main users of TokyoDev. Still, while these sponsorships haven’t been a cost-effective way of improving our bottom line, they have helped communities and gotten the word out, as well as offering some other knock-on benefits. One specific example is from 2024, when we gave away one of our sponsor tickets to a job-hunting developer, and they found a position through a connection they made at the conference. Another example is “in-house.” One of our contractors introduced her daughter to a community we’ve sponsored, which helps young women get into software development. This inspired her daughter to become interested in programming and eventually to enroll in the program—something nobody in her family had anticipated! Growing your own communities While TokyoDev got its start thanks to local, preexisting organizations, we’ve also worked hard to create our own TokyoDev community, both online and off. Running an online community One of the first articles I wrote for TokyoDev was in response to a reader’s question about how I got my job as a developer in Japan. Over the years, I continued to receive emails asking for personalized advice. While I was happy to respond to people individually, it felt like that knowledge could also be of use to other people, so I started a forum using Discourse. Over the years I’d get questions on there, and occasionally someone else might chime in with their experience, but it was mostly just me responding to queries, and so wasn’t anything I’d call a “community.” Along the way, one of our contractors pointed out that it would be nice to create a space where we could casually talk to our users. After he brought it up several times, I made a Discord community. This quickly took off, and currently sits at about 7,000 members. Growing such a community hasn’t been without its challenges. The primary difficulty is moderation—no matter how we handle it, some users feel alienated. Have too soft a hand? The loudest voices win, driving away other valuable contributors. Reprimand or ban people? You make enemies out of what were once fans. I can’t say I’ve always done everything right here, but one thing I did do right was bring on a moderator who cares about the community. Besides having someone to bounce ideas around with, it also helps to have an additional person enforcing the rules. We have seen several benefits from our online community. At least one client made a hire through us that I can directly attribute to our Discord. That said, it’s the indirect benefits that have proven most valuable. For instance, our Discord helped us identify common challenges that developers face when relocating to Japan, making it a good source of topics for articles. We’ve also been able to ask members with unique experiences to write articles for the site, and their posts have been some of the most popular, such as one on Japan’s digital nomad visa. Organizing offline events As our Discord community grew, members started asking us to host offline meetups. We held our first one with a dozen or so people at a space we rented out ourselves, and provided soft drinks. This cost us about 30,000 yen (200 USD). The meetup was a success and we continued to host. Eventually, one of our members offered to hold the meetups at their company. This change allowed us to grow the meetups further, and we started regularly maxing out their capacity with 40 or so attendees. It also meant we only needed to pay for the soft drinks, bringing our cost down to 5,000 yen (33 USD). Not only was that quite cost-effective, but the company hosting the event eventually became a client of ours. We also started using our offline meetings to bring our clients together with the larger developer community, by holding collaborative events where the client gives presentations that are technically interesting to our audience. We’re careful to make sure these aren’t direct recruiting events, as I think that would drive away the very people our clients are looking to hire. By indirectly highlighting why it is interesting to work with them, however, our clients have been able to find more prospects. Initially, we catered these events with pizza and soft drinks, which cost around 30,000 yen (200 USD) for a 40 person event. Since we haven’t been charging clients for organizing these talks, we began asking them to provide food and drinks instead. As a result, these events have been win-win for everyone involved. Our clients get better branding amongst the developer community. Our community members enjoy interesting content and new connections. We establish stronger relationships with everyone involved. In addition to this offline community for software engineers, we’ve also started to build another offline community for the internal recruiters using TokyoDev. We began by hosting small dinners with internal recruiters from three or four different clients. This gave them the opportunity to share about the challenges they faced hiring international engineers. Hosting such a dinner cost us about 30,000 yen (200 USD), and led one company that was on the fence to start using TokyoDev. The dinners have proven to be a big success, and recruiters tell us they want to attend more, but there’s only so much time we can spend on them. To augment these networking meals, we’ve also started holding seminars on the topic of hiring engineers, so we can bring together a larger number of our clients at once. These don’t have quite the impact as the small dinners, but they are more scalable. Conclusion Communities have been key to all of my businesses. If my focus had been solely on maximizing revenues, I think the time and money I’ve spent on community involvement could have been better used elsewhere. But the nice thing about being an entrepreneur is that you get to choose your own metrics for success. And unlike with other business strategies, I can always feel good about what we accomplish. Even if an activity doesn’t create value for me personally, it does for someone else, so my efforts are never wasted. If you’re an entrepreneur looking to combine business and the common good, I recommend finding ways to build your company through the community as well. Whether it’s by spending your own time volunteering, contributing part of your business’s revenues to causes you care about, or building up a community around your brand, all these avenues can help both your enterprise and the public at large.
Japan already stipulates that employers must offer the option of reduced working hours to employees with children under three. However, the Child Care and Family Care Leave Act was amended in May 2024, with some of the new provisions coming into effect April 1 or October 1, 2025. The updates to the law address: Remote work Flexible start and end times Reduced hours On-site childcare facilities Compensation for lost salary And more Legal changes are one thing, of course, and social changes are another. Though employers are mandated to offer these options, how many employees in Japan actually avail themselves of these benefits? Does doing so create any stigma or resentment? Recent studies reveal an unsurprising gender disparity in accepting a modified work schedule, but generally positive attitudes toward these accommodations overall. The current reduced work options Reduced work schedules for employees with children under three years old are currently regulated by Article 23(1) of the Child Care and Family Care Leave Act. This Article stipulates that employers are required to offer accommodations to employees with children under three years old. Those accommodations must include the opportunity for a reduced work schedule of six hours a day. However, if the company is prepared to provide alternatives, and if the parent would prefer, this benefit can take other forms—for example, working seven hours a day or working fewer days per week. Eligible employees for the reduced work schedule are those who: Have children under three years old Normally work more than six hours a day Are not employed as day laborers Are not on childcare leave during the period to which the reduced work schedule applies Are not one of the following, which are exempted from the labor-management agreement Employees who have been employed by the company for less than one year Employees whose prescribed working days per week are two days or less Although the law requires employers to provide reduced work schedules only while the child is under three years old, some companies allow their employees with older children to work shorter hours as well. According to a 2020 survey by the Ministry of Health, Labor and Welfare, 15.8% of companies permit their employees to use the system until their children enter primary school, while 5.7% allow it until their children turn nine years old or enter third grade. Around 4% offer reduced hours until children graduate from elementary school, and 15.4% of companies give the option even after children have entered middle school. If, considering the nature or conditions of the work, it is difficult to give a reduced work schedule to employees, the law stipulates other measures such as flexible working hours. This law has now been altered, though, to include other accommodations. Updates to The Child Care and Family Care Leave Act Previously, remote work was not an option for employees with young children. Now, from April 1, 2025, employers must make an effort to allow employees with children under the age of three to work remotely if they choose. From October 1, 2025, employers are also obligated to provide two or more of the following measures to employees with children between the ages of three and the time they enter elementary school. An altered start time without changing the daily working hours, either by using a flex time system or by changing both the start and finish time for the workday The option to work remotely without changing daily working hours, which can be used 10 or more days per month Company-sponsored childcare, by providing childcare facilities or other equivalent benefits (e.g., arranging for babysitters and covering the cost) 10 days of leave per year to support employees’ childcare without changing daily working hours A reduced work schedule, which must include the option of 6-hour days How much it’s used in practice Of course, there’s always a gap between what the law specifies, and what actually happens in practice. How many parents typically make use of these legally-mandated accommodations, and for how long? The numbers A survey conducted by the Ministry of Health, Labor and Welfare in 2020 studied uptake of the reduced work schedule among employees with children under three years old. In this category, 40.8% of female permanent employees (正社員, seishain) and 21.6% of women who were not permanent employees answered that they use, or had used, the reduced work schedule. Only 12.3% of male permanent employees said the same. The same survey was conducted in 2022, and researchers found that the gap between female and male employees had actually widened. According to this second survey, 51.2% of female permanent employees and 24.3% of female non-permanent employees had reduced their hours, compared to only 7.6% of male permanent employees. Not only were fewer male employees using reduced work programs, but 41.2% of them said they did not intend to make use of them. By contrast, a mere 15.6% of female permanent employees answered they didn’t wish to claim the benefit. Of those employees who prefer the shorter schedule, how long do they typically use the benefit? The following charts, using data from the 2022 survey, show at what point those employees stop reducing their hours and return to a full-time schedule. Female permanent employees Female non-permanent employees Male permanent employees Male non-permanent employees Until youngest child turns 1 13.7% 17.9% 50.0% 25.9% Until youngest child turns 2 11.5% 7.9% 14.5% 29.6% Until youngest child turns 3 23.0% 16.3% 10.5% 11.1% Until youngest child enters primary school 18.9% 10.5% 6.6% 11.1% Sometime after the youngest child enters primary school 22.8% 16.9% 6.5% 11.1% Not sure 10% 30.5% 11.8% 11.1% From the companies’ perspectives, according to a survey conducted by the Cabinet Office in 2023, 65.9% of employers answered that their reduced work schedule system is fully used by their employees. What’s the public perception? Some fear that the number of people using the reduced work program—and, especially, the number of women—has created an impression of unfairness for those employees who work full-time. This is a natural concern, but statistics paint a different picture. In a survey of 300 people conducted in 2024, 49% actually expressed a favorable opinion of people who work shorter hours. Also, 38% had “no opinion” toward colleagues with reduced work schedules, indicating that 87% total don’t negatively view those parents who work shorter hours. While attitudes may vary from company to company, the public overall doesn’t seem to attach any stigma to parents who reduce their work schedules. Is this “the Mommy Track”? Others are concerned that working shorter hours will detour their career path. According to this report by the Ministry of Health, Labour and Welfare, 47.6% of male permanent employees indicated that, as the result of working fewer hours, they had been changed to a position with less responsibility. The same thing happened to 65.6% of male non-permanent employees, and 22.7% of female permanent employees. Therefore, it’s possible that using the reduced work schedule can affect one’s immediate chances for advancement. However, while 25% of male permanent employees and 15.5% of female permanent employees said the quality and importance of the work they were assigned had gone down, 21.4% of male and 18.1% of female permanent employees said the quality had gone up. Considering 53.6% of male and 66.4% of female permanent employees said it stayed the same, there seems to be no strong correlation between reducing one’s working hours, and being given less interesting or important tasks. Reduced work means reduced salary These reduced work schedules usually entail dropping below the originally-contracted work hours, which means the employer does not have to pay the employee for the time they did not work. For example, consider a person who normally works 8 hours a day reducing their work time to 6 hours a day (a 25% reduction). If their monthly salary is 300,000 yen, it would also decrease accordingly by 25% to 225,000 yen. Previously, both men and women have avoided reduced work schedules, because they do not want to lose income. As more mothers than fathers choose to work shorter hours, this financial burden tends to fall more heavily on women. To address this issue, childcare short-time employment benefits (育児時短就業給付) will start from April 2025. These benefits cover both male and female employees who work shorter hours to care for a child under two years old, and pay a stipend equivalent to 10% of their adjusted monthly salary during the reduced work schedule. Returning to the previous example, this stipend would grant 10% of the reduced salary, or 22,500 yen per month, bringing the total monthly paycheck to 247,500 yen, or 82.5% of the normal salary. This additional stipend, while helpful, may not be enough to persuade some families to accept shorter hours. The childcare short-time employment benefits are available to employees who meet the following criteria: The person is insured, and is working shorter hours to care for a child under two years old. The person started a reduced work schedule immediately after using the childcare leave covered by childcare leave benefits, or the person has been insured for 12 months in the two years prior to the reduced work schedule. Conclusion Japan’s newly-mandated options for reduced schedules, remote work, financial benefits, and other childcare accommodations could help many families in Japan. However, these programs will only prove beneficial if enough employees take advantage of them. As of now, there’s some concern that parents who accept shorter schedules could look bad or end up damaging their careers in the long run. Statistically speaking, some of the news is good: most people view parents who reduce their hours either positively or neutrally, not negatively. But other surveys indicate that a reduction in work hours often equates to a reduction in responsibility, which could indeed have long-term effects. That’s why it’s important for more parents to use these accommodations freely. Not only will doing so directly benefit the children, but it will also lessen any negative stigma associated with claiming them. This is particularly true for fathers, who can help even the playing field for their female colleagues by using these perks just as much as the mothers in their offices. And since the state is now offering a stipend to help compensate for lost income, there’s less and less reason not to take full advantage of these programs.
Since November 2023, I’ve been living in Karuizawa, a small resort town that’s 70 minutes away from Tokyo by Shinkansen. The elevation is approximately 1000 meters above sea level, making the summers relatively mild. Unlike other colder places in Japan, it doesn’t get much snow, and has the same sunny winters I came to love in Tokyo. With COVID and the remote work boom, it’s also become popular among professionals such as myself who want to live somewhere with an abundance of nature, but who still need to commute into Tokyo on a semi-regular basis. While I have a home office, I sometimes like to work outside. So I thought I’d share my impressions of the coworking spaces in town that I’ve personally visited, and a few other places where you can get some work done when you’re in town. Sawamura Roastery 11am on a Friday morning and there was only one other customer. Sawamura Roastery is technically a cafe, but it’s my personal favourite coworking space. It has free wifi, outlets, and comfortable chairs. While their coffees are on the expensive side, at about 750 yen for a cafe latte, they are also some of Karuizawa’s best. It’s empty enough on weekday mornings that I feel fine about staying there for hours, making it a deal compared to official drop-in coworking spaces. Another bonus is that it opens early: 7 a.m. (or 8 a.m. during the winter months). This allows me to start working right after I drop off my kids at daycare, rather than having 20 odd minutes to kill before heading to the other places that open at 9 a.m. If you’re having an online meeting, you can make use of the outdoor seating. It’s perfect when the weather is nice, but they also have heating for when it isn’t. The downsides are that their playlist is rather short, so I’m constantly hearing the same songs, and their roasting machine sometimes gets quite noisy. Gokalab Gokalab is my favourite dedicated coworking space in Karuizawa. Technically it is in Miyota, the next town over, which is sometimes called “Nishikaruizawa”. But it’s the only coworking space in the area I’ve been to that feels like it has a real community. When you want to work here, you have three options: buy a drink (600 yen for a cafe au lait—no cafe lattes, unfortunately, but if you prefer black coffee they have a good selection) and work out of the cafe area on the first floor; pay their daily drop-in fee of 1,000 yen; or become a “researcher” (研究員, kenkyuin) for 3,000 yen per month and enjoy unlimited usage. Now you may be thinking that the last option is a steal. That’s because it is. However, to become a researcher you need to go through a workshop that involves making something out of LEGO, and submit an essay about why you want to use the space. The thinking behind this is that they want to support people who actually share their vision, and aren’t just after a cheap space to work or study. Kind of zany, but that sort of out-of-the-box thinking is exactly what I want in a coworking space. When I first moved to Karuizawa, my youngest child couldn’t get into the local daycare. However, we found out that in Miyota, Suginoko Kindergarten had part-time spots available for two year olds. My wife and I ended up taking turns driving my kid there, and then spending the morning working out of Gokalab. Since my youngest is now in a local daycare, I haven’t made it out to Gokalab much. It’s just a bit too far for me (about a 15-minute drive from my house, while other options on this list are at most a 15-minute bicycle ride). But if I was living closer, I’d be a regular there. 232 Coworking Space & Hotel Noon on a Monday morning at 232 Coworking Space. If you’re looking for a coworking space near Karuizawa station, 232 Coworking Space & Hotel is the best option I’ve come across. The “hotel” part of the name made me think they were focused on “workcations,” but the space seems like it caters to locals as well. The space offers free coffee via an automatic espresso machine, along with other drinks, and a decent number of desks. When I used it on a Monday morning in the off-season, it was moderately occupied at perhaps a quarter capacity. Everyone spoke in whispers, so it felt a bit like a library. There were two booths for calls, but unfortunately they were both occupied when I wanted to have mine, so I had to sit in the hall instead. If the weather was a bit warmer I would have taken it outside, as there was some nice covered seating available. The decor was nice, though the chairs weren’t that comfortable. After a couple of hours I was getting sore. It was also too dimly lit for me, without much natural light. The price for drop-ins is reasonable, starting at 1,500 yen for four hours. They also have monthly plans starting from 10,000 yen for five days per month. WhatI found missing was a feeling of community. I didn’t see any small talk between the people working there, though I was only there for a couple hours, and maybe this occurs at other times. Their webpage also mentioned that they host events, but apparently they don’t have any upcoming ones planned and haven’t had any in a while. Shozo Coffee Karuizawa The latte is just okay here, but the atmosphere is nice. Shozo Coffee Karuizawa is a cafe on the first floor of the bookstore in Karuizawa Commongrounds. The second floor has a dedicated coworking space, but for me personally, the cafe is a better deal. Their cafe latte is mid-tier and 700 yen. In the afternoons I’ll go for their chai to avoid over-caffeination. They offer free wifi and have signs posted asking you not to hold online meetings, implicitly making it clear that otherwise they don’t mind you working there. Location-wise, this place is very convenient for me, but it suffers from a fatal flaw that prevents me from working there for an extended amount of time: the tables are way too low for me to type comfortably. I’m tall though (190 cm), so they aren’t designed with me in mind. Sheridan Coffee and a popover \- my entrance fee to this “coworking space”. Sheridan is a western breakfast and brunch restaurant. They aren’t that busy on weekdays and have free wifi, plus the owner was happy to let me work there. The coffee comes in a pot with enough for at least one refill. There’s also some covered outdoor seating. I used this spot to get some work done when my child was sick and being looked after at the wonderful Hochi Lodge (ほっちのロージ). It’s a clinic and sick childcare facility that does its best to not let on that it’s a medical facility. The doctors and nurses don’t wear uniforms, and appointments there feel more like you’re visiting someone’s home. Sheridan is within walking distance of it. Natural Cafeina An excellent cappuccino but only an okay place to work. If you’d like to get a bit of work done over an excellent cappuccino, Natural Cafeina is a good option. This cafe feels a bit cramped, and as there isn’t much seating, I wouldn’t want to use it for an extended period of time. Also, the music was also a bit loud. But they do have free wifi, and when I visited, there were a couple of other customers besides myself working there. Nakakaruizawa Library The Nakakaruizawa Library is a beautiful space with plenty of desks facing the windows and free wifi. Anyone can use it for free, making it the most economical coworking space in town. I’ve tried working out of it, but found that, for me personally, it wasn’t conducive to work. It is still a library, and there’s something about the vibes that just doesn’t inspire me. Karuizawa Commongrounds Bookstore Coworking Space The renowned bookstore Tsutaya operates Karuizawa Books in the Karuizawa Commongrounds development. The second floor has a coworking space that features the “cheap chic” look common among hip coworking spaces. Unfinished plywood is everywhere, as are books. I’d never actually worked at this space until writing this article. The price is just too high for me to justify it, as it starts at 1,100 yen for a mere hour, to a max of 4,000 yen per day. At 22,000 yen per month, it’s a more reasonable price for someone using it as an office full time. But I already have a home office and just want somewhere I can drop in at occasionally. There are a couple options, seating-wise. Most of the seats are in booths, which I found rather dark but with comfortable chairs. Then there’s a row of stools next to the window, which offer a good view, but are too uncomfortable for me. Depending on your height, the bar there may work as a standing desk. Lastly, there are two coveted seats with office chairs by a window, but they were both occupied when I visited. The emphasis here seems to be on individual deep work, and though there were a number of other people working, I’d have felt uncomfortable striking up a conversation with one of them. That’s enough to make me give it a pass. Coworking Space Ikoi Villa Coworking Space Ikoi Villa is located in Naka-Karuizawa, relatively close to my home. I’ve only used it once though. It’s part of a hotel, and they converted the lobby to a coworking space by putting a bunch of desks and chairs in it. If all you need is wifi and space to work, it gets the job done. But it’s a shame they didn’t invest a bit more in making it feel like a nice place to work. I went during the summer on one of the hottest days. My house only had one AC unit and couldn’t keep up, so I was hoping to find somewhere cooler to work. But they just had the windows open with some fans going, which left me disappointed. This was ostensibly the peak season for Karuizawa, but only a couple of others were working there that day. Maybe the regulars knew it’d be too hot, but it felt kind of lonely for a coworking space. The drop-in fee starts at 1,000 yen for four hours. It comes with free drinks from a machine: green tea, coffee, and water, if I recall correctly. Karuizawa Prince The Workation Core Do you like corporate vibes? Then this is the place for you. Karuizawa Prince The Workation Core is a coworking space located in my least favourite part of the town—the outlet mall. The throngs of shoppers and rampant commercialism are in stark contrast to the serenity found farther away from the station. This is another coworking space I visited expressly for this article. The fee is 660 yen per 30 minutes, to a maximum of 6,336 yen per day. Even now, just reading that maximum, my heart skipped a beat. This is certainly the most expensive coworking space I’ve ever worked from—I better get this article done fast. The facilities include a large open space with reasonably comfortable seating. There are a number of booths with monitors. As they are 23.8 inch monitors with 1,920 x 1,080 resolution, they’re a step down from the resolution of modern laptops, and so not of much use. Though there was room for 40 plus people, I was the only person working . Granted this was on a Sunday morning, so not when most people would typically attend. I don’t think I’ll be back here again. The price and sterile corporate vibe just aren’t for me. If you’re staying at The Prince Hotel, I think you get a discount. In that case, maybe it’s worth it, but otherwise I think there are better options. Sawamura Bakery & Restaurant Kyukaruizawa Sawamura Bakery & Restaurant is across the street from the Roastery. It offers slightly cheaper prices, with about 100 yen off the cafe latte, though the quality is worse, as is the vibe of the place as a whole. They do have a bigger selection of baked goods, though. As a cafe for doing some work, there’s nothing wrong with it per se. The upstairs cafe area has ample seating outside of peak hours. But I just don’t have a good reason to work here over the Roastery. The Pie Hole Los Angles Karuizawa The best (and only) pecan pie that I’ve had in Japan. The name of this place is a mouthful. Technically, it shouldn’t be on this list because I’ve never worked out of it. But they have wonderful pie, free wifi, and not many customers, so I could see working here. The chairs are a bit uncomfortable though, so I wouldn’t want to stop by for more than an hour or two. While this place had been on my radar for a while, I’d avoided it because there’s no good bicycle parking nearby—-or so I thought. I just found that the relatively close Church Street shopping street has a bit of bicycle parking off to the side. If you come to Karuizawa… When I was living in Tokyo, there were just too many opportunities to meet people, and so I found myself having to frequently turn down offers to go out for coffee. Since moving here, I’ve made some local connections, but the pace has been a lot slower. If you’re ever passing through Karuizawa, do get in touch, and I’d be happy to meet up for a cafe latte and possibly some pie.
TokyoDev has already reported that Japan really needs international developers. But the more Japanese companies we’ve interviewed, the more we’ve realized that a talent shortage is not the only reason for Japanese companies to hire from overseas. There are a host of other advantages to recruiting internationally, and a growing number of managers are beginning to recognize the benefits. To gain more perspective on how multinational teams enhance their Japanese companies, we conducted interviews with the following businesses: Autify, which provides an AI-based software test automation platform Beatrust, which provides solutions to help companies maximize their human capital Cybozu, Japan’s leading groupware provider DeepX, which automates heavy equipment machinery Givery, which scouts, hires, and trains world-class engineers KOMOJU by Degica, a payment processor MODE, which pioneers innovative solutions to connect the digital and physical worlds Yaraku, which offers web-based translation management Below we’ve compiled the top reasons they gave for hiring international developers, and the specific ways in which those developers have improved their businesses. These range from the obvious—a greater talent pool to draw from—to surprising and even counterintuitive upsides, such as improved domestic recruiting and sheer enjoyment. The global talent pool Because Japan is suffering a developer shortage, and particularly lacks specialized and senior engineers, Japanese companies are expanding their recruiting efforts worldwide to find the staff and skill sets they need. That was DeepX’s initial motive for hiring international engineers: they needed employees with advanced technical skills. At first, when the company was founded in 2016, DeepX only intended to hire Japanese engineers. However, robotics is a fairly rare specialty in Japan, and those engineers who have studied it were reluctant to work at a newly-formed startup. Consequently, in 2018, DeepX hired their first international engineer; now they employ engineers from 20 different countries. Givery ran into the same issue. Though founded in 2009, the company spent five years trying to find enough staff to develop its B2C programming learning service, but struggled to attract talent because the company wasn’t yet well-known in Japan. In 2014 they received an application from a recruitment service, for an international front-end engineer who didn’t speak much Japanese. Since management was already discussing how best to globalize, they decided to seize this opportunity, despite the fact that many managers did not speak English. Seven years later, half of Givery’s development team of 120 are non-Japanese and hail from 20 different countries. The immediate benefits of widening the applicant pool speak for themselves. However Makoto Mizukami, head of Customer Engineering at KOMOJU by Degica, thinks recruiting internationally isn’t just a solution for today: it’s future-proofing. Because Japan is facing a declining and aging population, Mizukami believes that companies will face increased long-term risks if they insist on only hiring Japanese employees. In order for companies to survive, they must expand the range of people they employ. According to Mizukami, this applies to more than international engineers: companies must create an environment that can accept a highly diverse range of workers, including immigrants, women, people with disabilities, and the elderly. As will be seen later in this article, hiring international workers often has the side effect of creating a more favorable work environment for all. Recruiting at home But hiring international workers has a surprising secondary benefit: it improves domestic recruitment as well. KOMOJU found this out firsthand when they hired Shogo Ito as Staff SRE, since his primary motivation for joining KOMOJU was to improve his English. In Ito’s previous job, while he’d had the opportunity to collaborate with overseas teams, he hadn’t felt immersed in an English environment. But since at KOMOJU English is the primary form of communication, Ito felt confident he’d have a chance there to improve his skills. Givery has also benefited from this trend. It was their initial struggle to find engineers locally that led them to recruit internationally. As their multinational development team grew, though, they discovered that their diversity attracted more Japanese talent as well. As a result, Givery is one of the few tech companies in Japan to meet its recruitment goals on a regular basis. International knowledge Companies that hire internationally usually discover that their new employees bring more to the table than expected. It’s not just a question of tech skills—they carry with them fresh information that broadens companies’ knowledge bases overall. In the case of Beatrust, information from international employees contributes directly to their product. “We have a talent collaboration platform,” explained Dr. Andreas Dippon, the Vice President of Engineering at Beatrust. “The focus is [helping] employees better work with each other. Currently we’re focused on selling this product to big clients in Japan, which all already have some diversification. “Of course in Japan it’s mainly Japanese people, but you also have international engineers joining the big companies as well. So how can we support them collaborating in their company where there’s a language barrier, where there are cultural differences?” Having engineers of different backgrounds, especially with our product, helps us better understand how users think. KOMOJU also credits their global team with improving their product. As every country has unique payment methods and financial rules, the “insider knowledge” of employees from that country has proven invaluable. KOMOJU specifically cited China, which uses a number of payment methods such as Alipay and WeChat Pay that are unfamiliar in Japan; according to them, Chinese employees have been extremely helpful in explaining those systems to the rest of the team. Mizukami gave another example of international knowledge proving helpful. A user who had a free Chinese email address was flagged by the fraud detection system. At that time, Mizukami said, a Chinese engineer told them that “People who use this address cannot be trusted, so it’s okay to ignore it.” With that engineer’s assistance, the team was able to respond to the situation appropriately. Other tech companies we spoke to cited the benefits of international knowledge more generally, but Cybozu in particular knows the value of global perspectives. An earlier attempt to take their product, Cybozu Office, to the US via a subsidiary failed—in part, executives decided, due to differences in business customs between the US and Japan. That was why, in 2022, Cybozu approached international expansion differently. This time they created the New Business Division, an English-first multinational development team specifically designed to help Cybozu adapt existing products to the global market. In addition, the team has been tasked with building new products from the ground up, with an international audience in mind. Staying abreast of new tech Another plus to hiring international engineers, and particularly those who speak English, is earlier access to new tools and technology. Ito at KOMOJU pointed out that information on new services and tools is usually spread through English online media, and that most Japanese engineers don’t keep up with English articles on the subject. This means that, until someone writes an “I tried it” style post in Japanese, information on the latest developments isn’t readily available to Japanese developers. Having international engineers on the team, who are accustomed to scanning the English-language web for new tools and methods, accelerates the process. In addition, since KOMOJU’s official company language is English, there’s no concern about finding software with a Japanese UI, which greatly expands their options. Ito explained that KOMOJU uses services that are not very familiar in Japan, such as JumpCloud, Tenable, Vanta, and Honeybadger. Takuma Tatsumi, a recruiter for Yaraku, confirmed that the latest technology is overwhelmingly in English, leading to asymmetry of information. Even at previous companies, Japanese CTOs would ask the international engineers, “What are the current technology trends?” But since Yaraku has hired a number of international members, they’re now able to keep up with the latest development trends and incorporate new technology when it is, in fact, new. Changes in work environment Most Japanese companies with multinational teams end up making substantial culture changes to accommodate international employees. This could be considered a downside; instead, those we spoke to agree that the evolution of their company’s work environment was one of the top benefits of international recruitment. “The advantage I can see is with a mix of mindsets and [thoughts on the] future of work from so many different places,” said Thomas Santonja, VP of Engineering at Autify. I found a lot of very, very rich discussions about what to do, what not to do, and why, and a lot of debate, which is at least in my experience rarer in a pure Japanese environment. “Canadian and American staff are the ones that are the most vocal about why and how to do stuff, and [they] try to engage to get other people’s opinions,” he added. “That actually created a culture which is not necessarily super common. . . . I believe injecting a North American mindset in the mix is very valuable for a Japanese company, from my side of the fence.” Scott Tullis, head of Global Recruiting at MODE, also endorsed a mix of non-Japanese and Japanese work styles. “We’re a unique hybrid,” he said. Thanks to our Bay Area origins, we have the Silicon Valley tech startup culture in terms of entrepreneurship and innovation, and we also incorporate some of the great aspects of Japanese work culture around teamwork and collaboration. “We’re fortunate to not have any of the more notorious elements of Silicon Valley startup culture here,” he added. “The term ‘bro culture’ comes to mind and is well known in the Bay Area, which we thankfully do not have at MODE. Rather, we foster a more collaborative, thoughtful, and humble culture where people are truly trusted.” While the Japanese side of the company has inspired an atmosphere of humility and cooperation, the American side has contributed a fully remote work policy which, as Tullis pointed out, “is a relatively newer concept in Japan.” “We have offices in San Mateo and Tokyo, as it’s still important to have face-to-face interactions to collaborate effectively and continuously build our culture,” he said. “At the same time, the option to work remotely makes our work environment very flexible, which is beneficial for many team members, especially working parents. Our team comes from a diverse range of backgrounds, so this flexibility is key to better meeting the needs of each individual.” When it comes to work policy, Dippon at Beatrust has leaned on his European background. “ So I come from Germany, with German work culture,” he said, “which is like, we take care to take holidays and take time off and don’t do immense overwork and so on. So I try to bring that culture into my team, which is often difficult, because especially [people from] Japan, China, Taiwan, and so on—they used to work lots of overtime all the time.” So when I told them, ‘Please take the day off,’ and they said, ‘Okay, I’ll take the day off, but I can work in the morning and evening,’ I told them, ‘No, take the day off, don’t come in.’ They were confused at first, but over time I think they adapted to some extent, and now they really enjoy it, and when they come back they come back fully-refreshed and eager. That being said, Dippon takes great care not to impose his own European work paradigms too much. In fact, he finds the cultural differences amongst his team members both fascinating and useful. “Every day is very interesting,” he said. “You learn a lot about their countries, about their work style, and you can benefit from their experience in their work style as well.” Like Santonja, Dippon has noted how international hires lead to a more open style of communication. “The culture benefit is huge . . . when you can foster open communication in your engineering team, which we have achieved now. . . . So everybody can clearly state their opinion and not hold back,” Dippon said. “Which is very different from Japanese culture, from what I’ve heard,” Dippon added. “Even the Japanese people we have, they like that, so they can clearly say their opinion without having to fear any rejection.” All three of the executives quoted above are, notably, international hires themselves. But many Japanese managers also cite the benefits of adapting their company’s work environment. In fact, Tatsumi of Yaraku compared the company’s international members to the introduction of Western culture into Japan at the end of the Edo period, which led to profound cultural changes. Makiko Nakayama, Yaraku’s Human Resources manager, agreed with this. Foreign members are very frank about the issues they face, which is why we’ve created an environment that’s easy for them to work in. Those changes include a new approach to employee communication and collaboration. When work output is low or the team runs into difficulties, rather than immediately thinking, “Maybe someone is slacking off,” Yaraku employees tend to ask, “Why is it like this?” and “How can we improve it?” They said that the chance to actively communicate and think of ways to improve together creates a cooperative corporate culture, which has become one of the biggest attractions of working at Yaraku. International hires also led to new policies around paid leave. As Nakayama explained, employees from overseas told HR, “It takes four days to go home and back, so even if I use my paid leave, I really don’t have much time to rest.” As a result, Yaraku now allows employees to work remotely overseas for 30 days a year. Likewise, DeepX reported that its foreign engineers enjoy their new holiday substitute leave system. This system allows engineers to take a lump sum of vacation any time they like, by treating normal Japanese holidays as working days, and granting the same number of paid holidays. In this way, engineers can take longer vacations when returning to their home countries. But according to Satomi Makino, the system isn’t just used by international hires—many Japanese engineers are happy to take advantage of it as well. I feel DeepX is a comfortable working environment that incorporates the good points of overseas companies. In our interview with Givery, they offered some specific recommendations to other Japanese companies looking to build multinational teams. They suggested starting hiring early in the formation of the company, before internal policies had been well-established. Their newly-hired international employees, Givery’s management found, had different needs and expectations from their Japanese workers. For example, international engineers made requests like, “Can I go to the gym for two hours during lunch?” or “I want to go back to my home country in December. Can I take a month off?” Because Givery didn’t have too many procedures in place, it was able to consider suggestions like these and implement more flexible, globalized workplace practices. If Givery had waited to build its multinational development team until its policies were more firmly established, it may have struggled more to adapt to the needs of its international employees. It’s fun It may seem like an odd consideration, but multiple interviewees cited an interesting reason for hiring international employees—it’s fun! Yaraku’s engineering team was born out of CEO Suguru Sakanishi’s question to himself: What would happen if I created a global engineering team in my own company? Before founding Yaraku, Sakanishi had previously been to the US and worked in an international environment. This experience made him realize how fun it is to work with people from various backgrounds, and inspired him to hire people from abroad. KOMOJU shared a story about a newly-hired Indonesian member’s introduction to Japan. In Indonesia he had a 10 megabit Internet line for 6,000 yen a month; then he learned that in Japan, he could get a 10 gigabit line for the same price. The new hire was so surprised he exclaimed, ‘What’s going on?!’ The whole team enjoyed hearing that and sharing in his excitement. Members at KOMOJU believe that seeing and appreciating cultural differences, especially through casual conversations like this, is one of the unique attractions of multinational teams. Dippon, at Beatrust, describes this kind of cultural sharing as “one of the biggest pluses for me.” It’s so interesting, sitting together after work and talking about, ‘Oh, what’s going on in your country?’ . . . You get this kind of information in the news and so on, but you almost never hear from a person from that country. Conclusion For developers interested in working at Japanese companies, these interviews should offer insight into why Japanese managers are also interested in hiring them. Most businesses like these are looking for candidates who can bring more to the table than their work skills alone. They’re searching for applicants who can contribute the international knowledge and English proficiency that their teams need to level up. These companies also don’t necessarily expect candidates to conform to Japanese business norms. In fact, employees who forthrightly (but politely) explain their needs and expectations can benefit all the workers at the company, not just those from overseas. That being said, developers should be prepared to meet these companies halfway, mostly by being genuinely interested in Japan. It isn’t just a question of being willing to adapt to a new country: these managers appreciate the fun and interest of employing someone from another culture, so they’re keen to share their own as well. As Yaraku put it, they place importance on whether or not the candidate is specifically interested in this country, because that’s one of the greatest values that Yaraku can offer: “enjoying Japan.” To learn more about how you can work in (and enjoy) Japan, check out our job board or extensive library of articles. To continue the conversation, join the TokyoDev Discord.
More in programming
I have added syntax highlighting to my blog using tree-sitter. Here are some notes about what I learned, with some complaining. static site generator markdown ingestion highlighting incompatible?! highlight names class names styling code results future work frontmatter templates feed style highlight quality static site generator I moved my blog to my own web site a few years ago. It is produced using a scruffy Rust program that converts a bunch of Markdown files to HTML using pulldown-cmark, and produces complete pages from Handlebars templates. Why did I write another static site generator? Well, partly as an exercise when learning Rust. Partly, since I wrote my own page templates, I’m not going to benefit from a library of existing templates. On the contrary, it’s harder to create new templates that work with a general-purpose SSG than write my own simpler site-specific SSG. It’s miserable to write programs in template languages. My SSG can keep the logic in the templates to a minimum, and do all the fiddly stuff in Rust. (Which is not very fiddly, because my site doesn’t have complicated navigation – compared to the multilevel menus on www.dns.cam.ac.uk for instance.) markdown ingestion There are a few things to do to each Markdown file: split off and deserialize the YAML frontmatter find the <cut> or <toc> marker that indicates the end of the teaser / where the table of contents should be inserted augment headings with self-linking anchors (which are also used by the ToC) Before this work I was using regexes to do all these jobs, because that allowed me to treat pulldown-cmark as a black box: Markdown in, HTML out. But for syntax highlighting I had to be able to find fenced code blocks. It was time to put some code into the pipeline between pulldown-cmark’s parser and renderer. And if I’m using a proper parser I can get rid of a few regexes: after some hacking, now only the YAML frontmatter is handled with a regex. Sub-heading linkification and ToC construction are fiddly and more complicated than they were before. But they are also less buggy: markup in headings actually works now! Compared to the ToC, it’s fairly simple to detect code blocks and pass them through a highlighter. You can look at my Markdown munger here. (I am not very happy with the way it uses state, but it works.) highlighting As well as the tree-sitter-highlight documentation I used femark as an example implementation. I encountered a few problems. incompatible?! I could not get the latest tree-sitter-highlight to work as described in its documentation. I thought the current tree-sitter crates were incompatible with each other! For a while I downgraded to an earlier version, but eventually I solved the problem. Where the docs say, let javascript_language = tree_sitter_javascript::language(); They should say: let javascript_language = tree_sitter::Language::new( tree_sitter_javascript::LANGUAGE ); highlight names I was offended that tree-sitter-highlight seems to expect me to hardcode a list of highlight names, without explaining where they come from or what they mean. I was doubly offended that there’s an array of STANDARD_CAPTURE_NAMES but it isn’t exported, and doesn’t match the list in the docs. You mean I have to copy and paste it? Which one?! There’s some discussion of highlight names in the tree-sitter manual’s “syntax highlighting” chapter, but that is aimed at people who are writing a tree-sitter grammar, not people who are using one. Eventually I worked out that tree_sitter_javascript::HIGHLIGHT_QUERY in the tree-sitter-highlight example corresponds to the contents of a highlights.scm file. Each @name in highlights.scm is a highlight name that I might be interested in. In principle I guess different tree-sitter grammars should use similar highlight names in their highlights.scm files? (Only to a limited extent, it turns out.) I decided the obviously correct list of highlight names is the list of every name defined in the HIGHLIGHT_QUERY. The query is just a string so I can throw a regex at it and build an array of the matches. This should make the highlighter produce <span> wrappers for as many tokens as possible in my code, which might be more than necessary but I don’t have to style them all. class names The tree-sitter-highlight crate comes with a lightly-documented HtmlRenderer, which does much of the job fairly straightforwardly. The fun part is the attribute_callback. When the HtmlRenderer is wrapping a token, it emits the start of a <span then expects the callback to append whatever HTML attributes it thinks might be appropriate. Uh, I guess I want a class="..." here? Well, the highlight names work a little bit like class names: they have dot-separated parts which tree-sitter-highlight can match more or less specifically. (However I am telling it to match all of them.) So I decided to turn each dot-separated highlight name into a space-separated class attribute. The nice thing about this is that my Rust code doesn’t need to know anything about a language’s tree-sitter grammar or its highlight query. The grammar’s highlight names become CSS class names automatically. styling code Now I can write some simple CSS to add some colours to my code. I can make type names green, code span.hilite.type { color: #aca; } If I decide builtin types should be cyan like keywords I can write, code span.hilite.type.builtin, code span.hilite.keyword { color: #9cc; } results You can look at my tree-sitter-highlight wrapper here. Getting it to work required a bit more creativity than I would have preferred, but it turned out OK. I can add support for a new language by adding a crate to Cargo.toml and a couple of lines to hilite.rs – and maybe some CSS if I have not yet covered its highlight names. (Like I just did to highlight the CSS above!) future work While writing this blog post I found myself complaining about things that I really ought to fix instead. frontmatter I might simplify the per-page source format knob so that I can use pulldown-cmark’s support for YAML frontmatter instead of a separate regex pass. This change will be easier if I can treat the html pages as Markdown without mangling them too much (is Markdown even supposed to be idempotent?). More tricky are a couple of special case pages whose source is Handlebars instead of Markdown. templates I’m not entirely happy with Handlebars. It’s a more powerful language than I need – I chose Handlebars instead of Mustache because Handlebars works neatly with serde. But it has a dynamic type system that makes the templates more error-prone than I would like. Perhaps I can find a more static Rust template system that takes advantage of the close coupling between my templates and the data structure that describes the web site. However, I like my templates to be primarily HTML with a sprinkling of insertions, not something weird that’s neither HTML nor Rust. feed style There’s no CSS in my Atom feed, so code blocks there will remain unstyled. I don’t know if feed readers accept <style> tags or if it has to be inline styles. (That would make a mess of my neat setup!) highlight quality I’m not entirely satisfied with the level of detail and consistency provided by the tree-sitter language grammars and highlight queries. For instance, in the CSS above the class names and property names have the same colour because the CSS highlights.scm gives them the same highlight name. The C grammar is good at identifying variables, but the Rust grammar is not. Oh well, I guess it’s good enough for now. At least it doesn’t involve Javascript.
Simplify complex decisions by separating upsides from downsides, investing in upsides, vetoing with downsides, and using an appropriate decision framework.
I've been running Linux, Neovim, and Framework for a year now, but it easily feels like a decade or more. That's the funny thing about habits: They can be so hard to break, but once you do, they're also easily forgotten. That's how it feels having left the Apple realm after two decades inside the walled garden. It was hard for the first couple of weeks, but since then, it’s rarely crossed my mind. Humans are rigid in the short term, but flexible in the long term. Blessed are the few who can retain the grit to push through that early mental resistance and reach new maxima. That is something that gets harder with age. I can feel it. It takes more of me now to wipe a mental slate clean and start over. To go back to being a beginner. But the reward for learning something new is as satisfying as ever. But it's also why I've tried to be modest with the advocacy. I don't know if most developers are better off on Linux. I mean, I believe they are, at some utopian level, especially if they work for the web, using open source tooling. But I don't know if they are as humans with limited will or capacity for change. Of course, it's fair to say that one doesn't want to. Either because one remain a fan of Apple, in dire need of the remaining edge MacBooks retain on efficiency/battery, or simply content inside the ecosystem. There are plenty of reasons why someone might not want to change. It's not just about rigidity. Besides, it's a dead end trying to convince anyone of an alternative with the sharp end of a religious argument. That kind of crusading just seeds resentment and stubbornness. I know that all too well. What I've found to work much better is planting seeds and showing off your plowshare. Let whatever curiosity that blooms find its own way towards your blue sky. The mimetic engine of persuasion runs much cleaner anyway. And for me, it's primarily about my personal computing workbench regardless of what the world does or doesn't. It was the same with finding Ruby. It's great when others come along for the ride, but I'd also be happy taking the trip solo too. So consider this a postcard from a year into the Linux, Neovim, and Framework journey. The sun is still shining, the wind is in my hair, and the smile on my lips hasn't been this big since the earliest days of OS X.
Yesterday I gave a talk at Monki Gras 2025. This year, the theme is Sustaining Software Development Craft, and here’s the description from the conference website: The big question we want to explore is – how can we keep doing the work we do, when it sustains us, provides meaning and purpose, and sometimes pays the bills? We’re in a period of profound change, technically, politically, socially, economically, which has huge implications for us as practitioners, the makers and doers, but also for the culture at large. I did a talk about the first decade of my career, which I’ve spent working on projects that are designed to last. I’m pleased with my talk, and I got a lot of nice comments. Monki Gras is always a pleasure to attend and speak at – it’s such a lovely, friendly vibe, and the organisers James Governor and Jessica West do a great job of making it a nice day. When I left yesterday, I felt warm and fuzzy and appreciated. I also have a front-row photo of me speaking, courtesy of my dear friend Eriol Fox. Naturally, I chose my outfit to match my slides (and this blog post!). Key points How do you create something that lasts? You can’t predict the future, but there are patterns in what lasts People skills sustain a career more than technical skills Long-lasting systems cannot grow without bound; they need weeding Links/recommended reading Sibyl Schaefer presented a paper Energy, Digital Preservation, and the Climate at iPres 2024, which is about how digital preservation needs to change in anticipation of the climate crisis. This was a major inspiration for this talk. Simon Willison gave a talk Coping strategies for the serial project hoarder at DjangoCon US in 2022, which is another inspiration for me. I’m not as prolific as Simon, but I do see parallels between his approach and what I remember of Metaswitch. Most of the photos in the talk come from the Flickr Commons, a collection of historical photographs from over 100 international cultural heritage organisations. You can learn more about the Commons, browse the photos, and see who’s involved using the Commons Explorer https://commons.flickr.org/. (Which I helped to build!) Slides and notes Photo: dry stone wall building in South Wales. Taken by Wikimedia Commons user TR001, used under CC BY‑SA 3.0. [Make introductory remarks; name and pronouns; mention slides on my website] I’ve been a software developer for ten years, and I’ve spent my career working on projects that are designed to last – first telecoms and networking, now cultural heritage – so when I heard this year’s theme “sustaining craft”, I thought about creating things that last a long time. The key question I want to address in this talk is how do you create something that lasts? I want to share a few thoughts I’ve had from working on decade- and century-scale projects. Part of this is about how we sustain ourselves as software developers, as the individuals who create software, especially with the skill threat of AI and the shifting landscape of funding software. I also want to go broader, and talk about how we sustain the craft, the skill, the projects. Let’s go through my career, and see what we can learn. Photo: women working at a Bell System telephone switchboard. From the U.S. National Archives, no known copyright restrictions. My first software developer job was at a company called Metaswitch. Not a household name, they made telecoms equipment, and you’d probably have heard of their customers. They sold equipment to carriers like AT&T, Vodafone, and O2, who’d use that equipment to sell you telephone service. Telecoms infrastructure is designed to last a long time. I spent most of my time at Metaswitch working with BGP, a routing protocol designed on a pair of napkins in 1989. BGP is sometimes known as the "two-napkin protocol", because of the two napkins on which Kirk Lougheed and Yakov Rekhter wrote the original design. From the Computer History Museum. These are those napkins. This design is basically still the backbone of the Internet. A lot of the building blocks of the telephone network and the Internet are fundamentally the same today as when they were created. I was working in a codebase that had been actively developed for most of my life, and was expected to outlast me. This was my first job so I didn’t really appreciate it at the time, but Metaswitch did a lot of stuff designed to keep that codebase going, to sustain it into the future. Let’s talk about a few of them. Photo: a programmer testing electronic equipment. From the San Diego Air & Space Museum Archives, no known copyright restrictions. Metaswitch was very careful about adopting new technologies. Most of their code was written in C, a little C++, and Rust was being adopted very slowly. They didn’t add new technology quickly. Anything they add, they have to support for a long time – so they wanted to pick technologies that weren’t a flash in the pan. I learnt about something called “the Lindy effect” – this is the idea that any technology is about halfway through its expected life. An open-source library that’s been developed for decades? That’ll probably be around a while longer. A brand new JavaScript framework? That’s a riskier long-term bet. The Lindy effect is about how software that’s been around a long time has already proven its staying power. And talking of AI specifically – I’ve been waiting for things to settle. There’s so much churn and change in this space, if I’d learnt a tool six months ago, most of that would be obsolete today. I don’t hate AI, I love that people are trying all these new tools – but I’m tired and I learning new things is exhausting. I’m waiting for things to calm down before really diving deep on these tools. Metaswitch was very cautious about third-party code, and they didn’t have much of it. Again, anything they use will have to be supported for a long time – is that third-party code, that open-source project stick around? They preferred to take the short-term hit of writing their own code, but then having complete control over it. To give you some idea of how seriously they took this: every third-party dependency had to be reviewed and vetted by lawyers before it could be added to the codebase. Imagine doing that for a modern Node.js project! They had a lot of safety nets. Manual and automated testing, a dedicated QA team, lots of checks and reviews. These were large codebases which had to be reliable. Long-lived systems can’t afford to “move fast and break things”. This was a lot of extra work, but it meant more stability, less churn, and not much risk of outside influences breaking things. This isn’t the only way to build software – Metaswitch is at one extreme of a spectrum – but it did seem to work. I think this is a lesson for building software, but also in what we choose to learn as individuals. Focusing on software that’s likely to last means less churn in our careers. If you learn the fundamentals of the web today, that knowledge will still be useful in five years. If you learn the JavaScript framework du jour? Maybe less so. How do you know what’s going to last? That’s the key question! It’s difficult, but it’s not impossible. This is my first thought for you all: you can’t predict the future, but there are patterns in what lasts. I’ve given you some examples of coding practices that can help the longevity of a codebase, these are just a few. Maybe I have rose-tinted spectacles, but I’ve taken the lessons from Metaswitch and brought them into my current work, and I do like them. I’m careful about external dependencies, I write a lot of my own code, and I create lots of safety nets, and stuff doesn’t tend to churn so much. My code lasts because it isn’t constantly being broken by external forces. Photo: a child in nursery school cutting a plank of wood with a saw. From the Community Archives of Belleville and Hastings County, no known copyright restrictions. So that’s what the smart people were doing at Metaswitch. What was I doing? I joined Metaswitch when I was a young and twenty-something graduate, so I knew everything. I knew software development was easy, these old fuddy-duddies were making it all far too complicated, and I was gonna waltz in and show them how it was done. And obviously, that happened. (Please imagine me reading that paragraph in a very sarcastic voice.) I started doing the work, and it was a lot harder than I expected – who knew that software development was difficult? But I was coming from a background as a solo dev who’d only done hobby projects. I’d never worked in a team before. I didn’t know how to say that I was struggling, to ask for help. I kept making bold promises about what I could do, based on how quickly I thought I should be able to do the work – but I was making promises my skills couldn’t match. I kept missing self-imposed deadlines. You can do that once, but you can’t make it a habit. About six months before I left, my manager said to me “Alex, you have a reputation for being unreliable”. Photo: a boy with a pudding bowl haircut, photographed by Elinor Wiltshire, 1964. From the National Library of Ireland, no known copyright restrictions. He was right! I had such a history of making promises that I couldn’t keep, people stopped trusting me. I didn’t get to work on interesting features or the exciting projects, because nobody trusted me to deliver. That was part of why I left that job – I’d ploughed my reputation into the ground, and I needed to reset. Photo: the library stores at Wellcome Collection. Taken by Thomas SG Farnetti used under CC BY‑NC 4.0. I got that reset at Wellcome Collection, a London museum and library that some of you might know. I was working a lot with their collections, a lot of data and metadata. Wellcome Collection is building on long tradition of libraries and archives, which go back thousands of years. Long-term thinking is in their DNA. To give you one example: there’s stuff in the archive that won’t be made public until the turn of the century. Everybody who works there today will be long gone, but they assume that those records will exist in some shape or form form when that time comes, and they’re planning for those files to eventually be opened. This is century-scale thinking. Photo: Bob Hoover. From the San Diego Air & Space Museum Archives, no known copyright restrictions. When I started, I sat next to a guy called Chris. (I couldn’t find a good picture of him, but I feel like this photo captures his energy.) Chris was a senior archivist. He’d been at Wellcome Collection about twenty-five years, and there were very few people – if anyone – who knew more about the archive than he did. He absolutely knew his stuff, and he could have swaggered around like he owned the place. But he didn’t. Something I was struck by, from my very first day, was how curious and humble he was. A bit of a rarity, if you work in software. He was the experienced veteran of the organisation, but he cared about what other people had to say and wanted to learn from them. Twenty-five years in, and he still wanted to learn. He was a nice guy. He was a pleasure to work with, and I think that’s a big part of why he was able to stay in that job as long as he did. We were all quite disappointed when he left for another job! This is my second thought for you: people skills sustain a career more than technical ones. Being a pleasure to work with opens so many doors and opportunities than technical skill alone cannot. We could do another conference just on what those people skills are, but for now I just want to give you a few examples to think about. Photo: Lt.(jg.) Harriet Ida Pickens and Ens. Frances Wills, first Negro Waves to be commissioned in the US Navy. From the U.S. National Archives, no known copyright restrictions. Be a respectful and reliable teammate. You want to be seen as a safe pair of hands. Reliability isn’t about avoiding mistakes, it’s about managing expectations. If you’re consistently overpromising and underdelivering, people stop trusting you (which I learnt the hard way). If you want people to trust you, you have to keep your promises. Good teammates communicate early when things aren’t going to plan, they ask for help and offer it in return. Good teammates respect the work that went before. It’s tempting to dismiss it as “legacy”, but somebody worked hard on it, and it was the best they knew how to do – recognise that effort and skill, don’t dismiss it. Listen with curiosity and intent. My colleague Chris had decades of experience, but he never acted like he knew everything. He asked thoughtful questions and genuinely wanted to learn from everyone. So many of us aren’t really listening when we’re “listening” – we’re just waiting for the next silence, where we can interject with the next thing we’ve already thought of. We aren’t responding to what other people are saying. When we listen, we get to learn, and other people feel heard – and that makes collaboration much smoother and more enjoyable. Finally, and this is a big one: don’t give people unsolicited advice. We are very bad at this as an industry. We all have so many opinions and ideas, but sometimes, sharing isn’t caring. Feedback is only useful when somebody wants to hear it – otherwise, it feels like criticism, it feels like an attack. Saying “um, actually” when nobody asked for feedback isn’t helpful, it just puts people on the defensive. Asking whether somebody wants feedback, and what sort of feedback they want, will go a long way towards it being useful. So again: people skills sustain a career more than technical skills. There aren’t many truly solo careers in software development – we all have to work with other people – for many of us, that’s the joy of it! If you’re a nice person to work with, other people will want to work with you, to collaborate on projects, they’ll offer you opportunities, it opens doors. Your technical skills won’t sustain your career if you can’t work with other people. Photo: "The Keeper", an exhibition at the New Museum in New York. Taken by Daniel Doubrovkine, used under CC BY‑NC‑SA 4.0. When I went to Wellcome Collection, it was my first time getting up-close and personal with a library and archive, and I didn’t really know how they worked. If you’d asked me, I’d have guessed they just keep … everything? And it was gently explained to me that “No Alex, that’s hoarding.” “Your overflowing yarn stash does not count as an archive.” Big collecting institutions are actually super picky – they have guidelines about what sort of material they collect, what’s in scope, what isn’t, and they’ll aggressively reject anything that isn’t a good match. At Wellcome Collection, their remit was “the history of health and human experience”. You have medical papers? Definitely interesting! Your dad’s old pile of car magazines? Less so. Photo: a dumpster full of books that have been discarded. From brewbooks on Flickr, used under CC BY‑SA 2.0. Collecting institutions also engage in the practice of “weeding” or “deaccessioning”, which is removing material, pruning the collection. For example, in lending libraries, books will be removed from the shelves if they’ve become old, damaged, or unpopular. They may be donated, or sold, or just thrown away – but whatever happens, they’re gotten rid of. That space is reclaimed for other books. Getting rid of material is a fundamental part of professional collecting, because professionals know that storing something has an ongoing cost. They know they can’t keep everything. Photo: a box full of printed photos. From Miray Bostancı on Pexels, used under the Pexels license. This is something I think about in my current job as well. I currently work at the Flickr Foundation, where we’re thinking about how to keep Flickr’s pictures visible for 100 years. How do we preserve social media, how do we maintain our digital legacy? When we talk to people, one thing that comes up regularly is that almost everybody has too many photos. Modern smartphones have made it so easy to snap, snap, snap, and we end up with enormous libraries with thousands of images, but we can’t find the photos we care about. We can’t find the meaningful memories. We’re collecting too much stuff. Digital photos aren’t expensive to store, but we feel the cost in other ways – the cognitive load of having to deal with so many images, of having to sift through a disorganised collection. Photo: a wheelbarrow in a garden. From Hans Middendorp on Pexels, used under the Pexels license. I think there’s a lesson here for the software industry. What’s the cost of all the code that we’re keeping? We construct these enormous edifices of code, but when do we turn things off? When do we delete code? We’re more focused on new code, new ideas, new features. I’m personally quite concerned by how much generative AI has focused on writing more code, and not on dealing with the code we already have. Code is text, so it’s cheap to store, but it still has a cost – it’s more cognitive load, more maintenance, more room for bugs and vulnerabilities. We can keep all our software forever, but we shouldn’t. Photo: Open Garbage Dump on Highway 112, North of San Sebastian. Taken by John Vachon, 1973. From the U.S. National Archives no known copyright restrictions. I think this is going to become a bigger issue for us. We live in an era of abundance, where we can get more computing resources at the push of a button. But that can’t last forever. What happens when our current assumptions about endless compute no longer hold? The climate crisis – where’s all our electricity and hardware coming from? The economics of AI – who’s paying for all these GPU-intensive workloads? And politics – how many of us are dependent on cloud computing based in the US? How many of us feel as good about that as we did three months ago? Libraries are good at making a little go a long way, about eking out their resources, about deciding what’s a good use of resources and what’s waste. Often the people who are good with money are the people who don’t have much of it, and we have a lot of money. It’s easier to make decisions about what to prune and what to keep when things are going well – it’s harder to make decisions in an emergency. This is my third thought for you: long-lasting systems cannot grow without bound; they need weeding. It isn’t sustainable to grow forever, because eventually you get overwhelmed by the weight of everything that came before. We need to get better at writing software efficiently, at turning things off that we don’t need. It’s a skill we’ve neglected. We used to be really good at it – when computers were the size of the room, programmers could eke out every last bit of performance. We can’t do that any more, but it’s so important when building something to last, and I think it’s a skill we’ll have to re-learn soon. Photo: Val Weaver and Vera Askew running in a relay race, Brisbane, 1939. From the State Library of Queensland no known copyright restrictions. Weeding is a term that comes from the preservation world, so let’s stay there. When you talk to people who work in digital preservation, we often describe it as a relay race. There is no permanent digital media, there’s no digital parchment or stone tablets – everything we have today will be unreadable in a few decades. We’re constantly migrating from one format to another, trying to stay ahead of obsolete technology. Software is also a bit of a relay race – there is no “write it once and you’re done”. We’re constantly upgrading, editing, improving. And that can be frustrating, but it also means have regular opportunities to learn and improve. We have that chance to reflect, to do things better. Photo: Broken computer monitor found in the woods. By Jeff Myers on Flickr, used under CC BY‑NC 2.0. I think we do our best reflections when computers go bust. When something goes wrong, we spring into action – we do retrospectives, root cause analysis, we work out what went wrong and how to stop it happening again. This is a great way to build software that lasts, to make it more resilient. It’s a period of intense reflection – what went wrong, how do we stop it happening again? What I’ve noticed is that the best systems are doing this sort of reflection all the time – they aren’t waiting for something to go wrong. They know that prevention is better than cure, and they embody it. They give themselves regular time to reflect, to think about what’s working and what’s not – and when we do, great stuff can happen. Photo: Statue of Astrid Lindgren. By Tobias Barz on Flickr, used under CC BY‑ND 2.0. I want to give you one more example. As a sidebar to my day job, I’ve been writing a blog for thirteen years. It’s the longest job – asterisk – I’ve ever had. The indie web is still cool! A lot of what I write, especially when I was starting, was sharing bits of code. “Here’s something I wrote, here’s what it does, here’s how it works and why it’s cool.” Writing about my code has been an incredible learning experience. You might know have heard the saying “ask a developer to review 5 lines of code, she’ll find 5 issues, ask her to review 500 lines and she’ll say it looks good”. When I sit back and deeply read and explain short snippets of my code, I see how to do things better. I get better at programming. Writing this blog has single-handedly had the biggest impact on my skill as a programmer. Photo: Midnight sun in Advent Bay, Spitzbergen, Norway. From the Library of Congress, no known copyright restrictions. There are so many ways to reflect on our work, opportunities to look back and ask how we can do better – but we have to make the most of them. I think we are, in some ways, very lucky that our work isn’t set in stone, that we do keep doing the same thing, that we have the opportunity to do better. Writing this talk has been, in some sense, a reflection on the first decade of my career, and it’s made me think about what I want the next decade to look like. In this talk, I’ve tried to distill some of those things, tried to give you some of the ideas that I want to keep, that I think will help my career and my software to last. Be careful about what you create, what you keep, and how you interact with other people. That care, that process of reflection – that is what creates things that last. [If the formatting of this post looks odd in your feed reader, visit the original article]