Hey, guys!Here is my story. My family has always believed that I am talented for computers and that I can use that to get them out of poverty. So they invested a lot into me to learn how to program. I wrote my first program at the age of 9. But, because I am living in a small town in Croatia, and because my family couldn't have afforded to send me to a better high-school, I have been going to a high-school where we don't have ICT classes. So, today, I am 18, and I am still not able to make a program someone would be ready to pay me for.The most complicated thing I've made by myself is a web-app that converts arithmetic expressions to i486-compatible assembly. You can see it here:http://flatassembler.000webhostapp.com/compiler.htmlJavaScript is the only programming language I know well enough to be able to do that in right now. So, what would you recommend me to learn to be able to make some money?

The first thing you should learn is to write code and comments in english. Always. If you want feedback from others, then english is the one language that everyone in the tech world understands.

You also need to get rid of the Allman brace style. As much as I love that style, there are some unfortunate corner cases in javascript where that style will produce bugs. In a javascript world, you should use K&R.

Style issues aside, if you cannot afford formal education in something computer related, then you'll be having a hard time finding a job. Many of the well-paying companies will outright reject you if you cannot show a degree. Trying to learn all these things on your own is possible (there are plenty of excellent courses, guides and tutorials on the internet), but doing it without the guidance, feedback and evaluation from professors and peers just makes it so much harder. There is a market for untrained programmers (which you are), but that's probably not a way to get rich.

At this point, I'd suggest looking into local resources. School counselours, career advisors, open university events, job fairs, something like that? Do you know anyone who is working in your desired field, who'd sit down with you for a talk? The job market in your area is likely a lot different from mine, and you really need someone local to point out the options.

I also want to encourage you to follow your own dreams, not your parent's dreams. For as long as you financially depend on your parents, pick your battles carefully, but remember that you have no obligation to make your parents rich. Look out for yourself.

I also want to encourage you to follow your own dreams, not your parent's dreams. For as long as you financially depend on your parents, pick your battles carefully, but remember that you have no obligation to make your parents rich. Look out for yourself.

I don't know. It's hard to give up the programming after I've spent so much effort learning it. It will also be hard to tell my parents that maybe I wasn't born to be a programmer. They will ask me something like "Why did we buy you a computer and all those books if you are going to give up now? You realize how much those things cost?". What should I tell them then? Besides, I don't even know I have a dream to follow.

How long did it take to build something like that ?

It's only 700 lines of code. But I had to spend an incredible amount of time to learn programming well enough to be able to make a web-app that converts arithmetic expressions to i486-compatible assembly.

For the most part, individuals don't write programs that others pay for.

There are exceptions.

But the problem is that code scales. If I write a program that solves problem X, it can solve that problem for a million people. And if each of them pay me 10 cents, that is 100,000$.

Now, suppose I get together with a dozen other programmers and we write a problem that solves A-Z (26 problems) that are related. We spend 20 years of work writing it between us. And we sell this program to 1 million people for 2$ each.

That is 100,000$ per developer year of work. If we have 100% overhead, that is 50$k per year salary.

Now some lone programmer comes along. They write a program that solves some problem. Maybe it takes you a year. Suppose it solves problem X. How much can they charge? Obviously less than 2$, or people would buy the program that solves A-Z for 2$. Maybe 10 cents. And even then you now need to spend money on marketing to let people know you solve problem X. And even then, maybe only 10% of the people who would buy the A-Z program want to solve problem X and will pay you for it.

So 100,000 people buy a program for 10 cents and you make 10k$ for a year's work. Your overhead is going to be like 200% as you have to shoulder more marketing on less features. So you clear 3k$.

You did the same amount of work as the group of programmers, and got 15x less reward for it.

It gets worse if you want to do work for a single person. A well written solution can solve the problem of a million people, and that price is what you are competing with, except you have to fund your development with a single person's money. If there is an almost-good-enough solution for 50$ that maybe took a developer year to complete, you'd have to finish your competing produce in less than a day to stay afloat!

Software development is mostly about doing lots of work to automate the solution to a problem that many thousands or millions of people want a solution to, and getting them to pay you a small amount of money (or otherwise benefiting you) in exchange. There are exceptions; say, someone's company has an internal process that they use 10 people to run, and you automate it and free up 6 people's salary.

One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

As Yakk said, it is much easier to make money with programming if you work in a team. Therefore, if this is your goal, you should strive for being hired by an organization. If it is a big organization, they will also train you, which will be an advantage for the rest of your career.

As Tub mentioned, having received formal education makes you more attractive as a potential employee. I agree with his recommendation to get formal education if you can.

However, I think being hired without formal education is still possible. The good news is that you already have something non-trivial to showcase: your arithmetic expression compiler. Let's consider how you could polish that to make yourself a more convincing job candidate.

Imagine that you have applied for a job as a programmer at my organization. You have sent a motivation letter, a CV and a short portfolio that includes your compiler. The recruiter asked me to look at your compiler and advice her on whether we should hire you.

When writing code professionally, version control is indispensible. Learn Git and put your compiler as-is on GitHub before you start on anything I suggest below.

When looking at the code of somebody we might hire, I like to see that the candidate values well-organized code. It must be easy to find a part of the code, based on its role in the project. At the very least, I'd like to see your JavaScript code live in a separate file. Even better would be if you'd further split that into modules, for example one for the tokenizer and one for the parser.

Paradoxically, in order to make money with programming, it is important that you write as little code as possible. Reuse functionality from libraries whenever you can and try to keep your functions as short as possible. You could generate your parser using Jison. Every time you write

if you use jQuery. Building large chunks of HTML out of many short strings will be much easier using a templating system such as Handlebars. You could also simplify your algorithms by using Lodash and exercising functional style.

Appearance is extremely important, whether you like it or not. You can make your compiler look attractive by using a style toolkit like Bulma, Bootstrap or Materialize.

Finally, there are some other things you can learn that will make you a more attractive job candidate, but which aren't directly applicable to your compiler. I'll name a few.

Knowing more programming languages never hurts. You could, for example, consider Python.

Knowing at least one framework helps. Frameworks force you into somebody else's way of thinking, but once you accept this, they help to structure your code, thus helping you to make money. For JavaScript, you could consider Polymer, React, Angular, Vue, Ember or Backbone (roughly ordered from most to least fashionable; I'm leaving my opinion out of this). For Python, I could recommend Django.

What Yakk said isn't entirely wrong, but only a small part of all software development is meant to produce software sold to customers. Most software development is meant to solve some internal business need - automating processes, monitoring work results, data mining, totally boring business databases. Such software is often developed in-house and never leaves the company. Sometimes it's developed by a consulting firm and sold to a handful of clients as part of a comprehensive consulting and support package.

What is absolutely true is that most software is developed as a team, and it's never too early to start using git.

Reuse functionality from libraries whenever you can and try to keep your functions as short as possible.

Yes, but extensive reliance on the 3rd party libraries and frameworks can also be a sign of incompetence.

Appearance is extremely important, whether you like it or not.

Maybe, but it's important not to fall into the trap of over-designing. For example, it takes you some 200 lines of code (about 2 hours of work) to program a little man walking (and rotating his legs to and fro) across your webpage in JavaScript and SVG, and whether that actually makes your webpage better is questionable.

Reuse functionality from libraries whenever you can and try to keep your functions as short as possible.

Yes, but extensive reliance on the 3rd party libraries and frameworks can also be a sign of incompetence.

I personally love writing as much myself (my own bespoke XML parser, my own graphics routines) rather than just lazily "import DoThisBigThing::ForThisSimpleLittleThing", because then it 'feels' tighter code (even if I have to write more lines with system calls rather than use one imported DoThis(foo, bar)" command). But the balance is easily overstepped.

Usually, pre-formed libraries are well written and pre-tested on all kinds of exceptions (if your call to one goes wrong, you maybe didn't understand its usage properly) whereas if you write it from scratch yourself it's a different point of failure (you usually made an error in your subcode, that needs wheedling out).

I also dislike that some programmes have to be packaged with huge hoards of files like API-MS-WIN-CORE-FILE-L1-2-0.DLL, API-MS-WIN-CORE-FILE-L2-1-0.DLL, API-MS-WIN-CORE-LOCALIZATION-L1-2-0.DLL, (etc, etc, etc) that are so easy to get wrong/mutually incompatible versions of, rather than a .EXE that just runs as-is (or not at all, when you need to work out what new system-specific thing needs handling anyway).

But I also see the reasons for (intelligently!) out-sourcing much of the coding grunt-work to a good 3rd-party lib/dll/whatever, and that practiced use of ones that can/should assume to be professionally tailored leaves you with less 'trivial' stuff to do and you can spend a bigger proportion of your time on making and remaking and mending the bits of your code (program/script/whatever) that specifically make your program do what nobody else's does.

I'm not sure I've balanced that, myself. I tend to try to go too low-level. (Like I said: XML parsers and graphics routines… I can get really tight coding, based on knowing exactly how much complexity I need rather than fudging into and out of more generic layerings of code, but I know I mess up, miss common tricks or just reinvent the wheel for no particularly good reason.)

Appearance is extremely important, whether you like it or not.

Maybe, but it's important not to fall into the trap of over-designing. For example, it takes you some 200 lines of code (about 2 hours of work) to program a little man walking (and rotating his legs to and fro) across your webpage in JavaScript and SVG, and whether that actually makes your webpage better is questionable.

If you need a little man, you need a little man!

But now you've got me thinking about a more efficient little man, with less lines of code. Please excuse me, when I next get to a desktop PC I shall probably spend about 4 hours of free time trying to get that concept working in as few lines as possible.

Regarding using libraries vs. rewriting — it’s probably better to use a well used, tested library for production code that is important. However, it can be really, really informative to implement it yourself. For instance, when I started learning about neural nets, I could’ve just used Keras or another fully built library for it, and just taught myself parameter/hyperparameter selection. I wanted a deeper understanding, so I implemented my own framework to do it instead. Sure, it’s not as easy to use as a prebuilt framework, it has fewer features (it’s still missing lots of more complex stuff like convolutional nets, recurrent nets, binarized nets, better learning algorithms), and it’s probably less efficient (though, my testing has showed it to be fairly comparable for some things). But, I have a much, much, much better understanding of how, exactly, a neural net works and how lots of the operations work. I’ve managed to get really good performance on the MNIST dataset (even without convolution — it turns out an ensemble of large feedforward nets with data augmentation is quite comparable to convolutional nets in terms of performance).

It just depends on your goals — if you want to learn about something, using a library to do that for you probably isn’t the best way to go about it. But, if you are writing code that just needs to do something, you should probably use a library if there’s one available.

Reuse functionality from libraries whenever you can and try to keep your functions as short as possible.

Yes, but extensive reliance on the 3rd party libraries and frameworks can also be a sign of incompetence.

Who told you that? In my book, extensive reliance on libraries is a sign of professionality.

It's a different story if somebody is completely clueless on how to get something done if they can't use the libraries they know. That's evidence of lack of a firm base, or of a lack of general understanding of the problem domain. However, you have already shown that you have a firm base because you can do several interesting things without using any library at all. So in your case, starting to take more advantage of libraries will definitely add to your impression of professionality.

Also, I agree to everything written in between your post and mine.

Appearance is extremely important, whether you like it or not.

Maybe, but it's important not to fall into the trap of over-designing. For example, it takes you some 200 lines of code (about 2 hours of work) to program a little man walking (and rotating his legs to and fro) across your webpage in JavaScript and SVG, and whether that actually makes your webpage better is questionable.

You are definitely right about this. By "appearance", I didn't mean "adding visual tricks"; I just meant a polished look. Balanced colors, carefully chosen distances, nice fonts, a rounded corner or a gradient if it helps, stuff like that. GitHub, Stack Overflow and the xkcd forums are all examples of websites that have a polished look. You can make it easy for yourself to create a polished look by using a style toolkit.

Speaking for my part of the industry (keep in mind, this is not general advice): Mobile app development is big these days, and there's a shortage of programmers who can go beyond the simple "static" mobile app that just duplicates a web site. While iOS dev may pay better, Android might be a better place to start, as the barrier to entry is lower: Android development tools are free (as is the emulator), and unlike iOS dev you don't need a Mac to get started. Also, the skills you learn (for example Java or Kotlin) will be applicable beyond Android. There is also a free Udacity course on Android development (it's the official one from Google) that I've heard good things about.

If you want to build a good skillset, learn some back-end as well. For example, Android + Firebase (you can also make a free Firebase account to get started). Firebase back-end is basically node.js, so you can apply your Javascript knowledge there.

Tip: From day one, put everything in a git repo (even if it's local). Or rather, a repo per project. Knowing how to use git is also an important skill. If applying for a job later, you can share your repo on (say) github. Actual code makes it WAY easier for hiring managers to evaluate your skillset, and having the commit history in git lets potential employers see your development and debugging process rather than just the final product.

Although I can't make any hiring guarantees, if you can demonstrate the skillset I've mentioned above, I can at least promise a first-level interview with my company—we're always looking for more remote Android and iOS developers.

WanderingLinguist wrote:Speaking for my part of the industry (keep in mind, this is not general advice): Mobile app development is big these days, and there's a shortage of programmers who can go beyond the simple "static" mobile app that just duplicates a web site.

If I may pop in for a quick question, what's your stance on app development using cordova, combined with a non-static, mobile optimized web app?I'd expect development using a cross-platform toolkit in a popular language to be cheaper than native, especially when you can reuse code from an existing web site. Did you experience performance issues, did customers reject those apps due to a lack of native look and feel, do you require features you can only implement native, ...?

WanderingLinguist wrote:Speaking for my part of the industry (keep in mind, this is not general advice): Mobile app development is big these days, and there's a shortage of programmers who can go beyond the simple "static" mobile app that just duplicates a web site.

If I may pop in for a quick question, what's your stance on app development using cordova, combined with a non-static, mobile optimized web app?I'd expect development using a cross-platform toolkit in a popular language to be cheaper than native, especially when you can reuse code from an existing web site. Did you experience performance issues, did customers reject those apps due to a lack of native look and feel, do you require features you can only implement native, ...?

I've only briefly experimented with cross-platform frameworks. Some of them are quite impressive, but so far, they're simply not suitable for the types of apps that I work on (high-performance multimedia content creation apps). Also, on Android, wrapping HTML to make a native app is really hit-and-miss unless you cut out Android OS versions older than Marshmallow — Lollipop and earlier, the native web view can come from the OEM-provided browser which might not be Chrome and might have last been updated in 2012 (so much of HTML5 is out of the picture) . Especially if you have to cover the Chinese market, it's a disaster. Flutter (which is cross-platform but not HTML-based) looks really good, and might be in the running for my next major project. Kotlin Native also looks really promising, but I think we're a few years away from being able to use it in a truly cross-platform way.

The apps I work on need to manage multiple audio and video encoders and decoders simultaneously (and on Android, even with the native API, this is challenging and requires exceptions based on the phone's SoC). We also work extensively with hardware accelerated graphics (lots of graphics shaders), and webgl on mobile is still in its infancy. It's also really, really hard to debug HTML-based apps that have to call through to native APIs (there are still no tools that I know of to provide a unified stack trace, and last I checked crash reporting frameworks like Crashlytics don't include the javascript stack at all when reporting native crashes).

If you're doing simple apps, HTML-based frameworks are fine. But if you're trying to build an app that's going to handle several million MAU reliably across 80% of mobile devices currently in-use (which means a lot of older devices), and be eligible to be featured on Google Play or the App Store, HTML-based frameworks just aren't going to cut it in most cases. Native cross-platform frameworks like Flutter look really promising but are still a bit too new. Also, new features are introduced in the official native SDKs first, so if you don't want to lag behind the competition while you wait for the cross-platform frameworks to be updated, you need to know the native APIs even if you call them from the cross-platform framework. For now, we're stuck with native.

For large-scale projects like the ones I work on, native developers are in high demand, and so hiring is highly competitive; there are simply too many openings and not enough developers with relevant experience — it seems everyone learns HTML5, Javascript, and one of Python, PHP, or Node.js. I'm not knocking those skills at all (they are extremely useful and we have Node.js, HTML5, and Javascript engineers on the team) but they are easier to come by at the moment. If you have Javascript background already and can add any kind of native platform to your skillset, it's a powerful combination and there are a lot of opportunities that become available.

(My phone is for phone calls, alarm clock, notes and a web browser. I'm totally out of the loop with the app market.)

You're very welcome.

These days, it's possible to do a lot on a smartphone. You can shoot AND edit a professional quality feature-length film or documentary right on your phone (and people are doing it!) Depending on the phone, you might even be able to use a mouse, keyboard and external screen with it. The only serious limiting factor now is storage.

I'd guess that a lot of folks on the xkcd forums are developers, engineers, or otherwise have an excuse to be used to working with a fairly high-powered workstations. But we're an unusual case. Pick a random person on the street and the SoC is in their phone is likely to be more powerful than the chipset in their desktop or laptop computer (phones get upgraded on average every 2~2.5 years). The only inconvenience is the form factor, and both Android and iOS support bluetooth keyboards (with Android also supporting the mouse). Also, Android apps run well on Chromebooks, and there are rumors that Apple will be adding support for hybrid iOS apps that can run on both mobile and desktop.

My read on that market is that the trend is overwhelmingly towards mobile and cloud (and of course web), and these are good areas to focus on when building a career.

Some more quick notes on cross-platform mobile apps with Cordova and similar tools:

Spoiler:

Adding to what WanderingLinguist already wrote, there are a few reasons why something like Cordova doesn't save as much time as you might hope.

A WebView environment is not quite the same as a browser environment. For example, you can't rely on cookies being available. So if you are planning to port an existing website into a mobile app, you may need to make more adjustments than you hoped for.

Interface guidelines are not the same across platforms, so you'll likely still need to write platform-specific code.

Beyond showing an interactive web page, differences in feature support between platforms start to become apparent. For example, I had quite a struggle getting my PhoneGap mobile app to reliably display a PDF file in Android.

Anyway, I've tried to polish the look of my web-app. I've tried to make it look the same in all modern browsers, including Internet Explorer 6. If you want to make your web-app work and look the same in all browsers, you have to limit yourself to a relatively small subset of JavaScript and CSS that's actually available in all browsers. When you are doing string and array manipulation, that's not so much of a problem, but when you are trying to do something graphics-related, it's quite tough (and JQuery doesn't help so much).

Anyway, do you like the way the web-app looks now? The layout I've made works in IE6, IE9, IE11 and all the non-Internet-Explorer browsers I've tested it in except Safari 5 (though I haven't bothered to install Chrome to test it in it), but it breaks in IE7, IE8 and IE10.

Last touched that, myself, in the early '90s. Slightly too early to benefit from the Y2K revival/boom in demand, which didn't happen while I was still confident enough, that might have been a good earner. (Also I was in another steady job, ending up doing Y2K prep stuff at other levels, but on the same straight salary.)

Nice to hear it's still powering on. Even if it wasn't exactly an 'electrifying' computer dialect.

So, I've extended that compiler, using the Duktape framework, to be able to not just compile single directives from my own programming language into Assembly, but to be able to translate the entire files written in my own programming language to Assembly.So, here are one of the first programs I've written in the first programming language I've made myself:

What do you think, is it worth continuing developing it?I've designed this programming language to be as easy to integrate with Assembly as possible. The Assembly code C compilers have to produce (trying to declare variables themselves, trying to declare functions themselves...) has to be almost completely rewritten if you are targeting a different assembly language compiler or a different operating system. However, the solution I've made may be even worse than the problem.I am also dreaming about making a compiled LISP-like language in which you could write arithmetic expressions in both S-expressions and infix-expressions, but be able to use only S-expressions elsewhere (since they come very handy in string and array-manipulation). However, I probably won't have time for that in foreseeable future.

FlatAssembler wrote:I am also dreaming about making a compiled LISP-like language in which you could write arithmetic expressions in both S-expressions and infix-expressions, but be able to use only S-expressions elsewhere (since they come very handy in string and array-manipulation). However, I probably won't have time for that in foreseeable future.