Getting your development team / developers up to speed

I recently left a large university hospital for much less because of higher wages and because it was a career. Of course, these two things, as a rule, would be something excited and a great achievement (especially for someone of my age), but I found myself pouting when I go to work every morning, and that's why. The new t = eam I joined is terribly backward in time with coding methods, the latest technology (yes, they still use the classic .ASP) and software - leaving me the opposite of using VS2008, .NET 3.5 and SQL Server / BIDS 2008 using ancient relics of SQL 2000 / VS 6.0.

At first, it’s not so bad, I thought that not all companies are at the forefront and are just waiting for this right spark to send them in the direction of changes and improvements - no. I began to offer (in a professional and not condescending way) some new tools and the advantages that they would have for our company both on the client side and on the client side, but they (as in the team in which I participate) looked at me as if I were a stranger and just gave me why we need it, even after I did my thing.

This made me believe that I might not do this, and hoped that some of the older developers / engineers would share their experiences when they were young and just getting started. I know that times have changed, but I feel that it would be useful, though, and any advice would be greatly appreciated!

Thanks everyone!

+4
source share
12 answers

It is a senseless adoption of new technologies if they do not solve actual problems in a simpler and more effective way than previous technologies. (Including the learning curve.).

Perhaps your university has a huge amount of legacy code that relies on these old technologies. Moving to a later one can be an extremely expensive and tedious process that is pretty hard to justify.

The method of introducing new technologies will either be in a stepwise architecture change, as the university as a whole decides to switch to SharePoint or something else, or to a new project where you can demonstrate the advantages of new technologies, and let existing developers have time to understand them .

Something to remember about all this is that most people don’t like changes, and by changing existing technology, you are going to step on people. For example, experts in specific systems or technologies.

+8
source

First, realize that offering major changes when you're new is almost always a bad idea. First you make them respect you at the expense of productivity, and then you propose changes. Then you can also understand the value of the business to make these changes, so they did not.

IF they told you that they used these tools before going there, you must admit that this is the environment in which you decide to live and work there for a while, raises the topic again. If they told you that they wanted you because you have skills that they don’t have enough to move forward, then the person you need to talk to is a hiring manager, not a team. Please note that this will not make friends for you as a team.

My main suggestion for you is that you start reading about office politics. Build several alliances before retrying. Perhaps there are other people who also want to work with new things. Maybe dba does not like to get stuck with ten-year skills.

Regarding the change from SQL Server 2000 to 2008, you can indicate that 2000 will no longer be supported, and that when SQL Server 2010 is released, there is no longer a direct upgrade path. This is what finally allowed us to start upgrading to 2008. Better convert before. Check the Microsoft website for accurate information about what happens when.

+4
source

You are out of luck, to be honest. If they do not see the need to learn, they will never do it on their own. You will have to work hard to get new things in the office and probably find a way to pay for their training. Or convince your bosses to fire them.

In many non-technical environments, people sit in their rut and continue to use the same tools, even when they become obsolete. I saw it a hundred times.

+3
source

There are many unknown variables, so many of them are difficult to give advice. I'd like to know:

  • Do you manage this team or just an encoder?
  • Did your hiring manager help you fulfill a specific mission to upgrade your team to new technologies?
  • What is the attitude of senior management towards improving the technologies used?

If you are responsible for this team, then it is up to you to set the agenda, make everyone excited in a new direction, and possibly fire someone to show others that you mean the business (preferably someone who is moaning louder total or pulls his legs most obviously).

If you are just a monkey of code, or if top management does a great job of how everything works now, start sending your resume because you are not able to change anything. And the next time you get a job, ask about what technologies they use.

+2
source

This happens all the time.

You should have asked what tools they use and how they work before agreeing to join them. I would also like to point to something like "If I find that you did this just to make me register, I won’t stay long."

+1
source

You will find that people resist strong change, and you need to know the reasons that people use to reject change in order to try to change it.

First of all, people in general are a risk to avoid (with some exceptions to "early adoption"). That is, people avoid risk, and any change is a risk.

Secondly, in your situation, people tend to fear WHERE when this will change them. Look at it like this: the developer in your team will think: “If we move on to xxx technology, how will this affect my career? How will this affect my chances of increasing or even dismissing? New technologies, they don’t want to become obsolete or lose their a place as an expert or something else in the "old" ways.

Finally, everything new is difficult to learn and understand, especially when you have been working in the old thing for a long time. It takes time and makes you feel like you are an idiot. In the oldest teams (and I mean literally from the point of view of people older), this also increases the fear of replacement for someone young who already knows this technology.

If you intend to overcome resistance, you will need to decide everything.

First, the thing must be gradual. One step at a time, one product at a time. Do not try to change the whole process for the entire company. Instead, suggest adopting a smaller project and apply new technology to it. A gift is an opportunity and a test. If this is not useful, we will no longer use it, but let's just try it, then the risk will be minimal.

Then calm people down. Make sure that everyone feels valued and that you or the company no longer trust over long years of experience in the field, which is applicable to any technology used. Listen to people, respect their opinions and make them feel that you care about what they think. Of course, this should not be an act, you should really feel it. Great teams trust each other.

On the other hand, handle the change. Milestones must be wider, you must consider changes. You must make the team feel that you understand that change is difficult and is a lengthy process. That no one will judge if a new business takes longer than the older one, and that failures are expected, and no one will be fired because of this.

In the end, if you want to change, you need to reassure people and make them understand that this is just a test, if it works, then it is great for everyone, if it is not, then everything is in order. Of course, the company must understand this. For managers, this means giving them a clear account of the risks and rewards, which speaks of the truth and tells them WHY the change should be made.

When speaking with management, remember also that competition is always there. You must evolve or be more correct to always evolve. Even if the product is the same in terms of functionality and, it might seem, the saddest from a marketing point of view, saying that you are using the latest xxx technology with lates yyy development technology is a great hook. Customers are not stupid, but they are not computer literate, so they are easily impressed with fuzz words, so competition can steal them without having the best product, just “new”.

One more thing: maybe it will be useful for you to tell them about the “ Who Moved My Story” , which revolves around change and how the market develops around change.

Change is a fundamental thing in every life, both personal and professional, and should always be considered. Whenever someone says that “change is now too risky” or “we cannot afford to change,” you really need to think that this is ... the picture we see in the long run, or whatever we talking about a short-term scenario? Because, if this is the last one, then we will know well, but let's go back in the long run ... something like always giving credit to everyone to buy a house, because houses ALWAYS increase their value ... or they are? "..

+1
source

Are these only tools that are out of date? Or the code they produce subpar? If this is code, viewing the group code is the best option. If these are just tools, simply create articles and / or documents that list features that they lack and how they can benefit the group.

0
source

If a team is stuck in the past, you may not be able to do much. Some developers either do not see the benefits of new technologies / methods (and in some cases they may be right) or are afraid of changes. I would say, having learned that you can from them - there are many interpersonal, project management, political and other skills that you can learn. Take your time to keep up with current technology and don't open your eyes to go on to something else. For now, find out what can. Many developers focus on technology and overlook important skills that they will really need in the future in their careers.

0
source

We all have our biases in the field of platform and technology, and when a new person joins a team and wants to change everything to his own way of doing something, it is destructive, and the team will often try to reject the change, even if the motivation is good.

Unfortunately, "are you using Java? Ick! We need to send all this to C # immediately!" types made people rightfully skeptical of the new guy, offering a lot of new things.

One suggestion that I could offer when proposing a new process or technology is to create it from the point of view of the real problem with which they are associated, and may be relevant. Technology is not a solution, it is an answer. Find the problem, and then perhaps offer to teach the brown bag of technology, emphasizing aspects that will resonate with the team in the light of their pain points. Demonstrate value and let them come on their own, instead of taking a sales approach.

0
source

How did you do your job? Professional and not condescending - this is good, but this is only the beginning.

When you try to convince someone to change, emphasize what's in it for them. Find out what they want and show them how the new technology can help.

Management wants to work harder and save dollars. Managers will not care to get new and better things. Try to find cases and studies showing that moving to the latest materials will save X% in money and work. Find or create good grades of what it will cost (not only in tools, but also in training, in two directions of development, etc.). Remember that old things will remain, and you should have a plan to account for this.

Your employees should be told how good it is for them and that they will not suffer for it. They invested a lot in this. They know what they are doing, and they know the code base. Switch to a newer system and they won’t know what they are doing, they won’t know the code base, at first they will be incompetent and may fear that they will become disposable. This is a lot to ask the average person, and it may be too much to ask some people (for example, a guy who is three years from retirement).

Find out what they don't like about the current system and show them how the new software can help. Discuss training and be at least in advance about how easy it will be to convert. If you can show them how to do what they usually do in the new system without worrying about the benefits of the new features, this will help a lot. Emphasize that their knowledge is not only a code base, but also a business and its requirements.

And don't expect to dump old things. You will be able to introduce new tools when starting a project, and if it is incompatible with legacy systems, it simply will not work.

This, of course, is difficult, and you might be better off staying a few years and moving to a more modern store.

0
source

As already mentioned, before you forget the old projects, if they work OK, you can not convince anyone to rewrite them. It is best to wait until a new project arrives and at this stage suggest using new tools. Think about how these new tools will increase efficiency or something else, but do not argue, you should use them only because they are new. This might be easier to do with a small project that management would consider less important.

Once you have one project, you won half the battle and can use it as an example of the benefits of new technologies for leadership.

Good luck anyway.

0
source

When a new guy comes and begins to preach - even in a completely legal, positive and useful way - about new tools, he often can create an atmosphere of “you against them”.

This should not be so, but recognizing that these amazing new tools will save them a lot of work is a kind of implicit admission that they spent a lot of time. Even if they are okay with a personal level (external restrictions aside, most people just want to do a good job!), They will be careful about how this might look for their bosses if the “new guy” knows a lot more than they .

Idea: ask them to go to some local developer events with you. Then it is more like you discovering interesting new things together and less than "my tools are better than yours."

Among other things, you need to invest a little elbow-grease and nail several projects so that you build up credit at your new workplace.

Also, I always thought SQL Server 2000 was fantastic. SQL 2K5 and 2K8 are good updates, but 2000 is really solid stuff; this is not like they work in Access.

0
source

All Articles