Monday, February 18, 2019

My Issues with the Agile Team Room

DRAFT: 

I think I'm an introvert.  I like sharing my knowledge and learning what others know but I don't prefer large groups of people. I prefer to be alone most hours of the day.  Being comfortable by myself contimplating problems has helped me in my career as a web developer so far.  I've worked on large distributed teams also and had little trouble.  I'm an expert at digital communication tools. 

I think I have been a very good teacher and mentor to my more junior developers but I don't micromanage and let them have time alone to figure things out.  I've forced myself to be outgoing and entertain the team when I needed to but prefer to be a tag along during outings.

So now that you know all this, I'd like to discuss Agile Team Rooms and my preferred work space. Team rooms and my home office are on completely opposite ends of the spectrum.

Working on an Agile team requires a lot of informal communication and quick feedback.  I'm all for that.  I dislike waiting when it's easier for a quick timely conversation, even if it interrupts what I'm working on, I understand.

I just can't emotionally handle being that physically close to other people all day.  Every day, all day long sitting within inches of someone else makes my skin crawl.  When I have to lean up in my chair so someone can get up to go to the bathroom, that's just not enough work space for me.

I've worked in this sort of space once before.  It was called the "contractor room".  It was in a space at Exact Target (now Salesforce) that was organized to fit as many contract developers as possible without burdening the floor joists.  That space seemed temporary though.  Once a contracted project was over or a contractor hired on permanent, they moved to a more open space with some privacy and quiet.

After researching Agile Team Rooms, I have found that it was very popular at first back around 2010 but has become less popular.  Another term used was "War Room". The issues with war rooms came after the "Death March" projects that went on in them.

I haven't found a lot of writing on war rooms as the only work space for a developer.  The war room seems to be a concept to be used at crunch time and short term projects.

I've come to the conclusion that I'm working in a space that isn't good for a person with my personality traits.

Perhaps a room with slightly more space would be better?  Mixing developers and others isn't the idea but elbow room would be nice.  One could still come over anytime for quick feedback but not eat their sandwich and smack their lips while someone is trying to code.

I need to find a remote job.

Monday, January 28, 2019

SQL Saturday Cleveland 2019

Time:  Feb 2

Alan and I haven't spoken together for a while.  I mean we talk often but not presenting in front of an audience. Last year, Alan and I submitted our Grudge Match: XML vs JSON session to Cleveland and were delighted when chosen.  It's a lot more work to coordinate with a speaking partner when choosing when and where the both of us can be.  I'm really glad it worked out again.  The responses we received the first time were great.

Place: Cleveland

Northern Ohio has a vibrant .NET and SQL community.  Cleveland puts on several meetups each month and a couple yearly events like SQL Saturday that bring a large number of people together.  The larger companies like Hyland have great facilities and share them with the community and put on great parties.

Cleveland is great. It's a big event with great crowds that give awesome feedback and support. Sometimes with other venues there are issues but I have found that Cleveland really never has many.  I've been impressed with every event and meetup that I have spoken at in Cleveland.

Talk: Grudge Match: XML vs JSON

The format is a match between two technologies and two speakers.  Our session is interesting because it points out a few basics that professionals always need to keep in mind but on a pretty advanced or niche use case.
  • Never forget the internals of SQL Server
  • Test everything for performance not just easy coding patterns