December 22, 2014 at 8:17 pm
Comments posted to this topic are about the item We Want Maturity, But Is It Fun?
December 23, 2014 at 2:55 am
Interesting and thought-provoking article.
In a nutshell, I think a task is fun if it is difficult yet solvable, expands your knowledge and broadens your experience. These tasks feel rewarding when completed successfully.
My gripe with change-control, and other necessary bureaucracy, is that the fun part takes 30 minutes, but the boring part (attending meetings, justifying the change, writing up the documentation, informing users, testing the change, etc) consumes the remain 7-and-a-half hours in the day. In a small company, you might do 5 or 6 fun things in a day, in a bigger company you get to do 1 or 2 fun things a week.
Hmm, what a depressing way to end the year!
December 23, 2014 at 3:07 am
I think it's largely about 'flow'. In a small team situation, without the overhead of the bureaucracy that comes with change control etc, you get to build momentum in the project so that you are either progressing the task or thinking about the next step to progress the task.
Flow is the optimum mental state - that's why we percieve things that lead to that state as being fun.
Change control and the rest of the corporate BS that has grown up around IT all breaks up that flow - everything becomes stop-start - generally the more complex the company structure the more bureaucracy will insert itself into working practice and lead to broken flow. This has implications for quality of work as well as the enjoyment levels of employees.
While a lot of the corporate BS is a necessary evil, most companies need to put a lot more effort into making it as unobtrusive as possible and wherever possible to try to incorporate aspects of thet management overhead into the natural flow of the tasks that are being managed.
December 23, 2014 at 3:45 am
In the past 15 years I've gone from a similar situation - large company with a small IT dept all in the same room with me filling both the development and DBA roles. In the beginning you knew exactly who the users were and dealt directly with them when it came to new development, bug fixes, etc. And you knew which of your IT colleagues to speak to for help with something because they sat only a few chairs away.
Towards the end of that time-span the company's IT 'department' had grown to over 100 people, including Service Desk, Ticketing System, Change Advisory Board, sysops guys, developers, another DBA, etc, etc. And more directors of this-that-and-the-other whose titles suggested they had been given carte blanche to come up with whatever terms they thought sounded cool.
What else is different? Well users now have to wait weeks, perhaps even months, for even a straightforward request to be fulfilled; no-one in IT knows any of the users personally any more; no-one wants to fix anything anymore - they just want to pass the problem on, close the call and keep the call queue down; no-one in IT knows the skill-sets of other IT guys anymore because they are spread all over the country and no-one wants to maintain the documentation for that particular knowledge base. Oh, and I used to really love my job. Now it's just a job. But hey, at least we now had a process.
I guess what's really changed is I've become much more cynical over the years as to the purpose of IT. Is it to help users do their jobs? That certainly used to be the case. Or is it to justify an ever-expanding, self-generating IT infrastructure? I now work in an even bigger company with no contact at all with non-IT people. My sole purpose in life is to 'support' other IT users to 'make better business decisions'. I sometimes wish I'd gone with my original idea back in the day. I'd be much happier driving that bus.
Merry Xmas one and all 🙂
Gordon.
December 23, 2014 at 3:54 am
For me it is the people I work with who make it fun.
We have silos as a solution to a defined problem but the silos themselves cause problems. The problem is that below a certain level in the organisation you don't see or have incentive to see outside of the silo and therefore probably don't recognise the root cause of the problem. Devs vs DBAs anyone?
Now I am a manager I spend a considerable amount of time reaching across silos and engineering situations where my staff get to work directly with people from other silos.
The ritual of the Friday lunchtime pub visit is as much to do with encouraging social interaction as it is an excuse to visit the pub. I have an architect colleague who says the worst thing he did was to give up smoking because he learnt an immense amount from the smoking shelter sessions.
For me the bit that makes work worthwhile is doing something relevant with people I enjoy working with and being recognised for it.
December 23, 2014 at 6:11 am
Fun = getting things done, contributing tangibly to a company's bottom line. The cumbersome procedures that we have in place were originally intended to protect the organization -- improve security, ensure quality. Does it improve the corporate bottom line to require a twelve step process for a User to have a common product added to their machine? Do we actually use the information we get by tracking everyone's time on every project? (Too often our time accounting procedures fail to do anything but slow us down. The poorly administered, heavily fragmented time tracking systems can no longer tell us how much a project costs.)
It strikes me as unusual and painful that we add procedures and accounting that do not improve the environment. How do we ever make any money as a company?
If we approached infrastructure the same we do with technical assignments, we could actually return to doing things that resulted in success instead of tedium. What are we trying to do? Will this software/procedure/approach contribute to solving the problem? Is there a better/faster/cheaper way to get it down? Does this rule do anything for us?
As DBAs, we are paid to do more than administer databases. We are more than technicians. We should be leaders. By posting articles that address the day-to-day concerns (infrastructure, hiring, training, etc.) and by sharing the wealth of technical helps, this site has made me a lot more useful to my employer.
Good job! and many thanks!
December 23, 2014 at 6:22 am
I am responding to the question posed at the end, 'What was the most fun job you've had? Would you go back to it?'. The job I had the most fun in, was my assignment during the Y2K shenanigans. I was the team lead for a small group of contractors who ran around to each of the physical locations of our organization and surveyed the machines and software for compliance. As a side process, we were to select and replace all hardware that was below a newly established minimum platform level.
I loved the freedom of that set of responsibilities, my manager was so busy with his own stuff, he only needed to know about problems. Planning the visits, making the contacts, talking to location leaders, documenting the results, even putting together an adhoc database to feed the formal databases with our findings were all challenges, but they were still FUN! The added responsibility of being a low level manager/executor of the process was very challenging, but even in the hard interpersonal situations that occurred, it was exciting and fun to have positive results.
Would I go back? No, I think my early naivety was probably the major reason I had so much fun. It was also the people I worked with, my manager, the CIO at the time, the DBA, and my contractors were all very positive in their interactions with me. It came at a very formative time in my IT career. Knowing what I know now, that was a definite one-off situation I was glad to be a part of. It's opportunity was the result of a extra-corporate situation that forced a significant change on the methodologies they used. I got to participate and that was awesome.
December 23, 2014 at 6:55 am
Back in the 1970's, I started up an IT department for a large food distributor who had only totally manual systems. We immediately went totally online and put the old dumb terminals in everyone's offices. We practiced total change management from the start, and kept it very simple and straight forward. Crude but effective. At that point, databases did not yet store readable source code, but we already had millions of lines of code between purchased and highly customized code. The problem was compounded by needing to maintain 'pure' purchased code and be able to reapply our customizations on the fly.
Our business day began and ended at noon, since overnight was a very busy period. We did full backups, to magnetic tape in those days, to multiple tapes while also doing source control backups to other tapes. Changes were implemented during this process also, which gave us a clean cutoff for new code, and a few hours to react to problems before busy time hit again in late afternoon.
During the source code backups, changes were merged into new backup tapes. All data and source backups were then immediately removed physically from the premises to two different vehicles that went away at night. Our backups were thus available from two different sources daily in the event of disaster.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
December 23, 2014 at 7:23 am
Process is only beneficial if it provides a benefit. Sadly most process exists because it provides someone, somewhere with *** coverage. Providing a benefit and covering an *** do not necessarily corelate.
One place I worked at required me to keep 12 separate repositories (spreadsheets, code reporisotries, tracking systems, shared folders etc.) in synch (it was such a shame it was only 12, 13 would have been far more apt). You could just imagine the history that had created this situation. They'd introduced Process A to exercise control and it was probably quite beneficial. Then someone failed to follow it so they introduced Process B which was intended to ensure that everyone followed Process A correctly. When someone failed to follow Process B Process C was introduced and so on. The irony was that in tryng to ensure process got followed and control was maintained they'd created a scenario in which the oppposite outcome was pretty much guaranteed.
I personally think all process should be stripped out at least once a year and redesigned starting with the core goals.
edit>Oops, turns out that was a banned word. Seems odd at this time of year given that Jesus rode on one:Whistling:.
December 23, 2014 at 7:30 am
The most fun I have is to have a visible impact on my customers. Bureaucracy removes that visibility and creates barriers to communicating directly with the users. The worst job I had was to make code changes. I never saw the positive impacts my work had. I certainly heard of the negative ones :angry: .
Give me dierct access to the users and let me make them happy. That is fun.
As I move towards retirement (38 days, 8 hours, 1 min, and 23 seconds left; but, who's counting?), I will be working with groups that affect people's lives directly. That will be good.
Tom
December 23, 2014 at 7:46 am
I've never responded to one of the editorials before, so here goes....
This article really spoke to me because I'm in this type of small team organized chaos right now. We're not a tech company, but the data we deal with is not small-time either. I develop and administer an internal planning application for a leading construction firm on a multi-billion dollar project. I'm 27 and this company/project is all I've ever known. I've gone from barely knowing SQL to being the go-to database developer/fixer/administrator/automated process setter-upper and on track to full SQL Server certification.
We are on a small team of 4 (now 3 due to downsizing), and aside from my teammates, none of the key players around us are IT. While developing and managing this type of application is definite FUN and challenging, I'm strugging with legitimizing myself as an IT professional. Should I make the move to a more structured IT firm? But then I'll lose the autonomy that I have now. Will a traditional IT role pay better? Possibly, but then I'll most likely be siloed into one type of technology or process. I'm curious about the greener grass on the other side, but I'm having a hard time letting go of this team and this application (it's like my baby). If anyone has any advice, it's surely welcome.
So to answer the question...
So what makes my job fun? I don't think it comes down to a money issue. If they paid me less I'd probably still be here. If they paid me more I'd definitely still be here. My job is fun because I'm challenged every single day with a different issue. I'm given practically free rein to solve the problems of my users/management the best way I see fit. My direct supervisor (who I consider a close friend) also challenges me to be better and think faster, and never settles for good enough - and this motivates me to produce more solid results. Management has very little oversight, as long as the UI is fast, replication is running, and report subscriptions are delivered.
Thanks,
Jessica
What would you attempt to do if you knew you could not fail? -Robert H. Schuller
December 23, 2014 at 7:50 am
My first IT job was a similar situation. When the phone rang, we wrote code. Or changed the light bulbs. Or fixed the copier. Or upgraded a network.
Basically anything that plugged in to an electrical outlet was our responsibility.
We had source control, but that was about it.
The actual software was very complex, and we had to come up with some very cool algorithms.
The company grew significantly overnight. We added a help desk, ticketing and project management systems, networking, QA and support departments. We had to get to a higher level of organization, and fast!
It was very hard in many ways. Stress was high. There were days that we all screamed and shouted at each other, there were other days when we hugged each other.
But every day, we went home with a sense of accomplishment and a higher level of respect for one another.
At the time, we all thought that the processes we put in place were terrible and that everything was an accident waiting to happen.
Looking back, almost 20 year later, this was the gold standard of how a department should have been run. There was enough structure that controlled the chaos, but at the same time there was enough flexibility to allow us to respond immediately when we needed to.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
December 23, 2014 at 7:54 am
jevitts (12/23/2014)
So what makes my job fun? I don't think it comes down to a money issue. If they paid me less I'd probably still be here. If they paid me more I'd definitely still be here. My job is fun because I'm challenged every single day with a different issue. I'm given practically free rein to solve the problems of my users/management the best way I see fit. My direct supervisor (who I consider a close friend) also challenges me to be better and think faster, and never settles for good enough - and this motivates me to produce more solid results. Management has very little oversight, as long as the UI is fast, replication is running, and report subscriptions are delivered.
That pretty much nails it - autonomy and variety. Both things that make for an enjoyable work experience at the level of the individual, but which don't scale well as the systems and company grow. My favourite jobs have all had high levels of both variety and autonomy.
December 23, 2014 at 8:29 am
I would have to say the place that strikes a good balance between various competing demands is usually the most fun and least hateful.
a balance between life outside of work and at work - rare but nice
a balance between exerting control that prevents change vs complete entropy that contributes to the heat death of the universe - things get done with insurance against things getting broken
a balance between new work vs maintenance/support work - most of us don't want to get stuck just with maintenance, but recognize that maintenance does need to get done, and plus it's rewarding to get something fixed
I'd also say that I hate places that demand loyalty and dedication, but treat the people that work there as disposable. You can't have loyalty and dedication and not reciprocate. That is NOT fun, wondering how much longer you'll be employed as you finish a 13 hour Saturday to cap off a 60 hour week. And the people that work in that environment know, even if they might not be open about it.
I've had one stint that did a pretty reasonable balancing act, and I attribute this to the great management that was in place at the time. And yes, I told the people responsible for this unusual situation how great I thought they were, after we were reorganized by new management, but before I left.
Seriously, good managers are so hard to find, that the two or three people I'm talking about here (and they know who they are) could call me if they were in management again and wanted me to work for them and I would turn in my notice and go work for them immediately.
December 23, 2014 at 8:44 am
I spent three quarters of an hour responding to this first thing this morning only to lose it due to stupid Internet access problems. So, probably to your advantage, you get the 20 second version:
I had fun on a project where most of the lightweight processes were contained in tools open to everyone and we all pulled together. There was a "I broke the build" hat too.
EDIT: Angry typing!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 1 through 15 (of 35 total)
You must be logged in to reply to this topic. Login to reply