I picked up Daniel Kahneman’s "Thinking Fast and Slow" after a recommendation by Mike Jones in early 2013 – it’s taken me quite a while to get through it. The book starts by describing our two styles of thinking…
Most hiring issues can be broken down into one of three categories: constraining factors, improper vetting, or lack of awareness. The following sections outline the problems found within each.
This year’s Agile By Example (or simply ABE) was my 2nd visit to this conference, I’ve missed only the first edition. Last year I felt really refreshed by the conference built not only around code, coding, testing and developing software.
The Puritan Gift is not a book primarily oriented to programmers, but to knowledge workers and managers in general. Its goal is to show, through history, the evolution of American and Japanese management over the last two centuries, its strongest moments and its decline through the Cult of the so-called Expert and of corporate consultancy companies.
This week, for the first time ever, DZone is releasing the first in a series of checklists for software developers. Our first checklist covers Test-Driven Development (TDD). To complement this exciting new endeavor, I dug through the DZone archives and put together a Top 10 list of TDD resources.
In an open, self-regulated market, the tools gravitate toward their corresponding, welcoming environments. Low-trust tools go to low-trust, highly regulated environments, and high-trust tools are used in agile, high-trust cultures.
My recent “#NoProjects - why projects don’t make sense” post stirred up a fair bit of discussion, both on the blog and especially on Twitter. But, while that post railed against “projects” it didn’t say much about what we should do instead. So let me try and put in place the outline of how I see a #NoProjects world working.
Continuous Delivery and Service Management fundamentally differ in terms of both action frequency and ordering – while a Continuous Delivery pipeline will offer a single workflow encapsulating the same actions in the same order, the Service Management domain requires multiple workflows and adhoc actions in order to respond to operational issues.
I personally think that being “agile” is truly what makes a company “Agile.” Just like how happiness is a journey and there is no “permanent” state called happiness, being “agile” is a journey and there is no final/permanent state called “Agile”.
Agile principles are all about learning as you go and using the new knowledge to redefine the goals of the project. This is perfect for the developers and the immediately involved business representatives. But for a C-level exec it becomes hard.
This post is an excerpt from my new book, Conversational Git. The entire book is available online and its source is on GitHub. It’s designed to be a quick, accessible introduction for experienced developers. I’d be delighted to hear what others think.
Maintaining focus has become a such sticking point for so many. How do we keep it? How is it so easily lost? What tools can we use to find it, induce it, or retain it? If you’re constantly seeking focus and it seems nowhere to be found, you may need to ask yourself: how driven are you, truly, in what you do?
Many software developers I’ve talked to have expressed interest in the idea of someday either starting their own business, or in some capacity working for themselves. Before you do really quit your job, you should first understand why it is a good idea to quit your job.
Are you working in the way you are because it’s a good idea, or just because someone told you to do it? I die a little bit inside when people say “should we do Agile or not?” The assumptions behind this question are all wrong: That there is one way to “be Agile”