When you first started with git, you quickly got up to speed with committing, pushing, pulling, merging, and the like. But then you noticed a gaping hole in your knowledge - how do you find stuff in Git? Can you revert to a version of a file as it stood three weeks ago, or find out when a bug was introduced? Who was the last person to edit this file?
They always tell you that the great thing about Git is that you [almost] never lose any history. So how do you access and utilize that history?
These days it’s hard to tell whether the computer saves us more time than it wastes. However recently I had an experience programming in Ruby that demonstrated to me that the computer can be our modern time-saving friend, especially when wielding a language like Ruby, delicately designed to just “get out of your way” and let you program. The story involves number crunching, eyebrow scrunching, and in the end, an unabashed brute-force beauty.
It was early one weekend morning and I was trying to integrate AppVeyor with my GitHub project. But there was one problem: my build was failing miserably on AppVeyor. Strangely, it built just fine on my machine; but on AppVeyor the test ToStringShouldReturnResourceKey was failing a string comparison.
Investigating the failure
Fortunately I was using Shouldly, which produces very readable test output when your tests fail. See what you notice in the snippet below.
IFTTT automates many aspects of your online life. Is it going to rain tomorrow? Hey look I just got an email forecasting rain in my area. Golly thanks T-Guys! :) Or what about receiving an email or finding a new article in Pocket whenever there’s a new xkcd or CommitStrip. Or what if you want to automatically archive your tweets or internet favorites to Evernote or OneNote? Your online alliterative conditional buddy can do all that, and more.
Many believe that to be successful, the members of an Agile team have to be a bunch of highly skilled full-stack hot shots. Some even go so far as to say that you should only hire skilled developers, or “senior” developers. Are the pundits just a bunch of arrogant elitists? Unfortunately, their elitist views aren’t entirely without merit. At their core, Agile teams are supposed to be self organizing and largely autonomous. Take the Scrum framework for example: the Product Owner decides *what* to build, but it’s up to the team to decide *how* to build it. Why is that dangerous if the team is composed of junior developers?
This morning I found myself musing on a warm and fuzzy feeling that lay pulsing deep within my soul. Upon examining it more closely, imagine my horror when I should see it represented by one word, so laden with fear and derision: Microsoft!
I don’t think I’m alone among honest developers in thinking that Microsoft has done an about-face in its posture toward the development community. Herewithin I shall promulgate that this transformation is due to a new-found humility on their part.
The other day someone told me about some premium parking spaces in Manhattan going for a million bucks. Somehow I don’t doubt it. We all value a safe place to park our possessions. Oftentimes, however, we lack a place to park our inspiration.
Are you a slave to your inspiration? Does your curiosity keep you constantly roaming from one tasty patch of interesting information to the next without ever getting a solid grasp of anything? Perhaps you need to “park it”. You need an inspiration parking lot.
If you’ve been around the computer industry for a while, you’re no doubt aware that we are afflicted by information overload. There’s too much information and knowledge to be absorbed by one person in one lifespan. And that same body of knowledge continues to morph and shift with the capricious tides of the industry.
A recent article on SitePoint discussed How Not to Get Overwhelmed as a Developer. It advocates specialization in order to avoid eventual burnout. That’s a good start, but even subfields have become so vast that even then you feel overwhelmed under the torrent of technobabble. Further adding to your frustration, you read an excellent article or two, and within 8 hours, you’ve forgotten 80% of what you read. That’s annoying. In this post I’d like to introduce you a time-tested reading technique which can boost recall from that measly 20% to a respectable 80%. It’s called SQ3R. Combine that with the techniques of mind-mapping and you’ll find yourself better equipped to face the information onslaught.
O that your bloated code
Could meander less often
Or return to its commode
“What in the world… is this refactoring thing?” The question hung in the air one crisp overcast morning, intermingled with the varied roars and toots of stressed out commuters accelerating to merge onto the Brooklyn Queens Expressway. I’d recently ventured out from the lonely homestead of solo-cowboy programming and moved to a big-ranch team of seasoned developers. The term “refactoring” ricocheted in and out of every other tech-speak paragraph while they wrangled big sections of legacy code and pondered the design implications of introducing a new feature into the system.
Recently it struck me that there is a metaphorical similarity between technological disasters and geological earthquakes. The last 100 or so years have seen a big increase in the amount of damage caused by earthquakes, both to lives and to property. The US Geological Survey maintains a list of the most destructive earthquakes in history, those which caused more than 50,000 deaths. I counted 22 earthquakes. Of those, exactly half of them occurred since 1900.
So why are these geological phenomena killing so many more now than in the past?