From an Empty Workspace to a Work of Art

Ok, so I've been working at this awesome new company for a month now.  In that month, I have worked from home a lot of times.  I think I was only downtown for six or seven days in March.

Much has been written about setting up your remote workspace to feel official, and more like you're working, as opposed to sitting on the sofa on your laptop in your PJs.  Remote work requires incredible discipline, and part of that is mentally partitioning your home life from your work life.

But mental partitioning is hard.  It is handy to have some sort of physical partition.  We do have a den with a computer in it, but it's not a dev machine, and that's where Nicole works.  I decided a while ago that I'd make my space in my basement.  But it's an unfinished basement, and there are no physical partitions.

So I decided to physically partition my space.  Not just for separation, but so that when I was on webcam, I wouldn't have an unfinished space as my backdrop.

But I'm not really in position to do a basement remodel at the moment.  So I figured I'd do what they do in the movies and stage shows.  I'd create a set.

I have a couple old stands that I once built for a garage sale.  They were originally meant to last two days and to allow me to hang some rigid 3/4" metal conduit between them to use as a clothes rack.  Instead I've used these two supports over the intervening years for all kinds of things.

For example, I have used them as something for Gamble to paint on.  One day out of the blue, I opened up some cans of old house paint, deck-screwed a plank of plywood onto the uprights and let Gamble go at it. You can clearly see the uprights here.  And this was seven years ago.  And these were repurposed then. Also, this video has one of the best punch lines of any I've ever shot.

I dragged these scraps of wood to our new place.  Since then I've used them as temporary uprights, laid down as a stand for when I'm bottling homebrew (it's perfect for the bottling bucket to sit on), and a number of other things.

As I mentioned earlier, I don't have the ability to do a full room in my basement just yet, but I need something to make it appear I'm in an office, so I repurposed those uprights by hanging a leftover 4x8 sheet of drywall on them.  And then painting it green.

It's leftover green paint from our living room, so it's quite a responsible shade.  I figured it would look very office-y, and it did.  I even hung a plaque and a That Conference camp sign on it.  And then I put casters on it, so that I could roll it in and out of frame as needs dictated.  And it was perfect.

But it was missing... something.   That certain je ne sais quoi that makes it me.  It was boring.

I will be damned if I can find the original art that inspired this project.  I have searched and searched and cannot find it, but if I ever do, I'll link to it here.  I'd seen a beautifully masked wall that was lovingly done up in geometric designs and then painted.  It was a phenomenal piece of wall art, and I figured that if I was going to have a little partial wall, I'd do something like that.

Because when you're presence is mostly online, your backdrop becomes part of your personality.  It's part of the setting.  Ze Frank has his steady backgrounds, and so does John Green, Ray William Johnson, iJustine.  Now, I'm not a vlogger, but if I'm going to spend a decent amount of time online, I'm going to need something immediately identifiable.  It's all about branding.

So I started with the wall, all by itself.  Here's a shot of it by itself from the back.  It's there in place in front of my dev rig.  Yes, I'm using the Peavey amp that I've had for about 25 years as a stand for my third monitor. That's the same amp I rocked out on for Random the other night, so it still sees use.

Here you can see the back of the wall. I've already started masking it.

And here's a closeup of the feet.  They weren't designed to be super stable.  They weren't designed for what I'm trying to do with it.  Yet do it, I have.

The little feet.  They weren't designed for this.  I'm no damned engineer, though I should have consulted with my stepbrothers, who both are.

And here you can see how I got started with the masking.  Gamble helped me at first, because my wingspan just wouldn't support it.  We put the first piece of tape on, then marked some dots an inch from the first piece of tape, put another piece of tape on with those lines, and so on.  The image wasn't really planned, only that I intended for it to evolve organically.

Some of the lines.  The first line placed was the leftmost long "forward slash."

Finished masking and ready for round 2.

So the idea was to paint this, but a single paint color is boring, and two is still kinda boring.  I've always been fascinated by street artists that do spraypaint work.  They get some incredibly realistic and sweet looking paintings from a few minutes of work and a few cans of spray paint.  There's some beautiful randomness here, and some beautiful order.

After all these years, he's still painting on these two uprights.

My vision here was for something nebulous.  Literally like the beautiful pictures you see of faraway space dust. My instructions to Gamble were, "Yeah, put some heavy blue paint there, but make it kinda random, and don't cover the green up completely, so that we get a cloud effect."

So here are all the colors of spray paint that I had and wanted to include.  I can't believe I had so much paint.  I'm sure Home Depot thinks I'm out taggin' and saggin'.

I admit I was skeptical at this point.  I look at the muddle of color there and think, Hooboy, what have I done?  That little random arc of red?  The shades of green and teal in the bottom right?  But I was confident that this was going to work, so I pressed on.  The next step was to add stars.  

Gamble and I had done this before, for a presentation he'd done on Exoplanets, planets beyond our solar system.  We took black poster board, sprayed white spray paint on our hands, and flicked the paint toward the board.  I did this here, too.  I flicked white paint as a star field over every part of the board.

Then I removed the tape.  This reveal was awesome.

This was just amazing when I saw it with the tape off.  

A closeup.  From faraway, you can see the blotchy color from the original, but close up, this really is a thing of beauty.  the strips of tape I took off the wall were as cool as the wall itself.

And of course, one more for the road.  I'm not explaining this shirt, though.  That's a story for another day.

BEAST MODE!

Well, that's how I got my new background.  Nicole insists that I need something more low key for the other side, so I can turn the wall 180 degrees and have a professional setting, so I'll probably do that, too. Anyone have a 4x8 sheet of drywall they can drop off? 

Group Coding, Benefits and Observations

A few years ago, I started up a weekly tech seminar in my organization.  We do everything from demos of new technologies, to sharing technical issues and solutions we found to them, to watching videos from the web of our favorite speakers on technical topics.

There's another thing we like to use this time slot for: group coding sessions.  We take a simple problem from Project Euler, and we code it up as a group on a projected screen.  The sessions allow the developers to share tips on tools, talk about the right seams in code, and

Someone asked me why we would code in a group, and I sent them the following

Benefits

Here’s the benefits as I see them:

·         It’s great for everyone to get to know each other. 
·         It’s great to work with other people and learn how to develop in a more collaborative environment. 
·         It’s great to create a more collaborative environment. 
·         It’s great for everyone to know everyone else on all dev teams.  Especially as some groups are more segregated than others.
·         It’s great to see how people use tools differently, as we all use things differently and become more productive as we work together on things.

So from an organizational standpoint, it’s all good.

That's what I said.  The details are a bit more complicated.  Let me talk a little bit about some overvations I've made and lessons learned.

Results

We've seen great results from working together in these sessions.

It's no secret that I am a big fan of NCrunch (I tweet about them from time to time), and that and ReSharper are two of our key dev tools.  We got enough licenses for every developer to use both, but people weren't really using them.  After seeing the tools in use as we do a test-driven style example, people come up and ask for their license.  Spending a little time coding together has meant that we get a better return on the tools we bought, in terms of usage (hopefully they learn to use it wisely).

We usually send out the solution after the exercise, so everyone can work on any finer points after the fact. We've seen people dive deep into an optimization, or work on finding analytic solutions to brute force problems.  It gets people thinking about something other than the features their day job offers them, and they seem to be really excited about these other opportunities (I'm using the proactive follow up as evidence here).

Further, you get some peer recognition.  Everyone contributes some code, and those people who can code get the kudos of their peers.  Better still, we've found hidden talent and enthusiasm in all our colleagues.  It's great to know who can do what, and it's great to give them props for doing so in a group.

I don't care who you are.  When you start out, coding in front of people is hard.  You have to let go of that ego.  You have to silence that little voice of doubt.  You have to get past freezing up.  And it's better to do it here than, say, during a job interview or a more important coding session at a conference, meetup, or Hackathon.  And everyone does it.  It's harder for some than others, but you see them grow in confidence, both in themselves and in their code.

One Big Observation

One thing that kills, absolute kills a group coding session, and that's negation.  Someone else writes a test and implements a method, and the first thing the next guy does is delete the body of the method and put in a pet implementation.  Maybe it's better; maybe it's not.  I've seen both, actually, and what is most important here is a concept straight out of the improv comedy world.  I know it's a weird place to apply the concept, but one of the core concepts of improv is that you never negate anything anyone else does.  You build on it. You manipulate it.  But you never simply say no.

Imagine a comedy sketch at The Second City that goes like this:

Milli: "And now I'm a T-Rex trying to make a peanut butter and jelly sandwich in a military cafeteria."

Vanilli: "No, you're not.  You're eating a pizza on the set of The Sound of Music."

And where does Milli go from there?  Vanilli has just taken the momentum out of the skit and turned things over on their head.  The same thing happens in a coding session.

The trick of great Improv is "Yes, and..."  In the Milli-Vanilli sketch above, Vanilli can do this by saying, instead:

Vanilli: "Yeah, and I'm a four-star general who walks in and does a double take as you cut the crusts off your sandwich."

Momentum saved, and the skit moves forward.

Yes, And 

So do this while coding.  Sure, someone may have just taken a misstep.  Maybe you see a more optimal way to do something.  Maybe you think your way is cleaner.  Keep that to yourself and don't negate what someone else has done.  Add to the example as is.  One of a couple things may happen. The example might evolve until it's obvious why your way might have been better.  Or you might learn something new.  Either way, I've observed that sessions that are allowed to evolve dynamically are more enjoyable.

Conclusion

I happened to be talking to Clark Sell on Friday during our That Conference call.  He's currently reading a book on Improv Wisdom, and said something very similar.  I haven't gotten to read the book yet myself, but I recognize the rule on the cover... "Just show up."  Which has a familiar vibe to what draws me to the tech community.  A big part of getting better is speaking up, doing, and making things happen with the people around you who also show up.

So get your code on.  Do it now.  Do it with your co-workers.  Just because you're dark matter, doesn't mean you don't matter.  You can do it.

Software Archaeology

What is a Software Archaeologist?

Most of us that work in corporate Information Technology shops are Software Archaeologists. Every organization I’ve seen and many I’ve talked to has a built-up layer of legacy applications that are old and in disrepair. While many of these applications are used daily, it may have been years since they were opened, rebuilt, refactored. The source code may be missing, and the original authors may be long gone from the organization, taking their knowledge of the application with them.

It’s this organizational brain-drain that turns many of us in corporate IT into Software Archaeologists. Every time a developer has to don his leather fedora and dive into an ancient codebase with little to guide him but a few cryptic comments littered in the code tomb, and a document that some long-ago intern put together in a half hour to meet a letter-of-the-law requirement in the then-current SDLC, that developer becomes an archaeologist.

Being an archaeologist means digging through all the various eras of coding.  Being able to parse the Scatter-Gather patterns in Visual FoxPro, say, or to unwind the data calls from the business objects that were once part of the popular CSLA methodology - those become part of your everyday toolkit.  What about that legacy web services architecture that passes around typed data sets everywhere?  What about that .NET 1.1 Remoting service layer you built?  You need to know it all, and to hop back and forth through the disparate layers, gathering golden icons and dodging rolling boulders all the way.

Even those developers who only develop new applications need to be versed in Software Archaeology, because nowadays many internally developed applications are on end-of-life platforms or hardware, being scoped for moving to the cloud, or are being revisited as part of Business Process Reengineering.  These developers need to get back into recently rewritten code and re-envision.  You have to know how to dig.

As a Software Archaeologist it pays to know not only today’s architecture, but those of the past, especially those that were popular in the organization around the time the code was written. But not limited to the standard architectures of the day. Organizations hire people who come in to try their hand at something new, or bring in some flavor-of-the-day architecture, tool, library. As a result, one-off applications are going to be unearthed. As architectures become archeological layers in the binary geological strata of an organization, so do architects become archaeologists.

I have a deep appreciation for all my colleagues who perform software archaeology on a daily basis.  Those whose jobs are just to maintain those applications that time has forgotten.

I respect the dig.