MUGOYA DIHFAHSIH

Splendid! Yup, this is me working from a bathtub. But let me get back to the beginning. I work for Automattic, a 1000-person company spread across over 70 countries. My colleagues are around the globe - some of them work from a camper, driving across Southern America, some of them tried catching an internet connection from a cruise ship and majority work from the comfort of their homes. If I had to summarise remote work in a sentence, it would be: It just makes sense. When you think about modern office work, it is a bit peculiar. For lack of a better example, let’s imagine Facebook: Now here is a company that says you can foster real relationships online. They create a product focused on communicating with your friends, and they even sell (and use) a version of it designed for work. And yet, they force people to pay truly mind-boggling Silicon Valley rent, sit in traffic and get into the office to sit in front of the computer. If your work happens on the computer,

This book of the law shall not depart out of thy mind and l aptop ; but thou shalt meditate therein day and night, that thou mayest observe to do according to all that is written therein: for then thou shalt make thy way prosperous, and then thou shalt have good success as a developer . 1.  Thou Shall Ask For Help (  Be ye your senior/junior, don’t be afraid to ask  ). 2. Thou Shall Collaborate/Pair Program Often. 3. Thou Shall Be Empathetic to Other Developers. 4. Thou Shall Have the Knowledge that it’s Okay to not know Everything. 5. Thou Shall Acquire the right tools for day-to-day work and try to gain mastery in it. 6. Thou Shall Be very Confident in thy Abilities. 7. Thou Shall Be Very Formidable in Decision-making (  Your Clients would bow at your feet  ). 8. Remember Version Control and Keep it Holy (  Use Highly effective version control systems for all your projects  ). 9. Thou Shall not be Discouraged by the Successes of other Developers and How much Know

Choosing the right source control platform for your team is one of the most important decisions you’re going to make. There’s a good chance that you’ll choose Git for the version control software (VCS) itself, but the platform where the code lives is equally important. Many times, it comes down to Bitbucket vs GitHub. Over the years the two have grown strong communities and userbases. In this post we want to take a look at both platforms to see which would better serve your development team’s needs. GitHub vs Bitbucket: The Basics If you are a newcomer to Git, GitHub, and Bitbucket entirely, you may want to have a look at  our beginner’s guide to Git . It will walk you through the fundamentals and get you prepped for understanding just what is going on in this article. If you boil it down to the most basic and fundamental difference between GitHub and Bitbucket, it is this: GitHub is focused around public code, and Bitbucket is for private. Basically, GitHub has a huge open-so

Basically, the schools of thoughts are: Imperative (a.k.a. present tense) Should read like: Make foo do something Git uses the same imperative style and it shows when you do merges with commit messages:  Merge pull request #666 in kek from lord It tells someone what applying that commit will do, so it should read something like  If I apply this commit, it will [make foo do something...] More concise Past tense Should read like:  Made foo do something People reading the history tend to think of it in past tense…because HISTORY Reads more like a diary:  Last <insert date here>, I made foo do something.... Saving a couple of characters doesn’t matter much as long as it’s still easy to read The list goes on and on and the debates tend to go on forever, but I for one have seen both sides. I think it really depends on team preference — there is no right or wrong answer here. What matters is consistency. The team should agree on a convention and stick to it. Per