What eight years of side projects have taught me (2019)
What my years of side projects have taught me:<p>* At work its better to hurry than get anything done.<p>Regardless of language if you work for a company of greater than 1000 people there is a certain nearly identical way of doing things.  This way of doing things is based upon a combination user platform, quantity of developers on the market with a particular skill, and a need to pretend to be busy even when you don&#x27;t actually accomplish anything.  In most of my experience the platform was the web and the language of choice was Java (even though Java is not a web technology).<p>When you are working on side projects there are only two goals: don&#x27;t waste your own time and produce something of value.  Nothing else matters.  And so you learn to become very productive and extremely focused on what you ship to production, because you would rather be playing games or drinking a beer than pretending to be busy.<p>The corporate world doesn&#x27;t work like this.  Everybody is paid a salary exchange for 45 hours of your life each week and your assignments are generally governed by an agile sprint cycle, so there is absolutely no motivation to be productive.  Maybe if you work twice as hard your bonus will be 5-10% bigger.  Maybe if you deliver code that is perfect in that it never requires maintenance and never churns defects you can spend more time reading about foreign places on Wikipedia.<p>Frustration sets in after watching the corporate approach continuously releasing defective code into production because its important to hurry instead of write things down or write the code correctly the first time.  You could always suggest a better way of doing things, but since there is no motivation to do things better all you are really accomplishing is frustrating other people.<p>* At work don&#x27;t reinvent the wheel (if somebody&#x2F;something is capable of doing your job then let them do your job)<p>When you are working on side projects there is nobody there to do the heavy lifting for you.  You can figure it out or it simply isn&#x27;t important enough to get done.  It&#x27;s the same way with risks and product performance.  People who haven&#x27;t spent time on personal projects or with equity at a start up have no motivation to try harder.  That is why there are giant frameworks and a couple 1000 open source packages in your corporate application to solve simple common problems developers are unwilling to solve themselves.  Nobody working on a public personal project will build around something like the 1000 ton hammer of the gods that is Angular or Sprint MVC, but you will certainly find these in public facing enterprise applications where developers have no care about punishing their users in exchange for easy.<p>* You are more productive not doing work<p>A tremendous part of writing software is the cognitive thinking that occurs away from the keyboard.  This could be planning, brainstorming a new feature, reflecting on a past feature, or putting things together in a new way to envision defects or refactoring opportunities.  That said, its more valuable to work really hard to accomplish a feature or solve for a defect and then back off from the computer.  You haven&#x27;t stopped thinking about the application, but now you are thinking about the experience or new ways of doing things that you would never think about purely looking at the code.  In the corporate world you are extremely lucky to find documentation much less anything like planning or feature engagement from the developers.