14 My 5 tips for computer science students (my regrets)

In this episode, we would talk about a few gotchas which you gotta keep in mind when you go for an interview. Remember, in programming jobs, especially senior level jobs, you will be grilled. If you don't know your basics, you won't be hired. I will go in to detail on six strategies to keep in mind when interviewing. It all comes down to having empathy with your interviewer. You have to make it easier for him to hire you and these tips would be helpful.

Hey my dudes. This episode is more focused towards beginners and college students. I would be talking about 5 tips which if you inculcate in your life will for sure get you very far in your computer science career and help you secure great job. The back story behind these tips would be things I did wrong, my mistakes, my regrets, what I learned so far and what worked for me. Why wait, let's dive right in! Don't forget to subscribe, share and support (Patreon: blissfulprogrammer)

A lot of times when you are working with other teams, you would be given an impossible deadline. In my opinion, 9 out of 10 times it is out of no where. Impossible deadlines makes sense for a doctor where patient can die, or may be a fire fighter, or paramedic or a stock trader, but for a software engineer? Why? We all know software development should be strategic and not tactical. You should take a step back and ask the why before jumping on coding. A working code is just the start. If you don't do due diligence and jump on building softwares, most of the times it will not be useful and thrown away since you didn't strategically asked the right question to understand the whys. Remember that you are the expert in building softwares not the sales team or the client. Its your responsibility to inquire and poke and sit down with them and weigh in all the alternative and ways. After doing this heavy brainstorming, go back build MVP and then come back, let them test and repeat.  In this podcast I will discuss the same along with examples and what should you do in these scenarios. 

Hey my dudes! In this episode, we would talk about a basic strategy for understanding any new complex domain.  UML is very helpful but you don't have to go crazy about using each proper entity. Just drawing on the white board helps your mind and others find patterns which help you understand the core of the domain. It could be a new API (like I was doing recently with facebook ad api), a new service or a new product. It helps you understand enough so you can discuss the domain more properly with domain expert and help out stakeholders. So let's dive right in. And explore this in detail.

Hey my dudes! In this technical Episode, we will be talking about OAuth 2.0, its history, a little bit about OAuth 1.0 and OAuth 1.1, its advantage and briefly get in to understanding the protocol, entities, the grant types, use cases etc. I will try to keep it as basic as possible, I promise.  For show notes, references (Thank you Oath and Digital Ocean), and more readings, you can check my blog link here - https://www.onceaday.today/subjects/4/posts/181

In this episode, I would be talking about domain driven design. There is always two types of engineers in a team. One who are core members and understand the domain lingua well and others who just care about feature completion. Of course the core members are the ones who are least replaceable and are important asset for a company.  Understanding domain and talking and creating code and architecture that goes hand in hand with domain expert understanding is a big asset and is the topic of this episode and the book Domain Driven Design by Eric Evans. I would suggest reading that as well.

In this episode, we will talk about the importance of learning as a software engineer. Both in and out of your job.  The only way to grow as human is to learn. But it is hard to take out time to read everyday. After a whole day of intense mental work, we are usually too tired to act on that time. Although there is no way to go around it, a better way is to set task not time. If you get extra 10 minutes, take that to accomplish your task of learning out of job in that 10 minute. Read faster. If you get 30 instead, awesome, try 30 that day.   Setting weekly tasks might work as well if you are too busy all weekdays.  Read blogs, subscribe to newsletters, read books, watch videos, whatever works for you. Personally, I would suggest physical books so you can take a break from digital devices. 

In this episode, we will talk about why being assertive is very important while being a programmer.  You need to tell others if a problem is solvable in the the time given or you need help or more resource to finish it. You need to say no to an approach if you think it is wrong. You need to tell that you can't solve a problem and you need help if that's the case. As a programmer, you are the one who have to build or figure out solution. Others might want you to build a rainbow dumping unicorn but you know it is not possible, and you should let them know.  This assertiveness, this bluntness is going to help you so much in other aspects of your life as well. If you like someone, go tell her/him that. If you were mistreated speak up, if you don't like something, take steps to change it. If you were not given promotion or raise, ask for it. Regret is the worst feeling and it will eat you inside out. Believe me. If you bottle-up things, you will feel the energy transcending into stress and eventually regret. So from now on, count 3 seconds and on 3, do or speak what you want to do or say without caring about what others think of you. You are not supposed to be perfect. You are supposed to be you at your best assertive self though.

In this episode, we will talk about why you should save yourself money and not fall for scammy programming courses telling you that they will get you a six figure job once you take their courses. IMO most of these guys are disrespect to the community. They want to ride on the buzz word and make money by putting together contents which are freely available in open source docs. Most of them also pay others to prepare the script they can follow on. This is wrong. Heck, I also thought about creating a course and ride on this wave but I just couldn't find the joy in doing this and so I stopped. One of key component of being a software engineer is to learn the ability to find solutions to problems. Believe me, a good engineer knows how to google search an issue or concept he is trying to figure out. Most of the resources are there for free and enough to solve any programming problem. My mentors say the same. I have never seen them spend their money on these courses and neither have I. When you short circuit knowledge gain by buying these course, you are removing that step which might help you become a better knowledge seeker You might solve one problem but further on, you will get dependent on someone to do the heavy lifting. Tldr; If you see a course for less than $15 or may be even $20, go for it. But do not fall for these scammy course creators who fabricate open source free knowledge and sell it for a grand or half. Be wise, accept the grind, look for free open source information

In this episode, we will talk about the other side of maintaining the quality of your work. Coding is also an art. It is a creative way of bringing any new product to life.  We all know that any artist need a peaceful state of mind to achieve brilliance through his work.  Same with you. Never overdo it aka take breaks. Take breaks after every hour and a major break (1-1.5 hour) in the middle while working. When you are working, work hard, think more and write less. But once if you are done with that total time, just get away from any digital device.  Go spend time with your family, friends, wife, plants, dogs whatever you like. Also stop thinking about work once you are done for the day. Remember, you are a programmer not a doctor. No one is going to die if you don't overwork. There is no train to catch. Take your time.  This in-turn is going to help you escape the burnout for longer and actually produce quality code throughout your career.