Hello and welcome to my talk. I'm going to be sharing a bunch of anecdotes that encouraged during my last decade of development. And there has been a bunch of crazy stuff, mostly due to myself. First anecdotes in the series that I chose based on no order whatsoever is how I learned to do Linux administration. Basically it was the middle of the night, which is a perfect time for doing any sort of administration Linux production servers. So I wanted to delete some stuff. It was in a separate directory and normally I'm going to delete it with using pseudo privileges. So pseudo remove recursively everything under slash. Now for those not so versed into Linux as I was that moment that deletes everything from hard drive. And good thing is some things stay in memory. So there exists at a brief moment in time there was absolutely nothing on the hard drive, but website was working after 30 seconds. Once the realization hit me about what I just did, I had to boot up the new server, install all the requirements, do got deployment, set up all permission, check if everything is working correctly, and dont DNS server to that. Now that woke me up very fast. If you want to switch from Red Bull or coffee, I warmly recommend deleting production servers. That's going to wake you up very quickly. And I remembered almost everything from stack orderflow that I googled in that panicked moment. So that's how you should start your morning now. Another crazy stuff that I did was basically using text editor for the development. I know there are some super smart people, they can do text editor for development of complex programs, but myself am got among them. I love my autocomplete, I love syntax checking, all that stuff. So using Notepad, notepad Plus, but just notepad for the first two or three weeks of my career was not a good choice. To make it even better, I was doing basically had one file would write into it, then FTP uploads to the production server because what else? And if I managed to mess up the PHP syntax production site would crash. But that was okay because client was in USA and you would not notice that. So develop in the completely opposite time zone of your clients. That's a very good lesson if you're going to use production server for your testing purposes later. I did realize how you can create your local environment and why you should have a staging environment and dev environment when it comes to that. Things that I learned after that is version control. That was super amazing stuff that I discovered before entire mankind. Since what I was doing is every time I would upload a file to production server using FTTP. I would just make copy of that file with a timestamp and that way I could return to it later if there was need for that. I was watching YouTube at the time and I saw somebody talking about version control and I realized this cool, be good. I started using it and it was super fun. Then I think it was two years after I realized that branches existed in git and after that everything was super awesome. Another thing that is super useful is you should always try to be the smartest person in the room. That way everything you say is absolutely correct, no matter how insane it is. Since we were working at the startup in the first company we didn't have lots of resources, so we hired a bunch of juniors and me with my six months of experience was leading them technical disaster in all the possible ways. Seniors are expensive, but they are less expensive than juniors. Try to have a mix of them and company culture is important. Also, I realize I can be pretty stupid at the time, so I need somebody smarter to tell me when I'm making crazy stuff. Now that first startup was done, I realized, okay, in the end we managed to create something good because it was a search engine, it had some super good performances and you could get the listing from million track articles in less than 15 milliseconds. With the solar that's super good. Now design was created by me in the first version, which means that everybody who visited that website started bleeding from the iris. But later I hired a designer. That's probably smartest thing I did at that point, and website looked pretty good. Now why did that website or startup failed? Well, after one and a half year we realized we do not have any sorts of monetization plan. So before you start working on a project or a startup, figure out how you're going to make money. That's one of the things that's pretty crazy to me today because for most of the Silicon Valley companies, their business plan is we're going to get zillion users, then we're going to get funding, then we're going to got acquired. Myself, based on my lessons, I love to get business plan early, see how I'm going to monetize this project. It doesn't mean writing 50 pages of business plan, but I need to know how this thing is going to make money and focus on that. So with that in mind, I decided we should start the second startup. Now we are all smarter and super good. Same team and me. We decided we're going to make social network because it was 2012 2015. You can check on my LinkedIn profile. I do not remember the years, but social network movie came up and our main investor really wanted to make social network and we were all very excited. Now since social network was very hype at the moment, there was also another technology that was super hyped and you know what? That was NoSQL. Normally we started the project with MongoDB and everything was super good because we were ready for a web scale. Two years later, I did realize that majority of the code I have written related to communication with database was to turn it into relational database. So that's my lesson to you. In 95% of the cases, relational database is perfectly fine for you. You do not need to jump straight into NoSQL. And when you do, you need to know why are you jumping into NoSQL database. Do not be afraid. Relational databases are good. I can assure you I've been working with them after I learned my lesson. The second lesson that I learned during that whole trip is dont get hype driven. That second startup was pretty amazing to multiple factors, mostly because I learned how not to do things. Our main investor, he loved having meetings because those would inspire us. So every day we had hour and a half meeting where we would listen to speeches and get super inspired and get motivated to work whole day. This is not me making fun of my clients. This is me telling you how I failed to communicate and manage that project. Today, I would not allow client to hold that many unproductive meetings that had absolutely no point. I would communicate better. At least I hope I would communicate better to a client that his time can be spent in much more productive way. At that point in time, I did not know how to say no to the clients, because sometimes you need to say, this is not working. Also, we worked on that project for a year and a half before actually getting to our users. Now that's another lesson that's very well done, because once we release it, we release. Nobody's going to use this stuff. And always talk to your users, see if they want to use that crazy thing you're building. They may want to, they may not want to, but talk to them because you want to fail fast as possible. Less money spent and more you can focus on something else. And another thing is talk to your team. I did not communicate very well with my team. One time I decided to speak with each of the team members, 15 of us. And what happened is I just asked him a simple stuff, what are we making? I got 15 different answers, myself included in those, they were not even the similar. Everybody thought we were building the different thing. And I can assure you that product looked absolutely schizophrenic and was unusable. Now, after that, I started doing consulting because it should be less stressful than developing your own product. And I had plenty of python architecture skills. I encountered some very interesting clients. Sometimes it would be nontechnical client. Those are very difficult to work with because what you need to do is establish the trust between you and them. Basically assure them that you are not trying to steal money from them and that you know how to do your work. Almost all of the time you're going to be asked to send a proposal, and that proposal is going to be beautiful. I know that because I believe in each and one of you. You make beautiful proposals. Client is going to go over 20 pages of that proposal. It's going to ignore completely everything else. So what I learned during that is that you need to talk with your clients before sending them proposal to figure out what's important to them. Is it just the pricing? Is it quality of the work? What are their biggest fear? What problems are they trying to solve? Because sometimes clients just want to try making something and sometimes the project they're wanting to build actually requires bunch of expertise from their side and is critical to their business. You need to differentiate between those two. Based on that, you can make your proposal. I can guarantee your proposal is going to stand out once you've done your research and figure out what exactly client wants, than if you just send them the proposal. If you just send them the proposal, it's going to get ignored. Because if you got your job or contract just based on the price, there's always going to be somebody who can do it cheaper. Now, another anecdotes. One time we were building a simple video player and client was pretty successful in his business, decided to bring more innovation into our product. So I asked him, okay, what sort of innovation? He said, don't you think that majority of players are just one dimensional? I said, okay, what do you mean exactly? You can move backwards and forward in the video. How about we make it three dimensional? Okay, so you can go backwards and forwards in the video, up and down, could handle the volume. And what's the third dimension? You can go backwards and forwards. So I thought to myself, what's the third dimension? You can control videos. Would that be something else? However, client had very much confidence into me and told me, you can figure it out. Now, I spent about two weeks trying to figure but how to create the player controls that would work in three dimensions. And when I figured something out, I talked with clients and he already forgot. So don't be afraid to tell clients that they can be a bit crazy or let idea slip for a bit, because that can happen. Now, the most interesting type of clients that I encounter are clients that have friends that know something. Basically, they would get friends to tell them what's good or not. In my case, since I love doing things with Python, I would make a proposal for writing entire website in Python because I know that stuff. The client would ask their friend and they would tell me, yeah, but their friend says they're using Java in their company, so Python is no good. And I was like, okay, but you can write website in. No, no, they're not using Python. Well then you need to find, no, no, no, we want you to write in Java. So after back and forth asked to speak with their friend and they told me, yeah, you can write stuff in Python as well. Sometimes it pays to talk to the friends of the clients that are giving them awesome advice. Sometimes it just pays to pass on the project. And one anecdote that every designer is going to tell you is the moment when their client's child told them that a logo design is not nice and they need to change it. Luckily, since I'm backend developer, nobody ever gave me a compliment and told me, oh my gosh, your backend code is so beautiful. Most of the time what they tell me is, okay, it's working or it's not working, fix it right away. So that's what I do. Ash, I'm sure most of you have come to hear the story about nuclear silo and Python development. Well, at the peak of 218, when blockchain was all decraised as it is now, client decided to create a new blockchain and they invested a bunch of money into that blockchain. So one time, since I was a contractor and I was the most expendable person on the team, but sadly, I was the only person who knew the entire back end because I built it. I was also the person who could not be easily fired. So they put me as a sacrificial lamp to hear an idea from the CEO because nobody else could say no to him because they would get fired. I said, okay, I know something crazy is going to happen, but let's hear it. CEO starts telling me, okay, since we are developing this blockchain and it's going to got super popular, what we should do is basically buy a nuclear silo and put our servers there move everything from AWS to nuclear silo, and that's going to be super secure. And I was thinking back a little, because my first question is, you can buy nuclear silos. To which my response I got, yes, they're selling decommissioned nuclear silo for just 800,000. For me, that's a super good deal. I don't have that kind of money, but if I ever wanted to buy decommissioned nuclear silo, that's a super good price. So I tried to explain to a client that that's not how computer security works. AWS has a good security system. You just need to configure it. And we had a bunch of back and forth, and then I realized I'm using technical language. So I explained to him that using nuclear silos to secure your blockchain servers is the same thing as buying a dog and putting it next to your computer to ward off the hackers. And that worked. That metaphor solved everything. We did not buy the nuclear silo, which is super sad because I cool have worked on nuclear silo project, but can't have everything. And what he didn't mention that meeting, which I probably should, is that security and nuclear silos were not the biggest problem on that project. Problem was that nobody was using that blockchain. It was pretty much useless. So, lesson for everybody. Focus on project market fit, get some users, then try to solve problems in that area. And another client wanted us to write a file system for a website that was basically a marketplace. And I asked him why, and he said, well, Google and Facebook, they all have proprietary technology. So that's AWS. We should have our own proprietary technology. So let's write everything from the start. When client asks you something like that, then you know you're going to lose a bunch of times. So what they did is just make an estimate how much it would cost to reinvent a file system, how much it would cost to rewrite entire database from zero and stuff like that. And he realized that for his $10,000 web store, he did not need custom file system and database, and all was good. One thing I realized pretty quickly is that I have no idea how to do design. Because this goes way back into the time when I thought I actually can do design. Now, I'm not sure if you remember, but in the time of dial up days, Flash was all the craze. So I created a website that had five megabytes of Flash file that was always playing music and animation on a web page. And you could not stop that music. And I was super impressed because I was 16 and that was my first website. What was crazy to me is while I was getting so little visitors, oh my gosh, this works super fast on my local machine, but when I tried to visit it from my friend's house, it turns out it takes 20 minutes to load it up. Yeah, I would like to say that I learned the lesson, but as you already know me, I did not. I just left that website because fault was my friend's computer, not his Internet connection, so it was just him. I did try to find that website several years ago, but it's gone. Probably for the best. Also, one of the good things I learned is that I have no idea how front end works because in the olden days before the Javascript alien had a debugger, all the synchronous stuff, all the craziness that was happening there. Internet explorer six, that's all I'm going to say. That was super crazy to me because I love deterministic behavior as people say. I don't hate front end, some of my best friends do front end and my younger brother, he does front end and he's super good and he writes tests for front end. I'm probably only thing I can write in front end is background red in CSS. So learn your limitations. Learn what you want to do and what you don't want to do. Because at the end of the day at this job, you're going to be working it hopefully just 8 hours per day. And spending all that time on something you do not like and do not enjoy is not worth it in the end. Also, let's see, I probably have some bunch of cool anecdotes. Oh yeah. When I had a cool idea about got having a set work time, like when I said to my team, you know, we are super organized and we were all junior developers, we can work as much as we want as long as we finish our tasks. So if you want to work 2 hours per day it's perfectly fine. If you don't want to work Monday or stuff like that, perfectly fine. What happened was utter chaos because fronted was waiting on design, back end was working on something that was obsolete and stuff like that. What happened after that is at one point I realized we were working 14 12 hours per day. I don't know if you ever done that, but that's soul crushing to say the least. So after that I went back to hang regular hours. It worked fine. Like you don't need to reinvent the wheel. I'm hoping you can get it below 40 hours because I'm going to say this on the programming conference, but personal life is more important than your programming skills. I spent last decade programming, and most of the stuff I remember happened outside of programming. You deserve to have a life. Yeah, life tip and I think that's all the wisdom I have to show for at the moment. What I would like to do is had something super crazy and super amazing happen to you. Please share with me. You can reach me on LinkedIn. There's probably going to be link in the description or somewhere else. I also love having virtual coffee with people. I met all sorts of amazing people on Internet. So unlike what most people tell you, Internet is full of nice people. Thank you very much for listening my talk. I hope you enjoy it.