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.

The impression I get is you are emailing random links out to your coworkers without any context/descriptions attached. — enderland, Oct 15 '12 at 22:57
It varies. I will say that I put less effort into providing context now than I did at first--just a sentence or maybe the summary will be the email title. At first, I did more, but my motivation level has fallen. My boss has supported my doing this (to me) but I don't know what he has said to others. — Amy Blankenship, Oct 16 '12 at 01:22
Related: How can I deal with co-workers that send me a lot of off topic emails? — yannis, Oct 16 '12 at 09:59
This is a really poor title for this question. You've basically set-up a mailing list without having any way for colleagues to opt out or in. That's not just "sharing a link". — Lilienthal, May 13 '16 at 12:04
Thanks for leaping forward with this timely comment. Do you really think that at the workplace when someone sees a link that they think will help you do your job better, there needs to be a formal mailing list to help that happen? And then the opting out needs to be more complicated than just deleting unread? — Amy Blankenship, May 13 '16 at 14:55
FWIW, the people who never wanted to change anything are still doing what they were doing then (Flash and ASP classic), and I'm leading the HTML 5 team, which is made up of all new people. So. — Amy Blankenship, May 13 '16 at 14:57

score 24 · Answer 1 · answered Oct 15 '12 at 23:12

24

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.

answered Oct 15 '12 at 23:12

yannis

5,314
7
41
70

5

It's not just you. – pdr Oct 15 '12 at 23:42
I think your answer would be more helpful if it addressed the mechanics of how to get a blog instituted on a team that's so slow to embrace new technologies, especially if it considered the issue of how to broach the subject without ruffling feathers. I actually have done quite a bit of documentation and have also sent out emails directly related to code changes (to the old codebase), to a similar lack of response. – Amy Blankenship Oct 16 '12 at 00:43
1

@AmyBlankenship The thing is, every time I was involved in a team that was slow to embrace new technologies, there were other underlying problems and their unwillingness to learn new things was just a side effect. Organizational issues, management issues, salary issues, nepotism issues etc. Programmers typically are always eager to learn new things, and although I have absolutely no idea what's going on with your team I suspect deeper issues. – yannis Oct 16 '12 at 09:58
@AmyBlankenship The only way I, as a senior developer, found to talk about these issues with the rest of the team was to take them out for a beer and get everyone gloriously drunk (When I invited them I said beer, but after a couple of hours at the bar I took out my secret weapon, tequila ;). It's a very tough situation to be in, and I honestly don't have any better ideas on how to deal with it. – yannis Oct 16 '12 at 10:01
1

@YannisRizos, someone named Amy is not likely to be able to ask the group out to get drunk, that would be interprerted far differntly for a woman to ask than a guy. – HLGEM Oct 16 '12 at 21:41
@HLGEM That's probably true, sadly. And inviting the team out for drinks won't work for every team, obviously, regardless of who invites them. – yannis Oct 16 '12 at 21:49
+1 For honesty, even if I disagree with you. I enjoy receiving interesting emails. – geekrunner May 07 '14 at 22:46

score 5 · Answer 2 · answered Oct 16 '12 at 11:29

Some key questions which spring to mind here -

Why are the team slow to adopt new technology?
What is wrong with what they are currently doing, how is it harming the business?
How will adopting new technology make each individual's job easier? Not in a fluffy nebulous way, but in specific, tangible, measurable ways?
"best practises" - according to whom, specifically? Who says the 'best practises' are better than the current approach the team uses?
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.

score 4 · Answer 3 · answered Oct 16 '12 at 12:52

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.

No one is officially the team lead. I think that's part of the issue. For the boss to fully support me, he would have to work his way around to thinking maybe there are problems in how people who have been working for him a long time are doing things. And the reason I work for him is his loyalty to people, so I'm trying to find ways to work with this and not against it.
We actually have very friendly relationships when we meet (it's a small team), but we seem to actively avoid the big issues. — Amy Blankenship, Oct 16 '12 at 14:02
Perhaps it is time to ask to be made into the team lead then and start getting things moving in the right direction. I know it is a small company, but if you want to succeed someone needs to take the reigns. — Matt Ridge, Oct 16 '12 at 14:09

score 2 · Answer 4 · answered Oct 16 '12 at 11:01

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?

score 1 · Answer 5 · answered Aug 16 '14 at 19:00

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.

Yes, the group was new and I wasn't comfortable posting the real issue (and I felt the smaller issue I posted would be easier to actually answers). More ambitious questions have been asked since :) — Amy Blankenship, Aug 19 '14 at 00:11

score 1 · Answer 6 · answered Oct 16 '12 at 22:02

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.

I think that wikis and code reviews might be too much, too fast, since we're still struggling to get the entire team consistently using version control (which I think would be needed for code reviews to work on a remote team). — Amy Blankenship, Oct 16 '12 at 22:43
@AmyBlankenship, hostly if you can;t get them to use version control, then you should fire them. Fire one and teh rest will realize this si serious stuff. I know you aren't the boss, but not using version control is evidence of incompetence of the highest order. — HLGEM, Oct 16 '12 at 23:01
Like I said, I work for my boss because he is incredibly loyal to people. It is not going to happen. — Amy Blankenship, Oct 16 '12 at 23:40

Steve Jessop · Answer 7 · 2014-08-16T11:25:54.617

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".

Is it appropriate to share links with coworkers?

7 Answers7

Linked