For me, there have been two items in “Atomic Habits” that have immediately made a difference in my life.
The first is in Chapter 6, under the heading “The Context Is The Cue”, the understanding and the realisations following my reading that our habits can be associated not with just one single ‘trigger’ but with the ‘context’ that surrounds a behaviour, have changed my day to day actions.
The second is in Chapter 7, on how ‘disciplined’ people structure their lives in such a way that they do not require huge amounts of willpower and self-control; has caused me to change a number of small things, and this has made a large impact for me.
Implementing these two things into my life have not required any ‘rocket science’ on my part, just some simple changes. Those simple changes have made an immediate, positive difference in my life.
James explanation of these two things, the examples he uses, have made sense of why, in the past, some habits have stuck for me, why others haven’t, and why certain habits I’ve tried to change or remove haven’t changed or been removed.
PS. rest of the book is great, but those two things are what made the difference for me.
It lets multiple developers, programers and project managers all work on the source code for a project with minimal stepping on each others toes. The workflow we use is as follows.
We keep the a Git repository in the cloud, typically in Bitbucket.
Each developer then keeps a local copy of the repository. The developer can then create a new feature branch to work on an issue. More than one developer can work on a project at a time, and multiple branches can co-exist at the same time. This allows for more concurrent effort to be deployed.
(This image from the git-guide linked below)
Typically then the QA will pull that feature branch to a test server and test the new feature/issue for completeness/quality.
If they are happy with the quality of work, they can then merge that feature/issue branch into the master branch.
Then on the production server we can pull the master branch and deploy it in production.
We link the bitbucket repository with JIRA and Confluence so that features, issues and bugs can be more easily tracked and discussed.
For more information on how to use git, see the git-guide.
Using the cases.date_modified is not the same as the date a case is closed, as the case may have been modified after it was closed.
Thus, the query below will return the date the case was transitioned to ‘Closed’ provided the cases.status field is being audited.
CONVERT_TZ(cases_audit.date_created,'+00:00','+10:00') as 'date_closed',
accounts.name as 'account',
cases.name as 'case_id'
join cases on cases.id = cases_audit.parent_id
join accounts on accounts.id = cases.account_id
cases_audit.field_name = "status"
and cases_audit.after_value_string = "Closed"
Note, you might get more then one row returned per case if the case was re-opened, also my code above assumes a timezone of UTC+10
His Applescript does a fantastic job of this, the only issue I had was that my iCloud account was named differently to ‘iCloud’, all I did to resolve that was to rename my account in Apple Preferences > Accounts back to iCloud while I did the export.
A great deal of psychological research shows that studying in a burst is less effective than study sessions spaced out over time. Blogs naturally embody the latter method, dripping out ideas over weeks and months instead of in a burst.