From the non-developer’s perspective, the developer’s job is one that cannot be understood; it involves communicating in acronyms (XML, ASP .Net, MVC, etc.) and staring blankly at a computer screen decorated with bizarre combinations of words that mean nothing. Working in this manner to build a functioning application that anyone can use and understand (e.g. Google or Word) lends a certain amount of mystique to the work we do. However, strip away the layers of jargon and all of that messy code and you’ll find that a developer is nothing more than a puzzle-solver. Our puzzles are complicated, though, and to solve them we must learn a slew of technologies and special languages (both literally and metaphorically).

Regardless, the developer is not one who merely excels at writing inscrutable combinations of letters and phrases which we call “code” and non-developers call “confusing and nonsensical.” We have to be able to understand a variety of problems as they exist in the real world. We must be able to identify deficiencies in how these problems are defined and we must be able to invent solutions to these problems; only then can we perform the labor of writing code to implement the solution.To some degree, as developers we must also become bankers, doctors, house painters, etc. If we don’t understand the nature of the work that we are developing for, then we can’t understand what we are required to do. Being a doctor, banker, house painter, etc. is the most challenging aspect of being a developer.

We have to understand every aspect of what we call the “problem domain” in order to ensure that we produce the most reasonable solution. Thus, we must be very detail-oriented people, always requiring more information than we are initially given and asking a bunch of questions that tend to perplex some unfortunate project manager. Eventually, we will get all of those evasive details and through the powers of what I call “dev-magic,” we’ll produce a fully functioning (mostly) and bug-free (rarely) software application that will make everyone happy (never).

Let’s consider an example:

You’re a developer working in the “dev shop.” A frantic project manager approaches you and says “We need to figure out how quickly three people can paint a house… GO!”

…

“Well…”

“I have a few questions…”

“How big is the house? Who’s painting this house? Will they be painting more than one house? Do I need to accommodate the fact that they’ll be painting houses of different sizes? Do they paint at the same rate? Do we need to take weather into account? How do you want the total time displayed? How will the total time be entered?”

At this point, some poor soul (perhaps the developer) will have to contact the client and rattle off these questions. The two parties will then come to some mutual agreement about what is required (let’s call it “a moment of clarity”) and then the developer will embark on his or her dev-magical journey into the realm of a solution.

Here is what you find out:

All the houses are exactly the same (they just built a new sub-division in Canton), so we don’t care about differently-sized houses. Weather will impact the speed that each painter paints, but we don’t yet know how much (the client will provide the details later). Time will be entered and displayed as hours. Three people will be painting each house: Sally, Jimmy, and Sandy. They each paint at different rates. On days when weather does not interfere, Sally can paint a house in 3 hours, Jimmy can paint a house in 4 hours, and Sandy can paint a house in 5 hours.

You now have everything you need; you can finally begin to practice your dev-sorcery. First, you must restate the problem using only the most fundamental information required:

Sally can paint a house in 3 hours, Jimmy can paint a house in 4 hours, and Sandy can paint a house in 5 hours. If the three of them work together, how long will it take for them to paint the house?

A good ol’ fashioned word-problem clears things up for you. Now, you get out a little notepad and a pen from your pocket-protector (not really) and work out the math:

Every hour, Sally paints 1/3rd of the house, Jimmy paints 1/4th of the house, and Sandy paints 1/5th of the house. Let the number 1 represent a house that has been fully painted and let x represent the total number of hours required for every painter working together to finish the house.

x(1/3) + x(1/4) + x(1/5) = 1

The hard part is now over; you’ve gotten all the information you need, you’ve wracked your brain (and your little notepad) to come up with a basic algorithm (you developers love that word) that you can use to solve the problem.

The easiest part of the job is writing the code:

public decimal GetTotalPaintTimeFor3Painters(decimal sally_hours, decimal jimmy_hours, decimal sandy_hours)
{

//the following equation is derived from x(1/sally_ hours) + x(1/jimmy_ hours) + x(1/sandy_ hours) = 1

decimal total_time = (sally_hours * jimmy_hours * sandy_hours) / ((sally_hours + jimmy_hours) * sandy_hours + (sally_hours * jimmy_hours));

return total_time;

}

The above function will get used in your application like so:

decimal time = GetTotalPaintTimeFor3Painters(3, 4, 5);

You find that on an average day, these three painters can paint a house in 1.28 hours, or about an hour and seventeen minutes. When the client eventually tells you out how much longer it takes each painter to complete a house under adverse weather conditions, you can use this same function to find the correct answer.

The problem given in this example is far simpler than most of the problems we have to solve on a day-to-day basis. The problems we work on typically involve many different (sometimes competing) requirements that must be reconciled to produce the right solution. Additionally, we often have to leverage different development theories and technologies to produce an expected result. How we use these tools takes us into the realm of dev-magic, but there is certainly nothing magical or mysterious about the nature of our jobs. All we require is a clear understanding of the problem we’re asked to solve and a lot of Diet Coke (i.e. Spunlogic programmer fuel).