Share Your Work

This is a stub of ideas outlined in a talk I gave at the 2014 Hacks Hackers Media Party in Buenos Aires

background

Brian Boyer, back when he ran the News Apps Team at the Chicago Tribune, popularized the term: Show Your Work.

And by that, he and his team team meant: open your code and talk about process through things like team blogs.

And, since, we have all gotten really good at showing our work.

And man what work it is to show: over the last few years, the work that this community has produced has evolved exponentially. We've gone from google map mashups to writing entire mapping libraries. From basic charts and graphs to complex masterpieces using newsroom-built libraries like D3. (We've even gone from being in awe of Snowfall to making it a punchline in record time.)

That is, in large part, thanks to this SHOW YOUR WORK philosophy: it's allowed the things we do best--and the way we did them--to spread rapidly.

But I'm starting to think that that terminology is becoming outdated.

As we evolve as a community and as a culture:

We need to do more than SHOW our work, we need to SHARE it.

What Does it Mean to Share Your Work?

This is still cookie dough: it's not cooked. You should fork and add or modify or help. Feel free to submit new ideas, open an issue to discuss further.

It's cookie dough, but I do want to offer some things that I think SHARE YOUR WORK should mean

collaborate: First and foremost, we need to collaborate more on actually writing code together. We spend too much time reproducing work, not enough time putting heads together to just do it once. We need to find and make the time to collaborate more. Both across newsrooms, but within them as well.
document: Open-source code isn't simply code stuck up on github: that's available source code. Open code means really sharing that code: creating great documentation with examples, being responsive to questions and pull requests, and most importantly letting people know it's out there.
explain: Doing the work to help people to understand the WHYs of your decisions through extensive process documentation as well. And putting that in a place people will find it (like, say Source, which collects this kind of work from teams all over), including linking it up from the readme in repos.
connect: There are lots of people that should be involved in what we do. It's up to us to reach out to them. In a newsroom, maybe that means having informal lunches to discuss topics and get colleagues up to speed. Outside the newsroom it means finding underrepresented communities and bringing them in.

Share Your Work

This is a stub of ideas outlined in a talk I gave at the 2014 Hacks Hackers Media Party in Buenos Aires

background

Brian Boyer, back when he ran the News Apps Team at the Chicago Tribune, popularized the term: Show Your Work.

And by that, he and his team team meant: open your code and talk about process through things like team blogs.

And, since, we have all gotten really good at showing our work.

And man what work it is to show: over the last few years, the work that this community has produced has evolved exponentially. We've gone from google map mashups to writing entire mapping libraries. From basic charts and graphs to complex masterpieces using newsroom-built libraries like D3. (We've even gone from being in awe of Snowfall to making it a punchline in record time.)

That is, in large part, thanks to this SHOW YOUR WORK philosophy: it's allowed the things we do best--and the way we did them--to spread rapidly.

But I'm starting to think that that terminology is becoming outdated.

As we evolve as a community and as a culture:

We need to do more than SHOW our work, we need to SHARE it.

What Does it Mean to Share Your Work?

This is still cookie dough: it's not cooked. You should fork and add or modify or help. Feel free to submit new ideas, open an issue to discuss further.

It's cookie dough, but I do want to offer some things that I think SHARE YOUR WORK should mean

collaborate: First and foremost, we need to collaborate more on actually writing code together. We spend too much time reproducing work, not enough time putting heads together to just do it once. We need to find and make the time to collaborate more. Both across newsrooms, but within them as well.
document: Open-source code isn't simply code stuck up on github: that's available source code. Open code means really sharing that code: creating great documentation with examples, being responsive to questions and pull requests, and most importantly letting people know it's out there.
explain: Doing the work to help people to understand the WHYs of your decisions through extensive process documentation as well. And putting that in a place people will find it (like, say Source, which collects this kind of work from teams all over), including linking it up from the readme in repos.
connect: There are lots of people that should be involved in what we do. It's up to us to reach out to them. In a newsroom, maybe that means having informal lunches to discuss topics and get colleagues up to speed. Outside the newsroom it means finding underrepresented communities and bringing them in.

Share Your Work

This is a stub of ideas outlined in a talk I gave at the 2014 Hacks Hackers Media Party in Buenos Aires

background

Brian Boyer, back when he ran the News Apps Team at the Chicago Tribune, popularized the term: Show Your Work.

And by that, he and his team team meant: open your code and talk about process through things like team blogs.

And, since, we have all gotten really good at showing our work.

And man what work it is to show: over the last few years, the work that this community has produced has evolved exponentially. We've gone from google map mashups to writing entire mapping libraries. From basic charts and graphs to complex masterpieces using newsroom-built libraries like D3. (We've even gone from being in awe of Snowfall to making it a punchline in record time.)

That is, in large part, thanks to this SHOW YOUR WORK philosophy: it's allowed the things we do best--and the way we did them--to spread rapidly.

But I'm starting to think that that terminology is becoming outdated.

As we evolve as a community and as a culture:

We need to do more than SHOW our work, we need to SHARE it.

What Does it Mean to Share Your Work?

This is still cookie dough: it's not cooked. You should fork and add or modify or help. Feel free to submit new ideas, open an issue to discuss further.

It's cookie dough, but I do want to offer some things that I think SHARE YOUR WORK should mean

collaborate: First and foremost, we need to collaborate more on actually writing code together. We spend too much time reproducing work, not enough time putting heads together to just do it once. We need to find and make the time to collaborate more. Both across newsrooms, but within them as well.
document: Open-source code isn't simply code stuck up on github: that's available source code. Open code means really sharing that code: creating great documentation with examples, being responsive to questions and pull requests, and most importantly letting people know it's out there.
explain: Doing the work to help people to understand the WHYs of your decisions through extensive process documentation as well. And putting that in a place people will find it (like, say Source, which collects this kind of work from teams all over), including linking it up from the readme in repos.
connect: There are lots of people that should be involved in what we do. It's up to us to reach out to them. In a newsroom, maybe that means having informal lunches to discuss topics and get colleagues up to speed. Outside the newsroom it means finding underrepresented communities and bringing them in.

Share Your Work

This is a stub of ideas outlined in a talk I gave at the 2014 Hacks Hackers Media Party in Buenos Aires

background

Brian Boyer, back when he ran the News Apps Team at the Chicago Tribune, popularized the term: Show Your Work.

And by that, he and his team team meant: open your code and talk about process through things like team blogs.

And, since, we have all gotten really good at showing our work.

And man what work it is to show: over the last few years, the work that this community has produced has evolved exponentially. We've gone from google map mashups to writing entire mapping libraries. From basic charts and graphs to complex masterpieces using newsroom-built libraries like D3. (We've even gone from being in awe of Snowfall to making it a punchline in record time.)

That is, in large part, thanks to this SHOW YOUR WORK philosophy: it's allowed the things we do best--and the way we did them--to spread rapidly.

But I'm starting to think that that terminology is becoming outdated.

As we evolve as a community and as a culture:

We need to do more than SHOW our work, we need to SHARE it.

What Does it Mean to Share Your Work?

This is still cookie dough: it's not cooked. You should fork and add or modify or help. Feel free to submit new ideas, open an issue to discuss further.

It's cookie dough, but I do want to offer some things that I think SHARE YOUR WORK should mean

collaborate: First and foremost, we need to collaborate more on actually writing code together. We spend too much time reproducing work, not enough time putting heads together to just do it once. We need to find and make the time to collaborate more. Both across newsrooms, but within them as well.
document: Open-source code isn't simply code stuck up on github: that's available source code. Open code means really sharing that code: creating great documentation with examples, being responsive to questions and pull requests, and most importantly letting people know it's out there.
explain: Doing the work to help people to understand the WHYs of your decisions through extensive process documentation as well. And putting that in a place people will find it (like, say Source, which collects this kind of work from teams all over), including linking it up from the readme in repos.
connect: There are lots of people that should be involved in what we do. It's up to us to reach out to them. In a newsroom, maybe that means having informal lunches to discuss topics and get colleagues up to speed. Outside the newsroom it means finding underrepresented communities and bringing them in.

Share Your Work

This is a stub of ideas outlined in a talk I gave at the 2014 Hacks Hackers Media Party in Buenos Aires

background

Brian Boyer, back when he ran the News Apps Team at the Chicago Tribune, popularized the term: Show Your Work.

And by that, he and his team team meant: open your code and talk about process through things like team blogs.

And, since, we have all gotten really good at showing our work.

And man what work it is to show: over the last few years, the work that this community has produced has evolved exponentially. We've gone from google map mashups to writing entire mapping libraries. From basic charts and graphs to complex masterpieces using newsroom-built libraries like D3. (We've even gone from being in awe of Snowfall to making it a punchline in record time.)

That is, in large part, thanks to this SHOW YOUR WORK philosophy: it's allowed the things we do best--and the way we did them--to spread rapidly.

But I'm starting to think that that terminology is becoming outdated.

As we evolve as a community and as a culture:

We need to do more than SHOW our work, we need to SHARE it.

What Does it Mean to Share Your Work?

This is still cookie dough: it's not cooked. You should fork and add or modify or help. Feel free to submit new ideas, open an issue to discuss further.

It's cookie dough, but I do want to offer some things that I think SHARE YOUR WORK should mean

collaborate: First and foremost, we need to collaborate more on actually writing code together. We spend too much time reproducing work, not enough time putting heads together to just do it once. We need to find and make the time to collaborate more. Both across newsrooms, but within them as well.
document: Open-source code isn't simply code stuck up on github: that's available source code. Open code means really sharing that code: creating great documentation with examples, being responsive to questions and pull requests, and most importantly letting people know it's out there.
explain: Doing the work to help people to understand the WHYs of your decisions through extensive process documentation as well. And putting that in a place people will find it (like, say Source, which collects this kind of work from teams all over), including linking it up from the readme in repos.
connect: There are lots of people that should be involved in what we do. It's up to us to reach out to them. In a newsroom, maybe that means having informal lunches to discuss topics and get colleagues up to speed. Outside the newsroom it means finding underrepresented communities and bringing them in.

Share Your Work

This is a stub of ideas outlined in a talk I gave at the 2014 Hacks Hackers Media Party in Buenos Aires

background

Brian Boyer, back when he ran the News Apps Team at the Chicago Tribune, popularized the term: Show Your Work.

And by that, he and his team team meant: open your code and talk about process through things like team blogs.

And, since, we have all gotten really good at showing our work.

And man what work it is to show: over the last few years, the work that this community has produced has evolved exponentially. We've gone from google map mashups to writing entire mapping libraries. From basic charts and graphs to complex masterpieces using newsroom-built libraries like D3. (We've even gone from being in awe of Snowfall to making it a punchline in record time.)

That is, in large part, thanks to this SHOW YOUR WORK philosophy: it's allowed the things we do best--and the way we did them--to spread rapidly.

But I'm starting to think that that terminology is becoming outdated.

As we evolve as a community and as a culture:

We need to do more than SHOW our work, we need to SHARE it.

What Does it Mean to Share Your Work?

This is still cookie dough: it's not cooked. You should fork and add or modify or help. Feel free to submit new ideas, open an issue to discuss further.

It's cookie dough, but I do want to offer some things that I think SHARE YOUR WORK should mean

collaborate: First and foremost, we need to collaborate more on actually writing code together. We spend too much time reproducing work, not enough time putting heads together to just do it once. We need to find and make the time to collaborate more. Both across newsrooms, but within them as well.
document: Open-source code isn't simply code stuck up on github: that's available source code. Open code means really sharing that code: creating great documentation with examples, being responsive to questions and pull requests, and most importantly letting people know it's out there.
explain: Doing the work to help people to understand the WHYs of your decisions through extensive process documentation as well. And putting that in a place people will find it (like, say Source, which collects this kind of work from teams all over), including linking it up from the readme in repos.
connect: There are lots of people that should be involved in what we do. It's up to us to reach out to them. In a newsroom, maybe that means having informal lunches to discuss topics and get colleagues up to speed. Outside the newsroom it means finding underrepresented communities and bringing them in.

Share Your Work

This is a stub of ideas outlined in a talk I gave at the 2014 Hacks Hackers Media Party in Buenos Aires

background

Brian Boyer, back when he ran the News Apps Team at the Chicago Tribune, popularized the term: Show Your Work.

And by that, he and his team team meant: open your code and talk about process through things like team blogs.

And, since, we have all gotten really good at showing our work.

And man what work it is to show: over the last few years, the work that this community has produced has evolved exponentially. We've gone from google map mashups to writing entire mapping libraries. From basic charts and graphs to complex masterpieces using newsroom-built libraries like D3. (We've even gone from being in awe of Snowfall to making it a punchline in record time.)

That is, in large part, thanks to this SHOW YOUR WORK philosophy: it's allowed the things we do best--and the way we did them--to spread rapidly.

But I'm starting to think that that terminology is becoming outdated.

As we evolve as a community and as a culture:

We need to do more than SHOW our work, we need to SHARE it.

What Does it Mean to Share Your Work?

This is still cookie dough: it's not cooked. You should fork and add or modify or help. Feel free to submit new ideas, open an issue to discuss further.

It's cookie dough, but I do want to offer some things that I think SHARE YOUR WORK should mean

collaborate: First and foremost, we need to collaborate more on actually writing code together. We spend too much time reproducing work, not enough time putting heads together to just do it once. We need to find and make the time to collaborate more. Both across newsrooms, but within them as well.
document: Open-source code isn't simply code stuck up on github: that's available source code. Open code means really sharing that code: creating great documentation with examples, being responsive to questions and pull requests, and most importantly letting people know it's out there.
explain: Doing the work to help people to understand the WHYs of your decisions through extensive process documentation as well. And putting that in a place people will find it (like, say Source, which collects this kind of work from teams all over), including linking it up from the readme in repos.
connect: There are lots of people that should be involved in what we do. It's up to us to reach out to them. In a newsroom, maybe that means having informal lunches to discuss topics and get colleagues up to speed. Outside the newsroom it means finding underrepresented communities and bringing them in.

Share Your Work

This is a stub of ideas outlined in a talk I gave at the 2014 Hacks Hackers Media Party in Buenos Aires

background

Brian Boyer, back when he ran the News Apps Team at the Chicago Tribune, popularized the term: Show Your Work.

And by that, he and his team team meant: open your code and talk about process through things like team blogs.

And, since, we have all gotten really good at showing our work.

And man what work it is to show: over the last few years, the work that this community has produced has evolved exponentially. We've gone from google map mashups to writing entire mapping libraries. From basic charts and graphs to complex masterpieces using newsroom-built libraries like D3. (We've even gone from being in awe of Snowfall to making it a punchline in record time.)

That is, in large part, thanks to this SHOW YOUR WORK philosophy: it's allowed the things we do best--and the way we did them--to spread rapidly.

But I'm starting to think that that terminology is becoming outdated.

As we evolve as a community and as a culture:

We need to do more than SHOW our work, we need to SHARE it.

What Does it Mean to Share Your Work?

This is still cookie dough: it's not cooked. You should fork and add or modify or help. Feel free to submit new ideas, open an issue to discuss further.

It's cookie dough, but I do want to offer some things that I think SHARE YOUR WORK should mean

collaborate: First and foremost, we need to collaborate more on actually writing code together. We spend too much time reproducing work, not enough time putting heads together to just do it once. We need to find and make the time to collaborate more. Both across newsrooms, but within them as well.
document: Open-source code isn't simply code stuck up on github: that's available source code. Open code means really sharing that code: creating great documentation with examples, being responsive to questions and pull requests, and most importantly letting people know it's out there.
explain: Doing the work to help people to understand the WHYs of your decisions through extensive process documentation as well. And putting that in a place people will find it (like, say Source, which collects this kind of work from teams all over), including linking it up from the readme in repos.
connect: There are lots of people that should be involved in what we do. It's up to us to reach out to them. In a newsroom, maybe that means having informal lunches to discuss topics and get colleagues up to speed. Outside the newsroom it means finding underrepresented communities and bringing them in.

Name		Name	Last commit message	Last commit date
README.md		README.md

Name		Name	Last commit message	Last commit date
README.md		README.md

Name		Name	Last commit message	Last commit date
README.md		README.md

Name		Name	Last commit message	Last commit date
README.md		README.md

Name		Name	Last commit message	Last commit date
README.md		README.md

Latest commit

History

Folders and files

Repository files navigation

Share Your Work

background

What Does it Mean to Share Your Work?

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Latest commit

History

Folders and files

Repository files navigation

Share Your Work

background

What Does it Mean to Share Your Work?

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Latest commit

History

Folders and files

Repository files navigation

Share Your Work

background

What Does it Mean to Share Your Work?

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Latest commit

History

Folders and files

Repository files navigation

Share Your Work

background

What Does it Mean to Share Your Work?

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Latest commit

History

Folders and files

Repository files navigation

Share Your Work

background

What Does it Mean to Share Your Work?

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Latest commit

History

Folders and files

Repository files navigation

Share Your Work