Product Management: Tools and Tips to Optimize Your Workflow as a Developer

1. Introduction: Our world has changed. We are working differently right now and a lot of engineers have a problem getting their information heard and getting the information documented. Hello there. I'm Chris Heilmann. I'm a Principal program manager, but I used to be a developer for over 20 years. I've worked in the last 10 years from home with distributed teams all over the globe. Today, in this course, I want to explain to you how to optimize your workflow as a developer to be understood and to work easily together with people who are not in the same building as you. As a product manager, my main job is to make sure the product succeeds. That means I have to think about how it grows, how it actually works, and how it can be delivered in a certain amount of time. This means I have to get my engineers to optimize their workflow and give me the information that I need without me having to be somebody who's working on the code all the time. In this class, I'm going to talk about a few things. First, I'm going to talk about how to set up your machine to make sure that you actually not make mistakes that are avoidable. Secondly, I'm going to talk about how to change your setup for the new world that we live in right now. Because most of the time, we're not only developing, we're also being in meetings, and most of them are video meetings, so that's something we should consider, how to actually make ourselves more effective that way. We're also going to talk about version controlling, making sure that everything you do will be actually retained somewhere, and you cannot make mistakes and cannot get things lost out there. I'm going to talk about online collaboration, how you can actually build things that other people can collaborate with and they can work on it while you're in bed or you're not being available at the moment. We're going to talk about helping others how to document and promote your work. How you can actually get people access to what you do, so they can start the documentation and also tell other people about it without actually having to be part of the process all the time. One of the skills I hope you can take away from that is communication. Because I found in my career that no matter how good a developer you are, sooner or later, it will come down to the soft skills to make sure that people understand what you do, so people can give you the information that you need and the opportunities that you need as well to succeed in your career. One of the things I learned most as a developer is that my code is not the most important thing, but how I bring it to people, how much information I give around my code, and how I allow other people to do their job based on my information is much more important than the code itself. That's something that was hard to swallow for me as a developer because I love coding, but at the same time, it made my career. Hopefully, it will be a skill that helps you better as well. I'm excited for you to take this class because I want the next generation and the new generation right now of developers to start embracing the new world that we live in as well. It's not that we're actually sitting in an office next to a senior developer anymore and learn everything from them. We're are all distributed and we're all working in different places, and this is a freedom we actually fought for and we should embrace. It's a great opportunity for you to be somebody that's easy to work with, although they're not physically present, and that's something that you can learn in this course. In this class, we don't have one example in the project gallery just to copy and learn from. It's something that should inspire you to do the same thing to your code. You're going to learn about different things that you can do to it to make your code easier to contribute to and easier to understand for everyone out there. So take a look at it, what I've done, disagree with it or like it, and come to the discussion board and actually talk about what you have learned from this class and what other things you have found that we missed out on. 2. Avoiding Mistakes While You Develop: In this lesson, I want you to rethink what you do as a developer, if you're actually need to be the person to know everything or if you actually can be the person to know everything, or if it makes sense to actually embrace modern tooling to take some of the knowledge away from you because you don't need it at that moment, but you only need it when it's necessary. I'm going to talk about the subject that I'm more comfortable with here right now and that is web development as a general rule. I've been doing that for quite a while, and I thought I was a total expert in it. That's why I was always going back to the development environment that I felt comfortable in. I always thought like I only need a text editor, I don't need any fancy things, I can go to any website to look up information, and then I realized I'm wasting a lot of my time doing that. I'm wasting a lot of time accumulating knowledge in my brain that actually I don't need to have because some good editor could do that for me, and I'm going to show you right now how to use Visual Studio Code, and one plug-in that actually helps you doing these things in one go rather than having to know the knowledge, or having to be the person that knows where to look on the web when you're doing something wrong. Now this is my editor here set up in Visual Studio Code. Visual Studio Code is an open source editor. It's probably the most used one out there right now. It's the biggest GitHub project and most likely you're using it as well. What you might not be using yet though is a plugin called webhint. Webhint is an open source project that allows you to validate your web projects according to different issues. Like, it could be performance, could be compatibility, could be validation and accessibility. Webhint and itself is actually a service as well on the web, or it's also an NPM project. If you don't want to use the thing like I'm going to show you in a second in Visual Studio Code, you can also use it in your project as an NPM module and as part of your rollout. Before you actually put something into your main core, you can actually run a webhint on it, and that way do the same validation that I'm going to show you live right now on the project before you send it off to your colleagues and get it back that you did something wrong. The great thing about webhint in Visual Studio Code is that it's independent of language. It covers all the things that you do for the web. It covers JavaScript, CSS, and HTML. In each of them, when something is going wrong, then it actually puts some squiggly lines over it. If I move my mouse over it, it tells me what is going on here. In this case, this is something that's not supported by Internet Explorer, Safari, and I will now make the decision if I can still use it. But this is something that I can send my tester when I'm sending the project out there and say "This project doesn't need to work in Internet Explorer, so please don't file it back and give it back to me." I already know that this is an issue, even if I didn't know that these browsers don't support it. The same way when I go to any of the other languages, when I go in JavaScript for example, and I don't remember how something works. If I go for example here and say donations and addEventListener, and I don't even know what it does. All I need to do is open a brace and then it gives the explanation in context to me, what I need to know. When I was super proud to know all these things I realized, I'm using a lot of my brain power for things that are unnecessary because a good editor would allow me nowadays to give that information to me and give me the auto-completion with just one tab, instead of having to know it. When it comes to HTML, it actually does give me a lot of accessibility problems. if roll over it explains to me what to do, and if I open the panel to get more explanations or even learn how to fix it directly in my editor. Why do you embrace this idea right now? We have all this technology, we have all this knowledge of dozens and hundreds of developers that went into these linting extensions may it be webhint, may it be ESLint, CSSLint, JSHint, all the things out there. If you look for extensions or Visual Studio Code, you will find a lot of things that make you not make mistakes before you send them off to other people to look at. You don't need to tell people that it was the machine that knew it, you just didn't know to know it anymore and you can use your brain power for better things. 3. Setting Up Your Optimal Environment: In this lesson, I just want to talk about your environment a bit. I want to talk about a few things that you should actually spend a bit of money on or try to get your company to spend money on for you, to make it easier for you to collaborate with people outside your house, and that you don't have to go to the office to talk to each other. This means setting up your environment to use, for example, two screens instead of one, but also making sure that you can actually record things and communicate with people while you're working. I used to be a person that only used a laptop because I was coding on the go all the time and thought is was the only thing that I needed. I learned that with the new environment where I have to be on video calls all the time, and do my coding, and my testing, and all the things at the same time, having a second monitor is a really, really good investment. The main thing is that I'm changing my courses here. On this one, I still have my coding editor open, I still have my Git Workflow open and these kind of things, and there is I do all the things that I need to be doing at the same time, like documenting them, having all my calls. By having this here, having my Zoom calls, having my Team's calls on the other monitor, and having a camera on top of it, I also look people directly in the eye rather than being the person that types away on something, [inaudible] and they hear me doing it, I'm actually part of the meeting, I'm at the same time being effective doing the things that I wanted to do. Another big investment is something that is called headphones. Despite the weird sounding, but it's actually really important in meetings that you're not the person that actually uses the microphone, that is in your computer while you're typing away because they're super distracting and you don't want to stop typing just to say something. Just getting a distraction-free headset for people out there is a wonderful thing to be more effective in your collaboration with other people. Another thing I keep doing is setting up different profiles, both on the operating system and in my browser as well. The reason is when I share something with my colleagues, I don't want all the other work that I'm doing to interfere with it, like, some editor updating in the background when all I'm doing is a video presentation of what I've done before. Make sure that you're actually having different setups in your machine that only show what's necessary and things that you don't want to share or you shouldn't share, should not be visible. Having a different profile in browsers and having a different profile in operating systems, is a very good way to make sure that you're only showing people what you really want to show them, and don't get any distractions to surprise you. What can you do about this? The main thing is, think about different profiles in your settings. Think about what you want to actually share with people, and if you can get a second monitor, even an old one will do, it's really, really a good thing to have in this world that we live in because you want to separate your workflow as a developer from your workflow as a communicator with the rest of your company. 4. Version Controlling Everything: In this lesson, I want you to embrace one thing that saved me so many times. That's going into a version control first mindset. It's very easy to just start a new folder on your hard drive and just start coding and you're building something. Then anything can go wrong, your machine could die, your hard drive could die, and then you actually lost everything. Furthermore, we're actually messy when we do this things. You probably have one of those folders as a developer where it's like final version. Really final version this time I mean it v1, v2, five zip files with all the code in it. Version controlling helps us work around that issue much better because it only takes the Delta of the changes and allows us to go forward and backward and undo things that we've done wrong and go back to a certain stage. Embracing version controlling upfront is a very good idea for not only collaboration with other people because that's the second step of version controlling. But just making sure that you never lose anything any longer. This could be as simple as using the Dropbox folder for some of your documentation because that can go back to older versions of it as well. Or OneDrive folder or whatever you want to use Google Drive, there's many out there. But it also is mains for me most of the time when I start a new project, to start a new Git project every single time I create something. This also forces me to actually make sure that the code that I write is good enough before I actually put it up onto GitHub or somewhere else. Of course, you can use a private Git repo as well. But it's something that actually makes me better as a developer because I collaborate upfront rather than just doing things in my own little darkroom and nobody needs to see it. I realized that my code has to work because somebody else would take a look at it later. That to me is the whole idea behind open source as well. You might as well start collaborating with yourself by using version control upfront. I was very proud to be a person that knows everything about Git on the command line. Whenever I actually created something for Git this was my environment. I just went to the terminal and I did everything there. I also realized that this is a cool thing to do and gives you a lot of power because I really embraced it much early on, but nowadays we have better ways of doing that. When I start a new project nowadays, I actually just create a folder, and then I jump into the GitHub desktop client. The GitHub desktop client has one benefit for me as well. It shows me that I'm actually using different repositories and actually what project that I'm working on, and it shows me the state of them. You can see for example here an extension that I'm working on that it asks me to download it first. About changes that my colleagues have done that I normally would miss on the command line. This is a very simple way to get started and make sure you don't miss out on something, and often I had to do a Git stash and find out all the problems that are going on with my Git repository by doing it on the command line. But by using the desktop editor I realized right now there's changed files and that I need to pull from origin. If I pull from origin I get all the information in there. Then I can go back to the project itself and actually open it in my editor by choice and then start from there as well. In Visual Studio Code, there is also an inbuilt Git workflow. The really cool thing about it is if you take a look at your file explorer here, you not only see when I talked about weaponed earlier, which ones of those have problems. But also the things that I changed. When I change something and it has emerged here that I need to do something to send it back to the repository. I can go to the GitHub workflow and actually just type the command there and merge it. I don't need to keep track in my head what I had changed, but I can do that directly from my coding environment. If you're not into Git yet and you don't want to actually learn too much, take these powerful tools because it will get you into the power of Git rather than having to have all the knowledge. If you're already a Git expert like me, it might feel like cheating, but it actually makes me more effective. What I want you to do right now is not only think about that version controlling is something you have to do for work. But something that actually saves your backside if you do it the right way. To make sure that you're actually building something that you can't lose. If you're actually going away for a few weeks and come back to the project, you can actually get started again where you left off without having to worry that some code went way. The best thing to also do before you stop your work of the day is to make sure that all the version controlling stuff that you've done goes back to the repository, so your colleagues can actually see what you've done and work with what you've done without having to wake you up or send you an email. 5. Using Online Collaboration: In this lesson, I want to talk about online collaboration and how to make sure that people can see what you do and maybe help you out quickly how to fix problems in it. This used to be quite a task. You had to have a server or you had to send the code to people and they had to run it locally, which caused all kinds of problems, but nowadays with using free services, it's much easier to do. I'm using two things to get people to collaborate with me and find out what I'm doing and give me information about what I could do better. That is GitHub Pages and is CodePen. CodePen is a free service. GitHub Pages is something that comes with your GitHub repository and you might not know about it yet. Let's take a look how to actually set that up. The first thing I want to show you is what CodePen means. In CodePen, I can actually just get some quick example for people to show what the problem is. The other day a colleague of my wanted to know about Fetch and actually train some API out and get some him and didn't know what to do. I wrote this little example here for him. You can see that there's a few lines of HTML and you don't need to HTML construct around it, you can just write the HTML, that you want to have a bit of CSS and the JavaScript showing what the Fetch API can do. As it's the Fetch API, I used an API that shows dog pictures, so every time you click on it right now you can see a different dog picture. That's just was I wanted to do it for myself, but also to explain to my colleague how to use an open API like the dog.ceo/api in this case to play around with it. The great thing about CodePen is that you not only see the code, but you can edit it. You can embed it into other systems like blogs, or repositories, or anywhere you want to show it to other people, and it comes with a really powerful editor that does code completion, color-coding, and all the things that you want in there for free. You can sign up for it to get some more extra features, like you can become a presenter inside CodePen and so on and so forth. But there is just out of the basic free module, you can do a lot there to actually just show people that something is going wrong. It's so much easier than writing a long description of what is going on or what's the problem. Just cut down the problem that you want to have help with to the smallest amount possible, and put it in a CodePen, send that to people, and they can start forking it, editing it, and sending it back to you. Another big benefit of using something like CodePen is that you can actually use setups. If you want to use SaaS or something like that instead of CSS, you can set that up in that environment as well. You don't need to send a SaaS file to one of your colleagues and say like, "Here's how you set up SaaS and make it work," and lose a lot of time that way, but you just send them the CodePen and SaaS is automatically executed for you. This is a very powerful way just to get collaboration going. If you're using GitHub to host your code, you already have to source code in there. That's something that's easy for people then to for example, download a zip file or fork it and do something with it. GitHub also gives you GitHub Pages and it's something that you do in the settings. In the settings, you can scroll down all the way here and there you have GitHub Pages. You can see that for example, the repository I have here right now, is published at this repo. People can not only use the source code, but can also go and look at the different pages of it. In this case is a page with errors, and you can take a look at the code, how it runs in the browser. You didn't need to actually send that file to somebody else and hope that they have their computer setup properly. GitHub Pages does that automatically for you and you can do it for any branch in your Git repository. That's a really powerful way to get people started. Another thing that GitHub comes with, which is really interesting, is that it actually tells you to do the right thing. In this code repository right now, I only have code. I didn't have a read there that explains to people how to use the code, what to do with it. It actually asks me to put a README file in there. I can click on that, create a README, and I can just start writing a README file. Good repositories, like another one that I have for one of my code examples here, give me a screenshot, give me explanation what the thing does and how to use it. This is something that comes for free if you host your Git repositories on GitHub, and it's something that's quite easy to set up. Why don't you try it? Go to CodePen, try out something there. There's a great gallery of what other people are doing, so you can learn a lot from that as well. But try out the editor, set something up, an example that you always wanted to show a colleague, send them the link and then discuss together what you could do and let them play with it. Embed the CodePen in another product like in an HTML website or into your blog if you have one, it's a great way to show the world what a certain feature does before they actually want to try it themselves. When it comes to GitHub repos, make sure that you have a good README on all of them and actually use those GitHub Pages. Because if you just see something in action, it's so much more powerful than just getting the code and trying it out yourself, and you will stop people asking you a lot of questions because they see it should work. 6. Helping Others Understand Your Work : As a developer or a designer, you're not the only one that works on the project. There's people like me that have to document what you're doing and show it to people upfront, although it's not ready yet. This is a problem because I cannot access the code that you have. I probably don't have the environment to run it in. Your task would be to do a screencast of it, record something, send it to me, and then I can talk to people about it while you're still developing it. Back in the day, it was hard to do a screencast and do a narration over it, but nowadays most operating systems have something built in that allows you to do that. Don't worry if your narration isn't perfect. This is just about getting the information out there. One of the simplest things I've found is an extension to the browser called Screenity. This one is just an extension that accesses your camera, accesses your microphone, records the screen and creates an MP4 from it. It also highlights where you click on things. You can narrate things, you can actually highlight things and scribble on them. It's quite powerful and just an extension for Chromium browsers that you can use. Another one that people are using is OBS Studio, that's for all platforms as well. It's meant for game streaming, so it's daunting to look at. I myself, don't get around it as much as I want to be, and that's why I need you. Please go to the discussion board and tell us about things that you're using for screencasting that made you effective, that made it easy for you. I have a few ideas, but I don't have all the ideas. You might be on another platform. So please share with the other students what you use to do your screencast. Don't forget one screencast can save you a lot of emails back and forth explaining how to run some code. 7. Final Thoughts: That's the end of this class. I hope you learned something today to make you a better colleague to work with. Somebody who is not in the same room, who is not on the same skill level, and actually gives us information that we can work with. This will sooner or later be a boost to your career. You will be known as somebody that people can work with, not somebody that works for somebody else, and not somebody that expects you to understand their code and have their setup, but somebody that gives you information to work with, to document, and to talk to other people about. It also means that you're actually embracing technology more than you did before. You don't need to do everything on the command line, you don't need to know everything, tooling has come a lot since the first days of our development days and it makes sense to actually embrace the new technologies. Thank you for watching. I'll see you in some version control system nearby.