In the design and development world there is a lot of talk about constraints and embracing them to foster creativity. I love this movement and subscribe to it (at least I try to).
One thing that has slowly crept up on me though is that this type of attitude is starting to gain some real ground in the music world. Historically it would seem that sometime after the 60’s and the era of the power trio, musicians decided that adding more to bands was the way to go. Another guitar player here, a keyboard there, heck throw in another drummer and a triangle player for good measure! and even more so lately you have big bands like The Go Team (7+ members) and The Arcade Fire (5+ members). Now I don’t have anything against any of these bands (in fact I love the go team and the arcade fire), but it seems like the culture of bigger is better is getting out of hand!
Now I know in recent history the popularity of electronic music has soared and often times is a single person mixing records or composing using a computer this doesn’t seem as revolutionary to me as the advent of small rock bands.
Lately, and especially with new rock type bands you are starting to see a lot of 3 and 2 person setups
- Death from above 1979 – bass and drums
- Rodrigo y Gabriela – 2 guitars (fantastic too btw)
- White stripes – Guitar and drums
- Yeah Yeah Yeah’s – singer, guitar, drums
- Muse – guitar, bass, drums
These bands are realizing that great music can be made with less, embracing the constraints (whether by choice or otherwise) and not only succeeding but excelling at what they do.
Where have you seen people embracing constraints? Or creating constraints to foster creativity? I think it’s a fascinating topic and would love to hear more about it.
Tomorrow, the Mozilla foundation is releasing the latest version of the Firefox browser. While they are at it they are also trying to set a record for the most software downloads in a 24 hour period. If you aren’t using Firefox tomorrow would be a great time to try it, it really is one of (if not the) best browsers you can use.
Why can’t I do that?
16 Jun
Posted by jonezy as Uncategorized, awesome, design, development, google, software
I just had to post this video I came across the other day, it’s a google tech talk and the presenter is Aza Raskin (Son of Jeff Raskin, the guy who started the macintosh project for apple). He’s also one of the founders of Humanized who make the most excellent Enso launcher product, a company and product that I am a huge fan of.
Anyways, this is a fantastic video on the topic of “Humane Computing” and I think it’s well worth your time to sit down and watch it all the way through.
Birthday Contest @ CodeSqueeze
08 Jun
Posted by jonezy as awesome, blogs, development, friends, personal, software, twitter
Max Poole is holding a contest at his blog to give away a copy of Bamboo 2.0 (continuous integration software) and a copy of Slick Edit (suite of add-ons for visual studio)
I’ve never used the Slick Edit product but I’ve got lot’s of experience using Atlassian products (Jira and confluence) and would love to get my grubby mitts on a copy of bamboo since I am a huge fan of the other Atlassian products I’ve used.
So head on over and find out how you can win some of this software (hint, writing a blog post about it get’s you 25 tickets in this raffle style give away)
For the past 2 years the amazing sales team that I work with at Q4 Web Systems have ventured out to San Diego for the annual NIRI conference. It’s a really important event for us and it’s always great to hear about it when the team get’s back.
This morning while I was going through google reader, I noticed this post from IR Web Report talking about some of the newer social networks (twitter and friendfeed specifically) and NIRI’s presence on both of those social networking sites. There is a friendfeed room dedicated to this years conference and you can follow niri08 on twitter.
I was really excited to see this, as part of my job going to these events doesn’t really make sense for me personally but I’m always really excited to hear about the event afterwards. This year it looks like I’ll be able to follow the event a little more closely and share in the experience even though I won’t physically be there.
It’s great to see these newer technologies playing a role in business sector that’s just starting to realize some of the potential of these new networks, it goes a long way to prove how valuable some of these services can be.
So as part of our company alignment and implementing the Rockefeller Habits at Q4 our quarterly theme was moving rocks together. We set aside a room with a video camera and plates with peoples names on them, if you felt the urge to recognize someone you could go into the room and record a short video message and give the person a rock. The end result would be that someone would *win* and get a prize.
Well we watched all the video’s today, which was hilarious and very very inspiring at the same time. It’s amazing that you can work with a group of people every day for months and years on end and sometimes never know what they are doing, seeing those people recognizing and rewarding there peers is a great way to better understand what the people you work with do on a daily basis.
Anyways as part of the moving rocks theme, the person with the most rocks at the end of the month would win a prize, and much to my surprise I was the winner this month (the first month). I’ve got to say it’s a great feeling being recognized and rewarded by your peers (this months prize was 100 at Canyon Creek). Even though it was me that won this month I think this is an amazing step for a small company to take and really makes me feel appreciated and valued.
One thing I personally have to do for the next month is give out more rocks, I want to make sure someone else wins next month and this has just inspired me to give those rocks out. If anyone at work is reading this, you guys are all an integral part of an amazing team, YOU ROCK!
I was working on some code today and was getting ready to do a check in and I thought to myself, should I be checking this code in? I made tiny change that would end up being part of a bigger refactoring of some tests I was writing, I wasn’t sure if I would be working on the refactoring again in the short term so I figured I would check in what I had done, even though the unit of work was small, it was done and left the project in a running valid state.
The longer you wait, the more painful it will be
Kinda like ignoring that aching tooth, or that tweak in your back, it can wait it’s not that serious right now is it? I’ve seen much of the same attitude when it comes to working with source control systems. Developers will work on a task and not check in any of there changes for sometimes weeks. This often time’s leads to code conflicts and merging tasks because the developer waited so long to check in.
Check in early, check in often
The project I am working on at the moment is a small wrapper for the 37 Signals backpack api. It’s just me working on it right now so conflicts are unlikely, but i still check in any work that i have done when I leave the application in a valid state, even if the complete task isn’t done. For me it feels like the right thing to do, I can be sure that the repository is always in a state that works (if someone else ever felt like contributing) and it also helps me sleep at night knowing that if for some reason my laptop decided to off itself during the night, my project is still there ready and waiting for me.
jonezy.org.BackpackAPI
27 May
Posted by jonezy as awesome, development, open source, personal, web2.0
Is the reason why I haven’t been posting here, I’m working on building a c# wrapper for the 37 Signals Backpack API. Nothing terribly exciting yet (I’m basically just implementing the services per the api docs). I’m hosting this at Google Code and this will be an open source project. I’m also taking the time to try out doing Test Driven Development. I’m pretty happy with how that’s going so far, but it’s a new process for me so it’s taking some time (though I’m happy to report i have 33 tests for 13 implemented methods!)
Future plans include (some might happen, all might never happen)
- an offline version of backpack
- a to-do list application that is driven by backpack lists
- a WPF client for doing various backpack things (reminders, journal and status updates)
- update status on multiple targets (backpack journal / status, twitter, pownce etc)
If you are interested in this at all please have a look at the code and let me know if you are interested in using it or contributing. Oh and any / all feedback is great too.
What do you do when the shit hits the fan?
13 May
Posted by jonezy as business, development, q4, software, work
To cut to the point, I was promoting some changes for a client last night. It was an update to part of our product that allows our customers to send automated and one off emails to lists of subscribers. I had done promotions similar to this in the past (in fact i’ve probably done the same thing maybe 100 times). But somehow, someway I managed to screw up. Not a small screw up either, I accidentally sent a test email message to the subscribers of one of the clients email lists.
That doesn’t sound so bad?
Sure it might not seem like a big deal, in fact I wasn’t even aware of it until the client pointed it out to me (there is nothing worse then this, NOTHING). You see our customers are publicly traded companies, and the software we develop helps them streamline and manage disclosure around their websites. I with an accidental mouse click had caused some level of damage in there shareholders eyes. I don’t even have to tell you the anxiety and frustration I felt when I was alerted to what I had done.
Ok, that’s bad
Yes it was bad, it was too late to undo anything so it was time to put into play this great saying one of my co-workers has:
First, get the cow out of the ditch, then figure out how the cow got in the ditch, and then make sure that cow never goes back in the ditch.
It has nothing and everything to do with software development all at the same time.
Obviously getting the cow out of the ditch was out of reach, but there were some measures that could be taken to ease the impact on our customer. I recommended that they send a one off email to the list that I had accidentally sent to, simply explaining that a test message was sent in error, they thought this was a great idea and did it.
Next, I had to examine all the various steps I had taken trying to reproduce what I had done. I had opened the wrong test email and sent it, an honest mistake but one that can’t ever be repeated again.
With that information in hand I put together some process recommendations for our company internally to implement when promoting these kinds of changes, as well as some product changes that could make this same scenario much more difficult to repeat in the future.
So in the end it worked out ok?
I guess if you look at it optimistically, yes everything turned out ok. For me, this was a situation that I was not comfortable with happening ever again. Fortunately the people I work with let me handle the problem start to finish, they didn’t breath down my neck and demand answers right then and there, they trusted that I would do the right thing, plus the client who was initially annoyed and frustrated appreciated the constant communication and recommendations that were made.
So what do you do when the shit hits the fan?
I’m sure this has happened to many a software developer. What do you do when this happens to you? I would be very interested in hearing about it, I think these hard learning lessons are ones that should be shared, never swept under the rug. If we can’t reflect and learn from these mistakes we as individuals and groups will continue to make them over and over again.
Found this while reading blog today, I’ve tried to explain twitter to a lot of people but this pretty much sums it up in about 2 minutes, what more could you ask for?
(video source: http://www.commoncraft.com/Twitter)
« Previous Entries
