Jess Likens

I was brought on as someone who could both bring the technology side of the house to the next level and amp up the agile practices of the team. I wasn't really sure what I was signing on for, but the challenges, and opportunities, seemed intriguing. I quite enjoy pushing people to achieve their maximum potential, and I see a whole lot of potential (both realized and untapped). I'm totally psyched to be working with a group of people who are willing to jump head first into new things, and I know we're going to make great things happen!

As an aside, as enamored with the Azure platform as I have become, I do have one complaint: they change things so fast that their documentation is often horribly outdated or sometimes missing altogether. I suppose living on the bleeding edge comes at a price...

<steps up onto his soapbox>

One of my special (or annoying, depending on who you ask) talents is the ability to carve out spaces in which "things" can happen. What kind of "things"? Well, fun things. Different things. Exciting things. As developers, we read about, and become interested in, new technologies and design patterns. At home, it's easy enough to tinker with these. At work, though, it's often difficult to take these new things and convince others to try them out.

Our managers (and their managers, and the Big Bosses), and sometimes even other developers, may balk at the idea of introducing something new. There are the usual grumblings of, "It'll cost too much to do that," or, "I don't know how to estimate against a technology I've never used," or my personal favorite, "We'll add that to our backlog of technical debt." I find that, "No," as an answer given simply out of fear of the unknown is severely limiting and ultimately self-defeating. You can't grow personally without trying new things, evaluating how they're going, and adjusting accordingly. Similarly, organizations following the mantra of Change Is Scary will eventually find themselves having to perform company-wide overhauls, involving expensive reverse-engineering of existing systems, user retraining, figuring out how to transitition from old to new, etc.

Do not go where the path may lead; go instead where there is no path and leave a trail.

Walking trails blazed by others can take you to some really neat places where you can see and learn lots of fantastic things. For me, though, there is no greater thrill than veering off in my own direction and leaving a trail behind for those who are adventurous enough to follow.

</soapbox>

So what's with all the soapboxing? I promise there was a point! I was very fortunate to have been able to enjoy a great deal of freedom to trailblaze at VCI, generally with good results. There is a space that exists between corporate paralysis and developer anarchy that is small, tumultuous, and very rewarding. I was at VCI for a long time, and I made it my mission there to occupy that space as much as possible.

We started with an organization that was completely waterfall, thoroughly siloed, and reluctant to adopt new technologies and practices. We transformed it into a place where agility is valued, cross-functionality is promoted, and new technologies are embraced. Despite the fantastic technical achievements I've had the pleasure of being a part of here, I'm most proud of those instances where we were able to convince the Powers That Be to take a chance and try something new.

The startup atmosphere was invigorating, and I threw myself into the fray with enthusiasm. In short order, I found myself being asked to be the team lead for the group that was ultimately responsible for the rearchitecting and rewriting of the main TickesNow ecommerce site.

We were under an extremely tight deadline to accomplish this monumental task due to the company's desire to be acquired. We leveraged scrum to try to wrap our arms around the constantly changing requirements and shifting priorities. While we certainly made our fair share of mistakes, I was immediately fascinated by this new way of organizing the chaos that inevitably surrounds software development.

Designed and developed a taxonomic e-commerce website under an extremely aggressive timeline. Organized four development teams using scrum methodologies. Scheduled and assigned development tasks to team members. Conducted and oversaw test driven development. Acted as a conduit between the technical, marketing, and business units. Responsible for the technical interview process for the web technical unit.

This was a fun gig. It was my first all-remote project, so I had to reorient myself to the new work-from-home reality. After a few initial hurdles, I hit my stride and found myself being asked to be the lead developer on my first major ASP.NET web project. Granted, the dev staff was only two people (including me), so "lead developer" is a bit grandiose in this context. Nonetheless, it gave me the opportunity to understand what others look for in a lead. I had my fair share of humbling moments, and in so doing I learned that listening is generally more important than commanding.

The lesson that small, focused teams are faster than large, diffuse teams was not lost on me. You read about this, but there is no substitute for experience. With speed comes the need for flexibility, otherwise you can wind up running headlong into a brick wall. Requirement changes came fast a furious, and while this occassionally resulted in some heavy rework, more often than not we were able to accommodate these changes. This really drove home the point that there is a fine art to striking a balance between speedy delivery and high levels of abstraction and decoupling. It is virtually impossible to write code that is 100% "right" from the get-go when the definition of "right" is a moving target. SOLID can take you a long way with respect to making your code flexible to downstream requirement changes, but taking these principles too far can cause gridlock. Working with Anheuser-Busch, I had the opportunity to learn to fine-tune the balance between "good" and "perfect".