Planet Harvard

May 30, 2014

Greg Mankiw

May 27, 2014

Dani Rodrik

Erdogan’s Coup

Daron Acemoglu wrote what seemed like a surprising upbeat piece on Turkish democracy a few days ago. His argument seems to be that democracy required power to be wrested away from the secularists who had erected authoritarian structures, and Erdogan had achieved that. Even though, Erdogan’s recent turn to authoritarianism is “lamentable,” it was, Acemoglu claims, a predictable stage in Turkey’s democratic transition. Once Erdogan is gone, the article implies, democracy would be on a stronger footing than ever.

There were in fact many other paths that could have proved less costly. The more typical pattern is that the old elites reach a modus vivendi with the rising, popular forces that preserves some of their privileges in return for opening up (as happened in Spain and many of the Latin American examples). The Erdogan model of decapitating the secular old guard with a series of sham political trials served instead to deepen old divides and ended up erecting an alternative set of authoritarian structures.

In the early years of Erdogan’s rule, it was easy to mistake the loosening of old taboos associated with the Kemalist-secular elite as a process of democratization. But towards the end of the 2000s, anyone who looked closely could not have been under a similar illusion. The repression of the media and the jailing of opponents on bogus charges had become an unmistakable pattern. Saying this was an inevitable and necessary step towards democracy would be odd indeed.

The Acemoglu article prompted Erik Meyersson and me to write a riposte of sorts. It is called “Erdogan’s Coup,” and can be read here.

by Dani Rodrik at May 27, 2014 12:57 PM

May 23, 2014

Greg Mankiw

Improving Econ 101

Noah Smith says introductory economics needs to be more empirical. I understand his argument, and have some sympathy with it, but I wonder if the substantial change he seems to be proposing is practical.  Economists usually do empirical work with statistical tools that most college freshmen have not yet learned. 

We teachers of introductory economics can and should explain where and why economists disagree. That is part of helping students develop their critical thinking skills.  But I doubt students are in a position to try to evaluate the competing empirical work that shapes the differing views.

In the end, introductory economics is just that: an introduction to the economist's way of thinking.  That means giving students basic concepts--comparative advantage, supply and demand, market efficiency and market failure--that will make them more perceptive readers of the newspaper.

by Greg Mankiw (noreply@blogger.com) at May 23, 2014 11:49 AM

David Autor on Inequality

From a recent interview of the MIT economist (discussing this article):
Q. You are focused on inequality among the so-called “99 percent,” not between the 1 percent and the 99 percent. Why?
A. There’s a real national debate about the significance and causes of inequality. This public debate is dominated by the discussion of the top 1 percent. And the top 1 percent is important, but focusing on the top 1 percent conveys the message that the game is all rigged, that if you’re not in the elite stratum, there’s nothing to shoot for. And that’s just not the case. The growth of skill differentials among the other 99 percent is arguably even more consequential than the rise of the 1 percent for the welfare of most citizens. 
Here’s a concrete way to see it: The earnings gap between the median college-educated two-income family and the median high school-educated two-income family rose by $28,000 between 1979 and 2012. This [shift] — which excludes the top 1 percent, since we’re focusing on medians — is four times as large as the redistribution that has taken place from the bottom 99 percent to the top 1 percent of households in the same period.

by Greg Mankiw (noreply@blogger.com) at May 23, 2014 10:07 AM

May 22, 2014

Greg Mankiw

A Defense of High Frequency Traders

By Cliff Asness et al.  Very cogent, in my view.  The bottom line:
In summary, we don't believe HFT profits are excessive or excessively consistent. We censure illegal front running as strongly as anyone, but it has near nothing to do with HFT per se. Canceling orders in the process of providing liquidity is key to any sort of market making, whether HFT or not. We support the right of HFTs, or anyone, to try to guess the direction of the market, using order flow or any other public information. We not only support the right, we celebrate the successful exercise of that right as it adds to public welfare by making markets more efficient and lowering the cost of investing. Lastly, we believe markets are "rigged" in favor of, not against, retail investors.

by Greg Mankiw (noreply@blogger.com) at May 22, 2014 07:33 AM

May 20, 2014

Greg Mankiw

May 16, 2014

Harvard College Democrats

Progressive Summer Stipend Program Application

Have you secured an internship with a progressive organization this summer but need funds to facilitate your experience? Does the organization contribute to progressive causes, especially the goals of campaign finance reform or more equal political representation? Or, are you still looking for an internship in DC to reform Washington and get big money out […]

by Jacob Carrel at May 16, 2014 03:01 PM

May 14, 2014

Greg Mankiw

May 11, 2014

Greg Mankiw

A Visit to Dartmouth

I will be talking at a public event, along with Jared Bernstein, at Dartmouth on Monday.  If you are in the area and want to attend, information is available here.

by Greg Mankiw (noreply@blogger.com) at May 11, 2014 05:01 PM

Rogoff on Piketty

Here, via Project Syndicate.  A tidbit:
Would Piketty’s followers be nearly as enthusiastic about his proposed progressive global wealth tax if it were aimed at correcting the huge disparities between the richest countries and the poorest, instead of between those who are well off by global standards and the ultra-wealthy?

by Greg Mankiw (noreply@blogger.com) at May 11, 2014 06:31 AM

May 07, 2014

Matt Welsh

The Google career path, Part 2: Starting new projects

In my last blog post, I talked about what it's like to get started at Google as a new engineer. In this post, I'll talk about how new projects get started.

Standard disclaimer applies: This is my personal blog and nothing I'm saying here is endorsed or approved by Google. This is only based on my personal experience. Take it with a grain of salt.

Google is well known as having a bottom-up engineering culture. That is, new projects typically arise because a group of engineers get together, decide a problem needs to be solved, devise a solution, and convince others to (a) join in the effort and (b) launch it. It is rare -- although not unheard of -- for a Google project to start with a high-level mandate from some executive. (I have heard that this is how Google+ got its start, but I wasn't there at the time, so I don't really know.) More typically, a grassroots effort emerges out of engineers trying to build something that they think is important and will change the world. Or at least scratch an itch.

How my project got its start

My team is responsible for a range of projects to optimize and streamline the mobile web. The main thing we are known for is the Chrome Mobile data compression proxy, which provides users of Chrome on Android and iOS a switch they can flip in the browser to compress web pages by 50%. I thought it might be instructive to talk about how this project came about.

When I started the team in 2011, I was given a very broad mandate: Go fix the mobile web. Initially, we spent a bunch of time just trying to understand the problem. At the time, there were no good tools for even measuring mobile web page performance. Now, we have things like Webpagetest for mobile, but at the time you couldn't get decent measurements without a lot of work. So, we built a testbed for collecting mobile web measurements and bought a bunch of phones and tablets and started collecting data. We spent a huge amount of time analyzing the data and playing around with various technologies, like PageSpeed, to see what kind of gains could be had.

At one point we realized that the only way to move the needle with mobile web performance was to build our own proxy service which could be integrated into a browser. Around the same time, the Chrome Mobile project was ramping up, and we realized that the technology we were building would be a great addition to Chrome when it became available for Android and iOS. So, we went to the Chrome team (which we were not yet a part of) and pitched the idea -- would it make sense to integrate this hypothetical proxy into the browser, provide a setting for users to enable it? At the time, we didn't even have the proxy yet -- just a slide deck and a crude, proof-of-concept demo. But we had a lot of ideas of what it could do and how it would work.

Fortunately, the Chrome team loved the idea and even offered to take our team on as part of the Chrome project. Of course, they hadn't agreed to launch anything yet -- that approval wouldn't come until many months later -- but we had their blessing to develop the idea further and get it to a state where it could be dogfooded within Google. So we built it. We got it to dogfood. We collected data from real users (well, Googlers anyway). The data looked good, so we got approval to launch it externally, first behind a flag, then in the Chrome beta channel, and finally launch it to everyone. Boom!

So the idea for the proxy service and the project as a whole came entirely from within our team. Nobody told us to do this. And it was our job to "sell" it internally, in terms of turning the idea into a fully-baked feature that could launch with Chrome. In a lot of ways, it's like being a startup company (although one that does not have to worry about funding and already has fancy cafeterias and a gym).

Does this generalize?

I can't say for certain that my experience is the standard way of getting new projects off the ground at Google, but it seems to be.

Projects often seem to get their start with one or two engineers who have an itch to scratch, and come up with something compelling that they want to build. They might start the project on their own, in their 20% time (on which see more below), or they might spawn an effort out of their existing work.

A typical example might be where an engineer realizes that a new system needs to be built to solve a problem that they keep running into all the time (measuring mobile web pages, say). So with the blessing of their manager (or not, in some cases), they carve out time to get that project off the ground. If it's successful, it might grow, and more engineers will start to get involved.

New projects often die, too. Sometimes a project will start out with a couple of people, they'll spend a quarter or two trying to get it off the ground, and the effort fizzles out for any number of reasons. One example is that it turns out to be much harder than expected. Another is that other priorities come up and they don't have the time to run as far with the idea as they had hoped. Another is that some other project comes along which is a broader, more general form of what they were trying to do, so they decide to join forces (or just shut down the original effort).

What about 20% time?

Much has been written about Google's "20% time", whereby engineers are allowed to work on projects unrelated to their main job. (You can't do just anything for 20% projects -- taking guitar lessons wouldn't be allowed, for example -- but the definition is pretty broad.) 20% projects are a great way to seed a new effort, since (a) you don't really need any formal approval to work on them, and (b) it gives engineers a chance to do things that they would not otherwise find the time to do.

Gmail famously started as a 20% project. (The original press release was ironically posted on April 1, 2004, but it was not actually an April Fools' joke!)

There have also been many unfounded rumors of 20% time's demise. From where I sit, 20% time is alive and well, and several engineers on my team have active 20% projects. For example, one of them contributes actively to our internal platform for employees making charitable contributions, called "G-Give". Another contributes to the smart contact lens project. My own (unofficial) 20% project is doing outreach activities to the Computer Science research community -- serving on program committees, reviewing research proposals, that kind of thing. (It actually takes a lot less than 20% of my time, but don't tell my boss that.)

That said, 20% time is not used uniformly across the company and some managers are probably allergic to it. I don't think all engineers should do 20% projects, since often people can have more impact if they spend 100% of their time on their "day job" -- the 20% would be a distraction and not necessarily help them get promoted.

But promotions are the subject of my next blog post, so I'll leave it at that.

by Matt Welsh (noreply@blogger.com) at May 07, 2014 11:58 PM

May 06, 2014

Dani Rodrik

Today’s structural transformation is a more mixed story than in the past

Guest post by Uma Lele[1]

How quickly and how well are developing countries transforming their economies and with what effects on inter-sectorial growth and distribution? A group of us studied structural transformation looking at evidence from 109 countries over 30 years covering a 1980 to 2009 period with a particular focus on China, India, Indonesia and Brazil. We later followed up on the five members of the East African community.

Economists following Kuznets, Chennery and Syrquin, Johnston, Mellor and Timmer have described structural transformation (ST) as consisting of: (1) declining share of agriculture in Gross domestic product (GDP), (2) declining share of agriculture in employment, (3) rural-urban migration, (4) growth of the service and manufacturing sectors and (5) a demographic transition with reduction in the population growth rates and have noted that India’s transformation is stalled.

The turning point is reached when the share of employment in agriculture declines at a faster rate than the share of agriculture in GDP. Differences in labor productivity between the agricultural and non-agricultural sectors disappear in the final stages of structural transformation. Before labor productivities among sectors converge a huge and often even a widening gap occurs between labor productivities in the agricultural and non-agricultural sectors. Those differences explain inter-sectoral income inequalities and concentration of poverty in the agricultural sector.

Timmer and Akkus, noted in their earlier analysis of 86 countries that turning point for today’s developing Asian countries is taking longer and occuring at a higher income than was the case for the industrial countries because of the sheer sizes of the Asian labor forces in agriculture. Kuznets had explained the narrowing of income inequality at the later stages of industrial development in advanced countries in terms of their gradually increasing progressive policies, increased saving and investment in the new enpreneurial class and technological change which uses skilled labor. All these factors today explain the growing income inequalities in developed countries. We developed some new insights.

  1. In Asia value added per worker has been increasing both in agriculture and non-agriculture. The growth in labor productivity in both sectors is spectacular in China, less so in Indonesia and the least in India. It is clearly a result of more liberal policies, increased savings and investments including foreign direct investment and outsourcing to Asia. .Income distribution measured by Gini coefficients has worsened in all three countries in the same rank order as changes in labor productivities.
  2. In sharp contrast, per capita value added in the non-agricultural .sector has been declining in the rest of the developing world.
  3. In Latin America, value added per worker in agriculture has increased substantially and the continent has emerged as a major agricultural exporter and yet agriculture has been shedding labor fast. In the non-agricultural sector value added per worker shows a secular decline. Lowered Gini coefficients in Latin America are often seen as a sign of progress. But if they are the result of declining value added per worker in the non- agricultural sector, they may be less a cause for celebration.
  4. In Africa neither value added per worker in agriculture nor in the non-agricultural sector has increased much. This should be a cause of concern for both growth and poverty reduction.
  5. In short all is not well with the growth story in emerging countries.
  6. In Asia internal terms of trade have moved in favor of agriculture relative to non-agriculture. In the rest of the developing world they have shown a deterioration against agriculture perhaps because incomes outside agriculture are not increasing much and not creating as much demand for food as in Asia.

Ratio of Value added per worker in Non-Agriculture relative to Agriculture, in the World 1980-2009

 

Terms of Trade (Deflator for Agriculture/Deflator for Non-Agriculture [Industry + Service])(in US$) by Region (1980-2009)


[1]Based on a paper by Uma Lele, Manmohan Agarwal, Peter Timmer, and Sambuddha Goswami. Uma Lele is a Former Senior Advisor, the World Bank.

by Dani Rodrik at May 06, 2014 02:00 PM

Greg Mankiw

May 05, 2014

Harvard College Democrats

Op-Ed: We’re Ready For Hillary

History is just as important to forget as to remember. The New Republic’s cover article  regarding Elizabeth Warren, “Hillary’s Nightmare,” fundamentally misunderstands the Hillary Clinton that would run in 2016. Because Clinton would run as a complete reinvention. The idea of a successful progressive anti-Clinton applies to the paradigm of 2008, but two cycles later, […]

by Nick Bonstow at May 05, 2014 02:34 PM

Greg Mankiw

Very Sad News

A friend at the University of Chicago reports to me that Gary Becker died last night.  He was 83.

Gary was one of the greatest economists of the past half century. You can read about his contributions here.  I did not know him well, but based on every interaction I had with him, it seems that he was a truly nice man as well as a path-breaking scholar.  He will be missed.

Update: The Times obituary.

by Greg Mankiw (noreply@blogger.com) at May 05, 2014 07:27 AM

May 03, 2014

Greg Mankiw

VHA Revisited

Advocates of government-run healthcare often point to the veterans health system as a prototype.  For example, Paul Krugman wrote a while back:
that brings me to Mitt Romney’s latest really bad idea, unveiled on Veterans Day: to partially privatize the Veterans Health Administration (V.H.A.).  What Mr. Romney and everyone else should know is that the V.H.A. is a huge policy success story, which offers important lessons for future health reform.
So this story from CNN (hardly a right-wing news source) caught my eye:
At least 40 U.S. veterans died waiting for appointments at the Phoenix Veterans Affairs Health Care system, many of whom were placed on a secret waiting list.  The secret list was part of an elaborate scheme designed by Veterans Affairs managers in Phoenix who were trying to hide that 1,400 to 1,600 sick veterans were forced to wait months to see a doctor, according to a recently retired top VA doctor and several high-level sources. For six months, CNN has been reporting on extended delays in health care appointments suffered by veterans across the country and who died while waiting for appointments and care.
Maybe privatization would solve the problem.  If veterans had vouchers that they could take to competing healthcare providers, they would likely not have had to wait as long.

by Greg Mankiw (noreply@blogger.com) at May 03, 2014 07:21 AM

May 01, 2014

Matt Welsh

The Google career path, part 1: Getting started

Apart from how to get a job at Google (which I have previously blogged about), the most common question I get from people considering taking a job here is what the career path is like -- that is, how you get started, how you grow your career, how promotions work, and so forth. I thought I'd try to capture some of my perspective in a series of blog posts on the topic.

(But first, the obligatory disclaimer: This is my personal blog. Google doesn't condone or support anything I'm saying here. Heck, it's probably all wrong anyway. Take it with a grain of salt.)

This stuff is mostly targeted at new grad hires (at any level -- Bachelors, Masters, or PhD) for software engineering positions. (I don't know how things work in other parts of the company, like sales.) This may apply to a lesser extent to more senior engineers or researchers as well.

Before you join: The team match

Before your start date, you will be assigned to one of the many hundreds of teams at Google. While there are exceptions, teams typically consist of O(10) people who all report to the same manager and have a common project focus. Examples might include the Android Hangouts app, feeding real-time data such as sports scores into Search, or (my team) making mobile Web browsing faster and more efficient.

A lot of people want to work on teams doing things they have already heard of -- such as Search, Chrome, or Android. But keep in mind that the vast majority of teams at Google work on things that are (a) not user-facing and therefore (b) not something you would necessarily know anything about before coming here. My first team at Google focused our content delivery network for YouTube, which I never even knew existed until I started the job. Many project teams are building internal infrastructure and tools, and often the work they do is highly confidential, so we can't (unfortunately) always tell new hires very much about the details of what the team works on until they join.

Google tries to assign you to a team that matches your interests. If you are a Bachelors or Masters new grad hire, the team match is typically done in a "late binding" fashion, a few weeks before the start date (so, after you have accepted the job offer). Given how rapidly projects and hiring priorities shift among teams, it makes sense to do the binding as late as possible. For PhD and more senior candidates, because your skills are more specialized, the recruiters try to make sure that the candidate has a team interested in hiring you even before bringing you in for an interview. As a result, you essentially have a spot "reserved" on that team well before you would begin the job. In those cases you might be able to learn a bit more about what your target team is working on during the process of interviewing and negotiating the offer.

The thing I always emphasize is that when you are hired by Google, you are getting a job at Google, not a specific team at Google. In other words, the initial team match is by no means final, and nor is it locking you down. Engineers move between teams all the time -- it is not uncommon for people to look for a new team every couple of years. Some people prefer the stability of staying in the same area year after year, while others prefer to explore different parts of the company. New projects and teams are always spinning up, and (indeed) teams often reorganize or disband. So there is a fair bit of churn, and I would not stress the initial team assignment much -- it's a starting point.

The starter project

My advice to people starting at Google is to roll up your sleeves, dive in, and start contributing however you can. It's a super steep learning curve, and for the first month or two you won't have the foggiest idea what anybody is talking about, but the more you get involved the faster you'll come up to speed.

The first week on the job is typically spent in orientation, which is usually done at the headquarters in Mountain View. I blogged about my first week at Google a while back -- it is pretty intense, and there is a huge amount to learn. I found it to be super fun (though exhausting) and have great memories of that week. You get your badge, your laptop, your first five or six items of Google schwag, try to figure out where to get lunch, how the videoconference system works, and how to get started on programming in our insanely complex environment. There are a bunch of hour-long courses on topics ranging from how Google Search works to how to use our source code control system.

After the first week you'll start working with your new team. Your starter project is intended to show you the ropes and get you up to speed on our coding environment, build tools, code review process, and so forth, so you can start to be a fully productive member of the team. Starter projects might be something like adding a small feature to your team's code or fixing a straightforward bug. A starter project might take anywhere from a week to a month.

Taking ownership

As you come up to speed, you'll proceed to taking on projects with larger complexity and scope, as you become more familiar with the codebase and conversant in the problems that are being worked on by your team. It's really up to you to drive this process and own your work.

To give a concrete example, one of the (relatively) recent PhD hires on my team, Michael Buettner, started out by investigating the size and quality tradeoff for the image transcoding parameters we were using in the Chrome Mobile data compression proxy. Over time he expanded his expertise of our software and started taking on harder, bigger problems -- including sophisticated optimizations to the proxy's HTTP fetching backend. He is now our team's "latency expert" and has devoted a great deal of his time to making the whole system faster. Since he knows so much of our codebase, he advises on a broad range of new features and bugfixes, and works with other teams to implement functionality to streamline our system's performance.

I want to emphasize that this is not something Michael was specifically tasked with doing. Like most teams, ours has way more problems than people, so engineers tend to gravitate towards the problems that match their interests. My job as the team lead is to coordinate and prioritize our team's work, and fortunately we rarely have cases where we have something really important to do that's not up someone's alley.

In the next couple of blog posts I'll talk about the evaluation and promotion process at Google, as well as how new projects are started.

by Matt Welsh (noreply@blogger.com) at May 01, 2014 09:38 PM

Greg Mankiw

More Competition

Steve Cecchetti and Kim Schoenholtz are blogging, mainly on issues related to money and banking. 

The blog seems meant to complement and promote their textbook.  Who would ever think to use a blog for such a purpose?

by Greg Mankiw (noreply@blogger.com) at May 01, 2014 05:44 PM

British Healthcare Fact of the Day

"In Britain, even though they're already paying for the National Health Service, six million Brits—two-thirds of citizens earning more than $78,700—now buy private health insurance. Meanwhile, more than 50,000 travel out of the U.K. annually, spending more than $250 million, to receive treatment more readily than they can at home."

Source.

by Greg Mankiw (noreply@blogger.com) at May 01, 2014 10:15 AM

April 29, 2014

Greg Mankiw

Do more lectures improve student performance?

Yes, finds a new experimental study, but the authors interpret the effects as modest in size.  One group of students in introductory microeconomics got a lecture twice a week (what the authors call the "traditional" format), and the other group of students got a lecture only once a week.  All the students had the same access to online resources and the same wonderful textbook. (You can guess which one.)  The results:
We find that students in the traditional format scored 2.3 percentage points more on a 100-point scale on the combined midterm and final. There were no differences between formats in non-cognitive effort (attendance, time spent with online materials) nor in withdrawal from the class.

by Greg Mankiw (noreply@blogger.com) at April 29, 2014 03:19 PM

April 28, 2014

Greg Mankiw

First Thoughts on Piketty

I have been reading Thomas Piketty's "Capital in the 21st Century." It is truly an impressive work, and I am much enjoying it. I have recently organized a session at the upcoming AEA meeting (January in Boston), where David Weil, Alan Auerbach, and I will be discussing the book, followed by a response from Professor Piketty.

Let me offer a few immediate reactions.

The book has three main elements:
  1. A history of inequality and wealth.
  2. A forecast of how things will evolve over the next century
  3. Policy recommendations, such as a global tax on wealth.
Point 1 is a significant contribution. I like this part of the book a lot.

Point 2 is highly conjectural. Economists are really bad at such things. In particular, the leap from r>g to the conclusion of a growing role of inheritance in society seems too large to me. Many capital owners consume much of the return on their capital, so wealth does not grow at rate r. This consumption ranges from fancy cars and luxurious vacations to generous charitable giving. In addition, unless mating is perfectly assortative, or we return to an era of primogeniture, wealth per family shrinks as it is split among children.  So, from my perspective, Piketty tries to draw way too much from r>g. (Quick Quiz for econonerds: (a) What does r>g tell you in a standard overlapping generations model?  (b) And what is the magnitude of bequests in that model?  Answers below.*)

Point 3 is as much about Piketty’s personal political philosophy as it is about his economics. As we all know, you can’t get “ought” from “is.” Like President Obama and others on the left, Piketty wants to spread the wealth around. Another philosophical viewpoint is that it is the government’s job to enforce rules such as contracts and property rights and promote opportunity rather than to achieve a particular distribution of economic outcomes. No amount of economic history will tell you that John Rawls (and Thomas Piketty) offers a better political philosophy than Robert Nozick (and Milton Friedman).

The bottom line: You can appreciate his economic history without buying into his forecast.  And even if you are convinced by his forecast, you don't have to buy into his normative conclusions.
-------
* Answers to quiz: (a) That the economy is dynamically efficient (that is, it has not over-accumulated capital).  (b) Zero.

by Greg Mankiw (noreply@blogger.com) at April 28, 2014 09:58 AM

April 25, 2014

Greg Mankiw

Report from the Chair

Readers of this blog may have noticed that I have not been as active here over the past two years as I was previously. One of the reasons is that, about two years ago, I was appointed chairman of the Harvard economics department. That has been keeping me busy. But I am happy to report that the job is going well. One of the responsibilities of the chair is to oversee faculty hiring, and we have had some great results. Our new faculty hires include the following (in alphabetical order):
  1. Gabriel Chodorow-Reich
  2. Ben Golub
  3. Robin Lee
  4. Matteo Maggiori
  5. Matthew Rabin
  6. Gautam Rao
  7. Neil Shephard
  8. Stefanie Stantcheva
  9. Elie Tamer
A pretty good list, if I say so myself!

by Greg Mankiw (noreply@blogger.com) at April 25, 2014 11:31 AM

April 23, 2014

Harvard College Democrats

Enter the Lottery for the Dems’ Event with Governor Deval Patrick ’78!

Please enter the lottery to join us for an event featuring Governor Deval Patrick. The governor will speak on the importance of public service and community engagement, and we will be presenting our annual Community Engagement Award for Young Leaders to a local Boston high school student. A question and answer session with the governor […]

by Jacob Carrel at April 23, 2014 05:25 PM

Subscriptions

Subscribe

Want your blog listed?

Last updated:
May 31, 2014 01:16 PM
All times are UTC.

Powered by:
Planet