Tag: career

I’ve worked as a technical person for most of career. I’ve often been responsible for building or managing systems, and ensuring they operated according to some set of requirements. If things didn’t work, I’d have to fix them, but often there wasn’t the threat of losing employment unless I was grossly incompetent. If I made a strong effort, I’d get other another chance, or maybe be shuffled to work on some other application or system.

Throughout my career, I have worked with various salespeople in different companies. Either they were my customers/clients or they were just co-workers. However, they operated under a different mindset. Most salespeople are expected to make a certain amount of sales in a time period, and if they don’t, they may be let go. In fact, in quite a few companies, a salesperson couldn’t miss their target more than two time periods in a row without finding themselves out of a job.

I realize that sales isn’t like the creative work that developers do, or the tedious work of managing systems, but what if we were treated like salespeople? Do you think you’d want to work in an environment where you had some quantifiable measurement, such as uptime for a quarter, plus tickets closed, and if you couldn’t meet the goals, you’d be let go from your DBA position?

Imagine if you were a developer. You might have the demand that you meet the expectations for delivery and you are held accountable for estimates within some amount of variance. Perhaps as a developer there would be a requirement to complete xx amount of stories in some time period. I don’t this would work well. I think we’d try to make longer estimates and more granular stories to better define out work, but I’d also expect the business might press back and put more pressure on us.

In plenty of organizations, there are these pressures. I certainly see developers working harder to get things done, not because of the threat of their job, but because many of us that choose technical work feel a sense of pride and responsibility in the work we do. We work long hours to meet deadlines, sometimes because we’re afraid not to, but usually we do want to complete our projects in the best way we can.

I think we’d all be worse if we were treated like salespeople, and likely many of us would have more job changes. I also think our organizations would suffer more, with higher turnover and a lack of detailed institutional knowledge among those that build systems. Certainly some high performers might thrive, especially if we received large bonuses, like salespeople often do, but I also think we’d find shoddier work overall, with applications even more cobbled together with patches and prayers, with the hopes that our workload doesn’t overwhelm our systems.

I know I wouldn’t like working in that type of environment, and why I’m not sure I’d ever want to go into any sales role.

Steve Jones

There are some people that like working for an organization, sacrificing some compensation and flexibility for stability and security. Others enjoy the chance to experience constantly changing environments and a rich variety of projects at the expense of regularly searching for new work. Neither is necessarily better or worse than the other, and these aren’t polar opposites. In the real world, each includes some of the advantages and disadvantages of the other.

For many of us that work with data, we realize there are some advantages to understanding the business meanings and implications of the information derived from data. Indeed, those that tend to work with the same types of data become fluent and comfortable manipulating and discussing how analysis, transformation, and more relate to that type of data. This leads me to think that someone that works for a company or stays within a particular industry might be preferred as a data professional for organizations in that space. Maybe this is someone that an organization wants to hire and retain over time.

I ran across a piece that discusses the Gig Economy from the perspective of data professionals. Their view is that many data professionals would rather work on interesting projects, and analyze data that is interesting to them, rather than being stuck with a single organization. Certainly from the organization’s view, having very skilled professionals available for project work means less costs in training, benefits, hiring, etc. While the cost per day might be high, there is no need for an ongoing, or at least not a constant, commitment.

I do think that many of the changes in technology have made it possible for talented workers to find plenty to keep them busy and earn a very good living. However, there’s a cost in spending time looking for projects on a regular basis. It takes not only time, but mental strength and a desire to be a bit of a salesperson and marketing professional. Some people may find long term clients that call them over and over, which isn’t that different from working for an organization unless you can interleave a number of clients together on a regular basis. However, most people that work at “gigs” are regularly spending time looking for work.

I would postulate that most of us prefer some amount of security and stability, preferring to work for an organization for a period of time. While we may change jobs at times, it’s often at a lower pace than those that might prefer to work in the Gig Economy

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.6MB) podcast or subscribe to the feed at iTunes and Libsyn.

I’m a constant learner. I try to regularly experiment and try new things at work and in the rest of my life. For work, sometimes this means working outside of the other hours and commitments I have to get better at manipulating data. Sometimes I go deep and sometimes I just want the general gist of how to solve a problem I’m having. Time constraints come into play at times because there’s never enough. Even with limited time, I do want to understand the reasons why things work, or why I should make a choice for some function/method/framework/pattern/etc.

I’ve been working with R a bit this summer, trying to learn a bit more. I’ve tried tryr.codeschool.com as a guided tour, but sometimes it doesn’t help me understand enough of the details. Even as I experiment, I’m going through the motions. I purchased R in a Nutshell, and just got Stephanie Locke’s Working with R. I’m hoping these books will give me a more thorough grounding in R.

As I’m learning, I always want to ensure I understand the implications of how I may write scripts. What do my choices mean for quality, performance, etc. Sometimes trying to understand why slows me down, and I don’t get much done. That’s fine, and maybe that’s for the better. However, I don’t want to learn slowly by going through all the pain that someone else went through. I want to know how someone would write code today, and why they do so.

I ran across this post on learning the hard way. It discusses the way some people try to teach others, and I’ve been through some of this as I’ve tried to learn various technologies. The teacher sometimes wants to assume I am going through their pain and can sympathize, but often I’m learning something new for the first time. I’m sure I’ve been guilty of this as well, perhaps trying to level set or show an old (or poor) practice to emphasize why it’s better to write code in a new way.

The thing is that my time is precious, and I shouldn’t have to work through the mess of the way things used to work to build good habits today. What’s new to someone might not be new to all, and certainly at some point, all code isn’t new anymore. I’d rather teachers, and me, sometimes focus on giving us good habits today. Teach us the right way now, and spend time on error handling, testing, or other good habits. Certainly there are cases where we need to know about the changes to systems, but explain this is an upgrade section. And then tell me what’s different, don’t wax nostalgic on the way you once were forced to find innovative solutions.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.9MB) podcast or subscribe to the feed at iTunes and Libsyn.