Is it appropriate to share links with coworkers?

Question

I'm working at a company that is slow to embrace new technologies and best practices. I worry about this, because I was given the green light to rewrite a large part of the codebase in the current version of one of the the languages we use (Actionscript 3). The rewrite was largely complete a couple of months ago, but I am still the only person who has touched it.

I periodically send out links to blog posts and articles that touch on some of the concepts I've incorporated that I haven't seen evidence of in the existing codebase. I usually receive absolutely no response from these attempts, so I have no idea if the other developers are poring over the links with interest, deleting them unread, or what. I don't want to look like a know-it-all, but I also feel like there is a lot of foundational knowledge that I'll need to provide for them before they can use the new system.

We're all remote, so I don't know my coworkers as well as I'd like. In a good month, we meet once a month and the meeting is usually scheduled to the hilt, with no place to discuss things like adopting better practices. Ironically, I feel like we'd have more time/room to discuss such practices if we would adopt more of them. However, it's difficult to bring this up without sounding like I'm criticizing the developers who have been there longer than I have.

I guess the small question is: should I take the complete silence when I send links as a hint and stop doing it? The larger question is, what's a tactful way to educate the rest of the team in concepts I feel are important for them to know to build code that we can all work in efficiently?

---

Edit to respond to question: I usually email the entire team, so as not to be singling out a particular person. I might IM the link if there's some reason it's specifically of interest to that person. I'll usually send out links as I find them, and this will vary in frequency from once or twice a week to once a month (probably an average of once every two weeks or so).

---

More edits to address the questions about the types of links I send out. (I tried to keep this more of a generic question, so that it could be useful for others, but let's make this "about me" ;)

• For example, after the meeting where I pitched fr being able to rewrite the codebase and got the green light, I sent out a group of links, mostly from my archives at O'Reilly, that offered foundational principles that I'd be building upon.

• In the old codebase, when I got tired of doing screen captures of the menu for the part of our instructions where we walk them through what the parts of the Assessment are, I rewrote the menu so that it could just be used in the walkthrough (with the added benefit of allowing cool animations during the walkthrough), and summarized what I'd done, how to use it, and how it saves time (you don't have to redo the screencaptures and replace the old ones every time the menu changes, which happens a lot).

• I was talking to another dev on an IM, and asked rhetorically "Have you ever heard of the Single Responsibility Priciple" (expecting "yes, but I didn't use it here because..."). When he said no, I sent him a link to the Wikipedia definition.

• We have a lot of pressure from our customers to move to HTML5. When I returned from a recent JavaScript meetup, I posted a link to ToDoMVC with the comment "This site provides implementations of some of the major JS frameworks, which could really help us decide which Framework to use."

---

Final edits. I want to thank everyone that responded. I don't think I can mark any of the answers as "correct," because I didn't get an "aha!" out of any of these. The best suggestion, I think, came from Matt's comment that maybe it's time to take the bull by the horns and ask to be team lead. But it's not an answer, so I can't mark it correct.

Answer 1

I strongly dislike receiving emails from colleagues that aren't strictly about our work, however interesting or useful they might be, and I would go absolutely mental if someone interrupted me by sending me a link via IM. That might just be me, but the lack of response from your colleagues probably means that they aren't exactly enthused about it as well.

On several teams I've worked with I was (sometimes officially, others unofficially) the researcher of the team, and part of my responsibilities was to dig up anything new and cool we could use in our codebase. From my experience, what works best is a casual, in company blog. Every time you find something you'd like to share with the rest of the team, write a somewhat comprehensive article about it, don't just post a list of links without context. It doesn't have to explain the concepts / practices / technologies / tools in depth, but its essential that you point out clearly how whatever you are talking about applies to what you or your team works on at the moment.

You could start with the rewrite, write a series of small and casual but comprehensive articles on what new things you introduced to the codebase, what decisions you made and why, discuss challenging issues you faced and how you overcame them. Show real examples from your codebase, point to actual tickets in your issue tracker. In short: context.

At the end of the day your colleagues may still ignore you. But this time it won't be because you're spamming them, and you'll have excellent documentation of your thought process and progress of your skills.

Answer 2

Some key questions which spring to mind here -

1. Why are the team slow to adopt new technology?
2. What is wrong with what they are currently doing, how is it harming the business?
3. How will adopting new technology make each individual's job easier? Not in a fluffy nebulous way, but in specific, tangible, measurable ways?
4. "best practises" - according to whom, specifically? Who says the 'best practises' are better than the current approach the team uses?
5. In a nutshell, think from the individual team member's perspective "Why should I change? What's in it for me? How will it make my life easier?"

Question 5 is the KILLER - you absolutely must address that above all else, otherwise no matter how good your intentions, the team are not going to be motivate to make any change - why should they if it doesn't make their lives easier or better in some way? And it's not enough just to say "It'll make your life easier/better/whatever", you have to show clear, concrete, specific ways in which it will achieve this, with real reasons and evidence to support those claims.

There's a whole host of other considerations as to how one goes about this, of course. For example, one needs to avoid simply telling colleagues "You are wrong, you should do it this way", that is the quickest way to get them to ignore! People need to have a reason to change the way they do things, "It's the latest way / some researcher says it's best practise" is not a reason.

Introduce changes slowly and gradually - build up trust so that over time people will come to think "Hey, Amy knows she's talking about, that last change really helped me - I wanna listen to her more often".

Thinking about the articles you send out - do you give a summary of what the article is and why it is relevant? Or do you just say "Here's a link to an article about Actionscript 3 best practises" (for example)? If the latter, it's pretty much a dead cert the recipients will bin the email - we all get a ton of emails and RSS feeds and journals and info as it is, someone telling me I need to read an entire article but without explaining why I would benefit is not going to get me to read it. Give a very very brief summary, engage interest, let me see why I will benefit from spending my time reading it, and I'm there; tell me "This is interesting / you should read this" and it'll get binned.

Answer 3

I have to ask a question here, are you officially the team lead? If you aren't then you need to talk to the manager that gave you the green light and figure out your next step.

Realistically if you are the only one that knows what is going on about giving you the ability to re-write a large part of the codebase, you do sound like you are coming off as a know-it-all. I would request if it hasn’t been done already, to have your manager write an email to the other programmers and tell them their decision.

Then I would introduce yourself, and then say that while you are writing this codebase, you will be sending out periodical links and information that will help with the project in the future, and you would appreciate feedback once in a while. Perhaps get a communication going and find out more about your team. If possible get together if you are close enough and have a coffee, if not, suggest a meeting once a week to find out where things are, and how they are progressing. Perhaps even to brainstorm, use Skype, or something of the sort.

As for the silence, if your email has it, make it so that every time an email is read you are verified, otherwise you may never know. In reality though, these people may not know you from a hole in the wall, so they may be ignoring you because they don’t really know you, and as I said before, sending out stuff like that without saying more about why you are sending them stuff, really is an annoyance factor.

At least it would be to me. I hope this helps some, but in reality we need to know more about what is going on…. Because you have told us enough to help you a little, but not enough to really know your situation.

Answer 4

Many IT specialists nowadays are overwhelmed with RSS feeds they have subscribed to and many consume endless amounts of information. Individuals select feeds usually based on their own interests and what they think might be useful for them. Sending a pure link to a professional might even be quite strange -- the person may already know the information in question, and if they don't know it - why they did not subscribe to some source of information of such sort?

However, there is a probability that a certain number of developers do read the links you post and may be even expecting further from you. You can go explicit and ask whether it is good if team members share what they read. Lack of response would mean that the team is unlikely to be interested in doing anything beyond day-to-day tasks.

Remote nature of the team may be the primary source of such confusion. There may be subtle details of the team that you have not experienced yet. For example, if the management uses tough deadlines and frequently pushes for quick deployments, the usage of new technologies becomes strictly discouraged -- the team members would not like to 'waste time' learning new things when they have to deploy features tomorrow.

Since you seem to see value in what you are doing, giving up would unlikely be a good strategy. Rather, it might be good to find out what others think of what you do and about building a corporate knowledge base in general. You may try to persuade the management to give closer attention to the knowledge sharing activities. (A good rationale might be one that using the latest technology efficiently often cuts costs/improves quality). You may try to arrange virtual meetings with team members and management or video conferences to discuss these issues. However, chances of success (i.e. getting others involved in sharing or at least giving you feedback) would seriously depend on how objective are your interventions in the typical information flows of your co-workers -- how that link would help them today or tomorrow? what do you propose to change, how that information would be helpful?

Answer 5

Set up a wiki for the various useful professional links that people find. Put your links here.

However, you will never teach people new techiques simply by sending them links. It sounds as if your colleagues are in need of updating their training, so propose some training classes to your boss. You have written a new process, train them in what you did and how to maintain it. Set up an hour a week for training and everyone gets a topic to train on in a rotating fashion. What we did in one place was have the presenters be either people who were good at a particular technique or people who needed to learn it. But no one got out of presenting. The boss or the team could determine the list of subjects. We put out a schedule for a couple of months at a time.

Code review is another good way to get people up-to-speed. If they can't follow your code in a code review, they will never be able to maintain it. Plus it gives the person a chance to ask questions about what you did and why and because they are trying to ensure your code is right, they are more likely to listen to the answers if only to prove you wrong. Code review can also ensure that the new techinques are used. Code fails if it uses bad technique.

Answer 6

No one seems to be discussing the real issue: You feel the other developers are not adopting best practices.

Your method of sending links is obviously not the solution, as you can see from the lack of interest or adoption.

If you feel adopting certain policies and practices will improve the quality of the work, then you need to discuss this with your supervisor. Explain to him how adopting these policies will benefit the company. Will they reduce labor and costs? Will they help reduce bugs? Will it increase readability and help new developers get up to speed faster? Etc.

In my experience, developers tend to be very set in their ways. A friend of mine was a development manager and tried to implement code writing policies. He said getting a group coders to adopt things like using the same formatting for code, naming variables in a standard way, standardizing comments, etc, was one of the hardest things he ever did... And he said he did not achieve 100% success.

Answer 7

I periodically send out links to blog posts and articles that touch on some of the concepts I've incorporated that I haven't seen evidence of in the existing codebase

It's not unusual for people to send out "this is interesting" emails with links, but personally I think it's a questionable practice. Supposing it takes just 10 minutes to read the article and there are 10 people in the team, you created an hour-and-a-half task for the team to complete that probably won't amount to anything. Even if others generally agree with the article, they're agreeing with it in isolation not as a team. The team probably won't complete the task anyway because they won't all read the article, but that's hardly an excuse since to those who don't read it it's definitely a pointless email.

If you want to promote a particular practice, then you should make a case in your own words why it's useful specifically to your team, and link to the articles for further information. You should solicit opinions from other team members whether they think it would help. This takes longer than just firing off a link in an email, and even takes longer than reading the article, but at least it's a discussion among the team that might actually lead to something.

Email is (by design) particularly easy to ignore. If someone receives an email that says "you might like to read this" then they're perfectly entitled to think "and then again, I might not like to, and I'm already busy this morning" and delete it. And you're not entitled to expect anything different. You can't use a bulk email in that format to engage people. You need another approach, which might still be an email but it would have to be an email like "I think we'd benefit by changing from X to Y, what do you think?", not "Here is some information about Y".