---
# System prepended metadata

title: 'Week Two Experience at Software Engineering '

---

<h1>Week Two Experience at Blockfuse Labs  Software Engineering Program </h1>

This week at Blockfuse Labs was another step forward in my journey of becoming a better Software Engineer. I spent most of my time learning how Linux handles files and how to write basic shell scripts to automate tasks. These are not things I was familiar with before, but now I’m beginning to understand the power behind them and itnis all making sense to me now.

The concept of Command Line Interface (CLI) is one I was never familiar with. All my life, I have always believed in using my mouse tracker to carry out whatever tasks it is. But CLI says "NO, let us do in the hard way so it becomes simple"
Honestly speaking, new concepts don't make sense until they begin to stick and the difference they make is what brings the glamour amd satisfaction 

<h3>What I Learned</h3>

One of the most important things we learned this week was how to control file permissions and ownership using two key commands: chmod and chown.

<h3>Understanding chmod</h3>

The chmod command lets you change who can read, write, or run a file. Linux uses something called octal representation to make this easier. It assigns numbers to permissions:

`Read = 4`

`Write = 2`

`Execute = 1`


Permissions are grouped into three parts:

Owner

Group

Others


So if I write:

`chmod 755 file.sh`

It means the owner gets full permissions `(7 = 4+2+1)`, while the group and others only get read and execute `(5 = 4+1)`. This was new to me, but after trying it out on files and testing what works, it started to make more sense.

<h3>Understanding chown</h3>

The chown command is used to change the owner of a file or folder. For example:

`sudo chown user1 file.txt`

This gives ownership of the file to "user1". It’s important because in Linux, only the owner or root can make changes to some files. This taught me how serious Linux is about security and structure.

<h3>Challenges I Faced</h3>

One of my biggest challenges this week was writing a shell script that collects a directory name, validates it, and stores a file inside it. At first, it looked simple. But when I started adding conditions to check if the folder name was empty or too short, my script began to misbehave. I kept getting errors because I didn’t space the brackets properly or used the wrong syntax. For example, I tried using `$(Directory -lt 3)` which is totally wrong.

Even though I made mistakes, I learned how to read error messages and fix things step by step. I also learned how to make the script smarter by checking for empty input using -z, and how to measure the length of a string using `${#variable}`.

The good part is: I didn’t give up. I asked questions, watched what others were doing, and slowly improved my script. Now it works! It may still be simple, but it does exactly what I want it to do.

<h3>Looking Forward</h3>

As I move into the next week, I’m starting to see that reading is good, but doing is better. I learn faster when I try things on my own. Reading helps me know what’s possible, but doing shows me how it really works.

I plan to keep reading the Linux manual, checking real examples, and writing my own scripts. Even when it’s hard, I will keep trying, because the more I do, the more I learn.


