One of the best productivity hacks is to always keep a to-do list handy. This helps you keep a track of what needs to be done and what is accomplished. As it may sound very simple, almost all of us have struggled while trying to keep a to-do list updated and keeping ourselves on track to follow the list. We either get too busy and forget to update the list itself or take it too casually to stay on course and finish the tasks on the list. Either way, this is a failure. So, what is the solution?
Remote working is one of the biggest advantages of this cloud era - facilitated by cloud based infrastructure and the high internet penetration, more and more people are opting to working remotely. Rightly so, as an employee you get to see your family more, get to work in an environment you create yourself, 100% cut on office travel time and expenses - the list is long. Remote work has advantages for employers too - no real estate costs, no hardware, infrastructure costs and increased employee productivity!
This is the second post in the series on GitHub: A beginner’s guide. In the previous post we learnt about Git basics and some of its most important commands. Now, we will take a look at steps to create your own repo on a Linux box (with the master on GitHub). I assume you already have your GitHub account and a repo created. If not, you can do that using the steps mentioned here. Note that if you are on Mac or Windows machines, GitHub has desktop applications for both. After you download the desktop application, you can push code to your repo using the steps mentioned here. But if you are on a Linux box, you will need to install Git and then configure it to use your GitHub repo.
Today GitHub is world’s favorite place to host code - whether your software is open source or proprietary, you can host it on GitHub, choose who gets to see and contribute to your repository and be rest assured that you will have access to your software anytime anywhere. And why only code, you can even host and collaborate on other stuff like text files with GitHub. But, to the uninitiated, this looks like a huge maze with so many commands. There is also the obvious fear of doing something wrong and screwing everything up (more so because of there are others watching). In this two article series, lets take a close look at various GitHub features and when to use them in real world scenarios.
40+ participants... check, crazy projects marketplace... check, mailing list, repos, twitter hashtag, teams, permanent online conference tools... check, check, check...
Daily stand up calls in the office are almost mainstream now, everyone does it and everyone knows about it. But, on the personal front, we often struggle to manage our tasks and to-dos. It has happened to almost all of us - you forget to do something important one day and decide to create a to-do list to keep a track of all such tasks. You download the shiniest app out there, list out all the tasks, and then close the app. After a few days, you suddenly recollect - what happened to my to-do list, you flip open the app and then see that some of the tasks listed are already obsolete and it has almost become a task to update the task list itself. How do you make sure your to-do list is updated with your day to day activities? How do you ensure the tool you use complements your day to day life and is not an obtrusive addition to your already hectic schedule? How do you make sure the to-do lists actually help you clear your mind and improve your productivity?
Continuous integration is an integral part of an agile setup. Sprint after sprint teams strive to “not break the build” while delivering incremental features. But, while developers focus completely on adding features, it happens sometimes that code errors creep in and render the software unusable. To stop such errors from being integrated to the SCM, a CI server is the gatekeeper that helps keep a tab on code quality. Even if the code is integrated to SCM, a CI server can very quickly tell you what went wrong.
In recent years, agile went from experimental new technique for project management to a mainstream project management philosophy. Almost everyone is doing Agile now - even outside of software development.
If you have read the agile manifesto, you’d have definitely noticed the second line “Working software over comprehensive documentation”. So, what does this mean? No documentation at all, or few documents here and there - just for the sake of it! I am sure, you’d have faced documentation related problems somewhere during a project. Take this scenario for example - there is no documentation for a particular module, and no one has the time to explain it to the new developer who just joined. Now, you have boatload of work to be done (and so a new developer) but new joinee can’t work (at least not very fast) because no one is free (remember the boatload of work) to tell him how to work. Of course, you followed the agile manifesto - but what about such situations? They surely deserve to be nipped in the bud, and so, it would have been great to have some documents to help the new joinee here. But, the problem here is of sheer pace at which teams work, they forget and sometimes even ignore documents because that is not in the tasks list.
Let me confess - I am a newbie to the world of Agile. During 5 years of my career as a software developer, most of the time, I have followed the more traditional software development methodologies like waterfall and incremental development. It was recently that I joined a new project with dev teams in multiple locations - and they followed Agile. It’s been five months now, and I thought it is the right time to share whatever I learnt in these 5 months.