As a developer, I spend a lot of time working in the terminal. Besides starting long-running daemons such as web servers in the terminal, I also use Git, Vim, and other command line tools throughout the day, and terminal sessions tend to pile up. On any given day, I can have more than a dozen terminal sessions open at a time, and that’s just for one project. Read more on Setting Up a Project Workspace in Tmux…
If you’ve done much work with command line tools, you’ve undoubtedly wrestled with dotfiles, those pesky configuration files in your home directory that are hidden from view by having a dot at the beginning of their name. Bash uses a
.bashrc configuration file. Vim uses a
.vimrc file and a
.vim directory for additional scripts. Tmux uses a
.tmux.conf file. Git uses a global
.gitconfig. Untold other tools follow the pattern.
One tool you’ll hear discussed in Agile circles is kanban boards. You may have seen one, and chances are it had columns labeled “To Do”, “Doing”, and “Done”, perhaps with a few others thrown in for good measure.
At AgileConf 2014, John Krewson presented “The Show Must Go On: Leadership Lessons Learned from a Life in Theater” in which he outlined parallels between the stage acting and software development. Among his points on how project management is like directing and hiring is like casting, John remarked that when a director is preparing a performance, they don’t assemble the actors, distribute scripts, and say, “We’re all professionals. See you on opening night.” Even when everyone on the team is an A-lister, they still need to rehearse.
The same goes for software development.
When you work with Atomic Object, you’ll hear a lot about Agile software development. Agile takes many different forms, but all of them are, at heart, about writing better software faster. Agile is part philosophy, part methodology, and part discipline. The Agile Manifesto emphasizes people instead of mechanical processes.
But before diving into the specifics of how Agile works, let’s back up and look at the problem Agile is trying to solve. Why come up with a new system in the first place?
I’ve used many languages for my scripting needs, but my favorite — believe it or not — is probably Bash. Bash may not have any types, and scripting with Bash may be fraught with pitfalls, but sometimes the problem at hand is solved most succinctly and elegantly with small focused programs that compose well.
Bash’s composition comes in the form of piping one program’s output into the next program. No program needs to know where its input comes from, just like Lego blocks don’t care what block they stack on. This is an incredibly useful approach. For instance, take a look at how easy it is process the contents of the clipboard:
pbpaste | base64 | pbcopy
We just base64-encoded whatever was in the clipboard (at least, on Mac OS X; Linux has similar programs under different names, and on Windows you may need to write your own versions of
pbcopy). You can use
pbcopy and the rest of the Bash toolbox to do whatever processing of clipboard text you have in mind, and thanks to pipes, you can do it very concisely. Read more on Plays Well with Others – Lessons in Reusable Tooling…
When I went to college, I had no idea how to take notes, so I did what I thought I was supposed to do: I wrote everything down. For four years of college, I wrote paragraphs and outlines of class lectures, and other than studying for tests, I never looked at those notes again. When I graduated and said goodbye to all those lectures and tests, I stopped taking notes. Life’s tests, after all, are open-book.
But last October I started taking notes again. Midwest UX was held here in Grand Rapids, and one of the workshops was titled “Drawing What You Mean – In Real Time”. The presenter, MJ Broadbent, revealed the secrets of a kind of note-taking I had never heard of. It was called sketchnoting, and I was shocked that no one had told me about it sooner. Read more on Doodles with Meaning – The Art of Sketchnoting…
Humans are story machines. We think in stories. We process in stories. We store in stories. When you add up all the television shows, movies, books, jokes, rumors, and gossip we tell, story-telling is in the running for our biggest industry. We require stories. We’re so hopelessly bad at dealing with information that isn’t in story form that we invented computers, which of course gave us whole new things to tell stories about.
We need stories because even with billion-word languages, there are still experiences we can’t express with lone words. Shakespeare wasn’t afraid to make up words, but even he resorted to tiny stories. Characters “fought fire with fire” or went on a “wild goose chase” or learned that “all that glitters is not gold.” Four hundred years later, we make up words at the drop of a hat, but we still haven’t come up with catchier ways to express the dozens of tiny stories Shakespeare inserted into our language.
“Accumulate idioms… The only difference(!) between Shakespeare and you was the size of his idiom list – not the size of his vocabulary.” – Alan Perlis
Unlike computers, the mind’s memory is also its processor. The stories we know affect how we think. Sometimes, where we don’t have a story, we have a blindspot. That’s why it’s valuable to accumulate metaphors, like cleaning dust from our mental lens. Stories help us perceive the world more clearly and more memorably.
As adults it’s easy to think we have the vocabulary we need, but just because we have the words doesn’t mean we have the stories. Here are a few perspective-shaping stories to get you started. Read more on The Proper Care & Feeding of Your Mental Story Machine…
Here are a few reasons to explore LiveScript. Read more on Graduating from CoffeeScript to LiveScript…
In Douglas Adams’s Hitchhiker’s Guide to the Galaxy series, an advanced civilization builds a supercomputer to calculate “the ultimate answer to life, the universe, and everything.” After millions of years of calculation, the computer finally gives its answer: forty-two. Despite being an advanced civilization, it succumbed to the pitfall of getting an answer without first understanding the question.
We often fall into the same trap. I once worked on a development team that practiced Agile programming. Every now and then the team would debate whether we were really practicing Agile, whether we should do more Agile, whether we should abandon Agile altogether, and whether we should adopt some other methodology. The debates centered on personal preferences and impressions of team productivity. Alternatives were suggested based on what the team had tried before and who had what certifications. Never did our conversations start with understanding what problems the various disciplines were designed to solve. Neither did we begin with the most important question: what problems were we trying to solve? We jumped straight to the answers without first understanding the question. Forty-two. Read more on Considering a New Methodology? First, Understand the Question…