If you read this blog regularly you will know that I really believe in the power of tools to support people in their work. I even called my consulting company Strumenta, which means “tools” in Latin.
I am also a big supporter of Jetbrains: I think they make great products that really improve the life of developers. So you can imagine how thrilled I am about this interview with Joachim Ansorg. Joachim creates plugins for Jetbrains products for a living.
In this interview we discuss of several topics:
- why building plugins for Jetbrains products such as IntelliJ IDEA or PyCharm
- some of the challenges in building those plugins and how to get started
- his opensource projects and his views on opensource
- how to work with Joachim
- his experience freelancing
- some final comments on things he finds interesting
The day of the recording Skype had some issues so that my audio and my video were not in sync. For this reason we disabled my camera
Meeting Joachim
Federico: Hi Joachim. Can you correct the way I pronounce your name?
Joachim: That’s all right Federico. Thanks for meeting me. That’s usually pronounced Joachim at least in German.
Federico: My German is very bad. I will study more. Thank you so much for joining me for this interview.
Joachim: You are welcome.
Federico: Today we are going to talk about developing plugins for JetBrains. It’s a very interesting topic. First of all it would be nice if you could tell us something about you.
Joachim: Sure. I can do that. That’s not too much to tell, I think. My name is Joachim, I am living in the south of Germany near the border to Switzerland and France, so right at the border. It’s about 10 minutes to Switzerland and maybe about 20 to France. I’m 36 years old, I’m a software developer, I’m married. I think that’s all I could tell. If you have any questions feel free to ask.
Federico: Yeah. I have a lot of questions.
Joachim: all right.
Why building plugins?
Federico: First of all I would like to ask you, how did you start developing plugins for JetBrains?
Joachim: I think it was about 10 years ago. I had some time availableand there was a yearly plugin developer contest at that time, organized by JetBrains. I’m not sure how long they were doing that, that was the last year they were doing it, I think in 2009. They were having some development contest and a grand prize of about $8,000 or something. That was the reason to join, and I started to work on BashSupport at that time. I think there was also another plugin I was working on for the Erlang language, which I learned by doing the development. I think that the plugin was called Gray at that time, but there is now a much better Erlang plugin available on the repository. That’s out of date and not published anymore.
BashSupport received the first prize of that contest. I was happy to win that prize and I think that other plugin got the third or fifth place. I’m not sure, one of the lower ranks, but I was happy to be successful in that contest, and I think after that I continued to work on plugin development.
Federico: We also now learnt that if you want to learn a programming language, you can always write a plugin for it. It’s a good method. I wonder, what kind of plugins do you build more frequently? Do you build editors for new languages, debuggers for existing languages or something else?
Joachim: Mostly I think it’s either language support, which includes the editor and other things like error highlighting, writing quick fixes et cetera, or integration of third party tools, like for example to sync the current file users are working on with a remote server. That’s a very small example of a third party integration. I’m usually doing languages for third party integration for other companies.
Federico: I wonder, who is typically interested in building plugins?
Joachim: I think most of the open source community is interested to get plugins, because there are a lot of frameworks out there which have quite lacking tool support. I think a lot of JavaScript frameworks, or web frameworks, or even languages like I think OCaml has come up recently. Tool support, all that’s just very outdated or very basic tool support for these frameworks and languages. I think there is some interest in the opensource community, but also from I think companies doing commercial work. They are mostly interested to integrate their product into the IntelliJ platform I think. Often to get better tooling for their own programming languages if they offer some. I think people want to do that for in-house development and also to support third party developers working with custom languages.
Federico: Good. What advantages to people typically obtain by building plugins? I don’t know if you have any success story that comes to mind.
Joachim: I think a lot of the advantages, for productivity I think. If you have only very basic tool support or no support at all that makes very hard to work with a framework or with a language. And as soon as you get smarter tools support it becomes much nicer and much better to work with that framework or language. I think it’s saving a lot of time if you get good tool support. I think that’s a good point to provide.
Building plugins
Federico: I definitely agree that tools are important. I created a company that is named Strumenta. Strumenta means tools in Latin, because tools can change the way someone works. About your experience building plugins. I tried sometimes to look at JetBrains documentation, I found quite difficult to get started. I was wondering, how did you start developing plugins?
Joachim: I think it was a bit tough to get started. I think today there is much better documentation available. For example linked from the plugin repository. There is a developer handbook or SDK handbook I think to get started. I think that documentation is much improved to what was available 10 years ago when I started. There were some documentations, there were some JetBrains forums available to ask a few questions, but mostly looking at the Javadoc documentation and the source code, and looking at the available open source plugins mostly published by JetBrains or by some other parties. I think looking at existing solutions has helped me a lot to get started. That was quite difficult and time consuming.
Federico: I can imagine. My next question is: what advice you would have for someone that is interested in starting developing plugins? There is this documentation, they can also check examples on GitHub.
Joachim: I think that’s a very good point to get started. I think documentation published by JetBrains is a must read. You have to read it to understand all the architecture of the SDK, or the IntelliJ platform, and the different technologies involved and the wording, et cetera. You need to know about it, otherwise it becomes quite difficult to work on the plugin, because JetBrains has its own custom solutions for many things. Like parsing is usually, parsing uses data structures provided by JetBrains. I think there is some integration of third party parser generators but it’s usually done using solutions provided by JetBrains.
I think it’s essential to read the documentation, start with a small plugin. I think it’s very important to write test cases. I think that’s known wisdom for developers. I try to cover everything I do with BashSupport and the plugins I work on for clients to cover things by test cases, because it’s for one difficult to support all the different versions of the platform. For example, to support version 2016.1, up to version 2018.3 or the current early access preview is quite difficult. If you want to make sure that it’s not breaking on any of these different versions then you need to have test cases, which cover not just the basics but also the workflow inside of the editor, code completions, et cetera. Test cases are essential.
Federico: I imagine testing the editor itself has to be quite difficult or time consuming.
Joachim: I think it’s very well done by JetBrains. They have some great support to write test cases. That’s usually done in the Java language. Nowadays you can also use Kotlin to do that. I only use Kotlin for new projects because it’s time saving and helping a lot. JetBrains because they invented Kotlin provide great support for Kotlin as well. I think it’s possible to do nearly everything except for UI dialogs et cetera in test cases.
That’s basically a headless environment which runs your plugin inside a full IDE set up. You can basically open files, create new files, write into the editor, request code completions, check that code completions are matching what you expected, et cetera. That’s very sophisticated and I think quite advanced.
Federico: I’m a big fan of Kotlin. I also created a website named SuperKotlin.com, I think it’s a very nice improvement over Java.
Joachim: It is.
Federico: So you are specialized on developing plugins for the JetBrains platform. Do you ever experience developing plugins for outer platforms like Eclipse, Sublime, Atom, Visual Studio, or something else?
Joachim: I had some rather bad experience before I started to work on JetBrains plugins with Eclipse. I strongly disliked working on Eclipse plugins. I guess it has improved in the last years, but about 10 years ago it was just awful, or maybe I didn’t get it, how it’s done, but it wasn’t very nice. The support provided by the JetBrains SDK was much better compared to what was available by Eclipse. I did not consider to work on other IDEs, mostly because I knew what I’m doing with JetBrains platform and didn’t want to learn a completely new platform without knowing whether that’s worth it.
I have some experience with another developer who is working on VSCode’s plugins, and also on plugins for Atom. I have some insights on what’s possible and available. I think VSCode is gaining a lot of market share right now. Perhaps I will have a look at VSCode plugins, but from what I learned it’s quite difficult to do the testing and VSCode is not that advanced as what JetBrains is providing. And it’s in JavaScript or possibly TypeScript which I don’t like that much either. I don’t like JavaScript that much because I prefer typesafe languages and simple languages.
Federico: Yeah. I had some experience developing plugins for Eclipse, because of the time I was using the Eclipse Modeling Framework. It was very painful. From time to time I’m reminded of that time because someone comments on a bug I opened seven years ago. And so I am saying: “Okay. I’m not interested in this anymore.”
You said that you’ve been working on writing these plugins for 10 years. I was wondering if you have noticed any change during this time, either on the technological level, if the API changed a lot or in the community, maybe the community became bigger or more friendly.
Joachim: I think it’s quite larger changes in both of these areas. For one, I think on the technological level, a lot of new features and possibilities were added to the SDK, but I’m glad that JetBrains managed to stabilize the SDK at least in the important parts where I’m working on for example, the parts around the language, custom language development, is much more stable now compared to 10 years ago. Things are changing a lot and breaking things a lot about ten to eight or six years ago. That has improved quite a lot because they are now I think having more tooling in place to make sure that a change to the SDK is not breaking any of the existing plugins.
I think they are scanning the Java code that is published on their repository to see if plugins are using anything they want to duplicate or to remove. That’s much better. I think they found a solution in the SDK which covers almost everything what plugins need to do, the parsing and lexing, et cetera. That’s much better now. Things are breaking from time to time with the newer features or the UI integrations. I still manage to publish a single version of a plugin for all the different versions of a platform. I’m doing that for the plugins developed for clients as much as possible.
I now started to do that again for BashSupport. In the past I had different versions of BashSupport for each major version of the platform, which was quite painful to support. I manage to support now 2016.1 and later with a single plugin file, that wasn’t possible with the versions before because there were larger changes in the SDK. That’s much better I think.
Federico: Good point. It seems that JetBrains made your life easier over time.
Joachim: I think so. Yeah.
Federico: Is there anything else that you think they should do to make your life easier, and the life of other people building plugins of course?
Joachim: Yeah. I think there are a few things they could improve. I think they are doing well, and they try to support plugin developers. I think a few things could be improved, like when a user uses BashSupport, I guess he’s assuming that BashSupport belongs into IntelliJ because it’s suggested at startup I think to PyCharm users to install BashSupport for example. The users I think assume that it belongs to JetBrains and report issues in BashSupport to the bug tracker on the JetBrains service.
Then the guys from JetBrains will tell the bug reporter to report the issue to BashSupport. I think there are some misunderstandings. I think it would help if JetBrains could provide accounts to plugin developers to be assigned to bugs users report on the public YouTrack respository. think one of these smaller changes could help. I think at some point JetBrains decided to tag the BashSupport feature as, to tag it as a feature by JetBrains. I think that triggered a lot of more downloads. It’s a bit difficult to support that strong user base without strong support from JetBrains I think. I think things could be improved a bit.
Let me just have a quick look at my notes I think. One point I noticed is in the past I was working on an integration of a JavaScript dialect, or like language into IntelliJ, and that involved to dig into the JavaScript plugin, which is not opensource, and to see what they provide, and which extension points are possible to use in the third party plugin, which extends the JavaScript support in the IDE. This is quite painful to do, because there is an XML file in each plugin which lists which possible extension points are available.
I can use those, but I have to decompile the code to see what the plugin is doing with these extension points, and there is no documentation, but they somehow provide these extension points. I think they have some in-house documentation available for these plugins which are not opensource, but they don’t give access to that, and it’s very hard to do that without support from JetBrains for example.
Federico: Yeah. Regarding BashSupport it seems like from a marketing point of view it’s good that they are in a way promoting it, but in the other end if people don’t realize they are not the ones building BashSupport. In a way it seems like they are taking the credit. Not on purpose.
Joachim: Anyway, I think it’s good to highlight the plugins which are useful to developers. I think most of the users of BashSupport are using PyCharm. I think it’s good to highlight the plugins useful to the people using the different editions of the IDEs. Of course, JetBrains is somehow profiting from BashSupport in this case, because they don’t have to write it themselves. I think on the other hand it’s putting some more pressure on my end because I need to support that growing user base, which is difficult from time to time. I think it’s a good move of JetBrains to support the plugins by highlighting them or by supporting them. I think there is possibly some lacking support to handle that higher workload for example.
Federico: When a new version of PyCharm for example is released, and you need to make sure that BashSupport supports it? Is it a lot of work?
Joachim: It tended to be a lot of work a couple of years ago but now I think it’s usually a few fixes here and there to do this. JetBrains is publishing these EAP versions, so these early access previews available before the public release is made. I had some time to test the plugin with the latest, or with the upcoming version. Usually the users of BashSupport are quicker to mention that there is a new preview release available to test. Then I’m able to look at this, that’s just fine.
That is showing that BashSupport is in use, which is good. With the current new versions of the platform, that’s really just a fix here and there. For example, if a deprecated method was removed from some clause I need to work around there is usually by reflection to make sure that it’s working with older versions and the newer version for example, or to remove some overrides keyword from my implementation because I’m compiling with the lowest version of the SDK. I also build with the new versions, and then automate ways. I need to remove some annotations here and there, for example to make it compile with the new version when a method in the super class was removed for example. That’s manageable.
Opensource
Federico: We already named one of your projects but if I’m not mistaken you have two open source plugins, BashSupport and SmarterEditor. At least two major ones. Maybe you have more smaller ones. Can you talk a little bit about these projects, please?
Joachim: Sure. I think I already mentioned a few things about BashSupport. SmarterEditor is another plugin with a much smaller user base. I wrote that plugin to basically help me to work faster with IntelliJ when I’m working with the keyboard. I usually prefer to use keyboard only or the mouse as few times as possible. SmarterEditor helps to work with the keyboard by simplifying selections or moving things around, et cetera. That has a much smaller user base, and it’s usually not problematic at all, because there is usually no issue reported at GitHub. The people who use it, now seem to be happy with it. I don’t see any necessity to improve it, but BashSupport is different in that case because it has a much wider user base. It’s still lacking a lot of things like a debugger or proper formatting et cetera.
Sometimes I wonder why people use it, because it’s lacking a lot of things which are necessary to have for full support for bash scripting. I think it’s much better than what’s available outside of IntelliJ. I would like to work more on this but time is short and it’s difficult to handle this. Basically there is another plugin now which I’m working on, which is opensource, which is a plugin for the Tezos platform (tezos-intellij). The Tezos platform is basically a competitor of blockchain.
So it’s basically an improved version of the Bitcoin, blockchain or a much smarter version of that. I’m writing currently a plugin to support the Michelson programming language to write smart contracts for the Tezos platform, or for the Tezos blockchain. That’s fun. That’s supported by the Tezos foundation to do this. I’m happy to work on this, it’s cool to work on this.
Federico: I write domain specific languages for a living. Sometimes I wonder if for writing smart contracts would be possible to provide higher level languages that were maybe simpler for users.
Joachim: I think there are already some languages available, which are doing this. I think for the Tezos platform, for example a language called Liquidity. I think it’s based on OCaml, I think liquidity is based on OCaml which basically is translated into Michelson, and which is then executed on the blockchain. Michelson is a very basic, very low level language, which basically has a stack of values and operations to work with a stack, but it’s quite low level. Things like Liquidity, and I think that’s another upcoming language for the Tezos platform simply trying this a lot to work with it.
Federico: I will take a look at liquidity and see. So you are building these opensource projects but you are also doing consulting work. I wonder if these opensource projects help you to land some clients or in any other ways help your business.
Joachim: I think it helps for sure. BashSupport is paying off well. SmarterEditor is not contributing to this but BashSupport is doing well in this regard. I think because BashSupport is currently in the top 10 or top three plugins of the most downloaded plugins ever, it’s quite prominent on the plugin repository. It’s easy for people to find it. Basically my self employment started with BashSupport because my first client noticed BashSupport and was looking for a developer doing JetBrains plugins. That’s the way he found me and approached me to work on a project for him. That paid off very well.
Federico: Nice. We talked about a little bit already on how it’s difficult to maintain these plugins, the difficulty of dealing with new releases. I was wondering, if you receive many bug reports or if you receive contributions from other people in the project.
Joachim: I see. A lot more bug reports than contributions. I think there are some more pull requests and contributions to BashSupport in the last few months, but before that there were maybe two or three in the last 10 years. It seems to be a very limited thing to work on JetBrains plugins. I think more and more developers are doing this, but BashSupport is a bit nasty because it has its own handwritten parser because there were no parser generators back when I started.
Bash is a very awful language to parse, because it’s very hard to do this right, because it says these many different very complex structures or expressions. For example the pattern match of the parameter expansion is very difficult to parse. If you want to retain all the variable references et cetera, and regular expressions and keywords, meaning different things in different places. It’s quite bad to do this right. I think I’d have to rewrite the parser and the lexer to make this faster and improve experience. That’s not possible with the time available. It’s a bit hard to work on BashSupport for other developers.
There are many things which are not directly related to the parsing and lexing, and it’s more easily to work on this, but I think many people use it, but not Java developers. There is a new developer on the team of BashSupport, Alexander Nosov. He’s doing a great job to provide fixes and bug requests for BashSupport. I’m happy for that, and he’s doing well. I’m happy that there is someone else on the team. It’s a bit hard to manage about 500,000 users with the time available. It’s manageable, but sometimes I wonder why people are still using it because I’m not that quick to fix issues compared to the speed they report them.
Federico: I realize that it’s very difficult to maintain a successful opensource project. Much easier to maintain unsuccessful projects. No one complains.
Joachim: It’s correct.
Federico: For our readers: don’t make your opensource project successful or it becomes very tough.
Joachim: I think find a good way to pay for it. I think that’s good. In a way BashSupport is paying well because at one point before my wedding I had a little gift campaign inside of BashSupport to ask users if they wanted to contribute something to my wedding. That paid off very well. I’m very happy for my users that they were very generous to contribute to my wedding and basically paid off my wedding in full. That was very good. At that point I promised that I will not raise any money with BashSupport again.
I’m not doing that. In the long run it’s a bit difficult to do that with the free time available. Maybe I will find another way, maybe I’ll find someone else to help with development or some support work in the plugin. For now it’s difficult but if you do your own plugin and it becomes successful, then find a good way to pay for it.
Federico: Maybe writing some short book or video calls and ask for a free offer. We do that for JavaParser. It’s not like we are getting rich with this or anything. Who knows? You have more users than JavaParser I think.
Joachim: Yeah. I couldn’t write a book how to work with BashSupport, maybe I could write a book how to work with IntelliJ, but I think there are a few books available on that. I think it’s very difficult to do a successful opensource project and to make a living with it. Many people are trying with subscription model for server based software, but I think it’s still very difficult to do this.
Working with You
Federico: We have talked about your opensource work. Now I would like to talk more about your consulting work. What kind of projects do you like the most working on?
Joachim: I like the most, the projects where there are some gains on productivity which are helpful for the client. A project which helps the client work faster to improve productivity inside of the company or for the developers using the product of the client. I like that quite a lot because that makes me feel good to provide value to clients and developers. On the other side I prefer to work on projects which help me to learn new things. That project for the Tezos platform I learned a lot about blockchain or the smart contract language, et cetera. I like these kinds of project as well because I learn a lot about new things this way.
Federico: Regarding productivity I think that it’s crazy how much the value that someone provides when you increase productivity even by 10%. Considering the cost of employees, a company can increase productivity by buying a plugin can really save an incredible amount of money.
Joachim: I think so. You have to get that message to the person buying these plugins at the companies. I think these are usually different people to people who gain productivity and the people that have to buy it. I still have to find a good way to sell this. I think the gain in productivity if it happens with a plugin is very helpful for that company.
Federico: Yeah. Maybe we need to share more such stories and present them in a way that it’s easy to see the advantage.
How do you typically start a project, how do people approach you? What is the typical way to get in contact with you and get started?
Joachim: That’s usually I think in a very simple way. I have a website and usually people I think check out the website and then get in touch with the contact form or by email. After that I try to keep it simple. For example to not over-define or over-specify things in advance. I think it starts usually with a quick call to see what the client needs, and that’s a way to do this in IntelliJ. After that I try to continue to keep it simple. For example by releasing plugins early because a plugin usually consists of many small mostly independent parts, and it’s possible to just work on a smaller feature, publish it, let the developers or the client use it, and then get some feedback to provide further features in the areas I was working on, or to work on other upcoming features.
Some iterative development work is preferred but I think that’s mostly also useful for the clients as well, because they will get some quick feedback and they will quickly see if the plugin is working out for them or not. I think the work or the communication with the client itself, I try to keep it simple and maybe call once a week to talk about the current questions, or about the upcoming features or developments. I think that probably also highly depends on the company itself. If it’s a smaller, a more uncomplicated company I think then my current approach is working. If it’s a much larger company, if it hasn’t happened yet for me, and it needs to change, but for now it’s working out this way.
Federico: This leads to my next question. Who is your ideal client, is it large company, a small company, a company working a certain field? Do you ever see some characteristics that make you work better with a company?
Joachim: I think currently I’m not limited to any specific field of expertise or any department. I’m happy to work with companies from all different kinds of work. My ideal client would be some medium size or smaller size company, but which is still able to provide the compensation for the work necessarily to do for a good plugin. I think there are some differences in a basically working plugin, and a smart plugin, which really enhances productivity, and that’s needs some budget. I think that’s still manageable for a smaller or medium size company if they see the value of this.
I think it would be a bit more difficult to work with a very large company where things are more … Need to be in order in a certain way to make projects with third party developers or third party freelancers work, but I think medium to smaller size company which likes IntelliJ, and which is looking for some reward in productivity or tooling support is best.
Federico: Also for me it’s the medium sized companies. It’s also because you can really see the effect of your work on the company. You can have a significant impact on the company, while it’s difficult to change a super giant company.
Joachim: That’s a good point.
Freelancing
Federico: I think that also many of our readers are interested in freelancing, considering it. I’m curious of your experience, how did you start going into freelancing?
Joachim: I think basically it started with my first client who approached me, and asked me to work on an integration of his software into IntelliJ. At that time I was still employed but I was working remotely because I moved to southern Germany a few months before that. I was basically looking for something else. That turned out to be a good opportunity to start working as a freelancer or to be self employed. I started with that and I’m trying to find my way into consulting about plugin development. I’m still trying to find my way but I think it’s good to have a client at first which is looking for some midterm or long term contracting.
Federico: Definitely, it also makes clear that there is the need for this kind of service. I think it’s a very good thing to start with a client.
Joachim: I think so. I probably wouldn’t have decided to become self employed if this client wasn’t looking for a developer working on a plugin. I think it’s much more difficult to start without any client at all.
Federico: Why did you decide to specialize in plugin development?
Joachim: It’s a good question. I think for one because it’s something I like to do. I think I’m good at this. There are many other people good at this or better at this. It still seems to be some niche on the market where not many freelancers or consultants are offering the services. I think I know what I’m doing in this area and I just like to do it, because it’s fun and it’s not getting on my nerves like JavaScript web development or something. It’s just basically, whenever I do it, it’s just awful but doing plugin development is a good way to work I think. I like to create software which is smart and helpful.
I decided to do what I’m good at. I think I’m not limited to plugin development but just offering very generic services on my website wouldn’t work out. I’m trying to find my way here.
Federico: I think that normally developers are very scared of specializing, because they like to think they are able to do everything. I think that instead specializing from the point of view of the client gives you more clarity on what you are very good at. It means that you have a lot of experience in that kind of project. So it will probably give you best results than a java developer just trying to write a plugin, right?
Joachim: That’s correct. I think if a client contacts me to work on a plugin I’m able to provide much quicker results and better results compared to a Java developer who needs to find his way into development of IntelliJ plugins. I think in the end he will deliver the same results but he will take a lot longer to do this. I think for a client it’s helpful to know that I’m good at what I’m doing. Of course I can do a lot more than just to write plugins for IntelliJ. That’s currently not what I’m offering on my website, but for example for a client I’m doing developing in golang for backend services, a desktop software which runs in the background, which is headless. That’s fun as well but that’s not what I’m offering at first.
Federico: Do you have any advice that you would like to share with other freelancers?
Joachim: I’m not that long in business too. I have gained a lot of wisdom in this regard, but I think one point which is very helpful at least to me is to know that I’m planning to work on the things I’m doing for a very long time, like two decades or three decades. That’s a very long time, and in that time I need to stay fit and healthy. To know about this and to plan to work on this long term means to have good hardware, like ergonomic hardware, and to have a good seat and to have a good desk, because you can ruin your back and everything else if you don’t care for this.
I think it’s not directly related to self employment or freelancing or software development but I think when you are sitting 10 hours or eight hours for 10 years or 20 years at your desk, you need to care about this to be able to continue to do that.
Federico: I probably should change my cheap Ikea chair. I will ask you advices on this later.
Joachim: It doesn’t mean that it’s bad. It just needs to support you and to help you. I think I’m probably a bit concerned about this, because I usually have some troubles with my wrist, that’s turned out to be related to the keyboard I was using. I’m with an ergonomic keyboard I’m doing much better than the traditional size of keyboard. I think a simple change can help a lot.
Federico: Me too. I have this nice keyboard, it’s called the Natural Keyboard from Microsoft. I like it.
Joachim: I think it’s a good one.
Conclusions
Federico: We are now going go to the last set of questions. I was wondering if there was something that you have been recently interested into, something new that people could want to hear about?
Joachim: Not something really interesting. Personally I’m doing a lot of work in Kotlin. So I’m moving from Java to Kotlin mostly. From the Java language to the Kotlin language. I like it quite a lot. I try to do some web development with that to have some some types of development for JavaScript et cetera to do the multi-platform thing they are offering, but that’s still in the early stages I think, but they are making progress. I like Kotlin quite a lot, and I can fully recommend it, because you need to just write half of what you are writing for Java and get the same or even better results. That’s highly recommended.
Federico: Good. I totally agree with that. Is there anything else I forgot to ask that you would like to add?
Joachim: I don’t think so. Personally I’m trying to find a way to do something else in addition to plugin development. Currently I’m working on a side project to do something similar to Rollbar or Sentry which is error tracking and software. Basically I’m suffering from the not-invented-here syndrome. I decided to do some personal projects to learn about new technologies. For example, Kotlin and new up to date web development et cetera, and to write server software in Kotlin. I think I’m using it to learn new things, which is very helpful for me, because I usually don’t learn by reading alone. I need to do both to be good at it.
I’m trying to use this error tracking software in BashSupport at some point, because currently I’m doing, I’m using emails sent from a remote endpoint to send these errors over to my site. I don’t want to use any third party software, which is hosted on the cloud for this. I’m still trying to find my way into this. Maybe I will offer some hosted solution at some point, but maybe it’s just staying a personal project. It’s opensource it’s called LogRally and currently it’s still something I’m working on to learn about new things.
Federico: We will add the link and if later you keep working on it we will have another interview on this.
Joachim: Okay.
Federico: How can readers find more about you and your work?
Joachim: Basically by looking at my website. I have a website related to the plug development I’m offering which is at plugin-dev.com. I have a personal website at ja-dev.eu, which is basically my first and last name initials. I can send you the links later on. Thanks. It’s best to just look at the website to see what I’m offering and to get in touch by using the contact form or to write an email for example.
Federico: For clients that are interested in working with you, they should just use the contact form?
Joachim: Yeah. I think it’s best to just use the contact form, or if you prefer just write an email. My contact details are on my website. If you like you can also call me. My phone number is on the website as well. Feel free to do that.
Federico: I never put my phone number. Just recruiters are able to find it, I don’t know how.
Joachim: I think up to now I have not had many bad experiences with the phone number. I think I have it on my website. I’m not totally sure. I think do.
Federico: Because sometimes I worry that people are not aware of the fact there exists timezones. So maybe someone will call you in the middle of the night. Sorry, it’s morning for me.
Joachim: That’s right. I’m able to turn my phone off at night if I want to.
Federico: That’s also smart. That was my last question. Thank you very very much for spending this time with us and being so open about your experience, I think it will help our readers.
Joachim: Thank you Federico. Thanks. Bye.
Federico: Bye.