

For the last 5 years Iβve been dreaming about starting a podcast where I would interview indie developers who made it big and still decided to stay small and frugal rather than shoot for some imaginary stars just because our society considers it to be the βrightβ way. Why after creating a successful βindieβ product developers would decide to prioritize freedom and happiness over a chance to manage thousands of people is a question I can relate to and like to explore.
From dabbling in podcasting in the past I was reluctant to do it againβββpreparing, juggling meetings, producing, etc. is a lot of work. Additionally, no one probably wants to hear my Eastern European accent in audio-only form and I donβt have the time or determination to try and shake itΒ :)
So, I finally decided to do a series of written interviews instead of a podcast. And today we have the first βepisodeβ of the series. Who should be the first was always a no-brainer to meβββIβve known Antanas Marcelionis and Martynas Majeris for years. amCharts success has been a solid example of defying the βSilicon Valley modelβ that Iβve witnessed first-hand. Theyβve built a leading charting library in Flash and then repeated their success when the technological landscaped has suddenly shifted under them. Now theyβve put out a v4 and it looks like another great milestone in the history of the product.
So, I got the final push to do this series and here we areβ¦
Disclaimer: as Iβve mentioned above Iβve known Antanas and Martynas for a while. Weβve been partners in several businesses and Iβve been an on-and-off part of the extended amCharts team since 2008. So, Iβm hardly unbiased. Having said that, this could have had an opposite effect on this interview (as opposed to shameless praise) as I tried to steer clear of controversial topics related to our personal relationships.
Since I was a kid I saw business opportunities practically everywhere and explored a lot of them. And the main reason for doing business was to earn money for a computer. I even tried to build one myself, but it didnβt go well. So, I helped my father grow tulips and with the money we earned by selling them in the market Iβve got my first computer. It was Sinclair ZX Spectrum. I think I was around 13 then.
Later, Iβve got an IBM PC and then a connection to the internet. All I did since then was internet-related. I even helped people, mostly Americans, to find relatives in Lithuania for a fee (even if it was basically looking up people with some last name in a phone book).
Iβve built my first homepage on Geocities and then started offering web design services to some companies. I always worked for myself, opened and closed (or left) 3 web design companies until I was 27. During all this time I wasnβt actively programming, only sometimes (mainly because I havenβt had any programming education). I left my last company without a clear idea of what I will do next and it happened that we rented the same office space with Martynas and Alan. I was working on some freelance gig and I needed to draw charts a few times. So, I thought I can make my life easier if I create a utility to draw charts. Thatβs when I started coding more seriously and become quite an annoying colleague as I was asking a lot of questions about programming. And it happened so that the first chart I built (it was a pie chart, of course) became quite popular in Japan!
When people started buying licenses, I promised my colleagues at the office that I will buy pizzas on the day a more expensive type of license is bought. Pretty soon we couldnβt look at pizzas anymore.
The rest, as they say, is history and since then (2006) I am working on charts full-time.
Ever since my mom brought back an IBM PS/2 some 30 years ago, my life had a clear path. From first forays into programming as a teenager, into full-scale IT-related jobs, up to a point when I was juggling my time between a local dev house, a co-owned web consultancy in New York, some personal projects, and part-timing for amCharts since it was founded back in 2006.
At some point, the burden of divvying attention between so many things got old, and half a decade back I dropped everything else for a full-time attention to amCharts. Since then I have been responsible for certain parts of development, ran support crew, managed sales, and web operations. Your typical COE (Chief Officer of Everything). With the team growing, when we were starting development of v4 I was able take on more development responsibilitiesβββexactly what Iβve always wanted.
Iβve always been a geek, I first used a computer when I was 8, and I was immediately hooked. I started programming when I was 16, just for fun. A friend taught me the basics, but after that I was completely self-taught. Since then Iβve been programming for over 11 years, and Iβve learned a lot of programming languages.
I needed a part-time job, and unfortunately part-time programming jobs are pretty rare, but amCharts had a part-time opening as a support personnel. I did a good job at that for a few years, left for a couple years to work on a non-amCharts side project, and then came back to work as a programmer for amCharts.
My main responsibilities are handling the low-level infrastructure stuff: tools, utilities, libraries, integrating V4 with other technologies (Angular, React, etc.). Beyond that I offer advice and handle anything else that needs to be done. Iβm quite happy working for amCharts, I get along well with Martynas and Antanas.
Most likely because we are all introverts, 100% of our current staff work from homeβββmyself and Martynas work from our home-offices in Vilnius, Lithuania, Paul works from Hawaii, and our support team is scattered all over the worldβββwe have one guy who does support when he is tired from surfing in Bali. The main reason I quit my own web development companies was because I got tired of formally communicating with and managing people. And now, when some important-looking person from an investment company with a tie says that they want to invest in amCharts and will help us build a βnormalβ, more valuable company, I keep reminding myself that Iβve tried being normal. And I didnβt like it.
Weβve faced this choice a number of times during the years but dismissed it every single time. Weβve been enjoying this too much, to willingly concede our freedom for a bigger chunk of money. Going big(ish) would mean accepting outside capital, becoming accountable to someone, shifting our own responsibilities from development towards management. YuckΒ :)
We sometimes make huge business decisions in, like, 5 minutes, over Slack chat, then go ahead and implement them in the next hour. Just trying to imagine how it would have to go down in a growth-at-all-costs oriented, VC-backed company gives me seizuresΒ :)
We also have a philosophy that we work for developers. That means everythingβββlicensing, installation, features, support is designed to make senseβββfor developers. And if something doesnβt, we can change it on a whim, without long brooding how this will affect growth or the revenue stream.
Accepting VC, growing the team, would require us to shift our focus towards pleasing the investorsβββincreasing revenue. Bothβββto keep investors happy and to feed the large team. That inevitably lead to decisions that are more biased towards growth, than common sense in the dev community.
So, staying small, having no one to be accountable to, except our usersβββthe developersβββmade the most sense to us 10 years ago, and it still does now.
It wasnβt, ActionScript is very similar to JavaScript. I remember I was copy-pasting a lot of code from my charts made for Flex and only fixing some small differences. The main things that I missed in JavaScript were classes and, of course, type-safe programming.
The first reaction was βOh no what are you doing, Steve? Youβre gonna kill Flash, and weβll have to do everything from scratchβ. Once that initial reaction passed, we quickly saw it as an opportunity, both to rewrite and better our products, and to get ahead of our (at that time) βsluggishβ competition.
The only difference between now and then is that now people do not expect a library to work with old IE browsers which do not support SVG. Our v3 could be rendered using both SVG and VML (the vector format which IE8 and older support), and this caused a lot of problems as VML is much less flexible than SVG. And SVG today is the same as it was 7 years ago, so everything is possible now was possible then too. Well, the computers and the browsers got faster so you can do some more fancy effects and worry less about performance. With SVG you can do everything you could do with Flash. The only thing is that quite often you need to invest more timeβββFlash offered a lot of things out-of-the-box, plus you didnβt have to worry about differences in browsers.
Yes. It was ready before that. The industry just needed a nudge, which came from Apple. We transited from clunky, proprietary, plugin-based Flash into open, standards-based JavaScript and SVG. Best thing that could have happened.
We needed to up our game. We needed to do something flexible, extendable. Something that modern web developers are comfortable with. That is compatible with current frameworks and technologies. We needed modules, we needed type checking and error handling, we needed our stuff to be compatible with IDEs. Vanilla JavaScript just did not cut it, and TypeScript was a de facto standard. Easiest decision we have ever made.
I tried the very first version of TypeScript when it became publicly available and I liked it, as I said I was missing strict types, classes and other things from ActionScript a lot. And even the first version had most of the things I expected. I wrote first lines of amCharts V4 in 2015, with TypeScript 1.5. And itβs Typescript 2.9 nowβββthe development team has been improving the language all the time (and making us rewrite our code quite a few times, but no regrets there).
Only briefly. There are a lot of options out there, some might be even better at some tasks than TS. But frankly, with all the muscle behind TS, and overall acceptance in the community, itβs kind of a no brainer.
One friend advocated Coffeescript to me, but I must say I never tried it. The fact that a company like Microsoft is behind TypeScript with the right philosophy that played well with ours was enough to tip the scales right away. And during the time we were starting work on our v4, Google announced that they will use TypeScript in Angular so it felt like we made the right choice and thereβs no reason to βshopβ around anymore.
The biggest alternative at the time was Flow, which is also quite good. But ultimately the fact that TypeScript was more popular (and was gaining traction with things like Angular) made it a more attractive option.
Too early to count the ducks, as weβre yet to see commercial implications of switching to TypeScript. However, from the development side of things, it most definitely paid off. Without strong type checking, weβd probably still be chasing weird bugs nowΒ ;)
I am sure it did. Weβve spent 3 years developing V4 and I am afraid we could have spent twice as much if we had to do it without strict types, all the refactoring possibilities and all the other good things TS offers. And I donβt even want to think of the number of bugs we could have left without all this.
I was skeptical of TypeScript at first (Flow had better features at the time), however over time TypeScript has added all the features that Flow has (and more!), so I think TypeScript was definitely the right decision.
The biggest beef I have with TypeScript is that it requires compiling, and thereβs not one but whole three garden varieties of compilers out there. All with their own complexity, faults, bugs, and huge learning curves, it almost seems like a rocket science managing a huge project. I canβt count the times we hit snags with compiling. This might be a serious burden (one that might not be prominent until youβre well underway) for people trying to get into TS dev.
Weβve encountered a lot of minor problems with TypeScript (and filed a few bug reports), but overall weβve been able to work around everything. I think our unique situation (weβre providing a large and complex library, and we also need to worry about compatibility with JavaScript users) makes things more challenging: I think application developers will have a lot fewer problems with TypeScript.
We canβt speak in terms of βchangesβ between v4 and older versions, because itβs a completely new dataviz library. Imagined and done from scratch. That said, Iβm particularly proud of some conceptual decisions we have made. One in particular is what we call βstatesβ. Itβs a way to dynamically change, or gradually transition, anything to anything. Any setting, data, property. The engine will automatically take care of it. For example, we could say this column will now have different value and color, and it will just magically happen, transiting gently to a new value and changing the color gradually. Itβs so powerful yet so natural, it still gives me goosebumpsΒ :)
When developing v4 we started from building a core. I loved ActionScript so a lot of things in the core are done in the way I remember from Flash and Flex. We even call our main visible object Sprite (I hope Adobe wonβt sue us for thatΒ :)). So, this core does everythingβββlays objects out on a stage, does animations, interactions, changes states, filters, does math, number, string and date formatting, processes dataβββeverything you need to build any kind of SVG project, and you indeed can use it separately from charts. When the core was ready weβve built charts using it, improving the core at the same time to meet our needs. Our charts are architected in a way that lets user control everythingβββaccess every sprite, change any property, add interactions. If you are a developer, you can also extend our chart classes and build your own new chart types or add some things that are not supported out-of-the-box. And, as we have a really good core and very flexible classes needed to build charts we are planning to add a lot of fancy chart types soon.
In addition to TypeScript, we also now officially support npm, Webpack, Angular, React, etc. Because V4 was rewritten from scratch, we were able to ensure that it works great with modern JavaScript tools and ecosystem.
90% of the work happens in Sublime Text 3. The rest is pile of other stuff: Git, Node, Webpack/Rollup, Selenium, andΒ β¦ SpotifyΒ :)
My colleagues call me βan artistβ, because I donβt really care about the βbeautiful codeβ too much. I make things that work and do things I need but donβt care how I got there. For a year or so I was developing v4 alone and built the early prototype of the core with the main things I needed from it. Later Martynas and Paul joined me and they practically rewritten everything so that the code would meet the quality standards, be fast and well documented. At the moment I am more focused on developing the chart part of the product and they still make the core better each day. I think this approach worked very well for us, as itβs quite common that the perfectionist developers cannot finish their products because they get stuck perfecting their code and do not allow themselves to do some small crimes code-wise because then it would not be perfect. I donβt have such constraints.
As for tools, besides Sublime I use paper and pencil a lotβββdrawing charts requires solving a lot of geometry, so I draw things on paper and write some math there. Luckily geometry was one of my favorite subjects at school.
Yes, thatβs certainly true, there are many small βcrimesβ committed daily, haha. But overall I think the code is in a pretty good spot right now.
We use the normal TypeScript compiler (tsc) for transpilation, it works quite well for our ES6 and TypeScript users. As for our JavaScript users, we pre-bundle everything with Webpack, because it has great support for code splitting and dynamic loading, which improves the startup performance.
As for personal tools, I donβt use anything fancy, just Sublime Text 3 and a console. Iβve written a bunch of custom scripts which automate various things for amCharts (building, testing, publishing, etc.)
Being a programmer is a bit unique because you really donβt need much: even if you have no money, you can still be a top-tier programmer, because all of the tools are free or inexpensive.
We basically live in Slack. Before that we tried a number of solutions like Basecamp, and even plain olβ Skype. Nothing stuck. Now all of the teamβββdev, support, sales, and even part-time helpβββare on Slack.
Git does a perfect job of versioning and issue tracking. Naturally.
Build processes are all automated (thanks to Paulβs phenomenal affection to perfection and automationΒ ;).
This might seem like something taken straight out of a motivational poster, but whatever you do, make sure you love doing it. Boring stuff quickly gets old and deteriorates into neglect. No point in wasting your time on throwaway stuff. Thereβs absolutely no way we could still be doing this after 10+ years if it seemed like work.
Be patient. Weβve spent 3 years developing v4. Itβs a really difficult thing to do it for such a long time and not have an opportunity to enjoy the results.
There is a saying that it requires 10 years to master something. I think thatβs true, so you need to be in it for the long haul. If you expect immediate results, then youβll just be disappointed.
β
Check out amCharts website and follow them on twitter.
Create your free account to unlock your custom reading experience.