 Hey, good afternoon everybody, so we back after the lunch and first talk that we have is Aman Sharma No more tears from project nightmares. So thanks a lot. Aman. You can take it on Thanks a lot and welcome bike on India to this talk of no more tears of project nightmares with the added touch of Memes, this is the first time experimenting something like this. So bear with me and this is my first bike on talk So are you a person who always want to complete the project at time? But never does are your person and who's incomplete project are haunting you in the dreams or Are you the person who always think whether your code will survive the next print or not? Well, my friends if you are then this is the talk for you because today We have all the gifts and goodies and all these needed hacks and tricks that you always wanted to know to complete Your project at time. I'm Aman Sharma. Currently. I'm founder founder and CTO at Wimbit And also I'm a lead at mobile web dev which is a mobile web community And I'm also member at deep learning AI OS open source initiative and app So three things will be of key important in the all the slides that will be recovering So first one is consistency how you can be consistent across all these points How you can be efficiently carrying out all these tasks and of obviously how you're all team is expected to deliver everything at 100% time So this is a small talk agenda. Let's quickly go through it We'll be covering about what are the things that are currently going wrong with normal and a mature project practices Also, what should be done in order to plan a project in a very efficient and smooth manner so that all these Above problems doesn't occur and how you can set up our best environment so that you have a productive workspace Your team is productive and working efficiently all the time And how you can optimize your project to make it survive through all the future drops and tough sprints and whatever is coming along The final delivery day how you should plan to actually execute the final delivery of the product and Finally a quickly recap into everything that we covered in the today's talk Well, I want to clarify this thing I'm not a MBA student or I haven't done any project management and this talk is not about project management This talk is about you delivering the best way a project should be done So if you find these helpful feel free to add more suggestions or any opinions, let's start The first point is what's going wrong? You see that there is a visual project story chat that I have picked over here on the Excess you can see it is a relation between anxiety shame and fear and on x-axis You have time which is first of all unproductive and finally at the end of the time it becomes more productive So usually this is the line that is the ideal line of a burned-on rate and your anxiety shame and fear should get Decreased by the time you are ending the project But it doesn't occur all the time at the starting point You need in you everything that you need to do you assume that you knew what what you need to do But as soon as you start working as the time increases the anxiety shame and fear of completing the project increases a lot And then finally this is the point where you actually start working Which is a huge gap between the time you knew and then the time you start and that is where everything goes into crisis then Everything is a nightmare journey through all this hell of this time in which anxiety and shame and fear is Decreasing and increasing over the time and this is what we'll categorize at hell And this is the time where I'm trying to make things easier for you through the stock and After that everything is fine back into your productive space But you have already wasted a lot of time based a lot of energy and your team might not like it So let's make sure that this doesn't happen in your next print or next project. That's what the stock will help you One important thing that I have found during my career journey is to create half products That's totally fine, but not create half as product and there is a very good differentiating line between these two Always ship the things that you are fully confident with don't ship things that okay. How are half So one of the main reason why things fail is because of poor planning. You see poor planning is like Creating a rail track while the train is running or like fixing things as they occur So you are not actually developing something you are just doing crisis management And it's you are not the only one most of the problems occur in Crisis management only and that's because mainly due to poor plan Also another problem that people usually face is thought clarity every people every person in the team has a different Perception about what the project needs to be delivered and some people like just not understand What the thing that they are trying to build is mainly because everybody has a different opinion different level of thinking So they assume things differently how we can fix this things is also covered during the stock Also, many people are not using the tools optimized my friends Professionals who have a quite good experience will respect this opinion. That's too Tools should be very well used but most of the people like this poor fellow I don't know what these tools are or this guy who thinks that it's really overwhelming to use the tools So just get through this and which actually waste a lot of time of your team Everybody is not using the accurate tools that they should be use One important problem is also premature optimization, which is classified into three ways thinking too far You are thinking a lot ahead story You are thinking of making the product as comparison to Facebook or Google which is not possible at current time Also, most of the people are thinking of scalability. They are thinking of making the application run for millions of peoples Which is totally not through the application that has been designed for thousand people might not run for the next 10000 so always just take care of the current load size that your application is going to handle Don't think of a lot of scalability that is going to come in the future Also, sometimes the scope of the whole project is so much overwhelmed that just starting and finishing it is not making any sense Also another problem is if you don't optimize your project at all like premature optimization is wrong but not optimization at all is also wrong people think that if things are working in the project then you should not touch it and Things don't run constantly. It's sometimes they run on some piece of input and some other piece of input It won't work then people don't rigorously test things. They leave it to the users if there are testing Happening it should be by the users complaint, which is really wrong way to do things and of course unfavorable production It's not important that your machine or the development environment that you might be using is exactly the same as the server or the production environment That will be over there. So all these problems leads no optimization at all and creating a lot of chaos Let's come to the final solution then how you should actually plan the project So you see there are different definitions of what people think about, you know project from moms to dads To what clients think the project manager actually does what you think what project management is and this actually is what you are doing Is like micromanaging everything like kittens playing on the roof So one important thing that I found very important is talking in terms of time If you practice this thing in every project trust me there won't be any thought play already problem or problem in delays Talking in diagram means that you create a diagram of the fully functional thing that you're trying to build The benefits of this process are it brings a lot of clarity in the whole project It confirms that everybody is in the same page everybody knows what they are trying to build and they are not missing at the point Also, it also avoids any possible run-downs because all these modules are labeled very well on the diagram And you don't have any surprise modules or surprise function or surprise infrastructure that you have to add in the middle of the Also, it helps you plan properly what resources you will need what kind of skills that you will need and they don't create a mid project crisis or anything like that But another question that arises is how much planning or how much diagrams that you should actually It should be just enough to get everyone around you're not trying to plan a whole Indian Project or something you're just trying to get all these five people's know about what projects you're working on It should be made with collaboration if you are the project manager or the lead of the project It is not not just the responsibility of the project manager, but the whole team if everybody discuss comes on the same table and discusses What and how the project should be made trust me there won't be any problem occurring in the future Also, it should be regularly talk if you have a practice common practice of holding regular meetings Then try to get through this project plan that you have just created in every meeting Details are not necessarily it's not important to nail down every detail every touch point every single seconds But just a simple overview that what people actually should know about the project and Finally try to run through all these steps that you have written down in the flowchart like a stimulation What will happen if this is coming what will happen in this is coming 90% of the time you will face all these issues that might occur in the production solved in the diagram phase only and If you are a team of highly skilled marine, you don't need to you are already expert But most of us are not so let's try to follow these steps and how you should actually do that First thing that I have always found helpful is explored by a sample project. We are not expert in building everything from scratch So it always helps in trying to find an example project that is very very close to what we are trying to do It helps you understand what kind of problem they might have faced what kind of teams they might have used how much time It took them and there are they write mostly blogs and different fss software even have their open source code The diagrams that it the code is using so it's very helpful to go through these projects Always start by adding main elements of the project first and then go through the details You should carry on like basic structures like what databases you might be using where are the API interactions going to happen Where is the security infrastructure that you're going to put in place? Where is the identity management like the basic stuff that the important elements that your project is trying to cover This is the first thing that you should put on the project then start with specifying input and outputs Try to connect them with arrows like what is going out and what is going in into different modules This helps you plan if you are trying to create a loosely coupled or microservice-based application It helps Kind of reduce any possible deadlocks or any situation that is going to happen in the future They don't all the tools that you might be using for the whole this helps the team learn in advance What are the skills that they need to have in order to work on that project so that In order to work on the project people are not learning the skills going through a lot of Documentations in the middle of the project They are going to do it just before starting up the project and also add any connections If your application might be using any third-party API go through that documentation very very well and add these connections into the diagram Next of course if you are working in a team, which is the most cases if you're not a lone ranger So this is some do's and don'ts that you should follow first of all tech talk regularly don't create Information or communication silos between people you should talk clearly all these points that you are trying to discuss should be discussed Very clearly and there is no stupidness or shame that a person should feel in order to ask any questions If you are the leader of the team you should lead by example And you should be the first one who should start asking stupid questions, and then the team will follow yours Also connect efficiently. It's not important to Connect just for a chit chat your agenda and everything should be laid on in the beginning of any meeting and that how it should be It should be carried out then every responsibility that has been planned during the project And that's in the diagram should be shared responsibly so that Everybody is assigned with a key thing and whenever something goes wrong. There is a answerable person It's not important that it matches his skills under percent But if there is a manager for a small thing it really pieces of the process and doesn't delay the project a lot Also, there are some don'ts that you should follow while you should not hold long meetings long meetings Create a lot of chaos be it light a lot of tiredness and people will stop attending your meetings in the future Don't add unnecessarily people into the team just because it's they are around It's not important to add them into the meeting as Elon Musk says if you are not participating in a meeting You should just leave it and it's no problem in doing that Also, you should not duplicate roles one person should be assigned for one particular thing and that's it and Try to keep a regular energy and complete consistent energy throughout the project It's usually the case that people are very excited in the starting of the project and then after an hour They are just okay So try to keep up the energy base constant throughout the whole process Next important thing that you might be wondering is how you can predict the resources resources in prediction is very important in order to Avoid any possible delays that might happen in the future What things you should keep in mind is basically the time now the time shouldn't be Exactly calculated, but it should be roughly estimated that by when you are expected to deliver this project And by the time you start working on the project and your anxiety level goes down You'll be more sure about when the project is going to get finished off Also calculate the effort the difference between time and effort is effort is the output the time It will take each individual developer to complete a single module and the time divided by effort is the actual resource of the amount of developer time Also try to create a rough estimation of what servers machine or hardware you might be using and they should be already Kind of set up before even the deploy so that there can be Possible rundowns during the server failure or any configuration failure can be avoided on the final Also calculate and try to keep all these skills that the team needs on hand before starting the project so that they can start learning on things without any problem in the future Another thing that you might be thinking is setting up sprint Deliverable and milestone. So for those of you who haven't known the concept of sprint sprint is nothing but regular consistent work Kind of schedule in which you try to complete a particular task and you can use tools such as GitHub issues to complete particular Issues and then assign to it to a label and then completing these labels by one go And then you can use kind of burn tools like the Trello, which has been very helpful All these tools are free and get crack and timelines to measure the milestone that your whole project will be delivering these tools But what not to do while setting up the milestone is the important factor over here Don't add too much details to the sprint sort and too much kind of Individual details like how this thing should be made should be left to the users How they feel comfortable on how to create this also don't create a long sprints long sprints causes a huge chance of the project getting Don't add large number of deliverables to the project if there are large number of deliverables trying to split them into the previous print or the next Also, don't create half features Half features are not good for any of the sprint even the previous print or the next print so either add completely in the previous one or add a add completely in the next one and Don't add on the fly changes because they are the major reason which are trying to bring and to the project that you are trying People are not happy with it your developers don't understand them quickly and they won't be tested Also, don't try to be the uncle Sam who promises false deliverable time and then you can't actually deliver So be reasonable with the times and project time Now you have set up your time You have set up the every plan that you have to create now You are actually getting to start the work and this is the time where you should take care of the environment that your team is going The first thing that is very important is the team communications You should have a definitive meeting calendar and you should plan it ahead all the month calendar Whenever you are going to meet and talk about certain module It should be pre-assigned so that there are no surprise meetings coming in along and nobody can make an excuse about that Also after end of every meeting try to keep notes what have been talked about what have been assigned to someone So that they can come back and they can discuss the previous notes first before going into the next one Also create a definite communication channel that holds all the historical data all the historical Interactions that you have so that if somebody was not totally attentive We can go back and easily go through these points It's not important to only use Slack you can use any communication tool But it's very important to keep a transparency and everybody uses the shared channel of communication And if you don't then you will be missed like mr. Kim who orders something else and it causes a world crisis Just because of misunderstanding of the communication Now amateurs won't will have the problem in this thing and professionals won't So just for the neutrality of the whole talk We are going to talk about the git ritual that I've made myself So before starting any Code like whenever you start your machine and start coding for the work day First of all you should do a git pull definitely so that you know what other have worked on before you were not working on that And also after you do a significant change Let it be a new file addition new module addition try to commit it with a well labeled commit And also after every time you exit for the day or for an hour for the lunch try to push it to the git Trust me if you follow these ritual this will help you award this possible miss Price crisis which uses a git push force for everything and that causes a lot of chaos in the whole project So this is the git ritual that you can use and also as The environment that we are talking about the actual environment in which you are going to work on is as important as As all these points that we discuss So this is a photo of my workspace that I use you don't need to spend a lot of money on doing that Just take care of basics like having a nice ambient place to work With a good lighting condition good air coming in not lot of noises not lot of kids or dogs playing around Just a nice place so that you are focused on your work Dual display is a very good way to get productivity out of your setup It helps you debug things and Code things at different screens, which is very helpful instead of switching tabs Also take care about the ergonomics that you have been sitting on It's not important to spend a lot of money on just a gaming chair But a good one that has a good lumbar support and you have a good posture going on so that you don't get stressed If you are not if you are stressed and you won't be able to work and also If you have mess around that would lead to mess in your code also So just try to keep everything clean and light in your workspace and it will help you in getting through this print on the time So here are some apps you might already know about some of these apps which I have discussed in the previous one This is a quick recap of all the apps and tools that you can use Which include Trello for project planning slack for communication diagrams dot net for creating diagrams All these are three tools then you can use other the tools Ubuntu is a is mostly used for python project just because of the Compatibility that python has with ubuntu if you are a windows machine users You you have something called as linux subsystems that you can install on a machine and run Ubuntu inside windows without the virtual environment Directly like a cli command and then flask for the apis most of the things you will already know Use termics for cli client which has been very good But you can use any cli or ssh client But you should have one so that you can easily connect with the server And then jupyter notebooks to test out the code and github actions for ci cd And then a perfect ide either pycharm or vjscode depending upon your need personally I use pycharm because it is a bundle of lot of tools that you have seen inside one and their community addition is also very good Now you have created your project and now you're trying to come to the point where you are trying to optimize the So this is where you should start planning the project from the day one your project organization should be in a folder manner What I am sorry to interrupt just time check. We just have another five minutes Okay So the folder manner is a way that everything that you are trying to create a new module is inside different folders You should not add a lot of script into your main Script if your main script is loaded with a lot of things then this will lead the same example with the other project modules that you're having Everything should be enclosed within a function and main should not be bloated up with all the functionalities All files and functions should be named properly depending upon the aspect of Things that you are working on instead of just the gab and puppy names that you thought were funny to name But actually the workable things that you can name them and finally the comments formats logs Everything should be properly documented If everything happens fine, then the python won't bite you and there won't be any these kinds of hurting things occurring Okay This is a small note that people don't usually follow usually in python people install Dependencies on the fly And pip freeze is not a good way to use uh to like create the dependency which I have found Not not that good. So pip rex is a good Requirements management dependency management tools that you can use in order to create a well documented requirement or txt based on the modules that your current project is using And also try to always work in a virtual environment So that if everything goes south you are not able to understand environment You can just detach and create a new virtual environment from scratch so that it doesn't have any impact on the production And modern problems require modern solutions. So always try to find new ways to You know, kind of get around with the requirements and production We have covered most of the things and your project is working fine and everything Hope so everything worked fine. You are now on the final And this is the time where you will be thinking about how you should deliver the project So there are three ways to do that the easiest one is fpp file transmission protocol or ssh Which is the easiest way to get connected with the server But it's a lot manual and you will have to change everything manually But if your project is just in the starting stage This is the best one to go because this has the least number of complications If your project involves a lot of releases a lot of people are working on the project Then you should set up a CI series print. Now you should check out a tutorial I won't get in too much of detail about CI CD But CI CD is a way to automatically push your code from the code repository to the server with testing and everything in place And if scalability is a prime concern in your project and you have been into the all these edge Then finally the container comes along so that it can handle everything very easily and do the scaling on the fly Now this is the d-day plan which is actually run down and backward so that you don't have any Code imperfections or crashes happening while you are trying to show the demo to the boss The first thing starts with the day minus 10 where you should start creating a checklist or whatever things are left Now from day 10 to day 3 day minus 3 you should run this checklist every three days So that most of the things create a kind of a pressurized environment on the people and they started splitting the task And started creating things Which are not created yet Then on day minus 3 create another checklist with all these things that have have been And finally work one thing at a time on day minus one to check final things and on day zero plan your handle So everything starts with the day minus 10 to day And if you are a person who loves to Stay dangerously then you can skip the testing, but of course you should not do it Test everything that you have created very well so that everything happens on the fly on the production environment So a quick recap so whatever we got through the first principle is called less Whatever you do keep it less Measurable not add a lot of things you are not Microsoft or google who can handle a lot of releases at once So just keep limited things which you can easily measure Second principle is case which is keep it simple stupid in terms of your documentation in terms of your diagrams in terms of your planning keep it really simple And the final one is don't miss It's okay to miss the feature But it's not okay to miss the deadline because it creates a domino's effect for the future sprints that are going to happen So if you follow all these things you should be good And that's what I could actually create in this deadline and ironically we finished it on the time You're on time Exactly on time Okay, so briefly just just jumping on to one or two questions. We have actually quite a few So one of them was I think this was about the pip ricks. Yeah I love it. So I actually I try to cover this one So pip freeze means that if you are in a virtual environment, no problem But if you are in a global environment then pip freeze will take all the dependencies that pip has installed in your system and will Import it in the requirement or txt no matter if your project is using it or not But I found pip rex is very good because it goes line by line in the python code and try to find all the dependencies that are in inside Your whole project and then create a pip requirements Also take care about the version which pip freeze cannot it take the versions of your system And also if you have any problem, you can just delete a requirement or txt create a new virtual environment start installing them again So it's a good way to test if something won't freeze or mismanage on the production cool Thanks, Amun. That was that was wonderful. I'm not going into the other questions that are quite a few actually Maybe you could you know get on in the zulip and you'll probably you know wonderful chat with all the folks there I'll be happy to do that. Thanks a lot. Amun So to all of you, uh, we have a couple of great lightning talks lined up You could just go back and have a look at all the lightning talks So meanwhile, let me just uh put out a couple of uh banners, which might be really interesting. Thank you So guys feel free to join the banglore stream Uh, yeah, we have a couple of great talks lined up and also check out the other streams for Uh, the lightning talks, which are happening. Thank you