57

I started at this company in the Netherlands a bit over a year ago as a C# coder. It's my second job now, after quitting from a job of 3 years also as C# coder.

As I got interviewed for the current job, I was told it would be an all C# project with some small side tasks. This seemed perfect for me, I wanted to do C# most of the time but don't mind a small side task in another program as a change. As I officially started the job, things moved pretty slowly. Already 3 weeks later I (and some other people in the team) had to fill our time with self-made tasks because the project wasn't starting at all. Another team (Database stuff) had it busier and I was asked if I could lend them a hand because I also had SQL knowledge. As I had no other things to do, I just agreed.

Now over a year later I have basically become a SQL guy (within the C# team) with some C# tasks on the side. Not what I was hoping for when I started this job, and I can say I have gotten really tired of it. I told this to my Teamleader months ago and he said he would get me some more C# tasks instead, but that never happened. If anything, he still sees me as the SQL guy and tells people about how they need to ask me if there are SQL issues. I went to talk with the manager as well, but same story there.

Now I wonder how I can get out of this SQL loop and return to my original job? I have the feeling my position got rooted too deep into the company that I have no other option but to quit?

PS: no offense to SQL people. It's just not my thing.

4
  • 3
    Before you comment - ask yourself if you would be using the comment feature for its intended purpose and keep our Be Nice policy in mind. Please don't comment to chastise, vent, share your own opinion, or to answer the question.
    – Lilienthal
    Apr 1 at 22:36
  • @JörgWMittag how did people handle that? How did you handle it? Did your employer explain things to the employees?
    – user32882
    Apr 2 at 11:52
  • What level of SQL are you being asked about? Absolute basic select/insert/update or complex queries requiring deep knowledge about indexes and similar? Apr 2 at 11:53
  • How big of a company is it? I have worked at places where I have had to do angular/typescript/razor/asp front-end stuff, C# for the server/back-end stuff, and create tables/schemas/stored procedures/etc on the database...and wire it all together. I have also worked at places where there is a distinct division between front-end, back-end, and database. Could it be the company is more of a startup than a corporate/enterprise environment?
    – Bardicer
    Apr 2 at 15:38

12 Answers 12

81

Before you throw in the towel, there is no harm in being be more assertive in your discussions.

  1. Bring it up in EVERY one-on-one meeting. Make it #1 item on the agenda for every meeting

  2. Ask for some level of commitment from management and/or team lead. Don't make it "negotiable". Instead describe it as a future state. "I was hired as a C# programmer and that's what I want to be. I'm happy to help out with the SQL need temporarily but it's NOT my long term goal. I want to create a transition plan that gets me back into 90%+ C# work. Will you support this effort? "

  3. Focus on quantitative metrics and actionable items. "Let's create a transition plan with a timeline and specific actions". "My transition metric is hours spent on SQL vs C#, I want to track this going forward and set realistic goals with you" "I'm happy to help interviewing and hiring an SQL expert"

At the least, that conveys that you are dead serious about this and that you mean business and can't be easily brushed off. It is also still constructive and collaborative. Then start tracking your metric and share it with your management during each 1:1. If there is decent progress, things are good. If not, you have tried your best and you got "no" for an answer, so then it's time to move on.

4
  • 27
    If you're going to lay down an ultimatum like this (and that's essentially what it is), be sure to brush up your CV and start looking, as well. It's entirely possible that you'll get head nods and "oh, yeah, sure" responses while they start to look for your replacement who will be happy doing the SQL work you're not happy doing. Not to say that this is a bad answer, but it could have unexpected outcomes.
    – FreeMan
    Apr 1 at 14:13
  • 3
    @FreeMan depends on the type of employment contract. In the Netherlands it's difficult, if not sometimes impossible to "let someone go".
    – Gizmo
    Apr 2 at 7:51
  • @FreeMan: I agree. Hence my prefix of "throwing in the towel", which was supposed to mean "if you are ready to quit anyway". And yes, your CV should ALWAYS be up to date and looking for alternatives is definitely a part of this strategy
    – Hilmar
    Apr 2 at 11:42
  • @Gizmo fair enough. In the US, relatively few white collar workers have an employment contract, so I tend to forget that detail. I can get fired with or without notice, basically on a whim (though technically not for discriminatory reasons), and I can leave, with or without notice, on a whim.
    – FreeMan
    Apr 2 at 11:55
49

You have two options: accept the reality or move on.

The business needs SQL work, not C#. Since they are paying you, and you seem capable, they will ask you to fulfill the need they have. When you go to a store, and are looking to buy apples, no incentive will get you to buy kitty litter (if you don't own a cat).

On the plus side, you did pick up a additional skill that may help you land your next role.

8
  • 6
    This. So much this. I advanced in my career mostly because I reluctantly agreed to give up things I liked doing or was good at, and instead agreed to figure out how to do things I was (initially) utterly inept at.. I rarely got any opportunities to do things that I was comfortable getting into, and when I did do them, they resulted in zero career advancement withing the org.
    – S. Grey
    Apr 2 at 3:48
  • 9
    I think you guys are overlooking one important fact. They told this person it was going to be C# work. It was part of the job description. There's fundamental dishonesty or negligence on the part of the employer here.
    – user32882
    Apr 2 at 9:39
  • 7
    @user32882 Things change. Might have lost a contract or similar. Apr 2 at 11:39
  • @ThorbjørnRavnAndersen sure they do, but then they need to be open about and explain why the person will be doing more C# work than initially expected, rather than being all sneaky about it... Then OP would have a better idea of where they stand and whether they want to continue .
    – user32882
    Apr 2 at 11:48
  • 2
    @ThorbjørnRavnAndersen either way I don't think OP can do anything about it really. They just have to either live with it or find a new position.
    – user32882
    Apr 2 at 11:52
18

I got stuck in a similar situation, although more slowly and I was in even deeper by the time I realized how stuck I was. I was able to get out while staying at the same job, but it was pretty touch-and-go at some points.

From my experience, developers are fairly dismissive of SQL skills (at least, when hiring). The general sentiment seems to be that any developer can figure out SQL*. At the same time, you're unlikely to learn the rest of being a DBA from this (even besides the fact that you don't want to do SQL stuff). And your core developer skills can rust pretty quickly from disuse.

You do have to be willing to leave. From the business perspective it goes something like this: You doing SQL stuff > you doing C# stuff > you leaving. They will only take the second option if you remove the first option entirely. Learn from my mistakes and don't wait until you're entirely fed up with the situation for that to happen.

As long as you are willing to leave, though, you actually have a pretty strong negotiating position...because where else are they going to find someone to hire who is a known good quantity and already knows all of their stuff? And any loss of productivity due to rearranging the team is going to be less than the hit they would take if you walked.

What happened for me was to spread all the stuff I was doing back out onto the whole team. None of the stuff I was doing was that super special that no other developer could do it, and frankly having it siloed in one person was just dumb anyway (what if I threw myself under a bus?). That none of the other developers wanted to do it either was tough for them (not my problem).

I had to be mean for a while about protecting my boundaries. It was very easy for people to slide back into giving me certain kinds of work, and I had to be really firm about taking my share of day-to-day stuff and not even a little bit more than that**. Even when it involved flatly saying No in semi-public (in front of the rest of the team). (Including one incident which involved being called in to explain myself later--although since I had the three e-mails where I'd politely tried to work it out with that person in private before it all came out in public, it turned out OK for me.)

So polish up your resume and look at a few job postings, and go talk to your manager after you have it solidly in your mind that you can leave at any point. You don't have to tell your manager that you can leave, but if you're comfortable with the idea it will definitely come across. Explain that you need to start working on C# stuff, now. Explain that the SQL stuff can be spread out over the whole team, they are all developers, too! Talk about the benefits of removing knowledge silos and bus numbers. And then when work is being split up, speak up aggressively about taking some C# tasks. Relate any day-to-day SQL task that comes up to the skills of your other coworkers ("so-and-so knows that area really well") and brick wall anyone who hints that you might take that task.

Or, honestly, just leave--I'm still not sure all of this was worth it, except that it was a really bad (pandemic) time to leave when I got to the point where I was ready to.

* "Any developer can figure out SQL" is not wrong, exactly, but mostly because a lot of development only uses "hello world" level SQL. (You'll notice a lot of libraries exist to remove developers from actually having to understand the database.) I'm still not an expert, but at least I know that the DBAs are doing something besides twiddling their thumbs all day.

** Actual emergencies always got to the best person. I tried to emphasize that I was completely reasonable about that, although I'm not sure that it really helped--especially since the people who were most annoyed with me were the people who'd been successfully avoiding the **** work all this time.

0
14

Remind your team lead regularly that you are unhappy. Your manager too, if they're different people. Emphasise that it's perfectly reasonable for you to be unhappy in this situation, because you were hired as a C# developer with the understanding that you would be writing C#, which is something that makes you happy, but now you are spending most of your time writing something else, and while it's great that it helps the company, it doesn't make you happy.

But also, recognize that it might not be possible to switch back to C#. They might have overestimated how many C# developers they needed and underestimated how many SQL people they needed. Business conditions change constantly.

So your team lead might not be able to do anything about it. But at least they will be aware you are unhappy. If something else comes up that needs doing and is not SQL, they might think of you first.

2
  • Sounds like OP has already done this. What's the expected outcome of this action?
    – employee-X
    Apr 2 at 19:25
  • OP said they talked to their team lead about it once; this answer suggests they do it regularly. "Squeaky wheel gets the grease". The expected outcome is to raise awareness that you're mis-allocated.
    – B. Ithica
    Apr 6 at 10:53
9

When you don't want to be the SQL guy, make more SQL guys.

You have a reputation as the local SQL guru, so all SQL tasks go to you by default. That's because people assume (rightfully or wrongly) that you are the only one who can take care of them. When you don't want to do that, then propose that you could train a couple of your colleagues how to write SQL queries, so you can deflect future tasks to them.

I've used that method several times in the past to get rid of workloads I accidentally got responsible for because I was the one guy with the unique knowledge.

4
  • 3
    Indeed, that's solid advice. There are a few details I'd add from my personal experience: (1) Stop solving people's problems, train them the necessary skills instead. (2) Make clear to everyone beforehand that you are going to do this, and get an OK from your manager. (3) To repeat point 1: Do not make the mistake of first fixing their problem and then explaining what you did. If you do that, people will be glad that you fixed their problem, ignore everything you say and come back again two days later with the same type of problem. Instead, explain until they are able to solve the problem.
    – Heinzi
    Apr 2 at 13:05
  • This is the right answer. This is good for you, and good for the business too (i.e. what happens if you get it by a bus and nobody else can do SQL?)
    – John Wu
    Apr 2 at 22:17
  • This is assuming the manager will accept that they want the other developers bogged down with SQL related work. Usually, and especially if OP is a junior, this won't be the case.
    – user32882
    Apr 3 at 7:30
  • While that is good advice, it's hard to make happen. As a consultant I was able to base 50% of my business over 40 years on one fact: there is far more need for good SQL expertise than there are good SQL people available, and I could have easily made that 100% of my business (I knew many who did). Apr 3 at 15:55
5

Now I wonder how I can get out of this SQL loop and return to my original job?

The answer is you can't. The company has to decide that they want you back doing C# work.

It's normal for companies to have a clause in a contract that says any other duties so you can't claim it's not in your employment contract.

I've heard this from a lot of people of the years as a reason they are moving company so I'm afraid if you've asked to be doing more C# work and they haven't capitulated then I think you will need to look for another job.

4

In a healthy work environment, your manager is not just responsible for making sure you are getting your work done and giving you performance reviews, they are also responsible for helping resolve issues that interfere with your productivity or might cause you to want to leave the company.

You should discuss the situation with your manager and ask for their help. Your tech lead is not responsible for your job satisfaction. Their obligation is getting the work done within the parameters set by management, and if making you do all the SQL work is the most effective way to do that, it will be difficult to get them to choose a different path. You need the support of your manager to resolve the situation in a way other than "suck it up or quit". They can free time for you to train a coworker and can work with the tech lead to get you involved in more C# work.

At my first "real" job, I was "the queen of (a compression algorithm acronym)". All of my time was spent on that one project and I was never given the opportunity to work on anything else because I was the only person who had the expertise to do it. I went to my management and explained that not only was that a huge risk for the company, it was making me really unhappy. As a result, I was given time to train someone else to do the work and management tried to find other interesting stuff for me to work on, but failed. I ended up moving to a different department in the same company. If I hadn't had a trained replacement, it would have been unlikely that the company would have let me transfer to a different department, so even though I didn't get exactly what I wanted, it helped to get my manager involved. I was able to do what was best for my career without burning too many bridges.

2

Tell somebody relevant that currently, your team is moving towards a dangerous situation - creating what in my last job, we called a "lone peak of skill". Ideally, somebody relevant will be an agile coach, because agile coaches are trained to recognize the danger in this, and it is their job to prevent it. If you don't have an agile coach, the next choices would be, in that order: scrum master, team lead, or the manager to whom you report. That supposes that your company is more or less following the traditional definition of these roles - you may have to change your choice depending on who you think will grasp the situation, and will react with understanding on the human level too.

The reason why this is a better approach is that it makes them aware that the team has a problem, and through that, the company. As you will be talking to somebody responsible for the team, it makes it a problem they are responsible for. This is directly opposed to the way you have presented it until now - that it is you who has a problem related to personal preferences. There is a tacit understanding that it is management's responsibility to recognize and define the tasks which need to be done for the business to move ahead, and it is the specialists' responsibility to get these tasks done. The current top answers reflect how most people (especially most managers) see this cultural norm. Being choosy is allowed to some extent, but can quickly win you a reputation of being unprofessional. If a manager promises you to try to get you more enjoyable tasks, this is seen as a courtesy, and has lower priority than the current business goals.

If you, or your somebody relevant is not recognizing the problem for the company: a skill being concentrated in a single person is very efficient in the short-term and very damaging in the long term. There is not only the famous bus factor, but also more subtle effects like you not being flexibly available for that new project they wanted you for, because you are stuck maintaining all the company's SQL, and the juniors never gaining any experience, because they stay firmly in their comfort zone.

That state is not only problematic for the company/team, it is also a state that is a natural attractor for teams. It starts out innocently, with somebody getting slightly more knowledge about something than the other team members (if it is not a language, then it is a subsystem, usually one that person wrote first), and then all tasks about it being left to that team member, because they know more about it than the others. In the worst case, it is not just the others being unwilling to jump the hurdle of "I don't know how to do this yet", it is the experienced person not having the didactic fortitude to let them blunder their way to expertise, instead taking it out of their hands and saying "let me show you how it is done". And because it happens on its own, it is somebody's - ideally an agile coach's - job to actively steer the team to a different state, in which expertise is shared, and nobody has (or is allowed to use) the excuse of "but Hunkabonk is so much better at it than me".

In a perfect company, somebody relevant will listen to you, recognize the problem, and take measures to counteract it. It will not result in you never doing any SQL, but rather, in both the SQL tasks and the C# tasks being equally distributed among the team, which will hopefully make you happy (it may turn out that what bothers you is not the hours you are doing SQL - which will be reduced - but the unfairness of you being the only one who has to, or the feeling that you complained and were not heard). In just about any real-life company, you may encounter anything on the spectrum from the perfect company's reaction, to a blank "I don't understand, it's great that you are growing to be an SQL experts, so there is no problem." From there, it depends on your particular circumstances to recognize whether there is hope for the situation to change, or if you have to fall back on Pete B.'s answer.

0

I assume that you understood the job description correctly on day 1. The fact that they have assigned you different types of work from the initial agreement could be due to one of the following:

  • They were being dishonest or imprecise about the content of the work because they desperately needed someone with your background
  • They hired you with the prospects of winning projects in C# and assigning you C# work, but then those proposals fell through. When this happened they were left scrambling and decided to just assign you what's available (in this case SQL work).

Either way, you cannot force them to give you C# work. But I understand your frustration and feeling that you have been somehow tricked into this. I would first bring this up to your supervisor and explain the situation. Explain that SQL work was not your ambition coming into this position, and be as honest/blunt as possible about your feelings. Do not jeopardize your relationship with your supervisor.

No matter what they say, even if they promise you more C# work down the line, just go ahead and apply to new jobs which focus on C#. You cannot give them the benefit of the doubt anymore, as they have already shown you that they are capable of saying something and doing something else.

Keep in mind, no matter how stable this seems now, this situation could potentially deteriorate. You are being forced to do work that you're not interested in, and that can have negative consequences down the line. Get out of there as soon as possible, and find an employer who can honor the agreements they make with their employees.

0

Turn SQL into C#

A SQL job doesn't necessarily have to involve writing SQL commands. Use a C# library that will allow you to abstractify SQL tables as C# classes and SQL rows as C# instances. Then do all your SQL work using this C# API. Or if a library doesn't already exist that suits your needs, you might be able to write one that does.

4
  • 1
    This is what I call busywork. There's no explicit need for it and may end up costing OP a ton of extra time. The extra time will come across as lack of productivity to the manager.
    – user32882
    Apr 3 at 7:33
  • @user32882 Not really. I guarantee that libraries already exist for this - it looks like LINQ to Entities and Entity Framework might do this. I've never used them, but I can tell you that the Django ORM is much faster and easier to use than manually writing sql queries, and it allows for database migrations, so that you can keep track of your database changes. And it allows you to extract data, call Python methods on it, and save it again, which allows you to do things that would be impossible with pure sql. I'd only write raw sql as a last resort.
    – kloddant
    Apr 3 at 14:11
  • @user32882 Also, using a C# ORM for this would mean that they could potentially write an application that would allow whoever is asking for these annoying sql queries to just run them themselves by entering information into a form. Essentially, they could potentially automate this job away, which is what it sounds like they want to do.
    – kloddant
    Apr 3 at 14:14
  • I actually did this very thing - people would ask me and the other developers for queries on our sales database all the time, so I just made a website that interfaced with it and allowed them to fill out a form for the info they wanted.
    – kloddant
    Apr 3 at 14:20
0

Be a primadonna :)

Situation in your company (or at least in your team) looks like this : lots of C# developers (no offense, but language is in a decline) and one SQL guy - you! Now, people may say whatever they want about SQL, but it simply could not go away because relational bases are not going away. This gives you one huge advantage over rest of the team - you are rare, they are not.

As such, instead of asking for more C# tasks, you should actually decline them, saying you are busy with SQL. Also, be bold, ask for a raise, better computer, flexible work hours (if working in office, considering COVID-19 situation) , company car, parking space, whatever ... You need to create the felling that doing SQL is a job for a specialist (highly-paid), and C# is something mundane for junior developers.

Company could respond in three ways:

  1. They could fire you. This of course depends on your contract and local laws in Netherland, but you should be prepared for such outcome in any job negotiations.

  2. They could try to threaten you, to underrate you and SQL in general. In this case you should stay firm, and respond with "do it yourself if you think it's easy". In the end, they would have to share SQL load among other developers, to show you are not special, and you would get more C# and less SQL work (and this is what you wanted, right ? :) )

  3. They could actually meet you demands :) In this case, enjoy in your newly won perks until they find another SQL developer in which case you will find yourself either in point 1. or point 2.

There is of course this outlandish advice to simply find better company with the work more suited to your wishes, but I think this is safe to ignore :)

-2

Take the blame, it's yours to take.

The most important thing in solving such problems is in realizing it is your problem. You can do little or anything about things by making the outcome dependent on others. Another good side to this policy is the fact that it makes you able to accept the hard to enjoy choices of others without holding a grudge. The blame is the most beautiful gift to yourself.

Generate options.

It's perfectly all right to do so and it sets your mind in the right direction. Even the options you generate outside the company may result in solutions inside the company. Even if the options you're trying to create are really far out.

Consider the general nature of what you communicate.

I personally don't think repetitive mentioning of the negative aspects of your situation to others, will do a whole lot other than nag. Compare the response you would get when telling your team leader about how unsatisfied you are with the lack of tasks you like, with his response if you told him how excited you are over an offer you got. Keep in mind; The companies decision to not honor your right to C# tasks, has been taken a long time ago. Set your mind to change and it will set theirs.

Make sure you are happy with what you are doing.

Whether you enjoy your work or not, will always depend on the context in which you do it. The work itself brings no joy, C# or no C#. Cleaning toilet bowls is a whole lot less unattractive if you know you are making ten grand an hour or saving the world. Whichever makes your clock tick. If you are not enjoying your work, its not because the work is bad, but because it doesn't bring you enough life quality. If that is not in the job, it may be found in the reasons you do it.

A job is no marriage.

When you work for a company, your goal is to improve that companies success. In return the company offers you whatever you agreed on,... or not, like in your case. You should feel no emotional obligation to that company or your colleagues, because that is not what a job is all about and the way the company observes its obligations to you shows that. They're not even living up to what you agreed on. As much as you may feel obliged to colleagues, you are in fact only obliged to live up to your agreement. This is why the pursuit of happiness is a human right. You don't owe it to anyone to give that up.

You are a business.

At the end of the day, you're on your own. People who do paid labor tend to forget that. Observe yourself as if you are a company of its own. That is the first one that needs success. Keep track of the state of its inventory, its growth rate, the qualities of its products, its survival chances, and so on and so forth. If C# is your product, C# is what your company should sell.

Think forward.

Everything you will ever see that is not untouched nature, was once no more than an idea in someone's head. That should begin to give you a notion of how powerful (your) thoughts really are. They are the only truly creative actions, the rest is reaction. They set things in motion. In controlling your thoughts, try not to focus on the downsides of your present situation. That is what you want to get away from, so technically, it should be behind you soon. There is no point in thinking about it. Instead try imagine what you would want to achieve and mentally elaborate on that. As a general rule, if it feels good to think about it, it is good.

Acquire feedback

You are the one that got you in to this situation and you are the one who will get you out of it. In this process, it is incredibly helpful for you to know who you are. Write about what bothers you and then read what you have written. Read what you wrote a month or a year ago. Watch yourself change. Make sound recordings and listen to yourself. Make videos and look at yourself. Get to know you as others know you. There is no faster way to detect and solve weaknesses in your own conduct than by using yourself as a source for feedback to find out why you do the things you do. Remember that behind every weakness lures a talent. Fight the weakness and you will suppress the talent. Overcome the weakness by embracing it and the talent will bloom.

7
  • Why would OP take the blame? They are the ones who have been swindled into doing work not in the initial job description!
    – user32882
    Apr 2 at 9:33
  • That is not true. He was there all along, but that's not the point. Taking the Blame is an essential step away from dependence on others. rather than asking oneself, why the others aren't doing what they should do, it is way more productive to wonder how he got himself into this mess and how he will get himself out.
    – Berend
    Apr 4 at 18:25
  • Another thing that taking the blame does is, it moves away from a guilt guided mindset and towards a cause and effect guided mindset. Bottom line : Its a trick and it works.
    – Berend
    Apr 4 at 18:28
  • If you tell people who have a serious problem, that dancing the polka will solve their problem, you'll be amazed to see how many people simply refuse. They rather come up with a world of lame excuses to not do something that simple, than just do it and get their problem solved. The very first thing this man needs to change is his own mindset, because that is his part of what got him in to this situation.
    – Berend
    Apr 4 at 18:57
  • "He was there all along". Yes (s)he was, under the reasonable assumption that they would assign him/her work as outlined in the job description. I'm all for personal responsibility but there is no reason to always take the blame for everything. That is just as unhealthy as blaming others for all your problems. In this case, assuming OP understood the job description and holds the reasonable expectation that they will follow through with what they agreed on, I would argue that they are also, if not more to blame.
    – user32882
    Apr 5 at 8:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .