DEV Community: Shravan Kumar B

Sharing my thoughts on experience/learning from Freelancing journey

Shravan Kumar B — Sat, 03 Jan 2026 20:24:26 +0000

Shravan Kumar B

Dec 19 '25

On Freelancing: My lessons and learnings

#programming #productivity #career #learning

Comments

9 min read

On Freelancing: My lessons and learnings

Shravan Kumar B — Fri, 19 Dec 2025 10:52:42 +0000

On Freelancing: My lessons and learnings

Hi everyone!

This article is a reflection on my journey as a freelancer, the lessons learned, the challenges faced, and the reality behind the promise of freedom. If you are considering freelancing or already on this path, I hope that these insights help you navigate it better.

This article was originally posted on my personal space; before cross-posting it here.

The independent path: freedom comes with responsibility

Why Freelancing?

I was drawn to freelancing for the same reasons, that most people are drawn to freelancing:

Freedom from the daily commute
Freedom to choose your projects
Freedom to set your own hours
Freedom from office politics

But here's what they don't tell you upfront:

Freelancing isn't freedom from work. It's freedom in work.

The work is still work. The deadlines are still deadlines. The clients are still demanding. The difference is; they're yours—you choose which projects to take, which deadlines to accept, and which clients to work with.

A freelancer building their own path

The First Project

I remember my first freelance project clearly. I was excited, nervous, and honestly, I was undercharging.

I took a product that was to migrate legacy product to modern Next.js Application. Current system whose UI and Backend was built on Django with Server Side Rendered. The client was a Venture Capitalist company. The application was a No Code tool for the companies they have funded or undertaken, to manage their portfolio and all other operations. The whole system was legacy, where all UI design and components were done using jQuery, Javascript embedded on Django templates.

The client seemed nice, the requirements seemed clear initially, and I thought I had everything figured out.

I was wrong.

I quickly discovered significant technical caveats and communication challenges. There was no knowledge transfer, no API documentation, lets no documentation at all. It was like being handed a black box and expected to explore it and deliver results quickly.

To make matters worse, the team who built this product came from a business background with little to no engineering background as such. The entire codebase reflected this; it was a disaster.

None of these challenges were communicated during the initial discovery call. This was partly my fault; I was too excited to take on the work and get started, so I didn't ask the right questions upfront. Transitioning the existing jQuery-based UI components to React and decoupling the backend from the frontend proved extremely difficult, as the legacy system didn't follow standard engineering practices.

Reality of freelance challenges: what they don't tell you upfront

I managed to migrate two modules and deliver them before parting ways with the client. I decided not to continue with the remaining 10-11 modules. The product was built over years from 2008-09 and had been maintained (or rather, patched) using the same approach ever since. The technical debt was overwhelming, and decoupling such a legacy system was more pain than I was willing to take on especially since the client couldn't understand the technical complexity involved in decoupling legacy system and time taken to it, given such large product. Perhaps I'll write more about this experience in a separate article.

What I Learned

Negotiation is a skill: Don't be afraid to discuss rates. Your time and expertise have value.
Clear communication saves time: What seems obvious to you might not be obvious to the client. Always clarify requirements.
Contracts matter: Even for small projects. Define scope, timeline, payment terms, and what happens if things change.
Saying no is powerful: Not every project is worth taking. Some clients aren't worth the stress.

Example: Setting clear boundaries

Included:

Frontend development (React/Next.js)
API integration with existing backend
Responsive design implementation
Development testing and bug fixes

Excluded:

DevOps and deployment setup (outside project scope)
Post-launch maintenance and support (available as separate service)
Backend development or API creation
Content creation or copywriting

Terms:

Revisions: 2 rounds of feedback included
Timeline: 4 weeks from project start
Payment: 50% upfront, 50% on delivery
Additional features: Quoted separately and require scope change approval

The Feast and Famine Cycle

One of the hardest lessons in freelancing is dealing with the feast and famine cycle.

The Feast: You are drowning in work. Multiple clients, tight deadlines, late nights. You are making good money, but you are exhausted.

The Famine: Radio silence. No new projects. No responses to proposals. You start questioning everything.

The reality of freelance income: prepare for both extremes

How to Handle It

Save during the feast: When work is abundant, save aggressively. Aim for at least 6 months of expenses.
Use downtime productively: During slow periods, work on your portfolio, learn new skills, write blog posts, contribute to open source.
Build a pipeline: Always have potential projects in the pipeline. Network, maintain relationships, stay visible.
Diversify income streams: Don't rely on a single client or project type. Consider passive income, products, or retainer agreements.

The Loneliness

Working alone sounds romantic until you are actually alone. No water cooler conversations. No team lunches. No one to bounce ideas off at 2 AM when you are stuck.

Building Community

Join communities: Online forums, Discord servers, local meetups. Find your tribe.
Find accountability partners: Someone to check in with, share goals, and keep each other motivated.
Co-working spaces: Even if it's just a few days a week, being around other people helps.
Mentorship: Find mentors. Be a mentor. Both help combat isolation.

I've found that the best freelancers aren't lone wolves; they're part of a pack.

Setting Boundaries

When work is everywhere, work is everywhere.

Your laptop is always open. Your phone is always buzzing. Your mind is always working.

Protecting Your Time

Define work hours: Even if you are flexible, have core hours when you are available.
Create a dedicated workspace: Separate work from life, even if it's just a corner of your room.
Learn to say no: Not just to bad projects, but to requests outside your scope or availability.
Take breaks: Seriously. Burnout is real, and it is crazy harder to recover when you are on your own, trust me when I say this. This is coming from a very very personal experience.

Lets say if you are setting availability

Working hours: 9 AM - 6 PM
Response time: Within 24 hours
Emergency contact: Only for critical issues
Weekends: Unavailable unless discussed

Understanding Your Value

When you start freelancing, you'll likely say yes to everything.

Then you learn to say no. You learn that your value isn't in your availability, its in your expertise.

Pricing Your Work

Don't compete on price: Compete on value. Cheap clients are often the most demanding.
Know your numbers: Calculate your actual costs; this includes taxes, health insurance, equipments, software, time off.
Value based pricing: Sometimes hourly doesn't make sense. Charge based on the value you deliver.
Raise your rates: Regularly. As you gain experience, your rates should reflect that.

Your rate is not just about money. It is about the respect you
have for your own time and expertise.

The Reality Check

Freelancing is nott easier than a traditional job. It is different. You are still working. You still have deadlines. You still have responsibilities.

The difference is: they are yours.

You choose the projects. You choose the clients. You choose your path.

But with that choice comes responsibility.

What You are Really Signing Up For

You are the CEO: Strategy, planning, business development
You are the sales team: Finding clients, proposals, negotiations
You are the accountant: Invoicing, taxes, bookkeeping
You are the developer: Actually doing the work
You are the support team: Client communication, maintenance

It is a lot, but it is also empowering.

The Trade offs

Every choice is a trade off.

The trade-offs of freelancing: freedom comes with choices

Stability vs. Flexibility: Traditional jobs offer stability. Freelancing offers flexibility. You rarely get both. At least, in the current stage that I am in, that is what I have experienced.
Security vs. Freedom: Regular paychecks feel secure. But is it security or the illusion of security?
Comfort vs. Growth: Staying in your comfort zone is easy. But growth happens outside it. There are plenty of opportunities where you will have to work outside your comfort zone, and that is something you cannot avoid. That is where the real fun lies, you get to learn constantly, gain new perspectives, and understand how things work beyond just engineering and code.

There is no right answer. Only the answer that fits you.

Some days you'll question your choice. Some days you'll celebrate it.

Both are valid.

Setting your space & workflow

The most successful freelancers I know are not the most talented, rather they're the most organized. They are constant learners who adapt quickly to changing needs and continuously level up their skills.

Workflows that worked for me

Here are some things that have become essential to my workflow, making daily planning and execution much smoother.

Project Management: Track your projects, deadlines, and tasks. Use tools like AppFlowy, Trello, Notion, or a simple spreadsheet.
Time Tracking: Know where your time goes. It helps with pricing and identifying time sinks.
Invoicing: Automate it. Use tools that handle recurring invoices, reminders, and payment tracking.
Documentation: Document your processes, common solutions, and client preferences. It saves time.
Contracts: Have templates ready. Customize as needed, but start with solid foundations.

Note:
I use self-hosted open-source tools that have significantly improved my
workflow. I plan to write about these tools in a separate article.

Learning to Communicate

Communication is everything in freelancing. You are not just building products, you are managing expectations, setting boundaries, and building relationships.

Communication Best Practices

Over communicate: Especially early in a project. Better to share too much than too little.
Set expectations: Be clear about timelines, deliverables, and what is included (and explicitly what is not).
Document everything: Meeting notes, decisions, changes. Written records protect everyone.
Be proactive: Don't wait for problems. Check in regularly, share progress, flag issues early.
Know your audience: Technical details for developers, business value for stakeholders.

Freelancing: Usain Bolt or Mo Farah?

Freelancing isn't a sprint. It is a marathon.

You will have good months and bad months. Good clients and bad clients. Good projects and projects you would rather forget.

Marathon, not a sprint; Usain Bolt runs fast but Mo Farah runs far

But if you stick with it, you build something valuable:

A reputation: Your work speaks for itself
A network: Relationships that open doors to new opportunities
A portfolio: Proof of what you can do
Independence: The ability to choose your path

Is Freelancing Right for You?

Not everyone should freelance. Not everyone shouldn't.

The question is not: "Should I freelance?"

Rather, the question is: "What do I want?"

And are you willing to pay the price for what you want?

Signs It Might Be Right

You are self motivated and disciplined
You are comfortable with uncertainty
You enjoy variety in your work
You are good at managing your time
You can handle the business side (sales, admin, customer relationship etc.)

Signs It Might Not Be

You need structure and routine
Financial security is your top priority
You prefer working in teams
You do not want to handle business tasks
You struggle with self discipline

There is no shame in either path. The goal is to find what works for you.

Conclusion

Freelancing is not freedom from work; rather it is freedom in work.

Your projects. Your clients. Your time. Your life.

And that's the point.

Not escaping work, but shaping it to fit your life.

It's not easy. It's not for everyone. But if it's for you, it's worth it.

I know this has been a longer post than expected. If you got this far, I appreciate
your patience and thank you for your time.

If you are considering freelancing or already on this path, I hope these insights help. And if you have your own experiences to share, I would love to hear them.

If you like the article, hit the like button, share the article and subscribe the blog. If you want me to write an article on a specific domain or technology, feel free to drop a mail at shravan@ohmyscript.com

Stay tuned for more.

That's all for now. Thank you for reading.

Signing off until next time.
Happy Learning.

Expedition of Async Programming in JavaScript

Shravan Kumar B — Sat, 02 Aug 2025 10:48:40 +0000

My Background with Programming

This is a story of my expedition of understanding Asynchronous Programming in JS. Coming from a Computer Science background, I got various opportunities to explore multiple platforms, where I could learn different programming languages, from Assembly languages to High-level languages. However, I have never struggled to understand the construct or flow of the language.

Understanding Synchronous JS

As far as I know, JS is one of those technologies that stands out from the rest that is in the industry. Far more, I am not speaking about performance, optimization, and things so on.

JS in Node is an asynchronous programming language.
This might be pretty confusing. While JavaScript runs on a single thread, Node.js introduced a powerful way to handle non-blocking operations. This means, even though only one operation can run on the main thread, time-consuming tasks like reading files or hitting APIs don’t halt the execution of other code.

To put it in simple words:

JavaScript is a single threaded language, which means it has a one call stack and memory heap, that simply executes the code in the order it is written. It must finish executing a piece of code before it moves to the next.

This is the synchronous behavior of JS.

Whoa! You might wonder, then, why the title Async Programming, and what on Earth does Async Programming have to do with JavaScript?

For this, we should thank Ryan Dahl, the mastermind and also criminal behind one of the most dominant, powerful runtime environments, Node.js.
Node.js was an environment that enabled Asynchronism in JavaScript.

Asynchronism with JS

Asynchronism in JavaScript, or now on, let’s say Node.js, runs in a single process, without creating another thread.
This simply means that, unlike other languages like Java, Python, which block their thread for I/O ( What this means is, when we have to do an API call, accessing the database, or reading text files, so on), will pause the runtime until this process is completed.

In Node.js, it is contrary to the above situation. Node.js uses something referred to as Callbacks. The Node.js Event Loop orchestrates async tasks without blocking the main thread.

Simple real life scenario, let us say,
You are cooking and have to wash clothes as well. You put the clothes into the washing machine for a wash, and resume back to cooking. Once the washing is done, you can get back to it.
Washing clothes did not stop you from cooking? Did it?
The same principle applies here as well.

I suppose this gives you a basic ideology behind What and How of Async Programming, and now let us dive into something deeper, What and How of Async Programming in Node.js.

Async Programming in Node.js

In Node.js, functions that perform asynchronous operations, on completing the execution of the asynchronous task, they return control and push onto a stack known to us as a callback.

Callback

This is how I initially understood that the way Node.js works using a callback.

For instance:

function getUserById(userId, function(err, result) {
  if(err) { throw err; }
  console.log(result);
});

console.log('Hello World');

OUTPUT:
Hello World
{ id:1, name: Lee }

The above function runs, and once it's complete, the result is made available within the callback function.

In Node.js, for it to know that a function has some asynchronous operation, i.e., returns some data or throws some error, it points to a function that will be executed once the asynchronous operation is done.

This function, which deals with the returned value/throws an error, is called a Callback function.

Meanwhile, Node.js ensures it continues with the normal execution of the code, just as in the above example, where console.log() did not wait for the complete execution of the getUserById().

Callback hell, the vexation

As time passed, I found it quite frustrating to deal with these Callback functions.

The first problem is variable scope, and the second is dealing with too many callbacks to access the results of the callback function, as we cannot return the resultant value from the callback.

function getUserById(userId, callback) {
  // Simulate async behavior
  setTimeout(() => {
    const result = { 
     id: 1, 
     name: "Lee", 
     userEmail: "iam@you.com" 
    };
    callback(null, result);
  }, 1000);
}

getUserById(1, function (err, result) {
  if (err) throw err;
  console.log(result); // 3
});

console.log(result);     // 1
console.log("Hello World"); // 2

// 1,2,3 being order execution
OUTPUT:
undefined
Hello World
{ id:1, name: Lee, userEmail:iam@you.com}

The only way to access or do anything with the result was to operate inside the callback.


async function getUserById(userId, callback) {
  // Simulate async DB fetch
  setTimeout(() => {
    const result = { 
      id: 1, 
      name: "Lee", 
      userEmail: "iam@you.com" 
    };
    callback(null, result);
  }, 1000);
}

async function sendEmail(email, callback) {
  // Simulate async email sending
  setTimeout(() => {
    callback(null, "Email sent successfully to " + email);
  }, 1000);
}

// Call the function
getUserById(1, function (err, result) {
  if (err) throw err;

  sendEmail(result.userEmail, function (err, emailResult) {
    if (err) throw err;
    console.log(emailResult); // "Email sent successfully to iam@you.com"
  });
});

This caused me a lot of confusion with naming a variable, accessing the variable. All in the flow of the code and function calls. This is where I realized I was dealing with something called CALLBACK HELL because of its confusing paradigm view.

Heartily thankful to StackOverflow.

Promises

As I struggled with nested callbacks, I stumbled upon a concept that served as a solution to my problem of Callback Hell; something called Promises.

A Promise is an object that encapsulates an asynchronous operation and on completion of the execution. It is a proxy for a value not known when the asynchronous code starts executing.

In simpler terms, it's a placeholder for a value that will be available in the future, once the async task is done.

Sounds very similar to Callback?
It is quite similar to Callback design but was less sophisticated in terms of readability of the code, variable scope, and variable hoisting.

Instead of giving a callback function to deal with the asynchronous function, the Promises API provides its own methods called “.then” and “.catch”, which basically execute based on functional chaining, as given below.
The same example, in terms of promises;


async function getUserById(userId) {
  return new Promise((resolve) => {
    setTimeout(() => {
      const result = { 
        id: 1, 
        name: "someone", 
        userEmail: "someone@everyone@email.com" 
      };
      resolve(result);
    }, 1000);
  });
}

async function sendEmail(email) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve(`Email sent successfully to ${email}`);
    }, 1000);
  });
}

getUserById(1)
  .then(function (result) {
    console.log(result);
    return result;
  })
  .then(function (userData) {
    console.log('Email to be sent');
    // return promise
    return sendEmail(userData.userEmail); 
  })
  .then(function (emailStatus) {
    // waits until sendEmail is resolved
    console.log(emailStatus); 
  })
  .catch(function (err) {
    console.error('Error:', err);
  });


OUTPUT:
Hello World
undefined
{
 id:1, 
 name:someone,
 userEmail:someone@everyone@email.com 
} 
Email to be sent
Email sent

This looks basically more organized than the way Callback looked and the way the code structure seemed in the callback functions.

This paradigm, too, had issues. This dealt with firstly what I call Promise Hell when you need to keep passing the resultant to many 'then' functions.

Another major setback was the scope again. Data flow can be passed/ returned from one then() to another then(), but they were not available outside for processing.

This became a very major issue when I had to deal with several complex API's and that's when again I came across the solution, again in the StackOverflow, which was something called Async/Await.

Async/Await

This was a step forward for me, to write several logics simplified and sorted.

When a JavaScript date has gone bad, "Don't call me, I'll callback you. I promise!"

It turned out to be the ultimate solution for several problems I had been facing during the development.

Async/Await is one best way to make asynchronous Node.js operate more imperatively.

This was one such pattern, where asynchronous operations were handled much more simplified way.
It brings in two keywords into the picture;
"async" and "await", where async is for declaring a function that will be dealing with some asynchronous operations and await is used to declare inside the "async" function that it shall "await" for the result of the asynchronous operation.

Simple Example with the above code:


async function someFunction(userId) {
  try {
    let user = await getUserById(userId);
    console.log(user);
    console.log('Email to be sent');
    await sendEmail(user.userEmail);
    console.log('Email sent');
    console.log('Hello World');
  } catch (error) {
    throw error;
  }
}

OUTPUT:
{ 
 id:1, 
 name:someone, 
 userEmail:someone@everyone@email.com 
}
Email to be sent
Email sent
Hello World

In the above instance, isn't the code more readable? The code is neatly structured and also makes sense with the flow and how it executes. Async/Await makes the code look more like a synchronous code format.

One major thing to be considered in async/await way of handling asynchronous operation is that a function call can await only its "awaitable".

Awaitable, meaning a function that returns a Promise Object or if its function carrying some asynchronous operation.

This was my journey of learning Asynchronous programming with Node.js.

Conclusion

From my point of view, I believe Callbacks are one of the worst ways to code and deal with asynchronous operations, given that at any point in time. But the Promise method of dealing with asynchronous programming overcomes with Callback Hell issue. But definitely see that the Promises methodology of dealing with async operations has its own perks in different cases. Async/Await might seem the best solution to be as of now. But don't limit yourself to these. Explore and use each of them based on the optimal use cases that you are dealing with.

Thanks for reading. Signing off, until next time.

Happy Learning.

Interesting read!! ⭐

Shravan Kumar B — Mon, 14 Jul 2025 08:12:54 +0000

Raghav

Jul 13 '25

How Jekyll almost killed our vitepress docs

Comments 1

4 min read

VPS Management made easy with Nixopus

Shravan Kumar B — Wed, 09 Jul 2025 05:01:45 +0000

Shravan Kumar B for Nixopus

Jun 23 '25

Nixopus: Simplifying VPS Management

#devops #beginners #selfhosting #cloud

Comments 9

7 min read

Self Hosting Management made easy!!!

Shravan Kumar B — Tue, 08 Jul 2025 09:13:14 +0000

Shravan Kumar B for Nixopus

Jun 23 '25

Nixopus: Simplifying VPS Management

#devops #beginners #selfhosting #cloud

Comments 9

7 min read

Inside Nixopus: How We Manage Our Database Migrations?

Shravan Kumar B — Fri, 27 Jun 2025 13:44:31 +0000

This article mainly focuses on laying out our foundational approach to setting up the database migration system for Nixopus.

Database migrations are often the unsung heroes of software application development. They work silently in the background, ensuring that your database schema evolves safely alongside your application code. Yet for many teams, this is a major source of stress and uncertainty. In this blog, we will explore how we have set up the migration framework for Nixopus. This has become a pivotal step in our developmental and self-host workflow.

To start with, let us first explore and understand what we mean by database migration. As we always do, let us take an analogy.

We often use different database systems like MySQL, PostgreSQL, MongoDB, etc, for data persistence. These data are stored in the form of Tables having columns and rows.

As the application grows, the number of tables grows, and the data defined at each table might vary and change; hence, it is very important to keep track of these changes.

Tables are at the database system level, whereas at the programmatic level, we maintain them with something called schemas. Like a house blueprint that dictates where rooms, doors, and wiring go, a schema simply defines how the data is organized and connected.

Now, let's imagine that you decide to change the blueprint mid-build, to add a new room or window, you need to carefully make changes to the existing blueprint such that you don’t end up collapsing the walls down.

This problem is addressed at the schema level to ensure the changes in the existing tables, which may be in the form of adding new columns, altering the type of existing columns, or adding new tables, are handled through what we call Database Migrations

When we started building Nixopus, we quickly realized that database schema management would be critical to our success in self-hosting and local development setups. We planned with an expectation set that eventually we would see multiple developers working on different features, frequent deployments, and the need to support both development and production environments, which would require a very streamlined process to handle database migration.

We had aligned on the following factors that our migration system would have to adhere to:

Reliability: Migrations must execute consistently across all envs
Automatic: No manual intervention should be required during deployments
Forward & Backward Compatible: Ensure easy rollback scenarios
Separations of Concerns: Organization of migrations by domain or feature

Many existing tools either lacked the flexibility we needed or came with unnecessary complexity, be it in terms of testability or adding rollbacks in case of errors, etc.

Hence, we decided to build our migration system tailored to our needs and requirements using a tool called Bun ORM.

To those who are not aware of the terminology ORM, let me give a glimpse of it; ORM, otherwise called as Object Relational Mapper, is like a waiter at a restaurant, to who you tell what you want, he/she goes to kitchen(I mean database), then brings back your order(data) as perfectly plated objects in ready to use form.

Without ORM, you would have been presented with raw vegetables and ingredients straight from the kitchen (of course, by that I mean the database), and you would have to do all the cooking yourself, which means writing and managing every query and data transformation.

Coming back, we have built our migration system around a simple yet powerful concept, where a pair of SQL files represents every database change:

1) Applying the change (up migrations)
2) Rolling it back (down migrations)

This approach has helped our system to easily take care of schema evolution and database versioning.

The migration system follows a defined life cycle:

1) Discovery: The system scans the api/migrations directory

2) Parsing: Migration files are parsed and paired (up/down migrations)

3) Ordering: Migrations are sorted by their numeric IDs

4) State Check: The system compares file system migrations with applied migrations in the database

5) Execution: Pending migrations are executed in transactions

6) Recordings: Successfully applied migrations are recorded in the migration table

Now that you know an overview of our setup and how it works, you might wonder what actually sets our approach apart? Fair enough!!!!

1) Domain Driven Structure: Instead of throwing all migrations into a single directory, we have organized them by domain:

api/migrations/
├── applications/   # App deployment features
├── audit/          # Audit logging and compliance
├── auth/           # Authentication & authorization
├── containers/     # Container management
├── domains/        # Domain and DNS management
├── feature-flags/  # Feature toggle system
├── integrations/   # Third-party integrations
├── notifications/  # Notification system
├── organizations/  # Multi-tenancy & organizations
├── rbac/           # Role-based access control
└── users/          # User management and profiles

This structure makes it easy for us to find and create migrations related to specific work or flow, helping us avoid confusion or conflicts.

2) Automatic migration execution on application startup: One of the key design decisions was to make migrations completely automatic. When the application starts, the migration system runs before any other initialization. This approach eliminated the need for separate deployment and ensures that the database schema is always up to date when the application starts.

3) Atomic, Transactional Migrations: Every migration runs inside a database transaction, ensuring atomicity. If any part of a migration fails, the entire migration is rolled back, ensuring that the schema remains fully consistent.

4) Bidirectional Migrations: Every migrations have 2 files:

seqno_entity_up.sql (applies the change)
seqno_entity_down.sql (rolls back the change)

This ensures that we can always roll back changes if something goes wrong.

As we are close to concluding the deep dive into the first of many articles of the Inside Nixopus series, I would like to highlight some of the major learnings and key takeaways:

1) Keep each migration small and focusedfor easier review or rollback.
2) Ensure to keep a down migration for every up migration, ensuring roll backs are easy.

The key insight is that sometimes the best tool is the one you build yourself. By understanding our specific needs and constraints, we were able to set up our migration system that fits perfectly into our development workflow and easy self-hosting.

The project, as we publish this article, is in the Alpha stage.

You can check it out on GitHub and see for yourself.

To sum it up, the approach helped us change schema changes from a headache to a reliable process.

If you would like to get involved or have questions, join our Discord community for real-time support and feedback. You can self-host Nixopus today, subscribe for updates, and stay tuned as we roll out new features and stability enhancements.

We have recently collaborated with HostUp, a reliable VPS provider based in Sweden, to bring you an exclusive deal of 10% off recurring on any VPS plan. Whether you choose to self-host Nixopus or deploy containerized apps, this is the perfect opportunity to secure rock-solid infrastructure at a Discord Community.

Stay tuned for more freshly brewed content.

That's all for now. Thank you for reading.

Signing off until next time.

Thank you.

nixopus / nixopus

Open Source Alternative to vercel, heroku, netlify with simplified workflows

Open Source alternative to vercel, heroku, netlify with Terminal integration, and Self Hosting capabilities

Website • Documentation • Blog • Discord • Roadmap

⚠️ Important Note: Nixopus is currently in alpha/pre-release stage and is not yet ready for production use. While you're welcome to try it out, we recommend waiting for the beta or stable release before using it in production environments. The platform is still undergoing testing and development.

Features

Deploy apps with one click. No config files, no SSH commands.
Manage files in your browser. Drag, drop, edit. Like any file manager.
Built-in terminal. Access your server without leaving the page.
Real-time monitoring. See CPU, RAM, disk usage at a glance.
Auto SSL certificates. Your domains get HTTPS automatically.
GitHub integration. Push code → auto deploy.
Proxy management. Route traffic with Caddy reverse proxy.
Smart alerts. Get notified via Slack, Discord, or email when something's wrong.

Installation

…

View on GitHub

Nixopus: Simplifying VPS Management

Shravan Kumar B — Mon, 23 Jun 2025 18:03:39 +0000

This article is my reflection on the journey of how I relied on free tier clouds and platform specific hosting until I discovered VPS.

Shipping Code while Sipping Coffee

Back then, I was still trying to figure out and understand how all this worked. Starting from which command did what, which service refused to start, and why things that worked on my local; didn’t work when deployed (Thank God for Docker)

I still recall one of my earliest deployment. It was github-readme-quotes app on Heroku. A simple git push to deploy felt magical. I didn’t really have to care how it worked. I just knew that if I followed the documentation devoutly, it was assured to work; if not, StackOverflow always had my back.

This was the same with Firebase, Render, or Netlify for static stuff. All of them taught me how to ship quickly.

But then came the real world; need to host private apps, things that need ports, memory tuning, background workers, cron jobs, etc. Soon, those magical platforms started speaking back and complaining to me:

"You can’t bind that port"
"You’re out of free dynos"
"Exceed dynos quota for the month"

I found myself stuck on an architectural impasse till the day when one of the engineers I know suggested saying these lines, “Just spin up a VPS“. That advice removed the roadblock.

To those who are not aware of what is VPS? How is it different from Server? Let me try to explain it with an analogy:

Imagine you’ve built a website and now you want to make it public, so you need to host it. Basically put it out on a computer that is always online. This is called hosting.

Before hosting a website, there are 3 types of hosting, each of which balances cost, control, and performance in its own way. Let us take an analogy of hosting with where we live:

Shared Hosting is like renting a room in PG, which is extremely affordable, but you share your resources with others and have very little control
Virtual Private Server (aka VPS) is like having your own apartment, you get private space, you are secure, decorate and customize as you want, and truly call your own.
Dedicated Server is like leasing an entire bungalow; you alone enjoy all its resources and full autonomy at a very high price.

Dedicated Servers are either some crazy big computers in freezing cold data centers or virtual computers carved out of bigger machines using virtualization.

So, yep, VPS was that sweet middle ground; cost of a simple 1 BHK flat with freedom to knock down a wall (just kidding). So that balance I needed came in the form of VPS.

So I picked a VPS provider, bought a VPS server for 7€ (~₹697). I got an IP address, username(root), and SSH details.

Till then, I had learnt what VPS was and lil about behind the scenes from the few Google searches I had done. I understood that a VPS is a virtual machine running on a larger physical server with its own dedicated RAM, disk space, and CPU. And fortunately, since I was already comfortable with Linux commands, so felt navigating this environment shouldn’t be a problem.

Since I had previously tinkered quite a lot with Raspberry Pi, by hooking it to the local network and SSH’ing into it from my laptop, I already knew that the only way to connect to my VPS was using SSH.

To those who do not know what SSH means, let us again explore it with an analogy:

SSH is like a passport to access your VPS. With SSH, you can remotely step inside your VPS like teleporting into a distant terminal. It was like I’d opened the door to another computer without leaving mine. There is no UI, browser, but a simple terminal access for your VPS and raw power.

Every server I touched so far ran Linux, so I already had a clear cut understanding. So for everything looked good.

I started slowly moving my apps to the VPS, and running the scripts to have it run on the VPS. I ran into another hurdle; I was only able to access the deployed applications or services using their IP address, like http://123.45.67.89. Unlike Heroku or Netlify, which provided me ready made subdomain for a project like [github-readme-quotes.herokuapp.com], my move to a VPS setup left me staring at a bare IP address.

I knew I needed a proper name and URL, some-project.com, and that’s where DNS comes in.

To those who do not know what DNS is, consider it as a Internet’s Yellow Page (Phonebook); basically translates domain names to IP addresses.

A lot of them still find tying a domain to a VPS surprisingly tricky. Hence, I keep a simple recipe:

1) You buy a domain from Domain Registrar
2) Point it to your VPS IP using A records in your registrar’s control panel

Type: A  
Host: @  
Value: 123.45.67.89

3) Set up Nginx
4) Configure SSL

You might be wondering, what are these Nginx and SSL? Let us understand this better, diving a little deeper into the concepts.

Every service on your server or computer communicates over a specific port; some of them are already predefined, say:

SSH on port 22 for remote access
HTTP on port 80 for unencrypted web traffic
HTTPS on port 443 for encrypter web traffic via SSL/TLS

By now, you must have understood that SSL/TLS is what turns ordinary HTTP into secure HTTPS, making sure that the data between user and server stays private and secure.

Nginx is the traffic police on my VPS which is mainly responsible for forwarding user requests to respective applications, handling SSL encryption, and serving the static contents.

You must be wondering, "Voila, Great, now that everything is in place, and the hard part is over, life must be easier".

Hahaha!! Well, thats exactly when the real problems began. Over time, deployments process became a familiar and routine; rather painful routing I would say.

This routing masked a lot of headaches: broken configs, panicky Nginx configuration tweaks, dread thought of “Did I actually run the right script?“ and manual responsibility of deploying all of these without any automations and verifying the releases.

Eventually, I scripted it all, but I can never forget those initial days of manual, shaky deployments. They taught me the cost of carelessness, where I had spent a day to find one config misplaced. It wasn’t about skill, but rather about mental tax caused due to this.

By then, I had realised managing multiple applications on a single VPS only made things worse, where I had to juggle and handle process monitoring, checking the logs, and mainly running update scripts.

With power comes great responsibility

With experience comes great clarity; I started seeing patterns in the process I followed. I’ve been doing this for a while now, everytime I spun up a VPS or deploy new project on a VPS, I found myself re-Googling the same 20 commands. I observed that across some major pain points:

Copy-pasting Identical configurations
Deployment failures
DNS setups
Setting up Firewall rules
Forgetting about SSL renewals

It was the same story day in and day out. That is when I asked myself, is this problem not actually solved and standardized yet? Do we not have a tool that streamlines and simplifies the VPS management?

My search led me to Nixopus, an indie tool built by a community led by Raghav to tackle these exact frustrations. As we talked, it became clear that Nixopus wasn’t born from ambition rather from fatigue, the kind that drives you to refactor your life. It promised everything I had been hunting for.

Though in Alpha stage, I’ve started using it for managing my VPS and even actively contributing to improvements whenever I can. I am convinced that this project has a bright future. You check it out on GitHub and see for yourself.

We have recently collaborated with HostUp, a reliable VPS provider based in Sweden, to bring you an exclusive deal of 10% off recurring on any VPS plan. Whether you choose to self-host Nixopus or deploy containerized apps, this is the perfect opportunity to secure rock-solid infrastructure at a Discord Community.

You can claim your VPS coupon and start building with Nixopus today.

Join our Discord community, you’re always welcome to hop in for community support!

Summing it up, my journey from building on free-tier clouds and shared hosting to fully embracing VPS has taught me one thing is that having control doesn't have to mean endless repetitive manual work and management. Nixopus bridges that gap, so that from now on you can focus on what really matters.

Stay tuned for more freshly brewed content.

That’s all for now. Thank you for reading.

Signing off until next time.

Happy Learning!!

Neonode: Power Up Your Development with TypeScript & Neon.tech

Shravan Kumar B — Thu, 29 Aug 2024 13:34:10 +0000

This is a submission for the Neon Open Source Starter Kit Challenge: Ultimate Starter Kit

My Kit

Introducing Neonode, the Ultimate OSS TypeScript Starter Kit powered by neon.tech for Modern development.

A boilerplate built crafted to TypeScript with Neon.tech's serverless PostgreSQL. Neonode is not just a boilerplate or starter kit; it's your launchpad for building amazing products.

Neonode is designed to let you focus on building your product while handling standardization and development efficiency out of the box.

With Neonode, enjoy the amazing DX, where the essentials are taken care of out of the box, allowing you to innovate and create without getting bogged down by the usual setup hassles.

Neonode brings you:

Seamless TypeScript Integration
Serverless PostgreSQL Integration
Best Practices Out of the Box
Support Monolithic Architecture (ROADMAP)
ORM Flexibility (ROADMAP)
Server Framework Flexibility (ROADMAP)
Integration with FOSS utility tools (ROADMAP)
AI-based Automated Testing with Keploy (ROADMAP)
Many more innovative ideas (ROADMAP)

Link to Kit

Explore the Neonode starter kit on GitHub here: neonode-oss-quick-starter

My Journey

From my experience working with various server technologies and frameworks, I find that the development ecosystem for Node.js and TypeScript is less streamlined compared to others.

For instance, in my experience with frameworks like Spring and Spring Boot, I've enjoyed a mature ecosystem that offers a smooth development process with built-in conventions and extensive support. These frameworks simplify many aspects of application development, from dependency management to configuration. In contrast, TypeScript with Node.js typically requires more manual setup and configuration, which can be a shift from the streamlined experience offered by Java-based frameworks.

Neonode was designed to bridge this gap and hence, chose this stack for its potential to simplify serverless architecture while leveraging TypeScript's modern capabilities with Neon.tech's serverless PostgreSQL.

During this development of the project, faced few challenges with serverless setups and managing databases.

I had to deal with the complexities of TypeScript's type system and Node.js's asynchronous nature, which are quite different from the more straightforward, convention-based style of Spring Boot. However, these challenges helped to improve, as we learned to refine the approach and make development more efficient.

It's been a rewarding experience seeing how these tools can come together to create a seamless development and deployment environment.

Each change was a step in creating a toolkit that addresses current demands while also setting the stage for future improvements and innovations.

Reflecting on this experience, I believe Neonode goes beyond being just another starter kit or boilerplate.

I'm excited to see how the developer community will use Neonode to innovate and create. I hope Neonode serves as a valuable asset for fellow developers, helping them to craft exceptional applications with less effort and greater impact.

Cheers to pushing the boundaries of development and building solutions that drive the future.

PS: On a fun note, give me a shout when you use Neonode to bring your ideas to life 😛

Signing off,
Shravan Kumar B

Bit Wars: 32-bit vs 64-bit Systems Explained

Shravan Kumar B — Fri, 21 Jun 2024 06:26:27 +0000

This is a submission for DEV Computer Science Challenge v24.06.12: One Byte Explainer.

Explainer

A 64-bit system is like a highway, while a 32-bit system is like a bypass road.

A 64-bit system allows more data to be transmitted simultaneously, resulting in improved overall speed and performance.

Additional Context

A 64-bit system can handle more data at once than 32-bit, like using 64 fingers instead of 32, hence the analogy of a Highway with multiple lanes and Bypass road with 2 lanes.

Must-follow Ethics behind Pragmatic Programmer

Shravan Kumar B — Sat, 15 Jul 2023 08:00:48 +0000

This article(originally published on medium) speaks about the fundamental ethics that every programmer/developer must follow, so, as to be one of the elites and the best in the evolving Software and Technology Industry.

Most developers fail to understand two things, firstly to understand

What do people mean when they say Pragmatic?
What does it take to become a programmer following Pragmatism?

In the simplest words that I can put up, being pragmatic can be interpreted as “Being Skilled in Craftsmanship”.

Pragmatic is all about practicality and being guided by “the priority of action over doctrine and of experience over fixed principles”.

“ I am this person who values craftsmanship, not because the end is a result of beauty, but an investment for my future. ”

Being pragmatic is about being a better developer. It is less about skills and more about experience and practice. It takes a lot of practice and experience to evolve as a pragmatic developer.

With every new experience, you take away something new that you learn, which definitely will connect to the dot as you move forward to face new challenges.

A developer must understand that every software that you develop is a craft. Each person who involves in building that craft is equally responsible. In such a scenario, how do you think you can pragmatism help?

For instance, consider a scenario of the construction of a house, in which various craftsmen have an important role to play. From Architect, Civil engineers to Painters, Laborers, all of them have their own skills that contribute to beautifying and completing the construction of the house.

In the same context, when you are a part of a team that is building a product, your individual contribution plays a very vital role. Irrespective of whether you are part of the backend/frontend/DevOps team, it doesn’t matter. Your contribution is important, as you, on the whole, will be representing the team building the product, not just as an individual.

As said, Pragmatism is more about how you can make a quality contribution to the team, not just as a developer but also as a team member.

Wondering, what does it take to follow pragmatism? Let us figure out what distinguishes Pragmatic Programmers from the crowd.

Being Responsible

In every project, there will definitely be problems. Problems are packed with every project you will be working on, despite taking every safety measure, i.e., cross verifying the Minutes of Meeting, documentation, testing, etc.

Despite taking all the measures, the possibilities of deliveries being delayed or unforeseen technical problems may come up, which is unavoidable at times.

Take responsibility and be accountable for your responsibility. Ensure you are communicating and keeping the team informed with all the updates.

The smallest mistakes during the presentation of your product to the client can lead to catastrophic damage to the reputation of the company or firm that you are representing.

Miscommunication or lack of communication can cause a lot of misleading in the team or within the project. When I was getting out of my Intern developer phase, we had to showcase our work to the client. The backend team had to make some changes on functionality at the last moment and had conveyed it to the mobile team but failed to inform it to the web team, expecting it would be conveyed. This ended up causing a lot of fuss.

Ensure that everything is conveyed to the team properly and avoid miscommunication. If you or the team feel the product is not in the best shape for the presentation, make sure you ask for an extension by taking responsibility for what has happened and ensuring not to repeat it.

If we can accept and be proud of our ability, we must accept and be honest about our shortcomings.

Assuming a situation where you are not able to solve a problem due to the shortcoming of resources or any other issue, avoid presenting the problem/shortcoming you are facing for the given problem statement. Rather present the reasons why you cannot solve them and provide them with alternative solutions.

Avoiding Tech Debts - Software Entropy

When you work in a team, you are a part of a group sailing in the same boat to build a product. A leak on a boat (similar to the wrong decision or code that you put in the codebase) can cause the boat to rot (technical debt) and sink, leading the boat to sink along with people in it.

It is our responsibility to fix those leaks in the first place when we figured it. Do not leave such loopholes open even if the deadline is near. If it is not a serious one, add ToDo and fix it later.

In one of the projects, I was working on, we initially did not structure the code when we had 2/3 services to deal with, due to time constraints. As we kept on building features on top of them, we ended up with 12 services and a whole codebase beyond repair and in the end, had to structure it in a single go which was such a pain.

Take the initiative, be the catalyst

Sometimes it so happens that we see some dirty code. When it does happen, try to convey that to your team. If time constraint does not allow the team to work on it and fix it, the best you can do is flag it.
In a situation when pieces of code are such that you have to fix it (severe bug), inform the team, take the initiative and responsibility of fixing the broken code and get it reviewed.

Gardening is the closest analogy to the development process. Just like how once you plant a sapling, and you need to take care of it every day, the same way as you build the code, ensure no part of the codebase is getting rotten. Once you develop the software, it is necessary to ensure and nourish it carefully.

Whenever new requirements pitch in, ensure that the development of the new feature doesn't affect or cause a lot of change in the existing functionality. Also, ensure that the addition of the new requirement is done in such a way that there is space for another set of new requirements.

Good enough isn’t good enough

How can we evaluate that the product/software we are building is good enough?

Good enough can have two meanings:

Fully satisfactory: Requirements are met, expectations are satisfied, the underlying problem is solved.
Barely adequate: Lowest level of performance that doesn't qualify as a failure

“Good Enough” isn’t “Good Enough”, in the sense that “Fully Satisfactory” is not the same as “Barely Adequate”.

“ How can we know if it’s good enough? ”

Perfect Software is a myth. Perhaps the key to the right balance is to understand the perceptions of the user and stakeholder.

The software/products you build are going to be used by a certain set of users or by general users. It is always best to get feedback from the end-users from their user experience. We can release a beta (release candidate) version, roll it out to your stakeholders, other team members, and possibly end-users for feedback.

As I said earlier, perfect software is a myth. Despite being a myth, there is something that we call a Minimum Viable Product ( MVP ). Every product that you are building, will have minimum viability to be accepted as a functional product.

MVP can be best described as a mid-point between the earlier stages of the development process and the final product, meeting all the fundamental requirements of the product.

Assume a mansion is under construction, initially when a mansion is under construction, it doesn't fit good for you to stay in it. But as the construction of the mansion is completed with required carpentry work, it becomes fit (viable) enough for you to stay.

Same way, when a product solves the fundamental needs of a given problem statement, it can be considered as a Minimum Viable Product.

“ Apple shipped the first version of Hypercard with about 500 known bugs in it, yet the product was a smashing success. The Hypercard QA team chose the right bugs to ship with. They also chose the right qualities… it isn’t the number of bugs that matters, it’s the effect of each bug. ”

- James Bach, person who coined the term Good Enough Software

As we move on, there definitely must have been a situation, where you might have added some functionality as an add-on even without being mentioned in requirements based on your astrological assumptions.

The add-on that you add to the project, might be the one thing that is not necessary and ruins the quality or standards of the project.

Identify the expectation based on the timeline and the resources given. Give the best for programmers, end-users, and future code maintainers. Nothing is always perfect. And most importantly, we need to know when to stop. Do not kill the good program with over-engineering.

Knowledge Portfolio, long-term investment

As you all know, Software and Technology Industry is an ever-changing landscape, where technology and the science behind the technology are evolving. With the pace of evolution, just as important as it is to be an expert in a field of certain technology, it is equally important to keep yourself updated with regard to that technology.

If you fail to keep yourself updated in regard to technology you are working on with the time you will be considered as an outdated resource.

Investing in Knowledge Portfolio is a type of investment that has an assured ROI.

“An investment in knowledge always pays the best interest.”

- Benjamin Franklin

Considering Knowledge Portfolio as an investment, you can classify the investments into two types:

Low Risk, High Reward Investments
High Risk, High Reward Investments

Low Risk, High Reward Investments are the types of investment where you are investing your time in learning and sharpening your skills in the technology that you are proficient in.

On the other hand, High Risk, High Reward Investments are those investments in the knowledge portfolio, where you are not sure about the future of that technology but currently is in the trends.

You should aim to find emerging technologies and learn them before they become popular.

“ Learning Java when it first came out may have been risky, but it paid off handsomely for the early adopters who are now at the top of that field. ”

— The Pragmatic Programmer

Keep investing regularly with diverse technologies. Always stay contained with the spirit of learning new things that may enlighten you to think out of the box.

Always be skeptical and analyze what you have heard or read about.

Communication, a lethal weapon

Communication is an important factor that as a developer we fail to fulfill sometimes. Communication is an art of transmitting information, ideas, and attitude from one person to another. Communication is a process of meaningful interaction among humans.

As a developer, we have to communicate at various levels, starting from communication within the team up to communication with the client.

Most of the time we fail to identify and understand the WISDOM principle behind communication.

One of the most important factors that play a vital role in realizing who you are conveying your idea.

As a product owner, I would want to know about the product based on it’s viability and the problem that it solves.
As a developer, I would want to know how we can solve the problem statement or deal with it, technically.
As an end-user or client, I would want to know more about how does the product works and how does that fulfil all my requirements.

This is certainly something that we always miss out on. Despite being the best communicator in the team, if you explain the aspects and flaws of the products technically to the client, it is less likely expected for them to understand it unless they belong to an IT background or have some prior knowledge.

As far as effective communication is considered, listening is also as important as conveying your idea. Always be an attentive listener.

Finally, how you communicate your idea to the other person contributes to building an effective exchange of ideas. Every meeting not necessarily has to be some sort of presentation of your idea. Some might just be about mailing minutes of the meeting and cross verifying it.

And however you are doing it, make sure you are doing it right. Even when you write emails or minutes of the meeting, ensure there are no grammatical errors or spelling mistakes.

This is vital because, when these mistakes happen with the client we are working with, it speaks more about the firm you are representing and not just yourself. That is why it is necessary to be careful regarding these minute knots.

Note: Communication is not just about what you say. It is about what you say and the way you

Always respond to emails, missed calls, Slack messages, whatever.

Note: You don’t have to immediately respond to everything!

Documentation is another means of communication, basically a written proof of the process flow of functionality. In the software and technology industry, documentation plays an important role in keeping requirements intact to the final functionality.

Always ensure that you document the minutes of every meeting with the client and within the team.

I know this has been a bit longer post than expected. If you got this far, I appreciate your patience and thank you for your time. I had too many thoughts to put up, but adding them all onto a single post may not have been the right idea. Anyhow, wrapping up the post, these simple baby steps are the fundamental ethics that will make you stand out from the rest of the developers out there. As a developer, we should and must strive to be better than we were yesterday. That was my first step towards being pragmatic, and probably, I believe it could be yours as well.

I hope this article has helped to figure those minute things that you missed out on. Stay tuned for more.

Happy Learning! :)

Reflecting on My Voyage as an Intern to a Developer

Shravan Kumar B — Tue, 13 Apr 2021 19:58:52 +0000

Hi everyone! This is a revised version of my article from my personal blog.

This is an article that expresses a few major learnings I would like to take away and mistakes I wouldn’t want to commit again from my journey, and maybe stand out like a guide book for those who are starting their career in Software Industry. I have tried to put up my learning and takeaways from my voyage in the simplest way I can.

Learning is a Continuum Concept, where at every level and stage of your life, you learn and take away something from your previous experiences

I am closing in on completing two years of my career at a startup, starting as a Graduate Intern Developer to Junior Developer and what a journey it has been. I have learnt a lot during the course of this ride. I explored newer nooks of the developmental and DevOps technology. I have made mistakes and learnt from them.

During the Internship experience, I encountered a bunch of challenges that are very much typical to all, who is going through a transition from the College Graduate phase to the Working Professional phase. Likewise, I am going to address the challenges that I had faced along with the changes in my perception while growing as a working professional.

Some takeaways so far from my experience:

1. Tutorial Hell

Initially, when we start out as newbies, it is quite common that we prefer to learn videos from Youtube Tutorials, Udemy or any other LMS application. Some might prefer following and reading from some open blogs like Freecodecamp or Medium blogs.

Now, let us first understand what is Tutorials Hell?

Tutorial Hell is a typical situation, where you find a lot of tutorials and you are not sure about which one to follow and learn from.
Assuming, let us say somehow you figured out which tutorial to learn from. Now you struggle with what to do/build with what you have learnt.

Initially, I had a very hard time getting through this situation. I was learning Node.js and I was very new to the Event-Driven Programming Paradigm and had a lot of confusions about fundamentals, despite I had followed one of the many tutorials available.

Generally speaking, I do not have any issue with tutorials, but I find that most of the tutorials, always tend to miss 4–5 core concepts, as they expect you to have a technical grasp of the same. Those missed out concepts create a lot of voids as you go ahead.

Let me give you an instance from my own experience. If you have worked on any JS-based framework/libraries, you must be knowing different ways of handling asynchronous operations (Callbacks, Promises, async-await). Those of you who do not know, do not worry, it is just 3 different ways of handling async operations. The point being, Callbacks are a real pain, whereas Promises and async-await is a better and cleaner way of writing code.

Initially, when I started out writing RESTful APIs, I followed the Callback way of handling asynchronous operation, because the tutorial I had followed did not bother to speak about Promises and async-await. For around a month or so, imagine my life, handling every DB calls and asynchronous functions as callbacks. It was too difficult to write simple logic, despite the problem statement was quite straightforward.

With time, as I kept exploring different technologies, one thing that I realised is that nothing beats the OFFICIAL DOCUMENTATION. Every technology that you want to learn, has its own Learning Management System or its own Official Documentation published, which surely covers every aspect of the technology that you are learning. Since then, any technology that I want to explore, I always prefer to follow the official documentation.

Avoid Cobwebbed by tutorials

Finally, after we learn from the resource, follows another overwhelming situation where you are more confused about what to do with the updated knowledge portfolio?

Initially, since I was already working on a project, I could easily fill in whatever I learnt to fulfil the project requirements. It allowed me to constantly learn and explore.

There could be scenarios where you learn technologies out of the scope of your project you are working on. How to deal with situations in that scenario?

Difference between Knowing vs Understanding

The best thing one should do after learning technology is BUILDING SOMETHING. Build, Create something you want. Be it simply for fun. Does not really have to be a real-time useful product. It is simply a product that you can apply conceptual learning to practicality.

If it’s a new programming language, you can explore more by trying to solve problems from HackerRank or other competitive platforms. Maintain a GitHub Repository to keep track of whatever you are learning with simple documentation for your understanding. This allows you to have your own documentation that you can look back into whenever you want. Creating and documenting the Proof of Concepts is a deal.

Meanwhile, KEEP CODE-READING from different GitHub repositories. I used to randomly code-read just to get a glimpse of different approaches to solving problems and writing code. This actually helped me improvise the way I wrote the code.

Open Source Contribution allows you to spread your wings and collaborate with people having different ideologies.

One more way to get through this situation is to CONTRIBUTE TOWARDS OPEN SOURCE. Try to search for some Open Source Projects built on top of the technology and try actively contributing towards it or recreating your own project as a Proof of Concept.

2. Build Products, not Junk

This seriously was a huge misconception I had initially, where I thought trying to solve the problem statement and coming up with a solution, is the most important thing. Probably, because of an attitude sometimes your graduate syllabus forces you to inculcate, where finding a solution is considered important than any other factors.

There are two factors that we tend to fail to focus upon, firstly END-USER of the application and secondly CLARITY over USER REQUIREMENTS.

What user wanted vs What you delivered

Sometimes we fail to understand the user requirements. At times, we misinterpret given User Requirement, due to our individual perception and experience, which, of course, is not a mistake. But, it is very important to clarify what you have understood with the client/user/product-owner.

It is always better to ask, in the very initial stage of the project, with the product-owner/client, whether your understanding of the requirements are accurate or not. When you question the client in the very first stage, you won’t end up building a product that was not required.

Similarly whenever, requirement pitches in between the development cycle, ensure you clarify that as well, just to make sure that your project doesn’t end up going south.

Bad UI/UX: Label [PUSH/PULL] and Handlebars.

Why? Do I need the handlebar to push?

Always focus on building the product on the basis of how the product owner (End-User) wants it.

Bad Design Aesthetics: A button showing the corresponding number and another actual button to click the floor number

When you are building the product, ask yourself, “As an owner of the product, does this make my work easier? Does this solve my problem? Is this solution feasible? Is this the only approach available? Are there better approaches?”.

By the time, your research is done, and have it evaluated based on the above factors, you will have a conclusive and evident answer, portraying clarity over how to go about building the product with a better User Experience.

Keep constantly in touch with end-user and build the product always iteratively.

3. Knowing the Best Practices

To those who do not know what do I mean by Best Practices? Best Practices are evidently proved guidelines with a strong theory behind them.

Daily Healthy Routine is the closest analogy to the Best Practices

Just like how we follow certain practices on daily basis like bathing, washing hands after eating, and so on, to maintain our hygiene and keep ourselves neat and tidy. Similarly, in software development, we follow a certain set of proved norms, just to ensure that the product we are building doesn’t rot with time or newer requirements.

Every technology you learn, there are always best practices tagged along with it. It is quite difficult to remember all the best practices. Over time, one thing that I realised and noticed about the BEST PRACTICES is that most of them try to learn and recollect the best practices. And fail to understand the theory behind the practice that we should follow.

If you understand the theory behind the practice, it wouldn’t be difficult to remember them while implementing it.

Practice tells you that things are good or bad; theory tells why.

Let us take a simple instance, whenever we want to scale your project structure, how do you figure that out?

We have a proposed model called the Scaling Cube Theory, which describes the basic principle behind the model and why should you consider it when scaling the project.

Scale Cube: Service Scalability Best Practices

Each axis of the indicates, as shown below:

X-axis: Scaling by cloning, otherwise known as Horizontal Duplication. Usually monolithic projects when deployed, have multiple cloned copies of an application behind a load balancer. When you have only one service to deal with, we are mostly advised to go with Monolithic Architecture.
Y-axis: Scaling by splitting different services, known as decomposition. Usually, projects with complex problems statements and several services, are often advised to split the application into multiple distinct services. When you take this kind of decomposition approach, we call it Microservice Architecture.
Z-axis: Scaling by splitting similar things, known as Data Partitioning. In projects where robustness is a very high priority, improving Infrastructure from the Data Storage point of view helps a lot. In this kind of approach, there are several replicated copy of the code, but each of them is accessible only to a subset of the data.

If you see in the above instance, by knowing the theory behind the Scaling Cube, it is easier for us to understand which approach to be considered when we are building the project architecture, based on the business requirements of the project. When we apply Scaling Cube, it is easier to evaluate whether or not to scale the project.

4. Debugging

At the early stage of my learning, I devoted a lot of my time to debugging, since I was very new to the technology I was working on. And I did not have the grasp of the errors and crashes that followed. I always used to seek help from StackOverflow and Grepper extension for finding the cause and origin of the bug and do some quick fixes. As I kept exploring, I became quite familiar with some set of errors.

But as I kept exploring new services and stacks, sometimes it was due to bugs in packages that I am using, it so used to happen, where I encounter some new types of error. I couldn’t afford to spend more time to debug and resolve errors, so I started following a simple backtracking method to debug called Five whys.

Debugging is a sort of aggravating task when you can not figure out the origin and cause of the error. The five whys method was a very basic technique, which helped me determine the root cause of the error in the easiest way, by iteratively asking the question “Why?”.

5 Whys: Technique used by Toyota Motors for finding manufacturing defects

I used loggers to ensure from where exactly the issue has originated. This saves a lot of time. It is important to find the origin and root cause of the error.

Also ensure that you document the tracked bug, which is at the application level. It is important to document the bug, maintain the history of bug tracks and record the solution for the bug reported.

5. When you have to explore something new, create Proof of Concept

Whenever a new problem statement pitches in, something that you have not worked on. Always create a Proof of Concept for the same. Try out different possible solutions for the same. And do some research work on the different possible solution and make a simple Proof of Concept with enough documentation(for your teammates to follow up). Have a healthy discussion and take opinions from your team.

Proof of Concept is not final implementation, rather they are intended to provide proof that a given system would work effectively for the problem statement posed. Take feedback on the PoC, and also do not forget to keep them in your GitHub Repository for future reference for yourself and others.

6. Unit Tests makes your code better

I learnt this the hard way, but honestly speaking, Unit tests are the best way to catch bugs. In the initial stage, I hardly knew and cared about writing Unit Tests for the APIs, I used to often find myself concentrating on completing the tasks in the expected slot with good quality.

Unit Testing: Verify if the piece of code is doing what it is intended to do

Writing Unit Tests helps you to verify that the code is doing what it is intended to do. Unit tests always help and provide strong backbone support to maintain your code and safely refactor them from time to time. Sometimes, Unit Tests helped me to discover edge cases that I have missed upon. Since the time, I have learnt to write Unit Tests, I have always made it a habit to write Unit Tests for the code I write, which gives me more confidence in the quality of the code I deliver.

7. Maintain Documentation

Documentation is always the best way to define a feature from the User’s perspective. Before developing the feature, document the feature first. As a developer, always maintain documentation for the feature you are building.

“Documentation is a love letter that you write to your future self”
-Twitter

Whenever you can, ensure that you have the document written has been reviewed by the end users and stakeholders before any development begins. As and when the feature is modified during development, make sure that the corresponding changes are documented. Just as documentations are modified, so should be the Unit Tests.

8. Writing Blogs

Writing blogs is useful for many reasons. Writing blogs will help you realise if you have understood the concepts well and if you are able to explain them in a way others can understand. As developers, we mostly work on creating and adding values to the product, we are building maybe by resolving a bug or implementing new features, which most of them do, but writing blogs would help you get a better understanding of the concepts and gives you a very good feeling about helping people. Some day, someone might read your content and may be able to produce a feature required for their project through your guidance. Your experience can help someone get proper guidance.

9. Contribute towards Open Source

Open Source has a great community built around. Contributing and being part of the Open Source Community allows me to explore and embrace newer perspectives. Contributing to Open Source helps me a lot in improvising my problem-solving skills.

I get to meet like-minded people and they help me inspire to become a better developer. It is always nice to be part of a peer, passionate about developing and building products. Trust me, it feels great to have your name as a contributor to someone’s project, which boosts your positivity and confidence.

10. Always be Open to Continuous Learn

Firstly make sure that you build upon your fundamentals. Keep your fundamentals strong. If your fundamentals are strong, switching between similar technologies and exploring them would not be a difficult task.

Keep exploring new technologies. The Software and Technology Industry is an everlasting industry that keeps expanding with time. As time evolves, the industry also keeps evolving with new technology arising every new day. Always ensure you are open to switch and learn, explore and practically work on those technologies.

Read Technical and Non Technical books to keep yourself aware of the revolutionary changes happening in the industry. Keep reading blogs published by Major MNCs and have an understanding of their system design and architecture and the theory behind it.

I always keep exploring different technologies, because it helps me have a wider perspective. Wider perspective helps you come out with better and creative solutions. I prefer to be a Generalizing Specialist.

A Generalizing Specialist is jack-of-all-trades, and master of a few

11. Be polite

Life becomes much easier as a developer when you start listening to others. Always have a certain level of humility when listening to others. It is very important to be open to different perspectives and opinions.

Every expert was once a beginner.

You were a beginner before you reached this stage today.

Always be there for those who need your guidance and keep helping others learn and grow. In the process of guiding others and helping them expand their wings, there is a lot that you will explore and experience as well.

These were some of the major takeaways from my journey as an Intern to a Developer. I hope all the beginners who are reading the article, will find these useful for your journey. Those who have already passed this phase might find it very much relatable.

The post has been longer than expected, if you got this far, I appreciate your patience and thank you for your time.

If you like the article, hit the like button, share the article and subscribe to the blog. If you want me to write an article on specific domain/technology I am provisioned in, feel free to drop a mail at shravan@ohmyscript.com

Stay tuned for my next article.

That’s all for now. Thank you for reading.

Signing off until next time.

Happy Learning.

DEV Community: Shravan Kumar B

Sharing my thoughts on experience/learning from Freelancing journey

On Freelancing: My lessons and learnings

On Freelancing: My lessons and learnings

On Freelancing: My lessons and learnings

Why Freelancing?

Freelancing isn't freedom from work. It's freedom in work.

The First Project

I was wrong.

What I Learned

The Feast and Famine Cycle

How to Handle It

The Loneliness

Building Community

Setting Boundaries

Protecting Your Time

Understanding Your Value

Pricing Your Work

Your rate is not just about money. It is about the respect you have for your own time and expertise.

The Reality Check

What You are Really Signing Up For

The Trade offs

Setting your space & workflow

Workflows that worked for me

Learning to Communicate

Communication Best Practices

Freelancing: Usain Bolt or Mo Farah?

Is Freelancing Right for You?

Signs It Might Be Right

Signs It Might Not Be

Conclusion

Expedition of Async Programming in JavaScript

My Background with Programming

Understanding Synchronous JS

Asynchronism with JS

Async Programming in Node.js

Callback

Callback hell, the vexation

Promises

Async/Await

Conclusion

Interesting read!! ⭐

How Jekyll almost killed our vitepress docs

VPS Management made easy with Nixopus

Nixopus: Simplifying VPS Management

Self Hosting Management made easy!!!

Nixopus: Simplifying VPS Management

Inside Nixopus: How We Manage Our Database Migrations?

nixopus / nixopus

Open Source Alternative to vercel, heroku, netlify with simplified workflows

Features

Installation

Nixopus: Simplifying VPS Management

Neonode: Power Up Your Development with TypeScript & Neon.tech

My Kit

Link to Kit

My Journey

Bit Wars: 32-bit vs 64-bit Systems Explained

Explainer

Additional Context

Must-follow Ethics behind Pragmatic Programmer

“ I am this person who values craftsmanship, not because the end is a result of beauty, but an investment for my future. ”

Being Responsible

Avoiding Tech Debts - Software Entropy

Take the initiative, be the catalyst

Good enough isn’t good enough

“ How can we know if it’s good enough? ”

“ Apple shipped the first version of Hypercard with about 500 known bugs in it, yet the product was a smashing success. The Hypercard QA team chose the right bugs to ship with. They also chose the right qualities… it isn’t the number of bugs that matters, it’s the effect of each bug. ”

- James Bach, person who coined the term Good Enough Software

Knowledge Portfolio, long-term investment

“An investment in knowledge always pays the best interest.”

- Benjamin Franklin

“ Learning Java when it first came out may have been risky, but it paid off handsomely for the early adopters who are now at the top of that field. ”

— The Pragmatic Programmer

Communication, a lethal weapon

Reflecting on My Voyage as an Intern to a Developer

2. Build Products, not Junk

3. Knowing the Best Practices

4. Debugging

5. When you have to explore something new, create Proof of Concept

Your rate is not just about money. It is about the respect you
have for your own time and expertise.