TypeScript is a JavaScript superset. The most simple way to understand TypeScript is its JavaScript with a superpower. Normally, JavaScript is a dynamic type language, what this means is that when you write a code, you don’t have to define the type. This makes JavaScript much easier and cleaner to write compared to other static-type languages. However, due to this simplicity, make JavaScript presents flaws. TypeScript offered a way to catch type-related bugs while developing. This means you will know that your code is not correct before the runtime. This gives a huge advantage because most of the bugs will happen during runtime and when that happens it’s way too late.
You might wonder why would we need TypeScript if JavaScript itself also offers type checking by using typeOf. I mean, it works if you just want a type checking but the problem with this approach is that JavaScript will not show you any type error before it gets complied.

Type Inference is the way TypeScript knows how to infer the type of each variable. For example,

From the code above, TypeScript knows that the value x will be a type number, without you explicitly defining it.

Normally TypeScript will offer type infer for your object and array when you define it but we also can explicitly write as well

JavaScript doesn’t come with tuple but TypeScript does. A Tuple is a fixed-length array.

Normally you can’t add the third value into this variable because it’s a tuple. However, there is some caveat here.

Type any allow you to pass any type into a variable. This is what you should avoid when you using TypeScript as this won’t make a difference when you are using plain JavaScript. Unless you know what you are doing.

Enum in TypeScript is just a feature and not a type-level extension of JavaScript.

What enum does is provide a mapping value with the string defined. From the code above, Up will be a value of 0, Down is 1 and so on. You also can override enum if you want it to start with 1 instead of 0.

You also can use string as an enum. However, string enum doesn’t offer the benefit that they serialise but often it offers the readability when you have to debug.

A Union type is a way we can combine two types allowed in any parameter. For example

From the code above, both a and b could possibly be a string or a number.

You can also use a string defined as a type as well. This might sound a bit confusing but let me show you.

This prevents you from typo when you are trying to pass a string value in.

Types Aliases is a way to define a type prior to using it. This helps you to write a cleaner code and don’t have to repeat it every time.

In TS, you can specify what type of value should get returned in that function. However, it is also a good practice to let TS does its job by using type interference.

This function said it must return a type of number. But you also can omit this because TS knows anyway that the return type must be a number as two inputs are a number. However, in JS, a function doesn’t need to have a return keyword, which means it doesn’t need to return anything and still be a valid function. For example.

From the function above, you can see that this function only does console the sum of two inputs. It doesn’t return anything. But this function actually has a return type of Void. JS doesn’t know this void function, it doesn’t exist in the JS world. You even can do something like this.

Things to note here is that if you are trying to console.log this function, you will get undefined. The reason because this function doesn’t return anything.

You also can be called this function type expression. This is a bit hard to explain, let me show you the code first.

The code above is from TS documentation. What this means is that the function greeter takes in a function that contains one argument which has a type of string as a parameter and the greeter function will return nothing. As the function printToConsole contains one argument with a type of string so you can pass printToConsole into greeter.

Another example of function as types is when you define a variable and want that variable to store a certain function, what you can do is.

Let's say we have two functions, a constant the combinedValue specific that it will allow only a function that takes in two parameters with a type of number. So if you pass in add which meets the criteria, then TS will allow you to. On the other hand, if you pass the printOut function which takes in only one argument, TS will throw an error.

You also can pass a callback as a function while defining what type you want that callback function to take in.

This is the benefit when we are trying to call a function and we don’t have to explicitly tell TS that the callback function that we pass in return what type of value. From the example above, if you are trying to pass the second argument to the callback, you will get an error.

Another thing to note here is that we told TS that the callback function returned void. However, if we write a return statement here like this.

This is a valid code because when we told TS that we want this callback function to return void, what we are saying is that we want TS to don’t care what we will do with the return statement.

TypeScript 101 - Basic TypeScript - Types

Developers need solid technical skills as well as soft skills. You can't work flawlessly without good soft skills, I think this as a survival skill in your day to day work.

This skill is probably one of the most important skills when you start as a software developer. The reason is that you don’t know most of the work that you have to do so you have to ask your teammates or seniors. By knowing how to approach people to get an answer that you need you also have to get used to the response that you didn’t expect as well. You need to know how to behave when something goes wrong. This lead to the next key point which is “ask lots of question, even if it is stupid question”

Always ask a question even if it is a stupid question


This is what you have to get used to even if it sounds ridiculous but this can lead to success or failure in your early career. To emphasise this, when you don’t know something you have to ask but the problem here is that most of the thing that you don’t know somebody else in your team know it. You or they might think that it is a stupid question that you should not ask. This is normal as if you came across something over and over again then someone came to you and ask that question, deeply in your mind you will think that it is a stupid question(even if it is stupid). You got no choice but have to ask, do not think that this sounds stupid and keep it with yourself. You will never get an answer by doing that. The reason that I encourage you to ask rather than Google is it might take you 2 minutes to get an answer while Googling yourself can take up to hours. You can assure that most of the things that come across you, someone else has already been through it. So ask a stupid question!


You want other people around you to be kind to you but at the same time, you need to be kind to them as well. Don’t think just because you are a junior or just started and you can’t be any helpful. Sometimes your teammate needs some help during their peak time and you could be a lifesaver. If I think that someone might need a hand even I don’t think that I can’t help them anyway, I still approach them and ask them if anything that I can do. Keeping a good connection is better than keeping none at all.


This is probably one of the most important skills as a software engineer. This is due to the nature of the work itself. Technology always moves fast, whatever you think that you know today might be outdated tomorrow. That’s why keeping yourself up to date and being open-minded to learn new things all the time is crucial. When you get older you start to slow down and think that what you know is the best practice, you get bogged down by this. I saw people in day to day work always stick to what they believe but obviously, it’s not the best practice. Don’t be afraid to learn new things, do research and keep updating yourself.

Developer Soft skills


In this blog, I will point out important keys for you to find any job, particularly a software developer job.


The software development jobs are over demanded since the covid hit. There is a shortage of staff, especially engineers across the board. Thus, it is a good opportunity for a new joiner to start in this career. However, the interesting shift toward software development jobs makes it harder to get into the field. I still believe that the demand is always high, but sometimes it seems that the market is too saturated for newbies to start a career in tech, I'd say otherwise. There are always place for people who belong, this is my belief toward finding a job in tech. When people say the market is saturated, I'd assume that they think the market has too many engineers and getting one is almost impossible. This is not true for many reasons, but I will not mention those as the key topic in this blog is how to get a job!


First and foremost, get yourself out there. I can't stress this enough to anyone who started in this field. It is just impossible for a recruiter or employer to know that you are out there looking for a job if they can't see you. It doesn't matter, at all, how good you are if you are invincible. What do I mean by "get yourself out there". Well, I mean physically or verbally they need to notice you. The best word to describe this behaviour is "reach out". I mean it by aggressively. The way I did it is I will DM a recruiter or company that looking for someone to fill in a role that I'm interested in. I will reach out to them and make sure that they look into my profile. In this state, it doesn't matter whether my profile will catch their eyes or not. I just want them to see it. By doing this, at least they know that you are there.


You can try to impost someone that they want but that will never work. This is because you can't be someone else for the rest of your career. At one point you will flinch, and when that moment comes things won't be fun.
The most crucial part of getting employed is they need to hire you because it is you.
This is one thing that I'm most proud of as I'm always being myself. I got rejected many times no doubt about that but also at the same time I don't want to lose myself trying to be someone that I'm not. It feels uncomfortable and unnatural.



I think this is common sense that everyone should keep in their mind. I said this because if any of the words you said is not true about yourself then at the end of the day people will find out. Admit what you don't know and work hard to gain that knowledge. It is totally fine to tell someone that you don't know about something. No one knows everything. This is statement is underrated in the software world as there is so much information that we humans could not take it. That's why we have Google, that's why we ask someone else.


An employer needs to expect something from us. Show them what you can bring to the table, why they need to choose you over someone else. Especially, when you started as a junior, it is crucial that they can expect something from you in the long run or at least they think that they can expect something. If they look at you and they see nothing, there is no point to invest in this guy. You can show them by giving them your word what can you bring to the team. For instance, when I first started I told my employer what I will be bringing to the team. Why the team is better with me. I told them that I can bring energy to the team which is very important for me that you will feel the positive energy when you work in a team environment. I don't know at that time whether they will buy or not, but I said what I feel.


Don't overvalue yourself but also don't undersell yourself


When it comes to the moment when you have to sell yourself with a question like "What is your expected number?" or something related to the evaluation, you need to be honest with yourself. It is not ok to undersell your self just to get a job. You have to understand one thing, if they want you, they will try to get you anyway. So you have to choose a standpoint and stick with it, that's where your value comes in.





How to find a software developer job in a saturated market.

In this blog, I will explain how to get started in a software development job. In this blog, I will be able to write only in terms of my point of view as a front-end web developer so if you found something unsure about what is expecting to learn please DM me.

Well, this is a very broad question to start with. The answer would be millions of things to learn. But what you need to know is that "What is your end goal?" What do you want to do?

There are many types of software developer jobs from web developer to data science which is also included in the software field. You must be able to answer this question before you even sit down and start to work on something, as the details/knowledge that you need to know will be interestingly different. For example, most data science jobs need a foundation of Python while web development builds on JavaScript. These are two distinct languages that serve different platforms. JavaScript rules the web app, so you can't become a modern front-end developer without a solid foundation of JavaScript. Once you decided what you want to become then you move on with the next step.

In a modern time where there are many frameworks to choose from when it comes to building a web app. It is also undeniable that you still need a solid foundation of the language itself. React, which is probably the most hype framework at the moment is a JavaScript library, to say this, you can't just jump into React while you lack foundation skills from JavaScript. React got the 'react way' of writing code but at the same time, those syntaxes are still under JavaScript rules. To be honest with you, it is not hard to learn syntaxes, you could catch it pretty quick if you know what you are going to write. For you to write a React 'comfortably', you will need to know JavaScript ES6+ because mostly you will use it all the time in React.


HTML and CSS also play a big part as a front-end developer as you will need to work with the UI all the time. I hate to say this but it doesn't matter how much you hate CSS, you still need to master it because it will be your day to day work skill that you need. In a big project you won't write raw CSS, but sometimes styled-components or some other CSS frameworks. For instance, Chakra UI, Material UI and Semantic UI. All in all, you still need an understanding of how CSS works.

Personally, I'd recommend "Zero To Mastery": https://zerotomastery.io/

Why do I recommend this? This will give you the WHOLE picture of how web development works. You must have an understanding of how everything is put together before you start your journey. I'd recommend skimming through each chapter and course available for you to see which one catch your interest and then start from there. This course also contains a roadmap for which direction you will be going after you finish a certain course so you won't have to waste your time learning the thing that you do not need.


After that, you will get a rough idea of what you want to do. Then you start to dig deep into a specific niche that interested you. As this is a long term journey, you better choose wisely. To put this in a perspective, I spend more than 6 months just with React before I landed my first job as a React developer. This does not include the time I spent with CSS or Javascript. I mean, I still re-visit Javascript docs all the time when I need to write something, it is totally fine to do that.


From this point, I can't give you exactly where to go next. It is up to you which direction you want to go or which topic you still want to improve. And make sure that you don't limit yourself to just one learning medium. I always stick to video-based materials when I first started out but later in my journey, I found out that books and documentation also give me lots of knowledge that video can't give me. So make sure that when you get stuck at some point, allow yourself to switch around.

How much do I actually need to know to get a job?

This is probably one of the most asked questions that I get or see people ask. The answer to this question is "you never know". This might sound random but I meant it. Don't forget that along your journey, it is just you, no one else. The point is you can't evaluate yourself. You can test yourself with some test platform on the internet but that doesn't mean you are not competent. It is hard when you have to answer this question to yourself while you still learning. The downside of being self-taught is there will be no one to tell you that you are ready, go out there and find a job. That doesn't mean people who went to college or university get any advantage over you. They(uni gangs) might think that once they graduate they will be ready for a job(approval). But in the real world, this is unrelated. I saw many people who grads from top tier uni and struggle to find a job, not to mention got rejected many times. So, what is the problem here?

Let me tell you why. You have to understand that skills that are required to work as a software developer and skills that you obtain from uni or college don't necessarily be the same thing. In some cases, it might be different. That is a good thing about being self-taught, you can teach yourself just what you need. Just enough to get a job. Don't get me wrong here, I didn't mean to offend any uni grad that what you learn will be useless. It gives you something with our without your conscious. But I'm trying to talk about those skills that are subjective.

You might get confused at this point that "so what do you mean by skills?" Let me give you a real-world example. Let's say that the company that you want to apply for build a web app for various company. The tech stack they use might be something like this

Front-end: Next.js, React, Redux, Recoil, React-queries

The question is when you grad from uni or college do you know any of this?


Don't forget that software technologies move fast. What you think you know today might be useless or not used anymore in the next few months. So as a self-taught you choose what you have to know not someone else tells you what you have to. You cut so much time that you will spend in the uni.


To conclude, be confident in yourself. This is very important as a self-taught because you will be on your own. You need to cheer up yourself, pat yourself at the back and lift yourself. Once you are confident in your skills, start applying for a job. Don't underestimate yourself. You can do much more than you think you can but you just need to be confident.

How to get a start in a software developer job, how to learn and what to know.

Today I will be sharing some of the important git commands that I used daily as a developer. I won't be covering all of the git commands in this blog because most of the time you won't be using all of them. I have to admit that I have no clue about git command when I first started the job as a developer. The only command I know is git commit. But once you start to work in a real team on a real serious project, Git command is essential. You will not be the one who works on the project so if you don't know Git then you can't work with the team. Of course that you can learn on the spot but it's good to know beforehand.

The short and simple way to answer this question is its version control. To emphasise this it's the tool that helps you and your team not yelling at each other why you redo what I have done. Or why you are touching my code while I'm not finished with it. Hopefully, this makes sense.

Git used to add/remove/updated the code that was in the project. If you are working alone on your project it won't be concerned that much in using Git as the only thing that you will do is add and commit. However, when you are working on a project with many developers involved. Your changes will be a concern. Your code will need to approve before you can merge(we will talk about that later). Simply say, you can't just change whatever you want to change. There is a conventional way of doing things which will depend on how your team setup. Some time your change might affect the whole project and other people will get conflict.

Git add will add whatever changes that you did on your current branch. With git add . (git add + dot) means you will add everything that you make changes on all of the files in that project. If you want to specify the file you want to add you can follow git add by the file name.

Git commit. This command will commit whatever you add to the branch that you are on. Every time that you make a commit you will have to comment on "what you have done". This is where things get a bit tricky. In some developer teams, this part is important as when other developers come to check your branch they want to know what you have done. If some error needs to get fix then they know where they can find those changes. If your comment is not meaningful then no one would understand what you did. Not to mention it will be painful for others to figure things out. So it is a very good practice to give a descriptive action of what you did.

Git push. This will push all of the changes that you commit to the remote branch. To note, when I say remote branch I mean that branch that you are working on lived on the Github site already not just on your local.

You will want to make sure you don't work in the main branch ever. By adding some feature or fixing bugs, you will have to create a new branch to work on. Even that changes will contain 1 letter.

This command will create a new branch for you and move you to that branch directly so you don't have to run `git checkout`.

Let's say you are working on your branch fixing some bug, you spend way longer than expected and other developers have added some features to the main branch. You might want to update your branch before continuing. To do that.

When you run this command, Git will pull the main branch into your current branch that you are working on. Now you have the latest update from your team. But after you merge the main branch with your current branch, you will have to push those merges back to your branch as well. The point here is to try to pull the update from the main branch as often as you can to avoid the conflict that might happen. Fixing conflict is not fun.

Do not work on the main branch ever. The only thing you can do on the main branch is "git pull". The reason is if you make only 1 change and accidentally push that change up, no one will be able to approve your code. It will get pushed directly to the live project if that project hooks to the auto-deploy branch. If that unintentionally changes that you made crash the site, then you won't even notice until a customer comes to you and said my site is down.

Update the main branch before you create a new branch to work on. And occasionally pull changes from main to your current branch. Before you make a pull request to the main branch don't forget to update the branch one last time.

Add a meaningful comment when you commit things, it makes your life easier when you have to look back and find what changes you made that crash thing.

That's all my main git command that use every day as a developer. I know there is more than this when it comes to command. I will make an update if I seem that some other command will be useful.

Always hit me up on Twitter if you want to chat!

Git command(just the important one)

Have you been stuck in tutorials hell? Have you ever been curious that why you learn so much but know so little? Have you ever feel like you waste so much time staring at the screen?

I have been there. And I will tell you how to get out of that loop.

These days that knowledge is easily accessible. You are just one click away from gaining any knowledge that you want to know. From learning how to code, marketing skills, how to draw or even how to cook. We are blessed that we all have access to this information compare to decades ago that learning is a hustle. I still remember when the time that my mom has to drive 2 hours to buy me a book about how to learn English. It was tedious.

The good thing about putting so much effort into getting anything is you will know its value. The opposite is true as well.

This is 2021, the way people learn something is just video-based learning or maybe an ebook or even a simple blog that you are reading right now. The downside of this type of learning is once you get used to it. You are in autopilot mode. You keep watching video or tutorial and thinks that your brain absorbs that information that you need. It might be true, but most of the time people do not question themselves. I mean, you don't test yourself. You will forget what you don't use. That's how it works.

I will use coding or programming as an example. Because it is easy to fall into this trap. The majority of people who spend their time watching tutorials will end up knowing nothing much. The more time you spend watching tutorials or online courses the less you know. Don't get me wrong, everyone needs to have some guidance and a good instructor is the best way to get started. I have been there where I spend weeks trying to understand one concept. But I ended up knowing less than 20% of what I expected to learn. I have running in this loop over and over until I told myself that I need to break this loop and start to figure something else.

I did tons of research about the best way to learn anything. And I came up with some solutions that seem very interesting. The main idea here is called "Active Recall". It sounds conceptual and when I first heard this I was like "What?". But it is very simple.

"It doesn't matter what you learn, you just need to recall it from your brain to make sure you know it". This is my definition of this concept. If you want to know more about this concept I suggest read the book called "Make it Stick" by Peter C. Brown.

Active Recall: The best way to learn anything

In the programming concept, active recall means you need to apply what you learn to build something. The reason is when you have to build something you need various kinds of knowledge to complete your project. So when you try to build something you need to start with what you already know, then stack it up along the way of what you don't know. But learning while doing will make it stick to your head much more than just learning for the sake of learning. In this way will make sure you learn A and you use A. It's simple as that.

The majority of people who start learning how to code will try to learn as much as they can regardless of the situation. Because they want it now, they want to know that NOW so that they can do what they wanted to do. They think that more is better, that not wrong. But it depends. If you eat so much but your body can't absorb any nutrients then what's the point of eating, apart from the extra calories that you get. The fact is that you won't get anything now. The only way that will make you deeply know what you try to understand is by implementing that knowledge into something that requires that set of concepts. Let me give you step by step.

It could be books or docs or video tutorials. But the point here is "concept". If the video is 2 hours long, I'm pretty sure that the concept is less than 30 minutes. So what exactly is a concept. The concept is how things work. For example, let's learn React. The core concept of React is JSX, props, hooks, virtual DOM, state, components. That's it. You just need to know how these things combine and function. Some courses are 6 hours long to explain all of these things. But the fact is you don't need to spend that much time.

Now after you know some concept start to build something. Like literally anything. Or to be more specific anything that interested you. Start from what you know. STOP when you don't know. SEARCH for it. Continue. and repeat. That's the correct loop that you want to be stuck in not tutorial hell.

All of the programming concepts or frameworks got documents. If any of that doesn't have one then you should stay away from it. When you are stuck with something, even little things, open the docs. It will help you refine your knowledge so next time when you come across this topic again you will be confident of how to solve it. I have to admit that reading docs take time to get used to. I still find it very intimidating, it's not easy to read. But it's the only place where it's the core concept lived. If Elon Musk build Tesla and wrote how it works in his blog, then the only place where you should find an instruction is in his blog not elsewhere. You will have to get used to how to read the documentation because when you became a software developer you will have to read it. Like lots of it. So if you are comfortable with reading official docs then you are good to go.

Please note that these are all my personal experiences. There might be right or wrong based on your experiences. If you have any questions, my DM is always open.

Things I wish I know before I start to learn how to code.(The most effective way to learn)

     In this blog, I will tell you how I became a front-end developer without any related degree. I landed my first developer job a couple of months ago from the day that I write this blog. It's not an easy path for me, I have struggled many times but I ended up accomplished my goal.

     I got a background in Aircraft Engineering, I used to work as an aircraft mechanic for 2 years. After I figure out that it's not the time for me to settle down yet, I start to travel. Just so you know the aircraft engineering career is a very long term commitment. You will have to spend at least a minimum of 5 years to move from mechanic to licensed engineer. And that involved many tests and exams. Someone that I know spends solid 10 years from mechanic to licensed engineer.

     Another main reason that I do not prefer to work in this career is the nature of the work itself(I hate shift work). So after I know what my future will look like if I continue this path, I decided to quit the job and start exploring the world. At the time of quitting the job, I still have no idea of what I want to do.

     I always love computers, gadgets and tech stuff. I used to be a hardcore gamer when I was young. But then it was just a childhood memory to me. Not until I wonder what I really wanted to do for a living. Something related to computers is the first thing that I am interested in. Just so you know I'm really bad at arts but I'm really good at maths and most of the stuff that required logical thinking. So software engineering is the first thing that came up to me. I start to do lots of research and ended up going for web development.

     Around the end of the year 2019, I made the most expensive investment in my life from my own saving. And I never know that that investment gonna change my life forever. I bought myself a Macbook Pro. I committed myself that I will accomplish this, so I go all in. But sometimes things did not go as planned.

     My first course is the Web Development Bootcamp by Colt Steel. It's a massive course that covers pretty much everything that you need to know about web development. Of course, I ended up not finish the course. I spend around 2-3 months messing around with Colt's course and some other bits and pieces. I gonna be honest here, it's overwhelming. There are so many things to learn while you know nothing. It's like you are still at zero even you spend months trying to understand things. I admitted I gave up.

If you want something badly, you will come back for it

     After I gave up, fast forward about half a year. In late 2020, I started to come back to continue my learning. I know that I won't mess up this time. I put so much effort into my learning schedule.  I was working at the cafe at that time from 6.00 am till 4.00 pm 6 days a week. After I came back home I will always be in front of my computer, smashing whatever I need to get done. It was so tired that you have to work full time while you have to spend extra time using your brain learning new things. But after I get used to this schedule I'm kind of feel comfortable with it. Until the day it paid off.

     I know that as someone without prior experience and even no educational background it's very hard to land your first job. In this case, I will tell in terms of my perspective and this might be varied depends where you live. At the time I'm applying for a developer job in Sydney, we were in a lockdown situation. During the time that I learn how to code, I saw so many job postings that need developers. So I feel a bit better that if I'm qualified enough it not gonna be too hard to land the first job.

     Among developer communities, LinkedIn came first as the job-hunting platform. And I can confirm that it's true. The majority of the job posting on LinkedIn are active. It means that when you apply or DMs those people who listed the job will reply to you. My plan was to apply to the job as many as I can regardless of the job title, as long as it is related to web development I will apply for it. Because I always believed that you need to get yourself out there.

     I have to say that in a way I was lucky. The first company that I got an interview with is the company that I ended up sign the contract with. The reason I said that I am lucky is that I apply to so many jobs listing, and I can't remember what I have applied for. One day, I got a contact from one of the agencies. The first word that I heard is that 

"Hello, I saw you have applied for a senior developer role, but I can tell you that from your profile, you are far from senior." 

It was a bit of a giggle there but I know that I apply to jobs that I shouldn't apply to. But lucky enough the person who contact me also said that

 "But anyway, we also looking for a junior developer as well but we haven't put ads out there, and you could be a potential candidate".

     Later that day, he sends me the project to work on and told me that I got as many days as I want. I decided to give it a go. The task was about building a project that fetching the data from an external API and display it on the page. Simple is that. But with the limitation of I have to choose between using React or Next.js. I spent the weekend finishing this project and submitted it on Sunday evening. To be honest it was fun to build that project.

     After the first review of my project, I got a second interview with the Tech lead and one of the senior dev. They gave me feedback about my project and what I can improve to make it better. At that time I thought I won't get the job as most of the feedback is not in a good way. But it was constructive feedback and I really appreciate that. They told me that they will contact me within 2 days to give the result. I was super nervous, I can't do anything for that 2 days.

     The moment they call me back and told me that I got the job I was working at the cafe. I almost scream out. My face was full of smiles that day and I told everyone the good news. They send me the contract and ask me to review it if I'm happy with it or not. I was not fuzzy obviously, got the first dev job offer that I always dream of.

So that's my journey from zero to developer. Hope you enjoy it!

If you want to know more or have any questions just hit me up on Twitter!

Welcome to Briantells