StandardPixel.com

Last week, in an effort to meet an impossible timeline, our team was asked to make a few changes. We were assigned 7 people from other teams. We also were asked to stay some extra hours and work the weekend. Our commitment was amazing. We worked for an entire week of 12 hour days. The lack of ego and complacency remarkable. This was not by any means my ideal way to spend a week but I understood what needed to be done and the consequences if the goal was not met.

Introduce 7 new people

to a team that has been working together and there are bound to be a few bruised egos. Think of the actors involved

• Heros - some people love to be the one person on their team that knows one subject better then anybody else. With 7 new people there are bound to be one or two people the will match or exceed that skill.

• Black Boxers - Some people just don’t like to collaborate. Maybe they are trying to hide a perceived or real lack of talent or maybe they are just anti-social.
• Power Grabbers - There is usually one or two on the team that aspire to manage the entire team. They can be arrogant, nosey, and pushy.

All of these types are toxic to a teams ability to gel. I am not absolutely sure how, but we seemed to have none of these on board. Sure we had our conflicts but everybody was genuinely glad to help. This is more impressive considering most of the new people were traveling from our main office, and are now more then 5 hours away from their homes and families. 

Management started off on the right foot,

We all got the impression early on that this was a short term push for an important goal. Most of us felt that the request was made with respect and we saw our management committing themselves at the same level. Every hour that we were there we knew that they were there too. Now beyond that they picked up our lunched, dinners, snacks, and even threw in 30 minutes of seated massage with the professional misuse. These gestures did a lot to keep the 12 hour days from becoming stressful, which would have been very easy.  

Agile methods were employed

in one way or another. It was not a proper Agile project but we had tasks, a burn down, standup meetings, and most importantly a time box of one week of which we all were made well aware. These key articles of Agile were the keys to any successes that week. Many to my team mates had never been on a proper Agile project. I do not think that anybody could deny the positive affect that they had even if they never credit it to Agile.

Lastly, sense of purpose

was the jet fuel that propelled most of us through the week. We were obviously convinced that the work that we were doing was going to affect the bottom line in more than a usual way. There was a sense of pride. 

This pace was astonishing though not as all sustainable.

By the final day of the week I did start to see cracks appear. Everybody on the team was obviously exhausted and creativity was starting to wane. The next week, (yes this one) seemed less productive then any before. This was not a bad exorcize though, we managed to build some strong relationships and get a lot of work done in a short time. I am not sure if I would recommend this as a way too save time because it seems like there will be more time lost as the team recovers their motivation and creativity. It is however a great way for a new team to gel.

This was my first year ever attending a conference so I have no frame of reference. I do know that I enjoyed just about every geeky moment. I was able to connect with other people who have been through or are going through a lot of the same things that I am in my career.

A major benefit for me

was that since I do not work at at company that uses Rails, so I am not immersed in the culture like other developers. I am surrounded by some of the most accomplished front-end engineers and I am thankful. My back-end technology of choice however, is Rails and at times I start to feel like it only exists in a lonely little world of my own. I try to make a point of listening to podcasts and reading blogs to keep me in the loop but there is obviously no feedback there. 

What stood out to me

was the after-party scene. Don’t get me wrong, I got a lot of inspiration out of the couple keynotes that I was able to catch but I would have come here just to meet the Rails heros. I am leaving Portland with so much inspiration to try some of the things that I learned.

The hard part

for me is that I am not a Rails developer at my “Day Job”. I have to go back and try to apply what I can to better my job as it stands. I am also, going to do everything that I can to do some Rails stuff on the side so that I don’t loose my momentum.

One year ago…

I was working in a relatively small engineering group in a company where I had tons of creative control over my work and made crap money. Now, I work in a massive nationwide engineering group where my opinion makes a difference locally but inevitably ends up getting lost in the shuffle when up against the sexier, higher profile projects in the company. Add the fact that my desk was in front of a huge window with a view of mountains and is now a panoramic of three cloth walls and the most intense office lighting. I started to feel that i was hemorrhaging all of my creative energy.

As a first attempt to solve the problem,

I started working out ways to work from home. This helped a bit but not for too long. Turns out I can’t stand being alone for too long. I had no idea how much I needed the action of the office. I also like the 3:00 pm coffee banter. 

Okay, so it looks like I need more ideas.

Then it happened…

At the worst of my inspiration slump, I decided to take on a few extra credit tasks around the project. One constant throughout my career is that in every job I start a side project. Somehow that project manages to play a major part in my next career move.

Giving it some thought it makes sense:

Side projects are not controlled by the business. It seems without the influence of product managers I am left with full creative control. 

Disclaimer: I am by no means diminishing the contribution of Product Management. I just think it is useful for a developer to have some sort of skunkworks project where he/she is not regulated by our level headed friends. This is why we have hackdays, I am just not that competitive.

My little contribution is a useful little piece of code that everybody needs and nobody had time to do. I am proud of the results and I am seeing the effects in a lot of ways.

I do love taking the train to get to work. It is a rare chance to stop and think or read a book. I show up to work less stressed and more focused. Today however, I forgot my ear buds. That was the longest ride ever. I couldn’t even concentrate on my reading. I think I have become dependent on a random stream of my favorite songs. I could simply be a great way to escape the random sounds and conversations from the people on the train.

One thing that can render any perfectly executed SCRUM planning session useless, is a broken development environment.

Once the backlog has been prioritized, and the team had generated a sensable amount of stories and tasks, teams are energized to start moving those tasks to complete. What is lost when that developer goes back to their desk to find themselves without a db to code against or a login server that just doesent work? A Lot!

What we stand to loose

Sure we all know that these type of outages will cost us backlog, which will translate to time subtracted from our sprint. But what we should fear more is the loss of the momentum that the developer had when he/she finished sprint planning. The developer is now frustrated and will likely not find that lost level of inspiration again. At least not easily. Lets be honest, a developer has very few actual hours of productive time in a work day. Take an avarage 8 hour day and subtract meeting, email, IM, and phone distractions. Lets also consider that most people need a fair amount of time of immersion to reach their most creative state.

Tools make all the difference

All of our distractions require us rely on our tools to be there and ready to go when we need them. This means that we need to spend some serious time planning our tools and how each developer will interact with them through out the sprint. Designers shouldn’t need to interact with code to create designs. Back-End engineers shouldn’t need to hassle with CSS. Also, Front-End engineers shouldn’t need to configure XML files and compile. We have the technology available to make real use of the MVC pattern yet I have witnessed a lot of projects start out with the assumption that everybody can easily run that ANT script or whatever. I can also say that every time I have see this I have seen time being wasted on complex troubleshooting by smart Front-End Engineers and Designers that have been reduced terrible Java troubleshooters.

What to do? What to do?

Excuse my possible ignorance, but in projects where the heavy lifting was done by java and accessed through the magic of web services by clients written in PHP or Ruby on Rails. It cant be a coincidence that these projects had far fewer wasted hours. The pieces are smaller and easier to manage. Each person is working on a smaller chunk of the bigger project that he/she understands enough to easily fix problems. I am sure that somebody would argue that there is far too much processing overhead in such a configuration but i wonder how that weighs against the lost time and creativity without it.

I want to share a pretty cool pattern for collaborating on JavaScript files.A little backgroundIn the application I am working on, we have a need to keep all of our JS in one file that is committed to subversion and included in the application. This one file is updated multiple times by members of our team and as a result needs to be frequently merged. Sure we could use includes of some sort to simplify this process but that has overhead of it’s own. I am sure that a lot of teams have more then one hand in the Java Script cookie jar at a time.The pattern

<script>

//Promoted Code

(function(){

	//Stuff

}())

//John's Code

(function(){

	//Stuff

}())

//Paul's Code

(function(){

	//Stuff

}())

</script>

What does this format offer?

1. Each developer (John and Paul), will have their own closure to keep their development code. This will give them the freedom to create variables without worry of collision with other developer’s code. This also will do garbage collection before running the next developer’s closure.
2. A “Promoted Code” closure exists to hold code that is production ready. This code will be moved from the specific developer’s closure when it’s development is over.
3. Merging is way easier when you know where your code is in the file.
4. Development code is placed after production ready code. This will allow the developers to rewrite objects in the production ready code if needed.
5. Most text editors will let you collapse code blocks in a closure. This will clean up your work area and allow you to better concentrate on your code.

This pattern may seem simple but those are sometimes the best kind. I have noticed a dramatic improvement in my ability to work on these files in collaboration with other developers.

Just about everybody is using a framework or library for something these days. It is the logical next step. When everybody that matters and their mother has weighed in and IT is done as ITs going to be, it is time to lock what ever IT is down. This allows us a foundation to start building a greater ITs, you know? In my newest role, I have formed a bias towards YUI for layouts and javascript though I am fond of a few other frameworks too. Working with these libraries hopefully will inspire developers to start thinking of their work as something that could be re-used. Ideally everybody will see each html document as an API that could be used in a limitless amount of future applications. Even if you are just building a simple page for a one-off project that may never see the light of day, it is still important to think your conventions through.

Javascript conventions

Well thought-out javascript does not stop at the framework level. Creating a huge blob of overly specialized functions that leverage a flexible framework seems wasteful to me. There is so much extra energy that can be harnessed from all of those development hours that you spent toggling the visibility of that light box effect (or whatever). Learn to step back from your specific implementation and write a reusable control. This control would be a simple object-oriented chunk of behavior with a clear set of descriptively named methods and properties. I like to spend a little time brainstorming other use-cases before I begin creating any control. Once your inventory grows a bit you can start promoting your controls to a larger library that can be used for multiple applications. I find that this model, at first seems redundant, but in reality reduces the over-all code on your properties. If you are a freelancer, I imagine that this sub-library can be something that you package and sell to your clients to add value to your product offering.

Markup conventions

Hopefully you are already separating your behavior and style from your markup. If not, read this. One thing that will help you to build reusable javascript controls is a good Markup convention. Every control that manipulates what the user sees will need to work with the markup layer in some way. A little time spent deciding on some adaptable code standards will save you tons of time. Most of this is done for you in the W3C spec. They have worked hard to come up with flexible ways to represent things like numbered lists and definition lists and you owe it to yourself to leverage them. Sometimes however, you will need markup for a more specific implementation that does not match a W3C spec. When that happens try to stay shallow and make sure it works constantly in all browsers. If possible it would be smart to document this convention so that your peers and successors can easily pick up where you left off. I like to think that most conventions can be positioned so that a javascript control will bind to a specific container on a page using a className, then gain access to child nodes of the container relying on your pre-defined markup convention as an API. I suggest using a class because it is possible that your control will be used more then once on one loaded document.

And a little about style

I like to think that this can all be done without applying styles such as font types, images, and colors. With a few exceptions this can all be done through CSS which by now should go without saying.This pattern is one that I have been perfecting over that last couple of years. I am a huge fan of using conventions where possible because, I hate doing the same thing twice. I am sure most of you can agree with that and a lot of you are already applying this in some way.