You have firmly decided that you want to learn to create applications for Android using Kotlin. You are super motivated to create your first application.
Or are you?
If only it were that simple. There is that lingering feeling in your heart: “Perhaps learning iOS is better?” Were you thinking about Web and Desktop application development yet?
Choices, choices — everywhere!
Even if you’ve decided on Android, perhaps, you are still not sure what is the best starting point: Kotlin or Java.
There are a lot of comparisons between iOS and Android development out there, and they all talk about (if you haven’t seen those yet, go and search on the internet — there are plenty of those):
- size of the market
- jobs prospects
- revenue gaining opportunities
- development tooling
- knowledge transferability (how the knowledge you learn on one platform can help (or cannot) on the other platform)
- device fragmentation and many others
Let’s imagine that you have identified a benefit from one side, like Android’s market size being much more significant.
Next moment, you find a downside that either will cancel out the benefit or will make you spend a lot of effort to cancel out that itself (like device fragmentation and revenue levels).
So the choice is pretty tricky and not apparent.
I know how you feel right now. I’ve been there when I was trying to choose what mobile platform I wanted to learn first. It is frustrating and painful.
But hey, if you have already made a firm decision — great! Read on, and you will not be disappointed. Because what is to come — will surprise you.
In programming, when things go about learning, all of the above matters quite a bit.
But not as much as the learning benefit that you get.
Learning a Programming Language in a Day? — Impossible!
Or is it?
Did you know that a programmer who is an experienced learner, can learn a programming language in one or two days? And get comfortable with the platform, bunch of libraries, and a framework in another one or two days?
Sounds shocking, isn’t it?
And no, I’m not trying to sound arrogant here. These are actual people, who I know. And they can pull that off. Moreover, they can join a team that has an entirely unfamiliar set of technologies, and be productive on their first day.
They are not some geniuses or super-talented people.
They do share one observable trait though: they all know five and more programming languages, and they are proficient with a bunch of different libraries and frameworks from these languages.
These developers can start being productive with a technology they’ve never seen before in a matter of hours.
For that, they need access to someone already proficient in this technology. While working on some feature, experienced learners would ask a few specific questions to the experts, so that they can fill in the blanks in their existing knowledge.
So two to three questions and they are already ahead of most learners by far. As far as by months and years of experience.
That sounds amazing and daunting at the same time.
Perhaps, you are thinking “That is not possible!” Or maybe you’re feeling down because you can’t learn as they do.
The point is that, when you will be able to command (comfortably developing production-ready applications) roughly five and more programming languages (that are not very alike), and about the same amount of different frameworks, then this skill of rapid learning is yours to take.
In fact, it will already be yours. And you’ll be just like these “talented” (more like hard-working) developers.
To get there, you’ll need to accept the “Life of Learning” into your heart. You’ll need to become a lifelong learner.
Just like them, you will want never to miss an opportunity to learn.
There is a weird behaviour of the library? — You go out of your way to read the documentation and sources. And you debug and use print statements.
You do all of that until you understand precisely why it behaves this way.
Perhaps, you catch a glimpse of a new concept, but made it work without fully understanding it? — go there, read about it, play around with it, until you have a full understanding of it.
Do you have a bug in front of you, and somehow your last code change made it fixed? But you still don’t understand the bug? — You don’t stop there.
You figure out why it was not working, and why your fix worked.
Sometimes, you’ll need to create a tiny application just to play around with a single new concept. Use it in all the forms and for different purposes, until you’re confident that you got this.
I hear you’re saying: “One day? No matter how much learning you do — it is just not possible!”
Heck, it takes months and sometimes years to learn a programming language!
I know, right?
That is true. It takes so much time to learn even a single concept in programming.
But it takes a tiny bit less time to learn your second concept. Especially, if that concept has some connection to the one you’ve just learned before.
But it all checks out.
Science Behind Learning Programming Language in a Day
In Human Cognition and Learning, there are few theories on how people process information and learn. These all theories are significant and complement each other.
There is one theory that contributes to this effect of learning a programming language in a day.
It is the Schema Theory developed by the respected psychologist Richard C. Anderson (Anderson 1977, 1978; Shallert 1982).
You can dig into these white papers in your own time, but let me quickly give you an overview of most important parts here.
The main concept in the schema theory is Schema. It represents generic knowledge. A schema includes slots for all the components and features included in it.
One schema can contain other schemata (plural of schema). Essentially, schemata are embedded within others at different levels of abstraction. But relationships between those are not necessarily hierarchical (like a tree in programming), but more like webs (bi-directional graphs in programming).
Let me give you an example of what could be person’s schema of a “variable”:
I’m pretty sure there is a lot one can add to that schema. You can continue expanding this schema endlessly.
At some point, you will even escape domain of programming and start talking about normal things in life and nature. Or perhaps, you can connect it to mathematics or linguistics domain. And so on.
Why do you think I’m so obsessed with cognition and learning?
I’ve spent a few weeks digging through papers to understand how a person can learn faster and better. Especially, I was interested in formal and abstract concepts’ learning.
I did it because I’m creating a few Kotlin and Android tutorials and I encourage you to become a member of iwillteachyoukotlin so that you can receive an early preview version of my “Ultimate Tutorial: Getting Started With Kotlin on Android.”
Anyways. Schemata like that are not just drawn on the paper by a learning student (not saying that you couldn’t — it might be a good idea).
They are formed naturally in one’s brain when individual gains more an more experience and concept understanding.
Schemata change all the time. Even right now, while you are reading this same text, your schemata are being expanded and re-structured (unless you already know everything here).
The most important point is that schemata like that are much more than a sum of its parts. Whenever your brain makes a meaningful connection between two schemata, you gain insight.
It is like having a breakthrough.
Did you ever have an “A-ha!” moment like: “A-ha! This thing over here is just like that other thing I know everything about but with such small difference?”
This insight might not be 100% correct. But it doesn’t have to. Such insights are something that makes you able to apply an otherwise wholly new concept quickly.
So here is the deal. The more schemata you have readily available to connect concepts to, the faster you’ll learn these concepts. Some of these schemata don’t even have to be from the domain of programming.
For example, if you are learning how double-linked list works, you might connect that concept to a schema of how cars are connected in the train.
Then you can understand all the operations with a double-linked list (such as insert and remove) as an operation being performed on the train cars.
And it will all check out.
Obviously, such connections between schemata are just what we call metaphors.
They give us meaningful and useful models for the understanding of a particular concept. But they have edge cases when concepts differ from these models.
So it makes sense to discover these edge cases, and learn how the concept behaves in these.
That, my dear reader, is exactly what experienced learners do when they ask precise questions about new programming language or framework to someone already knowledgeable in it.
They probe those holes in their models. They fill in the blanks in their schemata.
Alright, this is all great, but what does it have to do with the question whether you should learn Android or Kotlin for that matter?
Or should I ask the real question?
Why Should I Learn?
See what I did there?
I’ve changed the question and made Android, or Kotlin irrelevant.
So should you learn?
According to the schema theory, the answer is a definite “Yes.”
You’ll need all the learning and all the schemata that you can get to achieve your life goals. So learning every day and at every opportunity should not even be a question. That is just what you do.
The simple reason to do it always is that the more you do it, the easier and faster it gets.
My famous phrase “learning is a skill that can and must be trained” shines here. The more you learn — the more schemata you have and more interconnected they are.
As a result, it gets easier and faster to learn new concepts — to expand said schemata.
That is all unless you don’t want to learn anything in your life again. Sorry to break it to you, but as soon as you want to achieve anything you haven’t done yet, you’ll have to learn and grow.
From the fact that you are reading this, I firmly believe that you want to learn.
That makes this question answered, you want, and you should learn.
What about Android?
Well, no matter how much you weigh the upsides and downsides of all the different platforms, you won’t arrive at the decisive solution. It depends a lot on what kind of application do you want to create, what business you are trying to build, and what is your market.
If you already have all that information, you should be able to make a choice.
If you are just looking at what new technology to get in your toolbelt as a software developer, then it doesn’t matter as long as it is something that is widely used. Android is.
What about Kotlin?
These two years and a half, Android community has seen a rapid increase in Kotlin usage. Every single software developer that I’ve met or been working with were super happy about Kotlin.
They’ve converted company’s application to Kotlin as soon as possible too.
Some of them made a conversion even before the stable 1.0 release of Kotlin. Which was a bold move, but it was worth it.
Moreover, Google and other big companies and communities are making their bet on Kotlin.
If you are reading this, you’ve perhaps already made a choice. If I were you today, I would do the same — learn Kotlin.
This article originally appeared on Hackernoon.
HackerTrail is a curated marketplace exclusively for IT talent ranging from developers to infrastructure specialists to data scientists. Using clever technology and gamification, HackerTrail connects the right candidate to the right job opportunities with top companies across Southeast Asia.
Looking for an opportunity in Android development? Check out top companies in Singapore hiring for Android developers now on www.hackertrail.com.