More from Alice GG
In the past few years, social media use has gained a bad reputation. More or less everyone is now aware that TikTok is ruining your attention span, and Twitter is radicalizing you into extreme ideologies. But, despite its enormous popularity amongst technology enthusiasts, there’s not a lot of attention given to Discord. I personally have been using Discord so much for so long that the majority of my social circle is made of people I met through the platform. I even spent two years of my life helping run the infrastructure behind the most popular Bot available on Discord. In this article, I will try to give my perspective on Discord, why I think it is harmful, and what can we do about it. appshunter.io A tale of two book clubs To explain my point of view about Discord, I will compare the experience between joining a real-life book-club, and one that communicates exclusively through Discord. This example is about books, but the same issues would apply if it was a community talking about investing, knitting, or collecting stamps. As Marshall McLuhan showed last century, examining media should be done independently of their content. In the first scenario, we have Bob. Bob enjoys reading books, which is generally a solitary hobby. To break this solitude, Bob decides to join a book club. This book club reunites twice a month in a library where they talk about a new book each time. In the second scenario, we have Alice. Alice also likes books. Alice also wants to meet fellow book lovers. Being a nerd, Alice decides to join a Discord server. This server does not have fixed meeting times. Most users simply use the text channels to talk about what they are reading anytime during the day. Crumbs of Belongingness In Bob’s book club, a session typically lasts an hour. First, the librarian takes some time to welcome everyone and introduce newcomers. After, that each club member talks about the book they were expected to read. They can talk about what they liked and disliked, how the book made them feel, and the chapters they found particularly noteworthy. Once each member had the time to talk about the book, they vote on the book they are going to read for the next date. After the session is concluded, some members move to the nearest coffeehouse to keep talking. During this session of one hour, Bob spent around one hour socializing. The need for belongingness that drove Bob to join this book club is fully met. On Alice’s side, the server is running 24/7. When she opens the app, even if there are sometimes more than 4000 members of her virtual book club online, most of the time, nobody is talking. If she was to spend an entire hour staring at the server she might witness a dozen or so messages. Those messages may be part of small conversations in which Alice can take part. Sadly, most of the time they will be simple uploads of memes, conversations about books she hasn’t read, or messages that do not convey enough meaning to start a conversation. In one hour of constant Discord use, Alice’s need for socializing has not been met. Susan Q Yin The shop is closed Even if Bob’s library is open every day, the book club is only open for a total of two hours a month. It is enough for Bob. Since the book club fulfills his need, he doesn’t want it to be around for longer. He has not even entertained the thought of joining a second book club, because too many meetings would be overwhelming. For Alice, Discord is always available. No matter if she is at home or away, it is always somewhere in her phone or taskbar. At any moment of the day, she might notice a red circle above the icon. It tells her there are unread messages on Discord. When she notices that, she instinctively stops her current task and opens the app to spend a few minutes checking her messages. Most of the time those messages do not lead to a meaningful conversation. Reading a few messages isn’t enough to meet her need for socialization. So, after having scrolled through the messages, she goes back to waiting for the next notification. Each time she interrupts her current task to check Discord, getting back into the flow can take several minutes or not happen at all. This can easily happen dozens of times a day and cost Alice hundreds of hours each month. Book hopping When Bob gets home, the club only requires him to read the next book. He may also choose to read two books at the same time, one for the book club and one from his personal backlog. But, if he were to keep his efforts to a strict minimum, he would still have things to talk about in the next session. Alice wants to be able to talk with other users about the books they are reading. So she starts reading the books that are trending and get mentionned often. The issue is, Discord’s conversation are instantaneous, and instantaneity compresses time. A book isn’t going to stay popular and relevant for two whole weeks, if it manages to be the thing people talk about for two whole days, it’s already great. Alice might try to purchase and read two to three books a week to keep up with the server rythm. Even if books are not terribly expensive, this can turn a 20 $/month hobby into a 200 $/month hobby. In addition to that, if reading a book takes Alice on average 10 hours, reading 3 books a week would be like adding a part-time job to her schedule. All this, while being constantly interrupted by the need to check if new conversations have been posted to the server. visnu deva Quitting Discord If you are in Alice’s situation, the solution is quite simple: use Discord less, ideally not at all. On my side, I’ve left every server that is not relevant to my current work. I blocked discord.com from the DNS of my coding computer (using NextDNS) and uninstalled the app from my phone. This makes the platform only usable as a direct messaging app, exclusively from my gaming device, which I cannot carry with me. I think many people realize the addictive nature of Discord, yet keep using the application all the time. One common objection to quitting the platform, is that there’s a need for an alternative: maybe we should go back to forums, or IRC, or use Matrix, etc… I don’t think any alternative internet chat platform can solve the problem. The real problem is that we want to be able to talk to people without leaving home, at any time, without any inconvenience. But what we should do is exactly that, leave home and join a real book club, one that is not open 24/7, and one where the members take the time to listen to each other. In the software community, we have also been convinced that every one of our projects needs to be on Discord. Every game needs a server, open-source projects offer support on Discord, and a bunch of AI startups even use it as their main user interface. I even made a server for Dice’n Goblins. I don’t think it’s really that useful. I’m not even sure it’s that convenient. Popular games are not popular because they have big servers, they have big servers because they are popular. Successful open-source projects often don’t even have a server.
Two weeks ago we released Dice’n Goblins, our first game on Steam. This project allowed me to discover and learn a lot of new things about game development and the industry. I will use this blog post to write down what I consider to be the most important lessons from the months spent working on this. The development started around 2 years ago when Daphnée started prototyping a dungeon crawler featuring a goblin protagonist. After a few iterations, the game combat started featuring dice, and then those dice could be used to make combos. In May 2024, the game was baptized Dice’n Goblins, and a Steam page was created featuring some early gameplay screenshots and footage. I joined the project full-time around this period. Almost one year later, after amassing more than 8000 wishlists, the game finally released on Steam on April 4th, 2025. It was received positively by the gaming press, with great reviews from PCGamer and LadiesGamers. It now sits at 92% positive reviews from players on Steam. Building RPGs isn’t easy As you can see from the above timeline, building this game took almost two years and two programmers. This is actually not that long if you consider that other indie RPGs have taken more than 6 years to come out. The main issue with the genre is that you need to create a believable world. In practice, this requires programming many different systems that will interact together to give the impression of a cohesive universe. Every time you add a new system, you need to think about how it will fit all the existing game features. For example, players typically expect an RPG to have a shop system. Of course, this means designing a shop non-player character (or building) and creating a UI that is displayed when you interact with it. But this also means thinking through a lot of other systems: combat needs to be changed to reward the player with gold, every item needs a price tag, chests should sometimes reward the player with gold, etc… Adding too many systems can quickly get into scope creep territory, and make the development exponentially longer. But you can only get away with removing so much until your game stops being an RPG. Making a game without a shop might be acceptable, but the experience still needs to have more features than “walking around and fighting monsters” to feel complete. RPGs are also, by definition, narrative experiences. While some games have managed to get away with procedurally generating 90% of the content, in general, you’ll need to get your hands dirty, write a story, and design a bunch of maps. Creating enough content for a game to fit 12h+ without having the player go through repetitive grind will by itself take a lot of time. Having said all that, I definitely wouldn’t do any other kind of games than RPGs, because this is what I enjoy playing. I don’t think I would be able to nail what makes other genres fun if I don’t play them enough to understand what separates the good from the mediocre. Marketing isn’t that complicated Everyone in the game dev community knows that there are way too many games releasing on Steam. To stand out amongst the 50+ games coming out every day, it’s important not only to have a finished product but also to plan a marketing campaign well in advance. For most people coming from a software engineering background, like me, this can feel extremely daunting. Our education and jobs do not prepare us well for this kind of task. In practice, it’s not that complicated. If your brain is able to provision a Kubernetes cluster, then you are most definitely capable of running a marketing campaign. Like anything else, it’s a skill that you can learn over time by practicing it, and iteratively improving your methods. During the 8 months following the Steam page release, we tried basically everything you can think of as a way to promote the game. Every time something was having a positive impact, we would do it more, and we quickly stopped things with low impact. The most important thing to keep in mind is your target audience. If you know who wants the game of games you’re making, it is very easy to find where they hang out and talk to them. This is however not an easy question to answer for every game. For a long while, we were not sure who would like Dice’n Goblins. Is it people who like Etrian Odyssey? Fans of Dicey Dungeons? Nostalgic players of Paper Mario? For us, the answer was mostly #1, with a bit of #3. Once we figured out what was our target audience, how to communicate with them, and most importantly, had a game that was visually appealing enough, marketing became very straightforward. This is why we really struggled to get our first 1000 wishlists, but getting the last 5000 was actually not that complicated. Publishers aren’t magic At some point, balancing the workload of actually building the game and figuring out how to market it felt too much for a two-person team. We therefore did what many indie studios do, and decided to work with a publisher. We worked with Rogue Duck Interactive, who previously published Dice & Fold, a fairly successful dice roguelike. Without getting too much into details, it didn’t work out as planned and we decided, by mutual agreement, to go back to self-publishing Dice’n Goblins. The issue simply came from the audience question mentioned earlier. Even though Dice & Fold and Dice’n Goblins share some similarities, they target a different audience, which requires a completely different approach to marketing. The lesson learned is that when picking a publisher, the most important thing you can do is to check that their current game catalog really matches the idea you have of your own game. If you’re building a fast-paced FPS, a publisher that only has experience with cozy simulation games will not be able to help you efficiently. In our situation, a publisher with experience in roguelikes and casual strategy games wasn’t a good fit for an RPG. In addition to that, I don’t think the idea of using a publisher to remove marketing toil and focus on making the game is that much of a good idea in the long term. While it definitely helps to remove the pressure from handling social media accounts and ad campaigns, new effort will be required in communicating and negotiating with the publishing team. In the end, the difference between the work saved and the work gained might not have been worth selling a chunk of your game. Conclusion After all this was said and done, one big question I haven’t answered is: would I do it again? The answer is definitely yes. Not only building this game was an extremely satisfying endeavor, but so much has been learned and built while doing it, it would be a shame not to go ahead and do a second one.
Neovim is by far my favorite text editor. The clutter-free interface and keyboard-only navigation are what keep me productive in my daily programming. In an earlier post, I explained how I configure it into a minimalist development environment. Today, I will show you how to use it with Godot and GDScript. Configure Godot First, we need to tell Godot to use nvim as a text editor instead of the built-in one. Open Godot, and head to Editor Settings > General > Text Editor > External. There, you will need to tick the box Use external editor, indicate your Neovim installation path, and use --server /tmp/godothost --remote-send "<C-\><C-N>:n {file}<CR>{line}G{col}|" as execution flags. While in the settings, head to Network > Language Server and note down the remote port Godot is using. By default, it should be 6005. We will need that value later. Connecting to Godot with vim-godot Neovim will be able to access Godot features by using a plugin called vim-godot. We will need to edit the nvim configuration file to install plugins and configure Neovim. On Mac and Linux, it is located at ~/.config/nvim/init.vim I use vim-plug to manage my plugins, so I can just add it to my configuration like this: call plug#begin('~/.vim/plugged') " ... Plug 'habamax/vim-godot' " ... call plug#end() Once the configuration file is modified and saved, use the :PlugInstall command to install it. You’ll also need to indicate Godot’s executable path. Add this line to your init.vim: let g:godot_executable = '/Applications/Godot.app/Contents/MacOS/Godot' For vim-godot to communicate with the Godot editor, it will need to listen to the /tmp/godothost file we configured in the editor previously. To do that, simply launch nvim with the flag --listen /tmp/godothost. To save you some precious keypress, I suggest creating a new alias in your bashrc/zshrc like this: alias gvim="nvim --listen /tmp/godothost" Getting autocompletion with coc.nvim Godot ships with a language server. It means the Godot editor can provide autocompletion, syntax highlighting, and advanced navigation to external editors like nvim. While Neovim now has built-in support for the language server protocol, I’ve used the plugin coc.nvim to obtain these functionalities for years and see no reason to change. You can also install it with vim-plug by adding the following line to your plugin list: Plug 'neoclide/coc.nvim', {'branch':'release'} Run :PlugInstall again to install it. You’ll need to indicate the Godot language server address and port using the command :CocConfig. It should open Coc’s configuration file, which is a JSON file normally located at ~/.config/nvim/coc-settings.json. In this file enter the following data, and make sure the port number matches the one located in your editor: { "languageserver": { "godot": { "host": "127.0.0.1", "filetypes": ["gdscript"], "port": 6005 } } } I recommend adding Coc’s example configuration to your init.vim file. You can find it on GitHub. It will provide you with a lot of useful shortcuts, such as using gd to go to a function definition and gr to list its references. Debugging using nvim-dap If you want to use the debugger from inside Neovim, you’ll need to install another plugin called nvim-dap. Add the following to your plugins list: Plug 'mfussenegger/nvim-dap' The plugin authors suggest configuring it using Lua, so let’s do that by adding the following in your init.vim: lua <<EOF local dap = require("dap") dap.adapters.godot = { type = "server", host = "127.0.0.1", port = 6006, } dap.configurations.gdscript = { { type = "godot", request = "launch", name = "Launch scene", project = "${workspaceFolder}", launch_scene = true, }, } vim.api.nvim_create_user_command("Breakpoint", "lua require'dap'.toggle_breakpoint()", {}) vim.api.nvim_create_user_command("Continue", "lua require'dap'.continue()", {}) vim.api.nvim_create_user_command("StepOver", "lua require'dap'.step_over()", {}) vim.api.nvim_create_user_command("StepInto", "lua require'dap'.step_into()", {}) vim.api.nvim_create_user_command("REPL", "lua require'dap'.repl.open()", {}) EOF This will connect to the language server (here on port 6005), and allow you to pilot the debugger using the following commands: :Breakpoint to create (or remove) a breakpoint :Continue to launch the game or run until the next breakpoint :StepOver to step over a line :StepInto to step inside a function definition :REPL to launch a REPL (useful if you want to examine values) Conclusion I hope you’ll have a great time developing Godot games with Neovim. If it helps you, you can check out my entire init.vim file on GitHub gist.
It’s been around 2 years that I’ve had to stop with my long-term addiction to stable jobs. Quite a few people who read this blog are wondering what the hell exactly I’ve been doing since then so I’m going to update all of you on the various projects I’ve been working on. Meme credit: Fabian Stadler Mikochi Last year, I created Mikochi, a minimalist remote file browser written in Go and Preact. It has slowly been getting more and more users, and it’s now sitting at more than 200 GitHub stars and more than 6000 Docker pulls. I personally use it almost every day and it fits my use case perfectly. It is basically feature-complete so I don’t do too much development on it. I’ve actually been hoping users help me solve the few remaining GitHub issues. So far it happened twice, a good start I guess. Itako You may have seen a couple of posts on this blog regarding finance. It’s a subject I’ve been trying to learn more about for a while now. This led me to read some excellent books including Nassim Taleb’s Fooled by Randomness, Robert Shiller’s Irrational Exuberance, and Robert Carver’s Smart Portfolios. Those books have pushed me toward a more systematic approach to investing, and I’ve built Itako to help me with that. I’ve not talked about it on this blog so far, but it’s a SaaS software that gives clear data visualizations of a stock portfolio performance, volatility, and diversification. It’s currently in beta and usable for free. I’m quite happy that there are actually people using it and that it seems to work without any major issues. However, I think making it easier to use and adding a couple more features would be necessary to make it into a commercially viable product. I try to work on it when I find the time, but for the next couple of months, I have to prioritize the next project. Dice’n Goblins I play RPGs too much and now I’m even working on making them. This project was actually not started by me but by Daphnée Portheault. In the past, we worked on a couple of game jams and produced Cosmic Delusion and Duat. Now we’re trying to make a real commercial game called Dice’n Goblins. The game is about a Goblin who tries to escape from a dungeon that seems to grow endlessly. It’s inspired by classic dungeon crawlers like Etrian Odyssey and Lands of Lore. The twist is that you have to use dice to fight monsters. Equipping items you find in the dungeon gives you new dice and using skills allows you to change the dice values during combat (and make combos). We managed to obtain a decent amount of traction on this project and now it’s being published by Rogue Duck Interactive. The full game should come out in Q1 2025, for PC, Mac, and Linux. You can already play the demo (and wishlist the game) on Steam. If you’re really enthusiastic about it, don’t hesitate to join the Discord community. Technically it’s quite a big change for me to work on game dev since I can’t use that many of the reflexes I’ve built while working on infra subjects. But I’m getting more and more comfortable with using Godot and figuring out all the new game development related lingo. It’s also been an occasion to do a bit of work with non-code topics, like press relations. Japanese Something totally not relevant to tech. Since I’ve managed to reach a ‘goed genoeg’ level of Dutch, I’ve also started to learn more Japanese. I’ve almost reached the N4 level. (By almost I mean I’ve failed but it was close.) A screenshot from the Kanji Study Android App I’ve managed to learn all the hiraganas, katakanas, basic vocabulary, and grammar. So now all I’ve left to do is a huge amount of immersion and grind more kanjis. This is tougher than I thought it would be but I guess it’s fun that I can pretend to be studying while playing Dragon Quest XI in Japanese.
Since 2019, Apple has required all MacOS software to be signed and notarized. This is meant to prevent naive users from installing malware while running software from unknown sources. Since this process is convoluted, it stops many indie game developers from releasing their Godot games on Mac. To solve this, this article will attempt to document each and every step of the signing and notarization process. Photo by Natasya Chen Step 0: Get a Mac While there tools exists to codesign/notarize Mac executables from other platforms, I think having access to a MacOS machine will remove quite a few headaches. A Mac VM, or even a cloud machine, might do the job. I have not personally tested those alternatives, so if you do, please tell me if it works well. Step 1: Get an Apple ID and the Developer App You can create an Apple ID through Apple’s website. While the process should be straightforward, it seems like Apple has trust issues when it comes to email from protonmail.com or custom domains. Do not hesitate to contact support in case you encounter issues creating or logging into your Apple ID. They are quite responsive. Once you have a working Apple ID, use it to log into the App Store on your Mac and install the Apple Developer application. Step 2: Enroll in the Apple Developer Program Next, open the Apple Developer app, log in, and ask to “Enroll” in the developer program. This will require you to scan your ID, fill in data about you and your company, and most likely confirm those data with a support agent by phone. The process costs ~99$ and should take between 24 and 48 hours. Step 3: Setup Xcode Xcode will be used to codesign and notarize your app through Godot. You should install the app through the App Store like you did for the Apple Developer application. Once the app is installed, we need to accept the license. First, launch Xcode and close it. Then open a terminal and run the following commands: sudo xcode-select -s /Applications/Xcode.app/Contents/Developer sudo xcodebuild -license accept Step 4: Generate a certificate signing request To obtain a code signing certificate, we need to generate a certificate request. To do this, open Keychain, and from the top menu, select Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority. Fill in your email address and choose Request is: Saved to disk. Click on Continue and save the .certSigningRequest file somewhere. Step 5: Obtain a code signing certificate Now, head to the Apple Developer website. Log in and go to the certificate list. Click on the + button to create a new certificate. Check Developer ID Application when asked for the type of certificate and click on continue. On the next screen, upload the certificate signing request we generated in step 4. You’ll be prompted to download your certificate. Do it and add it to Keychain by double-clicking on the file. You can check that your certificate was properly added by running the following command: security find-identity -v -p codesigning It should return (at least) one identity. Step 6: Get an App Store Connect API Key Back to the Apple Developer website, go to Users and Access, and open the Integrations tab. From this page, you should request access to the App Store Connect API. This access should normally be granted immediately. From this page, create a new key by clicking on the + icon. Give your key a name you will remember and give it the Developer access. Click on Generate and the key will be created. You will then be prompted to download your key. Do it and store the file safely, as you will only be able to download it once. Step 7: Configure Godot Open your Godot project and head to the project settings using the top menu (Project > Project Settings). From there search for VRAM Compression and check Import ETC2 ASTC. Then make sure you have installed up-to-date export templates by going through the Editor > Manage Export Templates menu and clicking on Download and Install. To export your project, head to the Project > Export. Click on Add and select macOS to create new presets. In the presets form on the left, you’ll have to fill in a unique Bundle Identifier in the Application section, this can be com.yourcompany.yourgame. In the Codesign section, select Xcode codesign and fill in your Apple Team ID and Identity. Those can be found using the security find-identity -v -p codesigning command: the first (~40 characters) part of the output is your identity, and the last (~10 characters, between parentheses) is your Team ID. In the Notarization section, select Xcode notarytool and fill in your API UUID (found on the appstoreconnect page), API Key (the file you saved in Step 6), and API Key ID (also found on the appstoreconnect page). Click on Export Project… to start the export. Step 8: Checking the notarization status Godot will automatically send your exported file for notarization. You can check the notarization progress by running: xcrun notarytool history --key YOUR_AUTH_KEY_FILE.p8 --key-id YOUR_KEY_ID --issuer YOUR_ISSUER_ID According to Apple, the process should rarely take more than 15 minutes. Empirically, this is sometimes very false and the process can give you enough time to grab a coffee, bake a cake, and water your plants. Once the notarization appears completed (with the status Valid or Invalid), you can run this command to check the result (using the job ID found in the previous command output): xcrun notarytool log --key YOUR_AUTH_KEY_FILE.p8 --key-id YOUR_KEY_ID --issuer YOUR_ISSUER_ID YOUR_JOB_ID Step 9: Stapling your executable To make sure that your executable can work offline, you are supposed to ‘staple’ the notarization to it. This is done by running the following command: xcrun stapler staple MY_SOFTWARE.dmg Extra: Exporting the game as .app Godot can export your game as .dmg, .zip, or .app. For most users, it is more convenient to receive the game as .app, as those can be directly executed. However, the notarization process doesn’t support uploading .app files to Apple’s server. I think the proper way to obtain a notarized .app file is to: Export the project .dmg from Godot with code signing and notarization Mount the .dmg and extract the .app located inside of it Staple the .app bundle Extra: Code signing GodotSteam GodotSteam is a Godot add-on that wraps the Steam API inside GDscript. If you use it, you might encounter issues during notarization, because it adds a bunch of .dylib and .framework files. What I did to work around that was to codesign the framework folders: codesign --deep --force --verify --verbose --sign "Developer ID Application: My Company" libgodotsteam.macos.template_release.framework codesign --deep --force --verify --verbose --sign "Developer ID Application: My Company" libgodotsteam.macos.template_debug.framework I also checked the options Allow DyId environment variable and Disable Library Validation in the export settings (section Codesign > Entitlements). FAQ: Is this really necessary if I’m just going to publish my game on Steam? Actually, I’m not 100% sure, but I think it is only “recommended” and Steam can bypass the notarization. Steamworks does contain a checkbox asking if App Bundles Are Notarized, so I assume it might do something.
More in programming
My latest love letter to Linux has been published. It's called Omarchy, and it's an opinionated setup of the Arch Linux distribution and the Hyprland tiling window manager. With everything configured out-of-the-box to give you exactly the same setup that I now run every day. My Platonic ideal of what a developer environment should look like. It's not for everyone, though. Arch has a reputation for being difficult, but while I think that's vastly overstated, I still think it's fair to say that Ubuntu is an easier landing for someone new to Linux. And that's why this exists as a sister project to Omakub — my opinionated setup for Ubuntu — and not a replacement of it. Because I do think that Hyprland deserves its reputation of being difficult! Not because the core tiling window manager is hard, but because it comes incredibly bare-boned in the box. You have to figure out everything yourself. Even how to get a lock screen or idle timing or a menu bar or bluetooth setting or... you get the idea. Omarchy is an attempt to solve for all that. To give you a default set of great, beautiful configurations for Hyprland, and installing all the common tooling you'd normally want. You could setup this, not change a thing, and you'll have exactly what I run every day. But you can also just use this as a paved path into the glorious world of Linux ricing. The flip side of Hyprland being so atomized is that it's infinitely configurable. You can really, really make it yours. No wonder its the preferred platform for r/unixporn, and even what PewDiePie picked up for his amazing Russian nuclear core build. I don't know when we'll literally get "The Year of Linux on the Desktop", but I've never been as convinced that its coming as I am now. There's enough dissent in the water. Enough dissatisfaction with both Apple and Microsoft. And between Valve going all-in on Steam on Linux (the Steamdeck runs Arch!), major creators (like PewDiePie) switching to Linux, and incredible projects like Hyprland — which offer not just a cheap visual copy of the two major commercial operating systems, but something much more unique and compelling — I think all the factors are in place for a big switch. At least among developers. But broad adoption or not, I'm in love with Linux, and thrilled to share my work to make it easier to enjoy.
Here’s a story from nearly 10 years ago. the bug I think it was my friend Richard Kettlewell who told me about a bug he encountered with Let’s Encrypt in its early days in autumn 2015: it was failing to validate mail domains correctly. the context At the time I had previously been responsible for Cambridge University’s email anti-spam system for about 10 years, and in 2014 I had been given responsibility for Cambridge University’s DNS. So I knew how Let’s Encrypt should validate mail domains. Let’s Encrypt was about one year old. Unusually, the code that runs their operations, Boulder, is free software and open to external contributors. Boulder is written in Golang, and I had not previously written any code in Golang. But its reputation is to be easy to get to grips with. So, in principle, the bug was straightforward for me to fix. How difficult would it be as a Golang newbie? And what would Let’s Encrypt’s contribution process be like? the hack I cloned the Boulder repository and had a look around the code. As is pretty typical, there are a couple of stages to fixing a bug in an unfamiliar codebase: work out where the problem is try to understand if the obvious fix could be better In this case, I remember discovering a relatively substantial TODO item that intersected with the bug. I can’t remember the details, but I think there were wider issues with DNS lookups in Boulder. I decided it made sense to fix the immediate problem without getting involved in things that would require discussion with Let’s Encrypt staff. I faffed around with the code and pushed something that looked like it might work. A fun thing about this hack is that I never got a working Boulder test setup on my workstation (or even Golang, I think!) – I just relied on the Let’s Encrypt cloud test setup. The feedback time was very slow, but it was tolerable for a simple one-off change. the fix My pull request was small, +48-14. After a couple of rounds of review and within a few days, it was merged and put into production! A pleasing result. the upshot I thought Golang (at least as it was used in the Boulder codebase) was as easy to get to grips with as promised. I did not touch it again until several years later, because there was no need to, but it seemed fine. I was very impressed by the Let’s Encrypt continuous integration and automated testing setup, and by their low-friction workflow for external contributors. One of my fastest drive-by patches to get into worldwide production. My fix was always going to be temporary, and all trace of it was overwritten years ago. It’s good when “temporary” turns out to be true! the point I was reminded of this story in the pub this evening, and I thought it was worth writing down. It demonstrated to me that Let’s Encrypt really were doing all the good stuff they said they were doing. So thank you to Let’s Encrypt for providing an exemplary service and for giving me a happy little anecdote.
Go is the most hated programming language. Compared to other languages, it provides 80% of utility with 20% of complexity. The hate comes from people who want 81% of utility, or 85% or 97%. As Rob Pike said, no one denies that 87% of utility provides more utility than 80%. The problem is that additional 7% of utility requires 36% more work. Here are some example. Someone complained on HN that struct tags are a not as powerful as annotations or macros. I explained that this is 80⁄20 design. Go testing standard library is a couple hundred lines of code, didn’t change much over the years and yet it provides all the basic testing features you might need. It doesn’t provide all the convenience features you might think of. That’s what Java’s jUnit library does, at a cost of tens of thousands lines of code and years of never-ending development. Go is 80⁄20 design. Goroutines are 80⁄20 design for concurrency compared to async in C# or Rust. Not as many features and knobs but only a fraction of complexity (for users and implementors). When Go launched it didn’t have user defined generics but the built-in types that needed it were generic: arrays/slices, maps, channels. That 8⁄20 design served Go well for over a decade. Most languages can’t resist driving towards 100% design at 400% the cost. C#, Swift, Rust - they all seem on a never-ending treadmill of adding features. Even JavaScript, which started as a 70⁄30 language has been captured by people whose job became adding more features to JavaScript. If 80⁄20 is good, wouldn’t 70⁄30 be even better? No, it wouldn’t. Go has shown that you can have a popular language without enums. I don’t think you could have a popular language without structs. There’s a line below which the language is just not useful enough. Finally, what does “work” mean? There’s work done by the users of the language. Every additional feature of the language requires the programmer to learn about it. It’s more work than it seems. If you make functions as first class concepts, the work is not just learning the syntax and functionality. You need to learn new patterns coding, like functions that return functions. You need to learn about currying, passing functions as arguments. You need to learn not only how but when: when you should use that powerful functionality and when you shouldn’t. You can’t skip that complexity. Even if you decide to not learn how to use functions as first class concepts, your co-worker might and you have to be able to understand his code. Or the library you uses it or a tutorial talks about it. That’s why 80+% languages need coding guidelines. Google has one for C++ because hundreds of programmers couldn’t effectively work on shared C++ codebase if there was no restriction on what features any individual programmer could use. Google’s C++ style guide exists to lower C++ from 95% language to 90% language. The other work is by implementors of the language. Swift is a cautionary tale here. Despite over 10 years of development by very smart people with practically unlimited budget, on a project that is a priority for Apple, Swift compiler is still slow, crashy and is not meaningfully cross platform. They designed a language that they cannot implement properly. In contrast Go, a much simpler but still very capable, was fast, cross platform and robust from version 1.0.
Hello! After many months of writing deep dive blog posts about the terminal, on Tuesday I released a new zine called “The Secret Rules of the Terminal”! You can get it for $12 here: https://wizardzines.com/zines/terminal, or get an 15-pack of all my zines here. Here’s the cover: the table of contents Here’s the table of contents: why the terminal? At first when I thought about writing about the terminal I was a bit baffled. After all – you just type in a command and run it, right? How hard could it be? But then I ran a terminal workshop for some folks who were new to the terminal, and somebody asked this question: “how do I quit? Ctrl+C isn’t working!” This question has a very simple answer (they’d run man pngquant, so they just needed to press q to quit). But it made me think about how even though different situations in the terminal look extremely similar (it’s all text!), the way they behave can be very different. Something as simple as “quitting” is different depending on whether you’re in a REPL (Ctrl+D), a full screen program like less (q), or a noninteractive program (Ctrl+C). And then I realized that the terminal was way more complicated than I’d been giving it credit for. there are a million tiny inconsistencies The more I thought about using the terminal, the more I realized that the terminal has a lot of tiny inconsistencies like: sometimes you can use the arrow keys to move around, but sometimes pressing the arrow keys just prints ^[[D sometimes you can use the mouse to select text, but sometimes you can’t sometimes your commands get saved to a history when you run them, and sometimes they don’t some shells let you use the up arrow to see the previous command, and some don’t If you use the terminal daily for 10 or 20 years, even if you don’t understand exactly why these things happen, you’ll probably build an intuition for them. But having an intuition for them isn’t the same as understanding why they happen. When writing this zine I actually had to do a lot of work to figure out exactly what was happening in the terminal to be able to talk about how to reason about it. the rules aren’t written down anywhere It turns out that the “rules” for how the terminal works (how do you edit a command you type in? how do you quit a program? how do you fix your colours?) are extremely hard to fully understand, because “the terminal” is actually made of many different pieces of software (your terminal emulator, your operating system, your shell, the core utilities like grep, and every other random terminal program you’ve installed) which are written by different people with different ideas about how things should work. So I wanted to write something that would explain: how the 4 pieces of the terminal (your shell, terminal emulator, programs, and TTY driver) fit together to make everything work some of the core conventions for how you can expect things in your terminal to work lots of tips and tricks for how to use terminal programs this zine explains the most useful parts of terminal internals Terminal internals are a mess. A lot of it is just the way it is because someone made a decision in the 80s and now it’s impossible to change, and honestly I don’t think learning everything about terminal internals is worth it. But some parts are not that hard to understand and can really make your experience in the terminal better, like: if you understand what your shell is responsible for, you can configure your shell (or use a different one!) to access your history more easily, get great tab completion, and so much more if you understand escape codes, it’s much less scary when cating a binary to stdout messes up your terminal, you can just type reset and move on if you understand how colour works, you can get rid of bad colour contrast in your terminal so you can actually read the text I learned a surprising amount writing this zine When I wrote How Git Works, I thought I knew how Git worked, and I was right. But the terminal is different. Even though I feel totally confident in the terminal and even though I’ve used it every day for 20 years, I had a lot of misunderstandings about how the terminal works and (unless you’re the author of tmux or something) I think there’s a good chance you do too. A few things I learned that are actually useful to me: I understand the structure of the terminal better and so I feel more confident debugging weird terminal stuff that happens to me (I was even able to suggest a small improvement to fish!). Identifying exactly which piece of software is causing a weird thing to happen in my terminal still isn’t easy but I’m a lot better at it now. you can write a shell script to copy to your clipboard over SSH how reset works under the hood (it does the equivalent of stty sane; sleep 1; tput reset) – basically I learned that I don’t ever need to worry about remembering stty sane or tput reset and I can just run reset instead how to look at the invisible escape codes that a program is printing out (run unbuffer program > out; less out) why the builtin REPLs on my Mac like sqlite3 are so annoying to use (they use libedit instead of readline) blog posts I wrote along the way As usual these days I wrote a bunch of blog posts about various side quests: How to add a directory to your PATH “rules” that terminal problems follow why pipes sometimes get “stuck”: buffering some terminal frustrations ASCII control characters in my terminal on “what’s the deal with Ctrl+A, Ctrl+B, Ctrl+C, etc?” entering text in the terminal is complicated what’s involved in getting a “modern” terminal setup? reasons to use your shell’s job control standards for ANSI escape codes, which is really me trying to figure out if I think the terminfo database is serving us well today people who helped with this zine A long time ago I used to write zines mostly by myself but with every project I get more and more help. I met with Marie Claire LeBlanc Flanagan every weekday from September to June to work on this one. The cover is by Vladimir Kašiković, Lesley Trites did copy editing, Simon Tatham (who wrote PuTTY) did technical review, our Operations Manager Lee did the transcription as well as a million other things, and Jesse Luehrs (who is one of the very few people I know who actually understands the terminal’s cursed inner workings) had so many incredibly helpful conversations with me about what is going on in the terminal. get the zine Here are some links to get the zine again: get The Secret Rules of the Terminal get a 15-pack of all my zines here. As always, you can get either a PDF version to print at home or a print version shipped to your house. The only caveat is print orders will ship in August – I need to wait for orders to come in to get an idea of how many I should print before sending it to the printer.
It’s well known that Japan is experiencing a labor shortage that includes the tech industry. As a result, Japan needs more international developers. However, most Japanese companies aren’t interested in hiring new graduates from overseas. While it’s easier than in some countries, bringing a developer to Japan still requires some time and financial investment on the company’s side, which they’re unlikely to expend on junior developers. So if you’re a new grad with no experience, can you still find a job in Japan? The answer is yes, but it will take considerable effort, and the opportunities you find may not be what you’re looking for. If you’re determined, it’s best to start preparing while you’re still a student. If you’ve already graduated, then your road is tougher but not impossible, especially if you’re patient, persistent, and willing to go above and beyond. This article will cover: The new graduate hiring system in Japan How international students in Japan can take advantage of the system The steps students and new grads overseas can take to maximize their chances How new grad hiring works in Japan While the primary audience of this article is graduates outside of Japan, understanding how the domestic hiring process works provides necessary context. The Japanese system for hiring new graduates (新卒一括採用, shinsotsu ikkatsu saiyou) operates quite differently from practices in many other countries. It is, however, an effective method: in 2025, 98 percent of Japanese graduates were able to secure employment. What companies are looking for in new graduates To better understand Japan’s methods for hiring new graduates, it helps to know something about Japanese employment philosophy. Traditional Japanese business practices center on the idea of lifetime employment. This approach is currently changing—as of 2023, one in three Japanese employees were no longer committed to lifetime employment, but were open to changing jobs or working independently if the opportunity arose. Nonetheless, decades of conventional wisdom still shape how Japanese companies approach hiring new graduates. Most new graduate hires are considered members of the company on a “comprehensive career track” (総合職採用, sougoushoku saiyou) which means that they aren’t being hired for a specific job, but instead to work for the company in general. In exchange, the business will train them and identify their strengths by assigning them to various departments and roles. Japanese companies therefore typically aren’t as interested in a candidate’s specific experiences and academic achievements, since they’re not certain what position the candidate will eventually occupy in the company. Instead, they prize qualities like good communication skills, independence, and willingness. This is also why Japanese companies often employ Synthetic Personality Inventory (SPI) tests, to attempt to understand if a candidate will be an “objectively” good fit. SPI tests are generally half knowledge-based (often general knowledge), and half MBTI-style personality tests. The job-hunting schedule In Japan, both the school and fiscal year start in April, and so does the job hunt—the year before graduation. If you wait until you’ve graduated to start job-hunting, you’re already a year behind! Study in Japan, a government-approved information site, outlines the following typical schedule for a university student set to graduate the following year: March–May is the entry period. Go to job fairs, seek company introductions, and request entry submission sheets. If your initial application is accepted, begin taking company examinations. In June, the interviews begin. Expect at least three rounds of interviews, of several different types. From June–September is when you may receive a preliminary offer of employment. In October, if you’re successful, you’ll receive the official offer of employment. If you are an international student in Japan, you should change your status of residence. Some companies do continue recruiting in October, but the bulk of the new grad hiring is completed by then. What to expect when applying The new graduate application process also differs widely from standard hiring practices in other countries. Entry sheet If you’re interested in applying to a company, you must first request and complete an entry sheet, which resembles a university application essay more than your average resume. It frequently includes personality-based questions such as “If you had 300 million Japanese yen, what would you do to promote world peace?” and “Describe how you would be indispensable to our company by referring to what you did best during your school life.” Written Examinations If your entry sheet is approved, you can then move on to take the company’s written examinations. Most of these are aptitude tests that evaluate a candidate’s mathematics, language, and writing ability as well as general knowledge. These are typically produced by a third-party company. Interviews It’s customary for companies to conduct at least three rounds of interviews. Some of those interviews are standard single-person interviews. Others are group interviews, in which the interviewer or panel takes turns asking a group of applicants different questions. This method is typically adopted to save time and help winnow down a large applicant pool. You may also be asked to participate in a group discussion interview, in which a gathering of four to six candidates are asked to discuss a given theme, while an interviewer evaluates the group dynamic and individual performance of the applicants. In particular, interviewers are interested in seeing how participants interact in a team situation. Employment offers If a company is interested in hiring you, they may make a preliminary offer of employment (内々定, nai naitei).These types of offers are informal and are not considered binding under law. The more serious step is when a company issues a formal letter of intent to hire (内定, naitei). It is very common for Japanese companies to provide this to show their serious intent of hiring you while they do their due diligence and prepare to issue a formal contract. Under Japanese labor law, the company might be held liable if they subsequently withdraw this offer without cause. If you accept the letter of intent, you are signaling that you will sign a formal employment contract with the company; if you have received preliminary offers from any other companies, you should call them to politely decline. While it is possible to accept and then renege on a formal letter of intent to hire, you should be aware that it is a major faux pas, and you will likely be blacklisted within the company, depending on the circumstances. If this is unavoidable, you should communicate your intentions as quickly and clearly as possible to the company. Japanese companies generally follow the process described here, especially the formal letter of intent to hire. However, these steps are not required by law, so some companies—especially newer or international ones—may not follow this schedule at all! A company following this flow does not indicate that they are reputable or trustworthy, nor does a company not following this flow indicate that they are engaging in deceptive or illegal practices. If you’re an international student in Japan If you’re an international student in Japan, you can join the annual job hunt in April with the rest of your class. Because every step is typically conducted in Japanese, your success in the conventional process will largely depend on how fluent you are. Yet according to a 2024 survey by employment information firm Career-tasu, Inc., most foreign students started job search activities the year they graduated, rather than the year before as their Japanese peers did. This, the staff at Career-tasu believes, puts international students at a serious detriment. International students are also less likely to participate in internship programs or other job experience activities: only 46.1% of international graduates did so, compared to 88.7% of Japanese students surveyed. Nonetheless, The Japan News by The Yomiuri Shimbun reported that some companies are keen to hire international graduates, particularly those who are bilingual or trilingual. In 2022, the percentage of foreign-born graduates finding jobs in Japan exceeded 50% for the first time. Those numbers may improve still further as the labor shortage in Japan worsens. Only around 36% of companies in 2024 were able to meet their recruiting goals. In 2025, 80% of third-year students undergoing the new graduate hiring process already had job offers before June. Companies are already adapting by focusing on mid-career recruitment and introducing fast-tracked interviews, so they may also be more willing to accommodate international student candidates. Certain cities, prefectural governments, and universities have also committed to supporting international students’ job-hunting, and they can help match you with Japanese companies. Ritsumeikan University, for example, not only offers its own job search engine in Japanese, but also lists a number of English-language job boards. New graduates in Japan can take advantage of these school and government resources, as well as being already in the country and available for interviews, examinations, and more. In addition, changing from a Student visa to one of the work-related visas is relatively simple and doesn’t require getting a Certificate of Eligibility or leaving the country. If you’re a student or new grad overseas New graduates from other countries are at a significant disadvantage. First, you’re not available to interview or take examinations in person, which will disqualify you from most companies’ usual hiring procedures. Second, unlike in most countries, the Japanese school year ends in late March. Even if a Japanese company is willing to accept your application via its normal new-grad hiring program, the mismatch in school schedules means you’d need to wait months before you could start work. There are several ways to overcome these difficulties, though, which we’ll explore below. Japanese language skills It’s not absolutely necessary to learn Japanese to get a developer job in Japan. In fact, many Japanese tech companies are creating multinational, English-speaking development teams, or even adopting English as the company language. There’s a catch, however. As mentioned above, those companies who are willing to hire English-speaking developers from overseas are typically searching for senior developers. If you are a junior developer, or a new graduate without experience, you’re far less likely to find an English-speaking position in Japan. That’s the trade-off: you can get a job with work experience and no Japanese ability, but if you don’t have the work experience, you’d better speak Japanese! If the prospect of learning Japanese just to get a job seems daunting, be aware that not every position requires full Japanese fluency. If you’re studying hard and demonstrate enthusiasm in interviews, then conversational-level Japanese might be enough to persuade a company to take a chance on you. Training and recruitment programs Given the high demand in Japan for new tech talents that also speak Japanese, some recruiting companies are offering fast-tracked training programs for students overseas. FAST OFFER, for example, has relationships with over 50 universities worldwide, primarily in Asia. It provides free Japanese classes, which are worth college credits at some participating universities, for students majoring in select fields. These classes are specifically designed to help candidates pass interviews with Japanese companies, as well as acquire the general language skills needed to work in Japan. Candidates who reach a specified level of proficiency—JLPT N4 for most IT roles—will be assigned a mentor, coached on the interview process, and matched with Japanese companies. If the applicant passes the initial screening, they will even be flown to Japan for in-person interviews, all for free. Another example is xseeds Hub, a recruitment platform that developed its own curriculum to prepare students for employment in Japan. As of now, xseeds Hub runs these programs at four Vietnamese universities, as well as one in Indonesia and one in Malaysia. The curriculum includes lessons on different scripting languages, as well as Japanese classes intended to help students achieve at least a JLPT N3 level of speaking. Students gain practical experience via mock experiment lessons and internships in Japan, which run for a minimum of three months. University collaborations with Japanese companies While you’re still a student, you should also find out if your university offers events or programs with Japanese companies. Mercari and Rakuten have particularly targeted the Indian Institutes of Technology (IITs) for recruitment events. But interest in Indian graduates isn’t limited to those companies; when the Indian Embassy hosted a seminar on the subject in Tokyo, over 100 Japanese firms attended. I spoke with Victoria Astingo, who works in Senior Talent Acquisition for Mercari. Mercari has been visiting IITs since 2018, interviewing and hiring soon-to-be graduates on the spot, and they’ve recently started similar campus recruitment drives in Indonesia. These rapid-hire events only take place at universities in Asia for now, but Astingo is expanding Mercari’s internship program outreach to European universities. Her first event in Europe took place at three universities in France, including EPITA, a top-level French institution specializing in Computer Science and Software Engineering. “The reception was way better than we expected,” she said. “At first we were like, ‘Yeah, nobody [here] knows Mercari. Maybe there will be five people coming to our seminar, five anime fans that want to make it to Japan.’ But then actually for EPITA, we had more than 120 attendees.” Other Japanese companies have also started directly partnering with universities abroad. For example, I-Shou University in Taiwan is setting up internships and hiring channels for students in cooperation with Japanese company Nisso Kogyo Co, Ltd., to help supply new talent for the semiconductor industry in Kumamoto. In Vietnam, Ho Chi Minh Open University cooperated with 22 Japanese companies for its 2024 Japan Job Fair, and HUTECH University of Technology hosted 40 Japanese companies at its event. Even if your university doesn’t have preestablished relationships with Japanese companies, you should still check in with your university’s Japanese or East Asian Studies department. The professors there may have personal connections to Japan, or be able to suggest helpful programs, scholarships, or internships. You could also explore your alumni network, and see if you can make contact with any who are currently working in Japan. Internships at TokyoDev companies “Internship” in Japan doesn’t always mean what you think it means—as TokyoDev contributor Lai Huynh Binh Minh discovered, the average “internship” in Japan only lasts one day! That’s not an especially convenient or helpful timeframe for anyone who is overseas. Luckily, TokyoDev works with several companies that offer longer internships with visa support. Not only can you gain valuable work experience, but you also have the opportunity to live in Japan for a few months and discover if it’s really for you. Mercari An internship at Mercari is only available to current university students. It lasts for two months, is paid hourly, and comes with full visa and financial support. Job offers on completion of the internship are considered to be nearly guaranteed. “Most of the time,” said Victoria Astingo, “students apply while they’re second-year students and do their internships before or during their third year. Then, once they graduate, they join us as full-time employees.” This intern-to-FTE pipeline helps explain why Astingo’s new recruitment drive focuses on Europe rather than Singapore or the US, where new graduates are typically offered higher salaries or better compensation packages. Still, Astingo clarified, students from any country are welcome to apply. “I would say the people who we hire as interns usually have previous internship experience as a software engineer,” she said. “[And] if I’m hiring for frontend or backend, I will always check to see if the candidate shares our tech stack—for example, if the candidate has experience working with React or Golang. They don’t really need to master those, but should at least have a basic understanding or interest.” Team experience, such as participating in a hackathon or some other type of group project, is also something Astingo looks for. The name of the applicant’s university doesn’t carry much weight, but majoring in computer science or a related field does. However, even if a candidate doesn’t meet every requirement, she’ll most likely still send the initial skill assessment and give them the opportunity to prove their abilities. Japanese language skills, on the other hand, are not a requirement. “Most of the people I hired for Mercari Marketplace were not Japanese speakers,” Astingo affirmed. HENNGE Like Mercari’s internship program, HENNGE’s Global Internship Program accepts applicants year-round from all over the world. Also like Mercari, it is considered part of the company’s pre-hiring process, so those applicants who are interested in working at HENNGE after graduation will have an advantage. One difference is that the HENNGE internship is unpaid, though participants do receive a monthly stipend, round-trip airfare, and other benefits. Also, the HENNGE program is intended for third-year university students or those who have newly graduated, and so will accommodate slightly older/more advanced candidates. The internships fall into two distinct categories: the Full Stack Engineering Pathway, and the Frontend Engineering Pathway. Each pathway has its own tech stack and experience requirements. It’s possible to apply for both at the same time, but not to change between them mid-internship. As with Mercari, Japanese language ability is not required, but candidates must be fluent in English. HENNGE’s is one of the few global internship programs offered in Japan, so it’s quite competitive, and applicants should be prepared for a selective process with minimal communication. Working Holiday and J-Find visas If you’ve already graduated, then you still have other avenues to come to Japan to look for work: a Working Holiday visa or J-Find visa. These visas both permit the holder to travel, work, and job-hunt in Japan for up to a year. By giving you one year in Japan to network and interview, these visas significantly increase your odds of landing a permanent position, as many roles will not accept overseas applicants. In fact, that’s how TokyoDev founder Paul McMahon got his first job in Japan, and it’s also worked for other TokyoDev contributors as well. However, both visas have specific requirements, so be sure to check whether you qualify. International job fairs If you’re not eligible for a Working Holiday or J-Find visa, try visiting an international job fair instead. Participating businesses have already expressed their willingness to hire overseas candidates, and you’ll be able to personally meet with—and hopefully impress—company representatives. At least some Japanese ability will be required, however, to take advantage of these opportunities. One of the best-known Japanese career fair organizations is Career Forum, which hosts fairs in Boston, Los Angeles, London, Tokyo, and Osaka. The largest overseas event is in Boston, with over 100 companies slated to participate in 2025. Career Forum’s target audience is candidates who speak both Japanese and English to at least a beginner’s level. While their offerings are aimed at current students or recent graduates, they also are interested in candidates who have lived or studied abroad, even if that was not in Japan. On the other side of the globe, Mynavi is holding fairs in Taiwan, Korea, and Australia, as well as online. Though labeled as “career fairs” on their website, these events are actually described as group interviews, and Japanese language skills are a requirement. The Australian event is tightly restricted to current students and new graduates, but the Taiwan fair is open to all those seeking employment in Japanese companies. In Singapore, Asean Career Fair in Singapore will feature 20 Japanese companies in their 2026 event, though it is unclear at the time of writing which companies those will be. Conclusion If you’re a university student or new graduate who wants to find work in Japan, these are your best options: While you’re a student, study Japanese and apply for internships in Japan. If you’re already studying in Japan, you can use university and government resources to help you succeed in the local new graduate hiring process. If you’re overseas, check to see if your university hosts recruitment events or has other connections with Japanese companies and universities. Students in Asia, particularly, may qualify to join a recruiting company’s training program. Working adults may be able to use a Working Holiday or J-Find visa to come to Japan to job-hunt. Visiting an international job fair outside of Japan could get you an interview with an international-friendly company. Good luck and good hunting! Don’t forget to read TokyoDev’s other articles on software developer salaries in Japan, finding a developer job, passing the resume screening process, etc. You can also connect with other developers by joining the TokyoDev Discord, which has channels for resume review, relocating to Japan, and more.