DEV Community: Warren Thinwar

What LuxDevHQ Week 2 Taught Me About Linux and Postgres

Warren Thinwar — Tue, 01 Sep 2026 04:02:30 +0000

What LuxDevHQ Week 2 Taught Me About Linux and Postgres

Week 2 of the Data Engineering track at LuxDevHQ was the week I stopped treating the terminal like a black box that occasionally yells at me, and started treating errors like they were trying to help.

Nothing dramatic happened. I didn't break the server. I didn't lose data. If anything, the most useful moment of the whole week was a command that refused to run. But that refusal taught me more about how Linux thinks than any command that worked on the first try ever has.

Here's what stuck.

Orientation is not optional

Before this week, my instinct when I opened a terminal was to just start typing the command I came to run. This week I got burned — well, mildly singed — by jumping straight into a task without checking where I actually was.

Over the course of one session I was hopping between three different contexts: a remote droplet, my local WSL environment, and a Postgres-as-a-user shell. Half of my confusion that day wasn't about syntax at all. It was that I genuinely wasn't sure which machine or which user I was operating as when I ran a command.

So now this is muscle memory, five commands, every single time I open a new shell:

`bash
whoami                  # who am I?
hostname -I             # what machine am I on?
groups                  # what can I do here?
pwd                     # where am I?
ls -l                   # what's in front of me`?

Boring. Cheap. Non-negotiable. It costs five seconds and it's saved me from running a "safe" command in the wrong context more than once.

SSH mistakes are loud, so don't repeat them

Small one, but worth writing down: I fat-fingered an SSH login with the wrong username (caleb instead of thinwar) and my first instinct was to just... try again with the same wrong username, thinking maybe I mistyped the password.

Bad habit. On a shared server, repeated failed logins with the same username look exactly like someone brute-forcing an account — even if it's just you being sleepy. The better habit is: if a login fails, stop, actually check which user you meant to be, and only then retry.

The usermod error that taught me the most this week

This is the one I want to spend the most time on, because it's the moment the whole week clicked for me.

I tried to change my own home directory while logged in as myself:

bash
usermod -d /home/data warren

And it failed:

usermod

: user warren is currently used by process 363

My first reaction, honestly, was mild annoyance — "why won't this just work." But sitting with it for a second: this is Linux doing something smart. You can't change certain fields — home directory, UID — for a user that has live running processes, because doing that mid-session could corrupt whatever's relying on the old value. And since I was logged in as warren, running the command as warren, I was always going to hit this wall.

Instead of guessing around it, I went and actually diagnosed what was running:

bash
ps -u warren                # everything running as me right now
ps -p 363 -f                # what specifically is PID 363?
ps -u warren --forest       # the whole process tree for my user

And the real fix, if you genuinely need to change a live user's home directory, isn't a force flag — it's logging out and doing it from a different session or a different admin user entirely:

bash

sudo usermod -d /home/newpath -m warren

The habit I'm taking from this: when usermod refuses with a "currently used by process" error, that's not a bug to route around. That's the system protecting you. My job is to log out and retry from elsewhere, not to go hunting for -f.

Shells, /etc/shells, and the case of the "no changes" mystery

Same session, different rabbit hole. I wanted to understand valid login shells before touching anything, so:

bash
cat /etc/shells

This file is the system's allow-list — the programs it considers valid login shells. chsh and usermod -s will generally only accept a path that's listed here.

I compared my current shell against my options:

bash
echo $SHELL
grep warren /etc/passwd     # last field = configured login shell
cat /etc/shells

Then tried setting it to something "different" just to watch the mechanism work:

bash
sudo usermod -s /usr/bin/bash warren
grep warren /etc/passwd

And got told, essentially, "nothing changed." Turns out /bin/bash and /usr/bin/bash are usually just the same binary — one's a symlink to the other — so the system correctly recognized there was nothing to update. Not an error. Just Linux being precise.

The real lesson here is the gap between $SHELL and /etc/passwd. $SHELL reflects your current session — it can lag behind a change until you log back in. /etc/passwd is the ground truth for what's actually configured. So now: grep /etc/passwd before and after any shell change, always.

A safe checklist for changing a live user's settings

Putting the two lessons above together, this is the sequence I'm now committing to for touching any account that might be actively logged in:

bash

1. Check if the user has active processes

ps -u <user>

2. Check current values before you touch anything

grep <user> /etc/passwd

3. If processes exist and you're changing something process-sensitive

(home dir, UID, GID) — log that user out first, don't force it

4. Make the change

sudo usermod <flags> <user>

5. Verify immediately

grep <user> /etc/passwd
id <user>

The distinction worth internalizing (this feels like the kind of thing that gets asked in interviews): shell changes and supplementary group changes are generally safe to do on a live session. Home directory and UID changes are not — and the system will tell you so, if you're paying attention.

Postgres: the 3-step grant pattern for a role that can actually do things

The Linux stuff was about being careful. The Postgres stuff was about being complete. It's easy to create a role and grant it something, run a query, see it work, and think you're done — and then discover three weeks later that half of what the role needs is still locked.

Here's the sequence that actually gives a new role (teammate, or an app) working access, not just existence:

sql
-- Step 1: create the database and the role

CREATE DATABASE project_db;
CREATE USER app_user WITH PASSWORD 'change_me';

-- Step 2: let the role connect and create inside the schema

GRANT ALL PRIVILEGES ON DATABASE project_db TO app_user;
\c project_db
GRANT USAGE, CREATE ON SCHEMA public TO app_user;

-- Step 3: extend rights to tables — existing AND future

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO app_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL PRIVILEGES ON TABLES TO app_user;

That last line is the one that's easy to skip and expensive to forget. Without ALTER DEFAULT PRIVILEGES, any table someone creates after today won't automatically be visible to app_user. It's not implied by the earlier grants — it's a separate, forward-looking rule. Now it's a habit every time I provision a role, not an afterthought.

Inspecting a database like you didn't build it

Also practiced: the muscle of walking into an unfamiliar database and figuring out its shape before touching it, which is basically the day-to-day reality of joining any real team.

SQL
\c project_db
\dt              -- what tables exist?
\d customers     -- what does this one actually look like?
\ds              -- any sequences behind it?
\di              -- any indexes I should know about?
\du              -- who else has access?

Then confirming data actually flows the way you expect:

SQL

INSERT INTO customers (first_name, last_name, email, age)
VALUES ('Test', 'User', 'test@example.com', 99);

SELECT * FROM customers WHERE age > 25;

The one-line habit here: run \d

before writing any query against a table you didn't create. It's the fastest way to avoid a typo'd column name costing you ten minutes of confusion.

Permissions, practiced on something that doesn't matter

Small sandbox exercise, but a good one — practicing chmod/chown on a throwaway file instead of on anything that matters:

bash

touch practice.txt

ls -l practice.txt              # baseline: -rw-r--r--

chmod u+x practice.txt          # add owner execute

chmod g+w practice.txt          # add group write

ls -l practice.txt              # confirm: -rwxrw-r--

sudo chown $(whoami):$(whoami) practice.txt

rm practice.txt                 # clean up after yourself

Habit: ls -l immediately before and after any permission change. Permissions are invisible until you actually check — and checking costs one command.

The loop underneath all of it

If I zoom out, everything above collapses into the same six-step loop, and I think this loop is actually the transferable skill — more than any individual command:

Orient — whoami, hostname -I, groups, pwd

Connect deliberately — SSH in, confirm you're where you meant to be

Inspect before you change — \l, \dt, \d, ls -l

Change one thing at a time

Verify immediately after — \dt, ls -l, id, SELECT *

Clean up test artifacts — drop test rows, remove scratch files

The actual takeaway

The usermod refusal is the moment I keep coming back to. It would have been easy to read that error as "this tool is broken" or go looking for a force flag to push through it. Instead it was the system correctly refusing to let me destabilize my own live session.

That's the real Week 2 lesson, underneath all the specific commands: learning to tell the difference between "this is a typo I need to fix" and "this is a safety feature doing its job." The second one shows up a lot more often in real infrastructure work than I expected, and it's a much better use of your attention than fighting it.

On to Week 3.

My First Week at LuxDev HQ: Getting Comfortable with Git and the Command Line

Warren Thinwar — Sun, 23 Aug 2026 10:35:21 +0000

Starting something new in tech can be exciting, but it can also be a little overwhelming.

This week at LuxDev HQ, I got to work with some tools and concepts that are becoming an important part of my journey as an IT student. We covered everything from installing Anaconda Distribution and Git Bash to learning basic terminal commands and using Git through VS Code.

At first, some of these commands looked very simple. But I quickly realised that understanding the basics is important because these are the tools developers use every day.

Getting Started with Anaconda

One of the first things we worked on was installing Anaconda Distribution.

Anaconda was new to me, but I learned that it provides a convenient environment for working with Python and its libraries. Instead of installing everything separately and dealing with different dependencies manually, Anaconda makes setting up a Python environment much easier.

This was especially useful because I’m becoming more interested in data and Python-based development.

The installation itself wasn't particularly complicated, but it was a good reminder that before writing code, you need to make sure your development environment is properly set up.

A small setup problem can easily turn into a big headache later.

Getting Familiar with Git Bash

Next came Git Bash.

I had used Git before, but this week gave me a better understanding of working with Git from the command line.

Git Bash provides a terminal environment where I could run commands and interact with files and Git repositories without relying entirely on a graphical interface.

Some of the commands we practised included:

mkdir
cd
touch
echo

They might look basic, but they are useful building blocks.

`mkdir`

mkdir is used to create a new directory.

For example:

mkdir my-project

This creates a new folder called my-project.

`cd`

cd is used to move into a directory.

cd my-project

This takes me inside the folder I just created.

It sounds simple, but being comfortable navigating between directories becomes important when working with larger projects.

`touch`

We also learned how to create files using touch. In our case, we created a README Markdown file:

touch readme.md

This creates an empty readme.md file inside the current directory.

It was a simple command, but it helped me understand how files can be created directly from the terminal instead of always using the VS Code interface.

`echo`

Another command we practised was echo.

For example:

echo "Hello World"

This displays Hello World in the terminal.

We could also use echo to write text into a file:

echo "Hello World" > readm.md

Practising these commands helped me become more comfortable using the terminal instead of always depending on a graphical interface.

Learning Git Through Practice

The biggest part of the week for me was getting more comfortable with Git.

Git can seem confusing when you're first introduced to concepts like repositories, commits, staging and pushing.

But once you start actually using it, the workflow starts making more sense.

The basic idea we worked with was:

Make changes → Stage changes → Commit → Push

After making changes to a project, Git allows us to keep track of what has changed.

This is one of the things I appreciate about Git. Instead of having different copies of the same project everywhere, Git gives us a proper history of the changes we make.

Using Source Control in VS Code

We also learned how to push our changes using the Source Control section in VS Code.

This was probably one of the most practical things we covered.

Instead of running every Git command manually in Git Bash, VS Code provides a visual interface where we can see the files we have changed.

Our workflow was:

Make changes to the project.
Open Source Control in VS Code.
Review the changed files.
Stage the changes.
Write a commit message.
Commit the changes.
Push the changes to GitHub.

Seeing everything directly inside VS Code made the Git workflow much easier for me to understand.

It also helped me realise that Git isn't just something you learn for the sake of learning it. It's something I'll probably be using regularly as I continue building projects.

What I Took Away From This Week

One thing I learned this week is that the simple stuff matters.

Commands like cd, mkdir, touch and echo aren't complicated, but understanding them makes working with the terminal much less intimidating.

The same applies to Git.

I don't need to memorise every Git command immediately. What matters right now is understanding the basic workflow and getting comfortable using it.

I'm also starting to see how the different tools fit together:

Git Bash → working with commands and files
Git → tracking changes to projects
GitHub → storing repositories online
VS Code → writing code and managing changes
Anaconda → managing Python environments and tools

Individually, these tools are useful. Together, they are becoming part of my development workflow.

Final Thoughts

Overall, this was a good week at LuxDev HQ.

There were moments where I had to stop and think about what a command was actually doing, but that's part of learning.

I'm beginning to understand that becoming better at tech isn't only about learning programming languages. It's also about becoming comfortable with the tools developers use to build and manage their projects.

This week was mainly about the fundamentals, but those fundamentals are going to matter as we move into more advanced topics.

I'm looking forward to seeing what we learn next.

One week down. More to learn.

Cohort 9 Onboarding Sessions

Warren Thinwar — Mon, 10 Aug 2026 09:35:05 +0000

Introduction

Introduction to LuxDevHq

Data is the new buzzword that every company is trying to figure out. Today I am joining an onboarding session for my new journey as a learner at LuxdevHq Cohort 9 Program, that starts today 10th of August. This article covers my experience at LuxDevHq's onboarding session for my cohort

List of Items Learned

Here are some of the areas I have discovered today;

I love baking
Wesley is a marketer

Additionally, we have also learned that:

Luxdev offers a course for free after the first course.
Moses has serious hobbies and Joker has hobbies, and both hobbies cannot compete

Stephen gave us a quote:

I Came, I Saw, I Conquered!
By Stephan

Writing Lines Of Code

Here is a practical example of a line of code I will be using in class to practice SQL:

SELECT * FROM cohort9.applications;

Writing a block of code

Here is an example of an SQL Block that I wrote during onboarding session

SELECT student_name,
FROM cohort9.Applications,
WHERE student_name = "Mark"

Photo Session

We also had a photo session with the available students who came for the session

Adding url link

Here is a link to Luxdev's github
Luxdev

Conclusion

In conclusion, today's luxdevHQ onboarding session has been quite
informative and insightful about their programs, different ways we can write good articles, the role of articles in Tech, and how to ensure how to write a good article.

How Excel is Used in Real-World Data Analysis

Warren Thinwar — Mon, 08 Jun 2026 04:31:09 +0000

WHAT IS EXCEL?

Excel is a software used for data entry, analysis and data visualization and uses data also to generate insights from the data given

Three ways Excel is used in real-world data analysis

1.Data Cleaning

A lot of companies or organizations use data cleaning to see whether their general insights are correct and also to fix any errors in the messy data so that it can be used efficiently

Checking Performance

This means that in Excel employees can be evaluated on the work done and the amount of hours they put in their tasks so as to ensure work is done efficiently

Marketing

Excel can be used to evaluate which products are selling and record latest trends happening so that they can engage with users and expect feedback on how to improve and what areas to work on

Mention at least 3 Excel features or formulas you've learned so far and explain how they can

be applied

Mention at least 3 Excel features or formulas you've learned so far and explain how they can be applied

Sorting

Sorting lets you arrange your data alphabetically, numerically, or by date, making it much easier to spot patterns and fix mistakes

Find and Replace

By pressing CTRL + H this helps you to fix typos across the selected row and also replace text or numbers with the desired figure or text

Sum Function

By writing (=SUM) and selecting the desired rows or column this is a mathematical formula used to add and find the total figure accurately

How has learning Excel changed the way you see data?

Learning Excel completely shifted my perspective. Now, I see data as something dynamic and full of hidden stories. Instead of just seeing a list of inputs, I realize that with the right tools, you can slice through the chaos to find actual patterns and trends. It has taught me to look at information more critically—asking why numbers look a certain way and how they connect to the bigger picture. Excel transforms raw numbers into actionable insights, and it’s made me realize that data isn't just something you store; it's a powerful tool you use to make smart, informed decisions.

Intro to Data Science

Warren Thinwar — Tue, 26 May 2026 09:47:37 +0000

Anaconda

hello

[](url)

this is ok

apple
banana

Introduction

key areas in Data Science

Luxdev hq is in garden estate
Hello its me