I said one swear word (a bad one) in front of my mother as a child and got my mouth washed out with soap. I developed a filter after that and have been quite successful with knowing when and where swearing is OK and when and where it isn't.
The world is not a terribly literal place. Speech is mostly not about words and it isn't about words being exactly right for everything all the time.
If you work with computers (which are very literal) for a good portion of your day, you need to develop a literal filter similar to your swear filter.
People are not computers. Start listening. Start paying attention to body language and context.
If you can't see the person, because you are on the phone, then you have to work harder. Or you can switch to video calls.
If you don't think someone meant exactly what they said, ask a question. Seek to understand.
The short answer is that you can't, if by 'budget' you mean that you plan to know exactly what you're going to spend on it and reduce the amount of time/energy/money you plan to spend on collaborative excitement if you need that time to do other things.
But what you can do is to plan and make space for it in your project - make sure that the time is there for brainstorming and excitement and creativity. If you do that then the energy you create will help the budget problem take care of itself.
I upgraded to version 0.8 of Ghost over the weekend. I am pretty proud of myself as it was all command line on Linux.
It would have been a half hour job if I had just followed all of the instructions here. Unfortunately, when they say follow all the steps exactly, they mean follow all the steps exactly.
It was true in first grade and its still true today: following instructions is hard.
Anyway, I didn't blow away the core directory I just copied the new one over the top and that led to weird problems down the road.
Fortunately, the fix was easy. Just follow all the steps exactly and voila! It works.
I'm taking Krista Tippet's online course about asking generous questions. It's bigger (in a certain sense) than the kind of questions I need in my line of work, though I think it is still useful to think of conversations in the broad terms that she defines them. You can still learn something about the way to discuss software development and design from thinking about the way you might frame contentious public discourse.
One challenge I have with online course material presented in a video format is that it controls the flow and rate of presentation. This is different than text or pictures, where I (the learner/consumer) get to choose where and how to spend my time.
What I like about the course described above is that the course is broken into many small videos, and I am able to bookmark the course where I need to.
I am using an old-fashioned, dead-tree-style book for this, though not everyone in the discussion is required to do so. What do I love about a paper book? I love being able to skim, reread, and annotate at will.
With text I can skim or not, pause, take notes or not, retrace, and reread, and I can do all that at pretty much the same time using my eyes, hands, and a pen. It's easy. I can access information quickly, get to the point, and move on. Or choose to reread if I want to. I can also access any part of the text that I have bookmarked, more or less instantaneously.
With video these things are harder. I have to wait for the video to get around to the information I am interested in, my bookmarks exist in the context of one video, and notes I still take by hand (albeit electronically) separate from the text.
I'm sure that people are working on solving these challenges with video. At least I hope they are. Video is great for certain things, but books and text still win at some things - density of information and efficiency of access - to name two.
At my current company we have a fair amount of data about the activities that constitute our work - developing software, planning projects, testing, selling, communicating with clients, etc.
While some of this data has some volume - the work management certainly runs into the millions of records - some of it is at a more modest scale. For instance, the number of projects that we've run in the last 5 years is in the thousands, not tens of thousands or millions.
Yet there is still plenty of insight in this data if you know the right questions to ask. Or if you are willing to ask questions on a journey to finding the right ones. On this journey you must understand that the first questions you ask may affect what questions you decide to ask later. If you enter into the process assuming you know the answer or even all the right questions, you are at risk of missing the point.
Some of our information about successful and failed projects comes from a deeper look at client types, project types, and technology types. We didn't always ask the right questions first, but we kept asking questions and looking for insight in the data.
In the end the answer to a couple of hard problems revealed themselves in the data with relatively simple SQL queries (no advanced degree or BI tool required). You just need to keep collecting the data and keep asking questions.
Jonathan Fries on .