Programming web is easier to get started with. I do believe everyone should be able to do so. I see a recent trend and find many software engineers with a couple of years' experience who can’t put a website on the internet. Do not be that person. You might be a data scientist, or machine learning engineer, or have specialized in AI but please do yourself a favor and be capable of throwing together a simple website. Invest in things that don't change.
When doing learning projects, ship. Deploy your code somewhere, always. Use Dynos, Netlify, Vercel, Google Drive, S3, Github pages, etc. It’s free(or almost free) these days. As Sahil Lavingia of Gumroad puts it, “start, then learn”. Don’t learn then start. When learning something, begin with a simple product in mind, even if it is as simple as a calculator. Better if you look for problems you face and solve them. Someday that side project might make money for you. Make them open source on GitHub and it will add to your profile. Many good companies look for open-source samples of code or open-source contributions.
Personally, I find courses to be near useless. A lot of people who buy courses are the ones who procrastinate a lot. Learning for the sake of learning is a form of procrastination. These days documentation and getting-started guides are good enough. Unless you are an entry-level engineer, when learning a new framework, go straight into the documentation. I have seen courses are most often outdated, slow, and biased. If you learn through documentation, you will improve your ability to learn new frameworks. Eventually, you will be capable of learning a new one in a matter of a few hours. You will get quicker in digging information from documentation and API references.
Similarly, for programming servers, have a deep understanding of basics. How servers function. What is needed to make a web server online. Learn to serve HTML from a web server. Learn ngnix. Learn Linux commands. Only after you have mastered the basics move on to REST APIs, GraphQL, containerization, and microservices. In server understand how the programming language of your choice works. How it handles requests, memory, concurrency, disk IOPs, and CPU utilization. It will help you write solid code. Writing code on a server needs good awareness of security. More on security in a later post.
Mobile is a bit different than the web. Many cross-platform frameworks are trying to bridge that gap between multiple mobile platforms and the web. I believe as Steve Jobs said, that eventually mobile platforms will be replaced by the web. Web will get as close to mobile applications as possible. Apparently, app stores don’t want that to happen because of the money they mint. Until then we have to live with multiple mobile platforms. A big word of caution here is that no cross-platform framework will get you the experience of a truly native application. Unless you are a very small startup and can’t afford to hire 2 instead of one person to develop on mobile, never go for cross-platform. I can am saying this after having developed multiple cross-platform applications in React Native, Flutter, and Electron. I have worked a lot with Unity on mobile so I have those insights as well.
Cross-platform will not increase the time to market. It will slow you down unless there is only one person coding. When using frameworks, you will always run into issues where the fix has not been done in the framework and you end up wasting time. You have to either wait for the fix or write some native plugin/bridge to make that happen. If a new feature is launched, you will get it the last. Apple favors apps that use the latest features in App Store rankings and features. Being on cross-platform, you will rarely be able to do that. No matter how lucrative it sounds to have one code base to ship it all, do not go for it. This gets very important if your app is more than CRUD and it uses some OS-related/OS-specific features like camera, voice, sensors, etc. If you are making a back office, low priority, low usage, admin panel, you can get away with cross-platform. In that case, you shouldn’t even make an App. Make a responsive website. Make PWA for fun. Having 4 developers on React Native app won’t ship faster than having 2 on Android native and 2 on iOS native. It is just a myth. The benefits, buttery smoothness and the first-class experience of native are just icing on the cake.
If the product you are building is not a product-market fit yet, then build mobile web only. If it needs to be an app, you may opt for a cross-platform framework. Another option is to build for one platform first in native code.
Generally speaking, be very wary of trying new tech and frameworks just for the sake of it. See this meme for example.
“1995: PHP is dead, learn ColdFusion
2002: PHP is dead, learn ASP.net
2003: PHP is dead, learn Django
2004: PHP is dead, learn Ruby on Rails
2010: PHP is dead, learn Flask
2011: PHP is dead, learn AngularJS
2016: PHP is dead, learn Next.js
2022: okay this is awkward”
Tech changes every 5 years but it is not necessary to follow the latest tech. Developers have curiosity and an itch to try new things and in doing so they create new frameworks. It doesn’t mean they have to be used by everyone. When Facebook launches React or Google launches Angular or Flutter they are just competing for their dominance in the developer market. Engineers have over-complicated things and in doing so increased the size of the market. Which is good for the “developer economy” but not so much from a business standpoint. Developer economy, as I put it, thrives on the fact that developers make new tools for developers which would need more developers to do the same job and also need existing developers to learn more tools and keep up.
Selecting tech is all about trade-offs. If you think your solution to a problem is perfect, be very afraid of this conclusion. It only means you don’t know the full spectrum. Either you don’t understand the problem enough or you are missing out on some alternate technical solutions. Be the person who understands the counter-narrative to the narrative better than the proponents of the counter-narrative. Exhaustively work with pros and cons and select the technology.
Do not go after the fanciest tech. Go after the right tech for the right problem when you are in greenfield. Greenfield is when you have to make tech decisions on a blank canvas, i.e. starting something afresh. Follow tech that scores high on the scale of Lindy’s law. After all the effort in studying the pros and cons and viability of a solution, if you are still stuck on deciding between two techs, flip a coin. Decisiveness goes a long way. Ditto for life choices.
Understand that a good developer can make the difference between various techs seem negligible while a bad or inexperienced developer can turn the pros of a framework into cons. Understand your strengths, your team, and the problem at hand, and then pick tech.
This piece of advice would work well if you are in an agile and modern company. For engineers in corporates, it’s sometimes the difference between getting a promotion if they are not proposing the fanciest of the tech in the most convoluted jargon. Someone at a job is not optimizing for the business’s best interest. In bigger companies, employees are going to have the least skin in the game.
I have seen services companies work on the mantra of, “if you can’t convince them, confuse them” and proposes microservices to every client and win more work for themselves. Interestingly, everyone is happy because microservices are trendy and clients can’t help but appreciate that.
Understand your position in the company, understand who you report to, how much skin you have in the game, understand what metrics your performance is evaluated against, and act accordingly. Nonetheless, default to goodwill. Goodwill prevails.