Programming Applications

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.

Learn basics, always. For the web, for example, before you start working with NextJs, Vue, or React make sure you understand basic HTML, CSS, and JavaScript. When you are past this point, learn TypeScript. If you use some front-end framework, always prefer typescript over JavaScript. It will reduce development time and bugs drastically and keep your head will be freer to remember the number of milk packs to bring back home.

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.

To make products, new frameworks are not needed but to function well in a job you need to learn new tools. T-shaped developers are always in demand. Have expertise in one framework and be a generalist who can fit in and code in anything. Take time at the start of your career(or during college) to understand the basics of how JavaScript works, browsers interpret it, render it, DOM, HTML, CSS, and learning new things will become exponentially easier. Without strong basics, you will end up fidgeting with every new tool. This goes across the domain, web, mobile, servers, and AI and sales and marketing or anything really.

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.

This post is from a series of related posts about software engineering. It is part of an attempt to write a book in public. I seek your feedback. Raise your opinion. Share with people who can benefit from it. Contribute in the comments section, on social media, over a cup of coffee, or however you prefer. This will help me and the community tremendously.