Throughout my software developer journey, I've had several "Aha!" moments, which made me take my skills to the next level. In this article, I'd like to share those realizations with you! I've arranged them in chronological order so that everything flows seamlessly from one topic to another. So we’re gonna start with the most newbie topic and then move to deeper insights.

How to choose your first programming language

I know that such decisions as choosing your first programming language are the most challenging ones. It’s like choosing what college program you’re gonna apply to, and what country you wanna move to. The challenge is that when you don’t know where to start, you just don’t know where to start. There is nothing you can do about that. Sadly, such confusion sometimes keeps people from starting in the first place.

But the good part is that if you’re just starting out, you don’t have to care about that. Seriously, my first language was Java only because I wanted to learn some programming and found a free boot camp where I was supposed to learn Java.

As a beginner, you need to understand that what actually matters is the tech stack you are working on. If you switch your tech stack, it’s almost a new world for you and you need to start all over again. But if you already know one programming language, it’s not an issue for you to learn another one. That means you can start by learning the essential concepts in any language you want and later decide which tech stack you want to proceed with.

And that’s what I did. After getting the hang of Java, I decided to delve into the world of Android development. And nowadays, there is no way to thrive in the realm of Android without the knowledge of Kotlin. So I had to learn Kotlin and I’m happy to say it didn’t take long because I already knew Java at the moment.

But wait a second. Have you already chosen the area you want to specialize in? For some reason aspiring devs struggle with the language-question and seem to not even think about what kind of products they actually want to develop. That may be making web apps, desktop apps, mobile apps, making games, developing artificial intelligence, etc. There are many options. And there is no secret solution to this. You’ll have to pick something that just feels closer to your heart! Or use can my next advice.

Alright, but you are an intelligent developer. You don’t want to pick the language randomly, do you? Plus, how do you approach this problem when you’re already at the stage where you need to choose your tech stack?

I think the most reasonable approach here is to choose one that will give you a job. So what I mean by that is you can research technologies for such factors as how many job openings there are, what are the salaries, what people think about the technology, what would they learn if they could start over, what are the trends, and so on. This way, you can figure out what is in demand and what is the most appropriate option for you. The situation may be different depending on where you live.

You can start with such websites as Stack Overflow Developer Survey or simply check out vacancies on LinkedIn, where you can also find out about the requirements for the job. In addition, you can find some sources that post info related to your location. For example, in Ukraine, we have dou.ua that shares insightful statistics.

And don’t just choose whatever is the most popular. If something is popular, it means that there is also a lot of competition for it. I used to be concerned that there aren't as many job openings for a native Android dev position as there are for, say, a web developer position. But if we think about it from another perspective, there also aren't nearly as many applicants. So mobile devs have much less competition now despite the saturated tech market.

Or consider another situation. You wanted to learn Spring Boot for example, but then you did a research and found out that .NET is actually in higher demand in your region, and there is less competition for it. So this way, you can discover such things and make an optimal decision for yourself.

The reason why I think choosing a technology that will give you a job is the best approach here is because you don’t have any personal preferences yet. Unfortunately, it’s impossible to determine whether you enjoy working with some technology or not before you dedicate a substantial amount of time to it. So job market demand is essentially the only decent criteria you have.

The choice is everywhere!

As you proceed in your programming journey you discover that choices are everywhere. You now need to choose between libraries, frameworks, and various coding practices. As much as there is choice, there are lots of people's opinions. For example, some people think native apps are better than cross-platform ones. Some people think that dynamically typed languages are preferable to statically typed languages. Some people think that doing everything in the command line is “the right way” of doing things. The list goes on and on.

Of course, every technology is there for a reason. Each one aims to solve some specific problem. But when it comes to choosing which one you’ll use for your project, the choice usually depends on

• what kind of product one wants to make;
• the current state of the project;
• decisions that have been already made in the past;
• personal preferences of the team members.

See why these decisions are tricky for beginners? They usually don’t have enough information to make them. One can research about what is more appropriate for them. However, a big part of such decisions usually depends on the insights gained from real-world experience. Because the devil is in the details. No article, video, or tutorial will open up all the potential pitfalls that you can face if you use some framework or library.

Programmers face these decisions every now and then. So how to deal with that? Well, IMO the wise approach for a beginner would be, again, choosing those technologies that they are more likely to use in the real job setting. For example, in Android development, these decisions are usually dictated by Google. Why is that? Because it is what is the first party, supported the most, and well documented. As a result, it's what people tend to use more often.

For example, when developing an Android app, you need to use some navigation library. There is an official solution but it’s not mature enough to satisfy all the needs. Many developers hate the absence of type safety in the official library. And some use third-party solutions instead. Does it mean that it’s better to learn a third-party library instead of the official one? Absolutely not! Because no matter how good that library is, it can’t compare with the official solution in terms of documentation, support, and the number of people that know this technology. Regardless of how much better other solutions are, many people will still choose whatever is recommended in the official documentation. And this makes you much better off using it as well. Plus, you’ll not understand why it’s sometimes not suitable if you don’t even try applying it.

The more experience you get, the wiser decisions you make. And remember: programmers can't agree on many topics so there is usually no “right approach”. “It depends” is usually the best answer in tech. In some cases, you will have to choose something that you feel is better, because you just don’t have any other criteria. This is cool too because you’ll get insights and form your own opinion about that.

At a certain point, this gave me a lot of freedom because I understood I could essentially do anything I wanted. I’m not restricted to what some other guy on the web thinks is right. I can make my own decisions. As long as I’m responsible for them, of course.

Tech is so opinionated!

Due to human nature, we tend to become addicted to our favorite toolset and propagate it not admiring the benefits of others. In my experience, this approach is neither good in programming nor in life. So it’s sad to hear something like “Why Java programmers hate python?”

Throughout my journey, I learned to ditch my personal preferences in a professional job setting and get out of my comfort zone. That’s because when you become addicted to your favourite tool set you stop developing and miss out on the opportunity to look at some things from another perspective. Programmers are lifelong learners and real programmers do not hate any technology. They understand that if something is the most optimal choice in their situation, they need to learn it and use it no matter whether they enjoy using it or not.

It’s easier to say that to do and not fall into that trap, so I’m gonna provide an example.

In mobile development, there is a term “native user experience” that typically requires a user interface that is native to a specific platform, super fast data loading, etc. In terms of user experience, websites usually can’t compete with that. However, in mobile development, we can instead use web views that essentially look the same as the mobile version of the website. But everything will get loaded a lot slower.

So should I as a mobile developer propagate using native components? I should, but only if the business requires it. Because most of the time the goal of the business is to quickly get the product into the hands of the customers and only then think about the user experience. And in terms of speed of development, webviews are many times faster.

I learned that from Donn Felker. A person who was a native Android developer in the past now propagates the Native where you need it approach, which involves first building everything with webviews and then gradually replacing them with native components in the parts of the app that require that.

So even though the web is not my area of specialty and it’s not what I like doing, shouldn’t I instead of arguing that native is better appreciate how convenient things are in web, how many developers know HTML, CSS, and JavaScript, and acknowledge the versatility they offer?

If a customer approaches you requesting a project within your area of expertise, and you recommend another technology that would better suit their needs, rather than simply agreeing for the sake of earning money, I believe you demonstrate a higher level of professionalism.

And as much as it’s not okay to hate some technology it’s also bad to become addicted to one. Better appreciate the whole variety of them and be eager to learn.

Don’t get stuck in the rabbit hole of learning everything

Tutorial hell is a common thing in tech. It happens because of people’s natural desire to stay in their comfort zone. Unfortunately, in our world, it’s hard to achieve something when you stay in your comfort zone. So in terms of learning programming, I think the #1 reason why tutorial hell happens is because one doesn’t want to make personal projects. This is absolutely convenient to stick to following some tutorials given that they indeed teach you stuff. But, as proven by science, we start to remember and understand something only when we question it or when we try to apply that in practice.

For example, when it comes to learning a foreign language, I noticed that learners who don't rely on their tutor too much, have intrinsic motivation, and are willing to investigate something on their own become much more successful and do that in a shorter time than those who just go to some courses.

There are areas in life where tutors are almost indispensable like in sports, dancing, acting, etc. And there are areas where the situation is completely the opposite, such as learning foreign languages and programming. Although mentors can save you lots of time by directing you in the right direction, creating a structured roadmap for you, and telling you what you don’t know, you can totally manage without the mentor.

That's why I always propagate the practical approach to programming. Here is how it works. You certainly can’t manage without the foundation, so at the beginning, I recommend still following some tutorials or courses that can teach the main idea of how everything works. And I mean not when you are the absolute beginner, it may be that you have some development background in another area or another tech stack. But as soon as you get enough knowledge that allows you to build something simple, which can even be a command line app, think about what program you’d like to build and jump right into the development. Regardless of your unawareness about things like how to set up a database structure, how to make everything scalable, and how to apply the best practices. You’ll learn that on the go. And this will be the practical knowledge from the outset, no going deep into any rabbit holes.

This approach also allows you to stress less about what you don’t know because you acquire the mindset that if it’s necessary, you’ll learn that fast. If I’m developing an app and I discover that I need to implement some functionality that requires some custom layouts, I won’t search for a course that will teach me everything about custom layouts. I will instead search for some quick tutorials or code snippets on the web and try to replicate them for my needs. And only if I discover that it’s not enough, I will investigate deeper. If I did otherwise, I’d probably spend a large amount of time learning something that I’d eventually forget because I wouldn’t use it that much.

Even though I followed that paradigm throughout most of my learning journey I still fell into that trap at one point. I wanted to create an app but couldn’t start developing it because I thought I didn’t know enough. The matter is that you’ll never do.

Don’t be naive

Everyone tends to run after new and shiny but I’ve come to realize that it’s usually not a good idea to be the first adopter of cutting-edge tech. The reasons are simple. Such technologies are immature, not thoroughly tested, and not well-documented. You can’t count on community support because too few people use it. And the devil is in the details so it may be a lot harder to implement some functionality than you think.

But a more interesting thing is why everyone is obsessed with new and shiny. I think that’s because there is always hype around new technologies. It’s advantageous for content creators to follow the trends and post about something new. Few resources make a comprehensive overview of these things. They only highlight the benefits of the technology and usually leave out its drawbacks entirely. And if they do, they often either don't consider all of them or these drawbacks are far-fetched for the overview to look more competent. This is understandable though because you need to use something yourself in a real job setting to make informed decisions about it. So what we get is just hyping, which only results in the technology becoming more trendy.

But have you ever wondered who creates this hype around new shiny? I noticed it’s often the creators themselves! You see, given the open-source nature of the tools we are using, I used to think that the main motivation for developing new tech is to make it better, simpler, and more effective. However, I have to remind you that, unfortunately, we are not living in the ideal world and few people are ready to invest lots of their time and resources for the genuine desire to make something better.

It’s usually business needs that drive the development of new tech. And usually, the main motivation for creating something new is to make money.

Yes, every technology is there for a reason and each solves some specific problem. And yet the main motivation stays the same.

For example, I used to not even question the appearance of Kotlin. It's such a pleasant language to work with. So I thought that as part of the continuous improvement of technology, people who learned from other languages saw the power of Java and decided to create a better version of it. Bullshit!

What really happened was Google had billion-dollar-worth lawsuits with Oracle about Google’s use of Java APIs. So it became no longer reasonable for Google to heavily rely on Java. They needed to find a replacement for it and think about the backup for Android devs in case they lost these lawsuits. So they started creating Kotlin as a replacement for Java and developing Flutter, which is now a cross-platform mobile framework.

So rather than blindly chasing the latest trends, evaluate whether adopting new tech aligns with your own goals and needs. I know these things feel nowel and exciting but we must be pragmatic. List all the pros and cons to adequately decide whether it's worth using that technology or not. Then bring these arguments to the team to decide on the implementation together.

Al will replace developers 🤩

There was an event in my country called Junior Online Conference. Speakers from different tech backgrounds were invited: backend, frontend, DevOps, test automation, etc. But there was one speaker named Lukasz Fliegel whose talk resonated with me the most.

He brought up the concept of Antifragility and how it can help one become a better software developer. The idea is that while fragile things break easily and durable things remain unaffected by damage when something is antifragile, it actually gets better when subjected to chaos or disruption.

Luckily, humans are antifragile. For instance, when you engage in physical exercise, whether it's weightlifting, running, or any form of physical activity, your body experiences stress. This stress breaks down muscle fibers, causing temporary discomfort or soreness. However, as you recover, your muscles rebuild themselves to become stronger than they were before. Apart from fitness, this works in many other areas of our lives, including programming.

Now, whenever I hear such things as AI will replace developers, it’s impossible to find a job in the current tech market, Java is gone, native Android development will be replaced by web and cross-platform technologies, and so on, I perceive this as an opportunity for me to learn and grow. I don’t deny that AI can indeed replace many developers in the future and that the job market is indeed hard right now. But I’m sure that my antifragility will not let me down. Because I’m willing to improve, learn new things, and get out of my comfort zone. And even in the worst-case scenario, I’ll find a way to solve my problems somehow.

Sadly, instead, many developers adopt the “whiner” mindset where they complain about literally every problem that exists in tech. But I don’t get it! I think his mindset is exactly what keeps people from achieving their goals.

Later on in the talk, Lukasz was asked what he thought about the future of developer jobs given the rapid development of AI. And he just said something like:

I don’t know. I don’t like to predict the future. Actually, I don’t think one should be even worried about this because we anyway can’t change anything with our concerns. Right now there’s need for software developers. If that changes in the future, being antifragile will already put you in the better position than your competitors. And if I am affected by a drastic decrease in job positions, I’ll probably do something else. Attending dance lessons, maybe.

I can add that in the case of such a worst-case scenario, dance lessons are not the only option out there. Food delivery, taxi driving, and barista positions offer plenty of opportunities as well. Just kidding. 😁

Of course, following stoic principles alone will not help much. But I hope you get the point here. It can be tough at times. Don’t give up and be patient. I believe if you love what you’re doing, success becomes inevitable over time.

Connect with people

I noticed that many developers consider themselves introverts. And I can hear that from those who attend events, network online, post blogs, do open source, etc. So if these people are introverts, it’s logical to presume that there are even more introverted people who we are unaware about because they do not open themselves up to the world in any way.

When we are starting, we overestimate our abilities due to the unawareness of how difficult some things are and how much time they take to develop. Developing some big things like a social media app with backend, frontend, and mobile is as complex as building a house using your own hands. And even if you manage to build the whole structure, you then need to maintain it, make sure it works properly, make everything scalable, market the app, process the feedback received from the users, and so on. Also don’t forget about such things as design and legal stuff. So it’s just impossible to make everything yourself.

Therefore, it’s crucial to develop soft skills and learn how to work in a team. Effective networking and collaboration also make one’s growth multiple times faster. And it’s actually a lot easier than it seems. There are many ways you can socialize.

Apart from passing tutorials and codelabs I also started listening to technical podcasts, attending online events, and communities and it was so much fun! I got lots of valuable advice, which I’m now sharing with you in this very article, BTW. I found out that I was not the only one who had certain problems. Oftentimes, we don’t know what we don’t know. So this a great way to find out about such things. This way you can also stay updated with the latest trends.

Entering a university turned out to be a great way of socializing too. You can find like-minded people and potentially team up with them to work on a project. I think it works with boot camps too, doesn’t it?

Posting on Twitter/X was a game changer for some people. You’re networking, sharing your knowledge, getting insights from others, becoming noticed in tech, and showing yourself as a great candidate. With the recent changes though, LinkedIn became a much better social network by a quality of content alone. Nowadays, you'll find it far easier to gain popularity and visibility on LinkedIn compared to Twitter/X.

I also started posting on DEV just because I had something to share, and wanted to share that. And now people say “You have your own blog? Cool!” Putting yourself out there is a great way to get noticed, especially in the current time when one needs to do things above average.

Putting myself out there is one of the first goals on my priority list right now. So, if you enjoyed this article, I bet you’ll enjoy the one coming up next week. And let's connect on LinkedIn.

Thank you for reading. All the best!