I unexpectedly had to quit my previous job and am now in search of a new one. If you are interested in hiring me or have leads, I would very much appreciate it if you could contact me at my ID + gmail.
During 2000-2019, I worked as a backend software engineer, writing anything from small tools to servers handling billions of requests. Now I focus on writing software with Go. During 2019-2024, I worked as TechPR, acting to promote my employer to the outside engineering community, as well as enabling and otherwise making internal engineers happier. I still wrote code for FOSS, but not for a living.
I have 15+ years experience writing about programming in commercial publishing.
I have experience starting and operating a small-scale businesses, large community conferences. I have previously worked for non-Japanese companies as well.
I am an accomplished Go programmer, author, speaker, etc.
I grew up outside of Japan, so I'm 50/50 Japanese/Western World hybrid inside. I speak and write English fluently, and understand some Portuguese. I have no problem working in a English/multi-cultural environment, as I am very familiar with western cultures.
I am proficient in writing technical material in both Japanese and English. I'm somewhat versed in editing as well, which I believe makes me a great fit for editing and writing technical materials for developers. You can see some of my coding / documentation styles / samples through github.com/lestrrat-go/jwx's docs, examples, and faq style docs.
I am also well versed in business outside of engineering through my experiences organizing large scale conferences and managing small companies.
Building products to be used by the masses is a great thing, but it is not something that excites me because it's hard for me to imagine the end users. Instead, what I am more interested in is to engage in projects that help engineers around me, especially those new to the field, and to make them feel happy being an engineer. These sorts of activities let me see the beneficiaries of my directly, and it brings me much satisfaction.
I'm also interested in teaching and otherwise aiding new engineers in getting up to speed. This comes from the fact that I was never the superhero engineer that I once dreamed to be. A superhero engineer might be able to understand the whole picture just by looking at the raw code, but for all of us laymen, we need to be given continuous support. This means not only educational materials and documentation, but also developing easy (easier) to use libraries.
Lastly, I'm also interested in developing "software for the random-joe engineer" -- for example, SDK/API design, common tools and libraries, and shared platforms. These types of software need to be designed specifically for the purpose of being used by various levels of engineers (not just the best ones), and require a specific set of skillset to design and maintain. I believe I'm capable of achieving this goal through my years of experience working on and maintaining FOSS.
I'm interested in the creative ativities around Tech PR: organizig events, coming up with swag, planning and executing promotions, etc. I believe I have the necessary knowledge and experience to know what kinds of activities are effective and where to draw the line; I have learned these through my years of active involvement in communities and the internet.
I have written about my activities in the TechPR area in a blog entry I wrote about my previous job (Japanese only)
First of all, I'm more interested in the TechPR/support field than software development.
However, I understand that there is more demand for software developers; as such, I'm not against the idea of being hired for software development. However, there are a few things I would like for you to understand.
I enjoy writing software, and I believe that I am more than capable of writing high quality software. But I do this best when it is software aimed at engineers.
The main reason for this is that while I'm not capable of imagining the end user when it's a regular consumer (e.g. an app user), I can clearly picture the engineer using my librarie and tools. I'm very much interested in writing and maintaining "ergonomic" software for the developers.
For example:
- Is the software easy to understand how to use?
- If not, is there documentation / is it easy to read?
- Is the software designed to be understandable even in the absence of documentation?
- Is there symmetry in the software (e.g. Get/Set)
- Is it capable of handling concurrent access?
- Is it robust/flexible enough that it can be used for purposes that go beyond the initial scope of the software?
- Is the software capable of reporting proper errors?
To reiterate, I'm not so enhtusiastic about developing applications for the regular consumer. SDK/API development for engineers, developing tools and systems to maintain and operate such consumer applictions are more in my wheelhouse. I'm interested in, and fully capable of designing and developing systems, that aare easier and more stable for a wide range of engineers.
Also I'm not interested in the following:
- Developing yet another Rube Goldberg machine where its only job is to make requests to SaaS/Cloud vendor APIs.
- Writing half-baked software for the sole purpose of achieving some artificial deadline.
I'm willing to accept taking up jobs that do not necessarily perfectly match with what I have described.
However, there are some deal-breakers that would make it impossible for me to be motivated. If the following apply, you should probably look for someone else:
- If you are thinking of hiring me as a software developer, I do expect to be paid more than a certain amount. For other types of roles, I'm willing to negotiate.
- Strong peer pressure / expectation to assimilate
- I grew up in cultures where people are expected to work together towards the same goal while each individual is allowed to keep their own beliefs. If your team expects me to assimilate in order to work together, I'm not your person. You can have your beliefs, but please do not force me to adhere to them.
- You expect immediate return from my work
- Most of what I'm interested in only yields results after some initial amount of time. Therefore, you should hire me expecting it to be a medium-to-long term investment.
- Nominal "flat structure" teams
- I believe that there are exceptions, but I do not work well with "flat" teams (within a small team, OK, but I don't agree that it should be applied to department/company level). I'm not interested in political survival while doing actual work at the same time. I could handle this if it were for my own business, but I'm not interested in doing this while I'm employed. This is especially true if your organization has more than 50~1,000 members and you employ flat structures. I don't believe I work well in that kind of environment.