Why backend engineers should make CLI’s

why-backend-engineers-should-make-cli’s

In this article, I am going to focus on why I think people are missing out by not making CLIs. Almost everyone I know starts with web development because it is one of the things that gives results fast, which makes us go “me best, me genius,” and that’s exactly why I am still learning about web development. But there comes a point where you just want to be a developer rather than a web developer.

It takes too much time

I wanted to be able to zip my files without using 7zip because I didn’t want to learn about their CLI, which is complicated for no reason, and because of this, I always had to open the GUI. 

Now if I made a website, that would just be too excessive because I am making a server with Go, having my UI with HTMX, containerizing my application in a docker, using nginx, and let’s encrypt to have https, and finally using docker-compose to have them in one container to run on my Linux server on the digital ocean.

Or I can think about the functionality that I wanted, the kind of input I wanted to support, learning about how to read a file, and later how to walk a whole directory with Go recursively, and figure out that there is a small thing about using backslashes with the zip.Writer() function. 

In the latter case, I was focused on the thing I wanted to learn rather than all the other junk that stopped me from actually getting into the thing that I wanted to learn. 

Making an entire website with all the bells and whistles for a little feature that you want to develop and figure out is too much. Just make a CLI. 

Reusable code

Another benefit of making a CLI is that you can reuse your code, i.e., if you decide to make a CLI that takes a video and converts it into different formats, something that YouTube does to deal with the varying internet bandwidth of its users. 

After making the CLI, that part of the puzzle is now demystified, which means you can use it in a project that has videos; it almost acts as a microservice. 

The Bliss of Finishing

Everyone has a lot of unfinished projects, which is completely fine, but sometimes your resume needs to have some complete projects that have the appropriate readme, which people can either install or see because that gives you credibility.

Remember, sometimes you have to finish the thing that you start. CLIs, in my perspective, make the probability of finishing higher because the problem you are going to tackle is by nature going to be small in scale. This also has the byproduct of giving you confidence, which is rather helpful, especially when you are starting. 

It is cool

My favorite thing about making a CLI is that any time you use the thing that you made and it just works, it makes everything you work for seem worth it.

My advice is that when you feel overwhelmed by the things that you feel like you have to do or just feel like programming is losing its spark, just make something. It doesn’t have to be grand; it only needs to be something that you want. It is by far the quickest way to feel the fire again, and CLIs are just a nice little middle-ground thing that you will use and will need. 

Final Thoughts

If you haven’t made a CLI yet, I would like to say just try it, or maybe start by customizing your command line to look the way you want to. You spend a lot of time there, so having ownership over the things you use is important. Having fun is also important. 

Note: I got this idea from the freecodecamp.org video about Getting a job It is a great video, and you should check it out if you are trying to get a job. 

If anyone wants to have a conversation about tech in general or talk about some of the cool CLI they’ve made for themselves, I’d love to talk about it. My information is on my profile.

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post
boeing-identifies-process-control-issue;-key-execs-to-step-down

Boeing Identifies Process Control Issue; Key Execs to Step Down

Next Post
my-binary-vector-search-is-better-than-your-fp32-vectors

My binary vector search is better than your FP32 vectors

Related Posts
arkui-x平台差异化

ArkUI-X平台差异化

跨平台使用场景是一套ArkTS代码运行在多个终端设备上,如Android、iOS、OpenHarmony(含基于OpenHarmony发行的商业版,如HarmonyOS Next)。当不同平台业务逻辑不同,或使用了不支持跨平台的API,就需要根据平台不同进行一定代码差异化适配。当前仅支持在代码运行态进行差异化,接下来详细介绍场景及如何差异化适配。 使用场景 平台差异化适用于以下两种典型场景: 1.自身业务逻辑不同平台本来就有差异; 2.在OpenHarmony上调用了不支持跨平台的API,这就需要在OpenHarmony上仍然调用对应API,其他平台通过Bridge桥接机制进行差异化处理; 判断平台类型 可以通过let osName: string = deviceInfo.osFullName;获取对应OS名字,该接口已支持跨平台,不同平台上其返回值如下: OpenHarmony上,osName等于OpenHarmony-XXX Android上,osName等于Android XXX iOS上,osName等于iOS XXX 示例如下:…
Read More