Today we have a guest editorial from Andy Warren as Steve is away on vacation. This was originally published on Dec 23, 2014.

I was reflecting recently on my first real IT job. It was a small-ish company when I joined it, perhaps a hundred employees or so, and still using a mishmash of software and a lot of dated hardware. We had one developer/sysadmin/DBA and a few people doing what we now call ETL and data cleansing. Not an elegant process, but one that absolutely was getting the job done. We had no change tickets, and the only development environment was on a developer's machine, with most changes deployed during the day. No QA team either. Interestingly all the code was in source control from the start. I guess in a lot of ways it was a startup, though I didn’t think much about it back then. Maybe it sounds chaotic, but it was challenging and fun. I learned a lot too.

As the company grew so did IT, and with it came the earliest silos: splitting up development and ETL. Hardware was upgraded, we hired a network/systems guy, and I became the first DBA, trying to figure out how to be a DBA and how to reconcile what I read about security and change control with the demands of the business and the realities of how much of the work got done. We grew a little more and the walls between the silos got higher. We started to add process because what works with one developer doesn’t work as well when you have ten. We needed a help desk to manage the calls and a task tracking system so we could manage the work. It took longer to make changes because the system was more complex and that meant it took more time for new hires to figure out how it all worked. We started moving away from the hero model and arguably away from cowboy coding, but it was still an environment that most of us today would consider lightly structured. Even back then then it felt like our velocity was slowing as we added process.

Since then I’ve worked in far worse/less mature environments, worked with teams where even small changes took 90 days to work through the process, and a lot that fell in between those. I tried to find something to like and to learn about all of them. I get process and change control. I’ve learned to bridge silos and work the system, to appreciate being methodical and patient, but I’ve never seen it as fun in the way it was when I was on a team of three tasked with rolling out a new product in ninety days. Nothing about process and change control should eliminate fun, but it seems like it does? Why is that? Is work only fun if there is risk? Or no rules? Or is the nature of things that as a company matures there is less fun to be had because it’s all been done or it’s too risky to try?

What makes a job fun anyway? Many jobs are satisfying because they pay well, or because they offer decent problems to conquer, but are they fun? I’m curious to hear from you. What IT job was the most fun and why? And looking back with the benefit of experience, would you go back to a similar environment today if you have the chance?

Join the debate, and respond to today's editorial on the forums

To alter the size of the buffer pool extension, the option must be disabled. The size can then be increased and the option turned on. No restart is required for increasing the size.

Ref: ALTER SERVER CONFIGURATION - click here

» Discuss this question and answer on the forums