An introduction to git

I recently wrote this to a friend who joined an open source project, QRatitude, I started under the banner of Freeside Atlanta. Freeside is part of the reason I haven’t updated this blog in a good while, but I need to save my thoughts on that for another post.

This is a collection of really good resources on git (and perhaps, an outline of a future class I might teach).

I strongly recommend learn by doing when it comes to git, and starting with the absolute simplest concepts. It can quickly overwhelm you as an insanely powerful tool for historical changeset management on text and files.

Don’t worry about the terms thrown out here now. You’ll get to those in just a second. The goal is to learn enough to:

  • clone a remote repo
  • edit some files
  • stage the changes to the index
  • commit the changes to your local repo
  • pull from the remote repo
  • learn how to fix up any merge conflicts
  • push to the remote repo
Really easy and straight-forward, with few steps for each exercise. I recommend only doing labs 1-15.
A well-written, entertaining and awesome introduction to version control in the general, as well as git. I recommend only looking at chapters 1-4.
Burn this image into your mind, and ignore all other diagrams that attempt to explain git in terms of commits and branches and arrows. If you get confused, keep this diagram open in a browser tab and look at it again.
From the git project itself, but you only want to read the first three chapters. Everything after that starts to go crazy.

The two most important concepts to remember about git are:

  • You have a staging area (the index) and a local repository (the local repo) on your machine, and a remote repository (the remote repo) on a server somewhere (say, github). The commands to put changes in each are add , commit , and push , respectively. Again, this diagram is god:
  • Git helps you manage sets of changes, not files. When there is a merge conflict, it is not that one version of the file is different from another – git typically takes care of that for you. A conflict happens when changesets collide and you have to disambiguate.

Further reading and/or advanced topics:
This is where the canonical git explained image came from, but some of the topics here are somewhat advanced.
Quickly gets into some advanced topics – I think these diagrams are horrible, but the text is really good.
No relation. This is the workflow I use. I always work in a local branch, then these series of commands basically integrate my work with whatever changes may have happened since I last did a push. git rebase is one of the most difficult things to understand and use effectively, and very easy to screw up.

Posted in Dev, Uncategorized | Comments Off

A (Fast and Loose) Model of Software Communication

I’d like to show that diction is a critical component to successful software products. Diction has nuanced meaning, yet “word choice” is possibly the simplest definition. It is a necessary, but not sufficient, requisite for successful communication in a software team, but I think perhaps 80% sufficient.

I want to approach this essay in the spirit of a (really) informal sketch of a proof. Maybe I’ll refine this further when I get more time.

Let’s first define these sets: software team, communication artifacts, and products. Then, a short methodology-independent discussion of the software process. Finally, the argument for how a failure of diction in an element of the communication artifact set is to the detriment of the product set.

Definitions and Sets

A software team is a mapping of roles to a set of people. Often, the size of the set of roles much larger than the size of the set of people. We need to revisit the mapping question later, but for now, let’s assume the role-set and people-set are of equal size and the mapping is one-to-one. Here’s a sampling of the software team set:

  • Developer
  • Tester
  • Analyst (commonly known as Business Analyst or BA, but I want a single word identifier)
  • Writer (commonly known as Technical Writer)
  • Director
  • Client (is often plural, Audience may be used as well)

I’m purposely excluding incidental, but common, accessories to software teams, such as Business Manager or Systems Administrator. Here, Business Manager is meant more like “Administrator”: she makes sure the timecards (if any) are punched and the seating chart is accurate. Folks like this are important, but for the purposes of dialogue concerning abstract concepts, they are left out. I think this choice is fair, since communications to and from these folks will be very concrete (i.e. “Take down the production server on node 2″ or “Update my cell phone in the company rolodex”).

Let’s treat Database Administrators and Artists/Designers (if any) like Developers. The Director can be anything from your Lead Developer to the CTO or CEO, informally, “Boss” – Strategist, or if you prefer, “The Buck Stops Here” person, or the decision arbiter. Client could be anything from individual end-user of your product to tens of thousands of users.

Generally, each element of the software team set has a voice, and they have the direct responsibility for products. Communication artifacts are generated as part of the process that creates these products.

The set of communication artifacts include intangiables like phone calls, hallway conversations, dialogue in meetings, and tangiables like chat or instant message logs, emails, documents, source control comments, anything input by users of an issue tracking system.

Finally, the set of products include anything tangiable produced by the software team, which is usually software.

Software Process Theory

Communication is nothing more than the generation of communication artifacts that orchestrate the production of products by a software team. In other words, it’s the activity of creating a common understanding in each element of the software team through communication artifacts, with the goal of creating a successful product.

Ultimately, a successful product can be defined as that which most accurately expresses the mental “will-outcome” or “sphere of thought-will” of the Client. This is a stupidily complicated way of saying the customer is always right. We cannot argue that what the Client expects in a product is wrong. However, we can accept how the Client expresses their desire for the outcome (the “will-outcome”) may be incomplete or inadequate. This doesn’t mean at all the Client has a short-coming – it is an extremely difficult exercise and often the full scope of the desired outcome is unknown to the Client! So, don’t jump to conclusions and fault the Client for anything. The product could be silly, or the business model flawed, but these are irrelevant concerns in this argument.

We can define a function s on the Client communication artifacts C, such that s(C) returns a number between 0 and 1 inclusive, so that 0 means the Client has conveyed no information about their “will-outcome” and 1 means all the information of the “will-outcome” is expressed in full. My experience is that this function s(C) is usually something between 0.25 and 0.60, if the products are moderately complex [0]. Simpler products mean a higher s(C) value, more complex products introduce more unknowns, so it can be lower.

The Client role interfaces primarily with the Analyst role. It is the responsibility of the Analyst to take what is likely an imperfect representation and create communication artifacts that expand on the Client’s “will-outcome” – like insulating foam around cracks in the attic walls. In math terms, the Analyst applies a transformation A to Client generated communication artifacts C such that C’ = A(C). We can measure the success of the work of the Analyst if they apply a transformation to the Client communication artifacts C, and s(C’) > s(C). Simply put, we are modeling the concept of clarification.

The set C’ is distributed to Developers and Testers. Products P can be produced by the function D, such that P = D(C’). The function T(P, C’) measures the difference between P and s(C’), or T(P, C’) = s(P) – s(C’). If T is negative, then this means that the product is not meeting the current clarification of the Client’s “will-outcome”. T has this interesting property where it shouldn’t be positive (given a strict C’), but it can be positive if somehow s(P) tells us that the current iteration of the product satisfies the Client more than the clarification of the Client’s “will-outcome” that the Analyst produced. In practice, this does happen because the function D can incorporate more information than just what is present in C’.

Writers generally invoke transform W on C’ to add to the set, but W can also accept P and produce P’ (informally, the software and its documentation, but also includes “support”). This is important because the Client ultimately queries s(P’).

Directors are interesting in that they use function B(C, C’) and modify C’ – meaning, since they are arbiter of Client meaning, they alter the value of s(C’), hopefully, for the better.

Immediately, it should be apparent that the waterfall model would never work. Only through successive applications of A, D, and B can we hope to increase s(C’) significantly. So, some variant of iterative development, be it Agile or Scrum, or whatever, has hope of producing a set of products such that s(P’) >> s(C).

Bringing it Home

We can define a function e (for effectiveness) that compares the elements of a set of communication artifacts C between a subset S of a software team, and let’s say it’s a value between 0 and 1 inclusive where 0 means “identical meaning across all elements in C” and 1 means “no common understanding among elements in C.” For simplicity, let’s say e(C, S) for a set C composed of two elements c1 and c2. We calculate e as a sort of Hamming distance on “understanding.” For example, let’s say c1 and c2 are requirements “Store spreadsheets on file system” and “Store documents in database,” respectively. One verb, two nouns. The verb is the same, so the distance is zero, and e remains 0. Documents and spreadsheets are similar but not identical nouns, so let’s just arbitrarily say the distance is 0.25. File system and database are completely different, so the distance is 1. Informally, let’s just say the value of e(C, S) here is about 0.4 [1]. Note that we assume the words store, spreadsheets, documents, file system, and database mean the same thing to all elements in S. This is the “understandability” calculation. If for some reason, one element in S believes a local Sqlite instance is a database, but another element in S assumes this is referring to the MySQL instance on a server, then e(C, S) can be lower.

Note that the value of e(C, S) approaching 0 does not strictly mean s(C) approaches 1. The relationship between s(C) and e(C, S) is that e(C, S) is the error term of the calculation of s(C).

Generally, if the diction between the elements in a set of communication artifacts C is similar, we should expect e(C, S) to be closer to 0, but only if the diction is understood in common between the elements in S.

That means that under this model, as iterations of software development go, the more e(C, S) is allowed to introduce error, the more these can be become amplified and result in a less satisfying products set for the Client.

This is all really hand-wavy, but if we expand s(P’) = s(P’ = W(P = D(C’= A(C)))), the error of A(C) is e(C, {Analyst, Client}), then error of D(C’) is e(C’, {Developer, Analyst, Client}), and then the error of W(P) is e(C’, {Developer, Analyst, Writer, Client}). In simpler terms, as we try and measure Client satsifiability, we introduce error that reduce the value of the s(P’) function at potentially each step of an iterative software process.

The Long and Short of It

If we accept that common understanding in a software team creates better software, then it follows that a common language implied by consistent diction in communication artifacts is necessary for satisfiable products under this loosely defined sketch of a software process model.

Conclusions and Recommendations

If you like this model and its thesis, then what it means is that you should consider if a misalignment of diction has ever resulted in a bug or requirements misunderstanding within your software team.

Consider making somebody a full-time “Editor” for all tangiable communication artifacts. This person is solely responsible for curating the language of all communications. If there is a mismatch (ex. “database” vs. “file-system”) then the Editor should get the parties together to clear it up.

Naturally, the Analyst or Writer is a good choice for the role. However, we must bear in mind that subsets of the software team also have private language, and maintenance of the private language in correspondence with the team language is also needed, but an outsider shouldn’t do that. The Editor should be somebody who can mediate and curate this correspondence. I believe it’s a critical job, and warrants a full-time position. However, I haven’t seen this role recognized or elevated to importance at all in any place I’ve worked.

Explorations and Observations

I mentioned that diction was perhaps 80% sufficient for successful software communication. I estimate 80% of understandability in software team members is driven by diction, so that if you have folks in this environment, then most language is going to correspond to common understanding. For example, “database” will generally mean the same thing to all team members, but “customer orders” can convey distinct meaning to each person on a software team.

So, I believe that 20% of understanding mismatch can come from having team members with really different backgrounds, different generations, differences in general. That is not to say a homogenous team is better, it just means there’s a little more work to be done to keep communications consistent to foster understanding, and to verify understanding. Often Analysts and Directors are much more experienced, which means there might be a generation gap where understanding fails.

In short, this is team “fit” everyone keeps talking about. It’s not easy to quantify, but we’re pretty sure if you can “get me” then we’ll make a great time. For one example, “getting me” starts with having a common understanding of the phrase “don’t break the build.”

An interesting observation is that this model fits the anecdote that a smaller team has an easier time communicating, and the model indicates this is because the diction is easier to curate and maintain in sync with understandability. However, as a team gets smaller, the bar is set higher for the initial value of s(C), because team where many roles are shared or compressed means a less contribution to increasing s(C) with each round.

[0] I’m really trying not to wing this. If a software estimate captures only 1/2 to 1/4 of the effort required to satisfy client, then we can imagine multiple rounds of this process to capture more of the Client’s “will-outcome.” This all implies that the initial s(C) value was low.

[1] In order to formally define the rules and calculation of e(C, S), we are tasked to define and measure “understandability” between elements of the set of humans in the software team set. Obviously, this is challenging, if not impossible. Let’s say e(C, S) is a placeholder for an estimate of effectiveness of a communication artifact.

Posted in Professional | Comments Off

The Programmer Competency Matrix

One day, I decided I wanted to find a metric to understand and track my skill level as a software developer.

This is a difficult thing to measure, since there’s any number of variables one can pick and choose to include in the metric, and how do we assign weight to each one? Some variables elude measurement altogether. How do you identify your 10x programmers? It’s not clear how to track the impact one person’s work has on others in the team. This involves cataloging the interpersonal relationships and defining the data to collect on these interactions. An accurate, meaningful, useful metric is impossible to create, and there may even be philosophical barriers to its production.

However, lucky for me and others, I only want a practical and imperfect metric. I found that in the Programmer Competency Matrix.

The simplicity of it is just great.  If somebody sees I claim a log(n) level in version control, they’ll understand I’ve worked with git and mercurial professionally, that my experience is not limited to cvs and subversion.  Coverage is excellent, but also succinct.  There are 32 categories, which not only cover technical skills, but soft skills like communication, reading, and blogging. One might argue IDE knowledge is overrated, but I see that category as being about source editors in general.  I’m a vim guy, and I’ve worked with Visual Studio (or against it at times.)  Knowing how to use the primary medium for your art is a key skill, like expecting a chef to know how to chop with a knife.  Finally, I really like that the top level is open-ended.  This means a developer always has room to grow.  However, it also notes that when somebody reaches the log(n) level, there really isn’t any place to go.  (I’m starting to sound like Nigel Tufnel.)  Sure, I can always keep learning more languages, but after some pragmatic experience in a few that cover different development paradigms, adding more doesn’t put me above and beyond any others.  I think I could hold my own with a developer that knew 15 languages versus my 10*, if we had to start from scratch on a new language tomorrow.  Once you get close to or past those 10,000 hours, you can only get worse if you decide to slack off.

The point of all this is I want to especially challenge myself this year, and raise my average score.  Maybe it’s stupid to put my weaknesses out there for everyone to see, but I also think it’ll only motivate me to do something about them.

Systems Programming (current level n^2): This is my weakest area.  I’m not a hardware guy, and have had little interest about the computer’s internals.  Still, it’s embarrassing to not give more than a cursory explanation of TCP/IP or multi-threading to somebody.  My plan to improve this is to really dive into the books I have on the subjects, and get some first-hand experience with these things in a language like C.

Build Automation (n): Some limited success in this category was with MSBuild for C# .NET projects.  I also currently work with maven, but a large part of it remains mysterious to me.  However, I am improving.  A current project I am working on is written in python.  I would like to put the code up on github, but I want to understand and write a good file to go with it first.

Automated Testing (n): For whatever reason, I have been in development environments where unit testing is just not done.  Occasionally in the past, my teams have flirted with some unit tests for a while, but the code always changes quickly and the unit tests rot.  At one point, I had even written a set of classes to bootstrap CSUnit tests using custom attributes.  I’d like to make a better, conscious effort in this area, but this is likely the area I’ll fail in this year.  One of these obstacles is the lack of a build server in my current (professional) environment, for reasons too complex to discuss here.  In my personal projects, I’m not too familiar with node.js and python’s unit testing frameworks, so I can definitely start there.

Defensive Coding (n): This is tied back to the automated testing dilemma.  I’ve not had the pleasure to work in a team that had the discipline to unit test, so I’ve never really had the opportunity to stress-test an application with simulated faults.  That actually sounds like fun, versus the droll unit tests I’ve had to write in the past.

IDE (n): I’ve already said I expand this section to include source editors in general.  One of my biggest vim weaknesses is macros, which definitely separates the wheat from the chaff.  Maybe I could write macros to help automate the droll unit test classes (hrm?!)

API (n): It’s not entirely clear how I could raise my level in this area.  Most of the APIs I work with are fairly robust and complete.  However, this year I’m getting more into web development, so maybe I’ll encounter something that I’ll need to improve upon to get my tasks done.

Frameworks (n): In this category, I actually have no interest at the moment in advancing to the log(n) level, because I do not want to write a framework.  It’s not that there’s nothing new under the sun, but that I simply don’t have a problem to solve where my own homegrown framework would help.  I’ve dealt with people who went down this rabbit hole and nearly took down entire companies with wasted time, energy, and effort in the name of a framework to rule them all.  The answer to “Should I write a framework for this?” is almost certainly “No.  Absolutely not.”

Scripting (n): Turns out, this current personal project for Freeside will be a great way to learn more advanced scripting techniques through python.

Databases (n): In this category, I still need more effort to understand advanced database topics, like indexing, optimization, and administration.  I know enough to get by and not make a DBA’s work a living nightmare, but knowing how to debug more low-level problems encountered databases can only be a plus.

Languages with Professional Experience (n): There has never been the use of concurrent or logic language paradigms in any professional capacity in my career.  However, I read a little about Erlang and would like to take a stab at it.  I have an idea for a program that should be simple to write in Erlang, so the next time I’m free I’ll set towards that aim.

Years of Professional Experience (n): There’s nothing to do here but put in another 2 years to get a full 10 years of professional experience.  I already crossed that mark in overall experience, but I want to keep things honest, since there is a huge difference between professional and personal work.

Tool Knowledge (n): I don’t really have good ideas for a new tool that I could implement and publish that people might find useful.  I think of a program like Charles, which is extremely useful to many people.  Yet to develop something like it is extremely ambitious.  Maybe in my foray into node.js, express, and jade I might come up with something others might like.

Platform Internals (n): When I see this category, I immediately think of Mark Russinovich.  That guy is a programming beast.  He might actually be a level 1 (constant time) in this category.  It is unclear if I can even approach that level in the next 10 years.  It’s not to say I won’t try, but this type of work is very demanding, requires very deep knowledge, and mastery over the machine.  It’s possibly the final boss of the Programmer Compentency Matrix.

So there it is: my response to the question, “What do you feel are your short-comings as a software developer?” I’d add I lack some experience in both web and mobile development, but that’s all just on the pile to improve upon in 2012.

* I’ve honestly lost track of the count.  My online resume I think has the most complete list.

Posted in Professional | Leave a comment

How Analogies Can Destroy Your Software Company

Back in high school, when it came time to take the SATs, I scored much higher on my math than my verbal. Perhaps it was due to analogies such as this one:

A) boon: beneficial
B) egotist: conceited
C) rascal: predictable
D) maxim: hackneyed
E) toady: important

One of the worst things you can do to your software company is to make up an analogy to help explain the software development process to yourself and others. Analogies are great in poems, fictional writing, and, to some extent, when writing arguments. The right analogy can make your writing interesting, make it come alive. The right analogy can win over a skeptic. When applied to the software development process, and management thereof, it can grow into a untamed, all-consuming hydra that leaves a trail of burned-out developers in its wake.

Let’s go over some software management/development analogies I have encountered out in the wild.

I am the Captain, and this is my Ship

The origins of this analogy are as old as time itself (or at least, the invention of travel by sea). The sea, a powerful uncharted mass, full of mystery – and possibly deep, evil sea creatures with a blood-thirst for man, or the false and alluring death song of the sirens. One tiny ship expressing the will of its crew braves her waves and lightning storms to reach destinations unknown. The ship, the vessel: a fragile creation of man easily smote by the whims of Neptune.

Managers that come from naval (or general military) stock seem to be especially prone to this line of thinking. Joel Spolsky called it the Command and Control style of management. There are two company-killing premises with this analogy.

#1: The captain has absolute authority and responsibility over the ship and its crew.

Nothing could be further from the truth in a typical software project. While software management definitely should plan and guide higher-level company goals, authority and responsibility are shared elements between management and developers or should be if they aren’t. Developers have insight into the technology, scope of work, and the huge responsibility of estimation. To deny them to set realistic deliverables and provide honest feedback about the technological choices is to ignore your first level of quality assurance. Early choices can and should be critically analyzed by the people who will eventually execute them, well before any customer (or competitor) are aware of your upcoming product. If you truly care about what emerges from your software production, authority and responsibility needs to be more fluid between management and development. Your developers will thank and respect you for it.

#2: The captain is always at the helm, to guide the ship, especially in the eye of the storm.

First, there’s no storm. If there’s a storm, it’s because management failed to listen to developers and set realistic deadlines (see #1). Also, the analogy that management steers the ship, or sits at the controls of the factory, or any other Great Commander-based analogy suffers from a completely unrealistic view on the nature of abstract work. Abstract and creative work is not dictated nor directed from above or without. In this type of environment, what is really happening when a manager retreats into her office is that she’s being a coward. Instead of doing the hard work of software management, she has decided to “focus on the big picture” in her office until the developers manage to eke out something unworthy of a release, usually late. This premise is a really courageous-sounding way of saying you’re going to stick your head in the sand until the problems go away.

The Captian can sink your company to the bottom of Davy Jones’ locker. Developers that appear to thrive under the Command and Control model are actually a class of authoritarians, the ones who prefer to have a strong, external guidance to their actions. Such developers are not your spontaneous and creative types. It’s not a judgement on authoritarians, but they’re more suitable to handle more visceral matters, such as server/network maintenance and databases. Developers that aren’t followers will feel alienated and leave your company. Over time, you’ll end up with a loyal crew, but they won’t innovate past what could be a myopic view of your world and your products.

I am the Zookeeper, and these are my Animals

This analogy can take on various forms, such as Gardener/Plants or Father/Children. Managers that have children or have strong religious inclinations seem to be drawn to this form of thinking. The basic idea is that developers are wild savages, driven by base instincts and do not recognize the more refined and civilized nature of Business. The behavior of the manager operating under this analogy will be to satisfy each developer’s environmental needs. This could be done by providing sufficient hardware, a quiet environment, snacks, unfettered internet access, etc. The thinking is that if you take a developer and put them in a clean cage with plenty of access to food and water, software will be produced without further interaction. If a developer escapes, say, to go kayaking over the weekend, the Zookeeper needs to fetch the developer and make sure they return to their cage to produce more software.

Some people thrive under this laissez-faire management style, in other fields, because other work lends itself to much easier cross-collaboration and interaction with different stakeholders. In software development, business people need to recognize that a successful product serves an audience, and is more than just the sum of requirements and specification documents. Without a business analyst on-hand, and some level of feedback, software development ex nihilo is to dream the impossible dream. You’ll get a product that serves the interest of the developers that works to make their jobs easier, all while ignoring your customer’s real needs. The failure to communicate these needs, to perform the duties of management, means a sub-par product, and inevitable failure of acceptance in the market.

That’s not to say you might get lucky. Developers that are passionate and care may go the extra mile and consult the business analysts themselves. Don’t count on that. Often, this behavior leads to the Zookeeper putting a quick stop to it. After all, if a developer isn’t with his hands on the home keys, then the software isn’t being produced. This is a similar manifestation of the Captain/Ship analogy, in the sense that developers somehow can’t be trusted to make appropriate decisions on behalf of the business. If you hire great developers, they are also great abstract and creative thinkers. To deny them input, to view them as wild savages running around your office, is to do your company a great injustice.

The Zookeeper threatens your company because the answer to great software productivity is not always a third monitor or a foosball table. In trusting their opinion, you are validating their view of developers as wild. In sequestering developers from the rest of the company, another form of alienation takes place over time. Developers lose connection to the business case for your software, and your other business units start to view development with resentment for all their perks. If only the groups were to communicate together, they would have common ground to produce a superior product. Isolated, both sides take a toll.

I am the Surgeon, and you are my Assistants

Scalpel, stat! Sometimes, the worst software managers are those with prior software development experience. They were the best of the group, and other developers looked up to them for advice. Naturally, a promotion was in order. First, to software lead. Then, to full-time manager. Only they never quite made the transition smoothly. When the deadlines started slipping, this type of manager assumes the role of the Surgeon, the great mind with his hands in the patient’s body cavity, saving a life. The patient is this busted up software project, that is literally clinging on to dear life. Who mangled it? None other than these other untrustworthy and unskilled developers lower on the chain.

If you have software manager that is all too eager to clean up after other developer’s coding mistakes, then you have a Surgeon problem. She might tell you the developers are incompetent, unable to follow the grand software architecture she planned out. She may only delegate the most mundane tasks, such as shell-scripting, SQL scripts, reporting, or creating data access objects. She is also quick to take all the credit for all successes, and quicker to throw the Assistants under the bus when things fail.

This and other similar analogies rooted in pure ego can and will destroy your company. No developer wants to work with somebody like that. High turnover follows the Surgeon, which is the death knell of any software project, or your company if you depend on software releases. It is preferable to have a headless software department than to allow such a scenario to play out.

Posted in Professional | Leave a comment

A Developer’s Attitude

Recently, I picked up a pair of clipless pedals for my bike.

a dramatization

I then promptly crashed in the parking lot behind Outback Bikes in Little Five Points. After a harrowing journey to the entrance of the Path near Boulevard, I almost had the hang of things, and started enjoying myself again. Clipless pedals allow you to take advantage of the upstroke, put a little less effort on your legs, and make you go faster. It’s a fun sprint down the Path from there to L5P, and in the slow sections I kept practicing the dismount. I learned I have to focus and dismount on the right side (later my good friend Amelia shared this cycling lore: It’s better to get bitten by the dog than hit by the car) as trying to unclip both feet results in disaster. I learned that a little later when trying to start pedaling slightly uphill near Oakdale. At the very least, a few commuters had a quick laugh at my expense. And that time I had some grass to land on. I’m cycling 10mi daily to train for a century, and these longer rides by myself are really helping me get comfortable with the pedals.

What does this have to do with software development? There are shockingly few software developers realize that the path to better code and better professional development is putting yourself into a situation where you risk injury to gain the reward of greater efficiency. For some developers, their threshold for pain is surprisingly low (“Oh no! Compiler errors! I’ll just copy and paste what I know works.”) and often completely misguided. For example, if you aren’t well versed in SQL and are scared of running a certain type of query, then why not spend the next 15min to clone the DB and run it against that? Don’t know how to clone the DB? Learn! We have all the tools at our disposal to experiment. In the most paranoid case, create a virtual image with a Linux distro and try everything there. If you completely ruin the machine, then just delete the virtual image. What’s stopping you?

There are many tools that if we spent the time to learn, we’d increase our productivity a hundredfold. I’ve often heard a good developer is about 10x more effective than a standard developer. That’s not hard to believe. This isn’t about that 10x productive developer being smarter, having a better background/degree, or installed Linux on their baby monitor when they were in the crib. They are smarter, but only in the sense they’ve cultivated the right attitude to go through the pain and come out the other side.

You don’t learn better software development arguing on forums, reading blogs (like this one), or running around evangelizing technology. You have to step outside your comfort zone, and fall down a few times before getting better.

Posted in Professional | Leave a comment

Google Places Listing

I added a Google Places listing for the office.

I’m not entirely convinced advertisement will necessarily bring in the business I want to have, but we’ll see if that changes in the future. The focus for now is on trying to find good clients to work with. A great job for a great client makes it easy to bring in more and more work.

Posted in Uncategorized | Leave a comment

It’s Social Network Time(s)

Twitter, Facebook, and all this compulsary social badgering business is coming soon.



I setup the Facebook page today, and then I think a Twitter account will follow soon. These things aren’t going to look like what I see other businesses doing. For example, I’m not going to blast across the social sphere every time I write a blog post and link it back here. That’s what your friendly RSS reader is for (I use Google Reader.)

My feeling is the Facebook page’s wall posts will probably be limited to job listings as they come up. That seems to make the most sense for that social network.

The Twitter feed is probably going to just be random quips. Something like a micro-blog, I’m not really sure. I’m thinking similar to Seth Godin’s neat one-liners, but more software-centric. I figure the Twitter account is simply going to serve me more than any audience, by following interesting software people.

It is a push for some marketing, and hopefully I’ll do it in a way where I’m not adding to the miasma that currently pollutes the web. That’s a promise.

Posted in Uncategorized | Leave a comment

My Real Life NullPointerException

Sometimes, it’s easy to see parallels* to software engineering in my daily life.

At least it wasn't that serious...

While biking, I hit a pretty big pothole on Hosea Williams the other day. I didn’t know if that was the Primum Movens of my flat tire, but the next day it was completely flat. I took it into a shop for a number of reasons: it was the first time I had a flat tire, I didn’t have the tool to remove the tire from the rim, I didn’t have a spare tube or a patch kit, and I didn’t have a lot of time.

The repair guy quickly took the tire and tube out, replaced the tube, and sent me on my way. I went up to Silver Comet for an 18mi ride, then went home.

The next morning my back tire was completely flat again. I searched the tire on the outside but couldn’t find the problem. I brought it back today and this other repair guy searched the tire, and found a small piece of metal (less than 0.5cm). Metal gone, new tube, I’m on my way again.

There’s a few points here. First, I need to spend the time to learn how to fix my bike. Second, I also need to put together a kit to keep in my bag with some basic tools, patches, pump, etc. Third, the next time I get a flat I know I have to search the tire for the problem. Fourth, I don’t really fault the first repair guy for not finding the piece of metal. It was also partly my fault for not thinking about it and asking him.

In software engineering, we need to have the right tools and the knowledge to fix problems that come up. There’s a pervasive RTFM culture out there, but mentors that filter all the possible ways to solve basic problems are rare. It simply takes time up-front to collect the right tools and learn how to use them. Software developers that don’t spend this time suffer over the long term.

The first repair guy is a typical software developer, coding for the optimistic case and overlooking an obvious problem. The piece of metal was his error to check for null and my NullPointerException. I also passed the buck onto him because I didn’t have my house in order. In the software world, this happens all the time and it’s unproductive to cast blame. When we work in teams, every developer is at a different level. Some know some tools better than others. Some use defensive programming techniques to avoid NPEs.

The ideal team dynamic here is that the rock star developers need to avoid laziness, and the other developers on the team should be willing to put in the time to improve. In the real world, things rarely line up this way. So, the challenge for managers and leads is in how to create the incentives to try and attain this dynamic. It’s an effort that I can’t really recall ever seeing in action.

* One can draw a degree of insight from observing similarities between software development other fields, as long as such observations are limited in scope. There’s a drawn out post I’ve been working on about the fallacy of analogies when applied to software development.

Posted in Professional | Leave a comment

A Flex Annoyance

In Flex, it’s not very clear that the iterator you want to use on a Dictionary type to loop over the keys is simply rather than for

Dodongo is actually Everyman

Of course, the Flex compiler doesn’t care. It’s baffling why there can’t be simply one iterator syntax in the language, and maybe useful collections on the Dictionary type like .keys or .values? I wonder sometimes if Adobe just creates things only for the sake of trying be different.

// NOTE: use of instead of for
for (var obj:Object in this._roomConfigurationRateMap) {
    var configuration:RoomConfigurationVO = obj as RoomConfigurationVO;
    var configurationXML:XML = <room-type/>;
    configurationXML.@code = configuration.type.code;
    configurationXML.@bestFlexRate = this._roomConfigurationRateMap[configuration];

for each (var date:DatePair in this.blackoutDates) {
    var dateXML:XML = <item/>;
    dateXML.@startDate = XmlUtilities.formatDate(date.startDate);
    dateXML.@endDate = XmlUtilities.formatDate(date.endDate);
Posted in Dev | Leave a comment

First Post

I looked at the calendar this morning, and saw it was the year 2011 and I didn’t have a website.  No worries – problem solved.

Posted in Meta | Leave a comment