Sunday, May 25, 2014

Confessions of a Type 2 Developer

I recently read an article that divided workers into two types and illustrated the second type with a story about a child building a sand castle. I can't remember if this was a blog post or a Facebook post. I'll try to outline the gist of what I remember about the two types of workers.

Two Types of Workers

We visit a small, undeveloped village built about a mile away from a small river. Every day, the men of the village go down to the river and retrieve water, filling cisterns with what they bring back. These cisterns are used to draw water for the people to drink or water their crops. Most of the men (we will call them Type 1 Workers) carry back enough water to fill one cistern each. However, there is one man (we call him a Type 2 Worker) who only brings back for his family to drink and they have to rely on water others retrieve to water their crops.

The Type 1 Workers scoff at the Type 2 Worker because his contribution is so much smaller. However, one day, we see that the Type 2 Worker has completed a project that completely upsets the balance. He's built a wooden channel that diverts water from the river directly to the village. There is no more need for people to walk a mile to the river and back to get water.

The tables have turned now. The Type 1 Workers feel short-changed because they have been performing so much more work for so long, but now the Type 2 Worker is getting the attention because of his project. The Type 1 Workers have been working a lot longer and a lot harder, but the Type 2 Worker has invalidated the need to do that anymore and is getting more attention for his time-saving project.

The illustration that accompanied this story was about a child who had built a sand castle some ways up from the high tide mark. However, he wanted to have a moat and realized that, whenever he brought water up from the sea, the water was quickly absorbed by the sand. In an effort to keep water in his moat, he started digging a channel from the level of the sea to his castle. It wasn't long before more people joined in and helped him build his channel to keep water in the moat around his castle.

Two Types of Developers

As in the story above, there are also two types of developers. Most developers are Type 1 Developers who, familiar with an existing set of tools and overwhelmed by deadlines, stick with the techniques they know and write their code using those techniques. A few developers are Type 2 Developers who, frustrated with copying, pasting, and tweaking code over and over again, search for ways to simplify the process. These Type 2 Developers are meeting some of the same deadlines, but they are willing to risk missing the deadline in order to divert a little time here and there to build automation and write templates that they see as time-savers in the future. "If I can get this right, this process will be a lot easier."

I am a Type 2 Developer. I love to build tools. I was building tools from the time I was asked to build a menu-driven console application with no functions longer than ten lines (including whitespace). Where most of my classmates built switch-case statements that ran hundreds of columns wide in order to fit within the line count limitation, I built a template object that allowed me to simply write menuObject.AddCommand(funcToRun, keyTrigger) and the object handled the rest once I wrote menuObject.GetCommand(). One of my first development jobs was in a shop that used C/C++. When I was confronted with functions over 3,000 lines long, I started finding ways to reduce the line count. Since then, I have consistently looked for opportunities to build tools that reduce development time.

The trade-off is that I sometimes spend so much time working on the time-saving device that I start running into problems with my deadlines. Of course, one such as myself is never quite happy with the time-saving device. "I wonder if I can get it to do this." "I wish it could do that faster." "Let me see if I can use this technique I just read about."

There is a great sense of joy when you develop a time-saving device and other developers discover it and like what you've done. If you find yourself writing the same code over and over again and tweaking it only slightly, try finding a way to automate it and experience the euphoria that results when you use your automation time and time again.

Wednesday, March 26, 2014

Good Coding Practices and the Real World

I was reading a blog post by Adam Cameron, An Insight Into the Mind of a CFML Developer, and, like Adam, had some similar thoughts to what Adam and others from the development community said. The essential gist of the comment that started this was, "ColdFusion used to be such a simple language; why did you (the developers) have to make it so complicated that an amateur can't master it anymore?"

It was attractive because it was easy and easy to make a database enabled application.
ColdFusion is still an easy language to learn; that has not changed. It is easier to make a database-enabled application in ColdFusion than it is in any other server-side scripting language. I've made database-enabled applications in ASP and PHP, too; ColdFusion makes it easier to develop database-enabled applications than either of those.

I think the community has ruined CF.
Everyone is entitled to their opinion. I think that ColdFusion has improved a lot from where it was. I've worked with CF5, CFMX7, ACF9, and ACF10. With a college education primarily using C++ and field experience in C/C++ and Delphi, I watched ColdFusion as it grew. Saying that CF has been ruined is like telling someone they're ugly because they don't look like a baby anymore. ColdFusion is no longer a child. It's more of a teenager: a bit gangly, still growing into adulthood as it attempts to mimic some of the more mature languages.

Ya all want to code in java script make everything OO, put everything in a cfc.
I love the black-box effect that object-oriented programming affords. Apparently, this poster does, too, but doesn't realize it. On the one hand, the poster says that he likes how easy it is to make a database-enabled application, yet doesn't like object-oriented programming. Object-oriented programming is at the core of modern, reusable code; it allows you the developer to simplify the tasks you do all the time.
Of course, that previous paragraph is making the assumption that developers want to make things easier for themselves. I specialize in tool-building, in making it easier for my co-workers and myself to complete tasks. Some developers like "job security", though. They don't want to build on their skills because doing so raises expectations. They don't want to make it easier to do tasks because doing so raises expectations. They don't want to make it easier for others to do the task because doing so reduces demand. In maintaining low expectations, these developers have allowed themselves to remain gainfully employed while stagnating developmentally.

make a bunch of simple stuff terribly complex.
This appears to be the proof of stagnation. Any developer truly interested in growth will realize the shortcomings of his own tools. You design a tool to do the best you can possible design it to do and, down the road, realize that you need it to do more or that you can make it work more efficiently. So you revisit your tool, apply lessons learned, and make it more powerful, more efficient, faster. This is as true of a developer working on his own tools as one who writes an IDE. C++ as a language has not changed significantly in the past few decades, but the compilers and libraries available for it have changed dramatically.
Phone gap mobile apps just add to that.
A ColdFusion developer is not required to build websites that double as mobile applications. With all the programming experience that I have, I still haven't written mobile applications or responsive websites. I have not been required to do so to this point. Would I like to? Yes! Am I terrified of it? To a certain extent. Why? Because I haven't done it yet. Treading into unfamiliar territory can be daunting, but it's the recluse who never steps out of his comfort zone because he's confronted with the vastness of the outside world.

CF should be simple, auto generate everything, and make all the jquery bs and the ajax that goes with it be behind the scenes.
Again, the disconnect between wanting a language that's easy to use and not wanting something that's object-oriented. ColdFusion does offer this. Compared to other languages, ColdFusion makes it super simple to make AJAX-enabled applications. You can generate an AJAX-enabled webpage without writing WSDL or any JavaScript using ColdFusion because of ColdFusion's UI tags. If the programming community is disgruntled with the quality of ColdFusion's implementation of these UI tags, the programming community has the same right to free speech that you have; if you don't want to hear it, you don't have to.

CF was once easy and simple and I could hire an 8th graded to code it, and it worked great.

ColdFusion is still easy. ColdFusion is still simple. You can still hire an eighth-grader to code in it and they would probably do a better job of it. Why? Eighth-graders are still adventurous. Got a problem with your computer? Consult your nearest ten-year-old. They're not bound by the fences that most adults have built for themselves: "I don't understand this new-fangled technology." "I don't think it can do that." "I've tried going in there and I just can't understand it." "People will think I'm stupid if they see me reading the manual."

Let me put this a different way. When I first started with ColdFusion, I found the ColdFusion UI tags and used them. I liked how they simplified things. Then I wanted them to do something more or do something a little different. They disappointed. I ended up writing my own custom tags to simplify display, grouping, and aggregation of data in a grid. I wrote my own tab control and then revisited it to utilize the jQuery UI Tabs widget. I wrote my own custom tag to handle pagination. I started using the jQuery UI Dialog widget. I started with the ColdFusion UI tags and migrated as more was required.

I have my qualms with ColdFusion and I'm not afraid to say that. I do take issue with developers who have lost the desire to continue improving themselves. I hope that such developers do not become the educators of future developers.

Saturday, March 8, 2014

The Imperative Programming Life

Freedom Needs Fences

Last year, I gave a presentation to a group of people regarding fences, both actual fences and metaphorical fences. What is the purpose of a fence? For many people in urban areas, fences silently tell us, "Do not trespass," or, "This is private property". In certain cases, particularly around construction sites, fences are a safety precaution: "Enter at your own risk." In rural areas, fences are often used to set aside a safe area, whether you're setting aside an area safe for your livestock or an area safe for your children. In certain cases, the "dangerous area" has an exclave inside your "safe area", such as a well, so you build a fence around it.

What's the point? Many people, particularly in the United States, have the impression that freedom means "no rules". Freedom means doing whatever you want whenever you want to do it. Is that true freedom? If we rid the world of all the rules and there were no legal consequences for any and all actions, what would happen? How long would it be before robbery and murder were again outlawed? How long would it take before people started developing their own rules of law again?

Freedom does not mean "no rules". True freedom means having just the right number of rules with the right amount of leeway to interpret them. What would we be saying if we removed the fence from around the well: "You are free to fall into the well and kill yourself." Would you do that if the well were fenced in your children's "safe area"?

Anyway, you get the gist. One of the other ideas that I presented were some of the metaphorical fences that we build for ourselves. How many of your day-to-day tasks do you do in a specific order and no other? Most pilots follow a checklist in a specific order and don't deviate from it. They do this to make sure that prerequisites are met, safety concerns are addressed, and everything is in order before they take off. When you get in the car, do you do things in a specific order? Have you made a mental checklist for getting into a car and for getting out of the car? These are metaphorical fences designed to prevent doing something potentially dangerous or costly, like driving without the seat belt engaged or forgetting to lock the door when we get out of the car.

Morning Routine

I am a morning person by training; I am a night owl by heritage. My parents were night owls, my brother and sister are night owls, and I usually stay up all night with them when we're all together. However, I have had to learn how to get up and operate in the morning and, by and large, I am usually required to get up in the morning. Gone are the days of sleeping until 5 p.m. like I would on Saturdays and Sundays during the college term. Gone are the summer days where I slept all day and studied Latin all night.

I understand the dangers studies pose about hitting the snooze button. When I was teaching myself to be a morning person, I also learned how to wake up and operate with the first alarm and try not to hit the snooze button. I've not been totally successful, but I wake up more completely and quickly than anyone else in my household on the weekdays. This essentially means that I am the driving force behind the family's morning routine, particularly in helping my son get ready for school.

You got it. There's a routine. There's a mental checklist. Believe me, if I do something out of order on that checklist, I've lost time trying to figure out where I am, what I've done, and what's left. I stick to that mental checklist because, if I deviate from it, my wife may not make it to work on time, my son may not make it to school on time, and I may not make it to work on time. I've built this elaborate, metaphorical fence to prevent those consequences.

Metaphorical Wells

Another metaphorical fence we sometimes build for ourselves crops up when we use complex machines, like household appliances and computers. The more complex the machine, the less most people tend to know about the available functionality. Do you understand all the ways you can operate your microwave oven? Does your stove do things you didn't know it could? When you use your word processing application, are there huge areas of functionality that you've never explored? Do you even know they're there?

I venture to say that most web programmers don't know all the tags available in HTML. Most CFML programmers don't know all the CF tags and functions available in that language. Don't worry: I've got three fingers pointing back at me and I know it. We've found what we need to get along and, to a certain extent, fenced off the rest until we're good and ready to explore those areas. Many programmers, comfortable with their knowledge of the language and uninspired to expand that knowledge, may never explore those areas.

Let's look at the well now. Are there portions of your word processing software that you used once upon a time and it didn't work correctly or didn't do what you expected it to do? Did you find a workaround and never try using those portions again? That's another fence. "The software says it can do that, but it's buggy, so I do this instead." Are there similar aspects of your language of choice that you avoid because you never got it to do what you expected it to do or it was broken?

The Imperative Programming Life

My son recently got on another of his stints watching the same movie repeatedly. This time, he was watching "WALL-E". On our way home from school, he was asking me some questions. There are three main characters who are computer-driven: WALL-E, EVE, and AUTO-PILOT (nicknamed "AUTO", which comes out sounding like "OTTO"). These characters and others in the movie are given "personality".

My son asked me, "Why didn't AUTO want to go home?"

"AUTO was programmed not to go home."

"But the captain said it was ok. Was AUTO afraid to go home?"

"No, AUTO was programmed to obey commands. He was commanded not to go home. Remember: Computers are really stupid; they're just very good at following instructions."

He then transitioned: "Why did WALL-E keep cleaning up?"

"That's what he was programmed to do."

"But there was nobody left. Why did he keep cleaning up?"

"Did someone tell him to stop?"

"No."

"Nobody told him to stop, so he didn't stop."

Do you find yourself performing actions a particular way, in a particular order, hesitant to change because you're afraid of the consequences? Do you continue doing something, even when it doesn't seem necessary anymore, simply because you were never told to stop?

Credit goes at least partially to my father, Norman Rowe, for the "Computers are stupid..." quote. I don't know if he got it from someone else, but I got it from him.

Saturday, March 1, 2014

The Transition from a 9-to-5'er

In reading some other blogs written by other programmers, I realize that I have long been deserving of the term 9-to-5'er. In fact, I was aware of the symptoms long before I realized there was a term for it. I knew that I would only program when I was being paid to do it; I couldn't build up the motivation to do programming on my own.

Did I lack interest in developing my own projects? No! It was simply a question of willpower. I couldn't make myself sit down and start something new nor could I find a project out there that I really wanted to work on.

Here I am now. For more than a year, I have been designing a very complex application in my head. I set up CFWheels on my computer, I've got Resin running, and I even drew up some graphics. But the code for the application isn't coming. The ideas multiply, the database structure grows in complexity, but all of this remains vaporware.

This is a business application that I want to develop. However, I am wanting to bring together two concepts that mesh nicely together. The one is this concept that employees enjoy working with business application software that feels like a game. The other is the Nurtured-Heart Approach, which encourages parents to reward (and discipline) their children in much the same way that a game does.

I've also been working as a government contractor for more than a year. Government websites must be accessible to people with disabilities. So I find myself struggling with more questions. How do I make business application software look and feel like a game yet not sacrifice accessibility?

I realized this week that, as with so many other things, I should start small and build from there. I won't work on my massive project yet. I will wait until I've gotten myself into the habit of developing at home.

To that end and others besides, I will try to learn how to write HTML games. I may start by writing educational games, since I may have an audience for those already. I will learn how to write accessible, responsive websites, because some of the members of my audience are learning-different and many of them have mobile devices.

Wish me luck in my transition. Hopefully, my blog won't die with but one entry.