workflows and rough edges

I've got this new blog now, and I have to say that I'm a huge fan of WordPress, they definitely have created a great piece of software here. I'm going to split this blog post in two, half for my programming diatribe about workflows and the other half for some rough edges commentary about my new blog.

workflows

The idea of a workflow is central to software development, on a simple project your workflow might be

1. Type up some code


2. Compile or run the interpretter

This can get more complicated, here is a standard workflow with some sort of version control software in the middle

1. Type up some code


2. Build


3. If broken go to step 1, else go to step 4


4. Check-in changes


5. If necessary merge changes with server

It can get more complicated even still with test driven development.

1. Write up a test, make sure it fails


2. Write code until test passes


3. ...same as above

And when office bureaucracy get involved.

1. Write up test, make sure it fails


2. Write code until test passes


3. Perform necessary QA testing and UA testing


4. Submit changes for Code Review and Architecture Board Approval


5. Deploy changes to production environments


6. Monitor health of production


7. Pray nothing goes wrong, if it does, prepare for more reviews and meetings

[caption id="attachment_35" align="alignright" width="300" caption="flow"][/caption]
The job of a programmer is to program, the "Write Code" part of all the lists above, the job of a software developer is to be able to do that and navigate the lists of bureaucracies and procedures necessary to get their code into the user's hands. Now I'm not a bash the process person, source control, unit tests, and peer-review are all great ideas and serve necessary purposes. The great thing is that we are humans and our brains are amazing at internalizing these kinds of tasks and making them second nature.

There have been many times when I have been asked to document a process I've performed hundreds of times, only to sit there blankly looking at my empty word document, silently thinking to myself, "How do I deploy to production?" Normally I then do a dry run through the task, observing the stranger that takes over my body and knows how to do a production deploy. He works quickly clicking this or that, as I furiously document the procedure, he knows all of my passwords, even knows when to stop to ask me a pertinent question or two, but more or less he effortlessly autopilots his way through. I'll look at the documentation I've taken of the steps I just performed and sometimes the list is staggering, 23 steps, wow! In my head it is just 1 thing, do the deployment.

I don't currently have a major project that I'm assigned to, so I've been relegated to working on several smaller projects, none to complicated, the only problem is that I don't have the workflows down yet. This cause a major problem because there is a psychological theory of flow that states

Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.

None of the new tasks I have are difficult, on the whole they are very easy, but the fact that I can't get into a flow state means that I'm less productive than I normally am, and it is a little bit frustrating. This is why we dislike changing gears, this is why when someone distracts you even for a moment it can be dreadfully annoying, because getting back into that state of focus can be incredibly difficult. The new tasks I'm on are constantly pulling me out of the flow, I have to stop and think about how to get my code into this repository or that, what was the password again, where is the remote test environment, ugh.

When starting a new project or when documenting an existing project one of the most important first things to do is to set up your workflow. I'm going to have my source code right here (points at directory), and I'm going to edit it with this program right here (points at program), and when I've made a change I'm going to see if that worked by doing xyz, and when it works I'm going to submit my changes by doing abc. It seems like a stupid thing to do, you can easily figure out from one step to the next what you should do, but explicitly defining it in your mind will help you stay in the flow.

rough edges

New blog means spending some time making it feel like home. Here are some rough edges you will notice for a while until I get everything set up nicely again.

• In article links may link to the old ihumanable.blogspot.com version of an article instead of the new ihumanable.com version


• Syntax Highlighting is broken in many posts


• JavaScript is being escaped and so some posts that rely on JavaScript don't function properly


• The import process changed all my tags into categories, which feels wrong


• The css is the shine theme default, it needs to be tweaked to my liking


• The navigation on the blog isn't as nice as it used to be


• ihumanable.com redirects to ihumanable.com/blog/ which takes a noticeable second, I'm planning on putting a home page there that will also have links to software projects and other stuff I think is worthwhile


• Still need to learn the ins and outs and workflow (see above) of WordPress

The move was fairly painless but there might be some wonkiness for the next week or so, I hope to get some time over the next few days to clean up links, fix the scripts, and restyle some stuff, so bear with me.

If you have any suggestions or comments about the new blog now is your time to act, since I'll be doing work already, your suggestions might actually get implemented instead of just thrown down the memory hole like I normally do.