Your aunt's uncle is your great-uncle. It's more correct than your intuition.

Cool to see this on HN - this is a product from the World Resources Institute[0] (my employer). I can potentially relay some knowledge from that team or try to direct someone here for questions and comments. The important thing to know for these maps is that Tree Cover Loss is not directly "deforestation". On a pixel by pixel basis (each covering ~30m x 30m) tree loss can occur without the major ecosystem destruction of deforestation. This is still measureable. That is why the visualization of tree cover loss is parameterized by percentage for greater inspection and nuance.

I will take this opportunity to point out the joy and satisfaction that comes along with making these kind of data for impact products. We get to work on globally critical problems, making real measured impact, solving interesting technical problems, and developing features and tools for real and appreciative users across the world. We have dedicated and talented staff (product and engineering teams, in addition to tons of researchers and engagement staff) who are passionate about their work and our collective mission. It's a great environment to work in each and every day. There are always challenges - project/institutional revenue is driven mainly by grants, our salary can not compete with the cash+equity offers of big SV tech companies and VC backed startups. But when I wake up in the morning and come to work (we are a very distributed/remote organization) I know that the time and effort I spend is directed towards a global good and I can easily say the same for almost all of my colleagues. That is invaluable.

If this kind of work interests you feel free to reach out to me (email in profile). We frequently have job openings[1] for PMs, SWEs, and many technical roles.

Edit: Senior Software Engineer position currently open (and would be working on Global Forest Watch) [2].

[0] https://wri.org

[1] https://jobs.jobvite.com/wri

[2] https://jobs.jobvite.com/wri/job/oeglifwR

I disagree on not building your own blog engine as a general rule: Building a blog engine can be as simple as using a markdown-to-HTML converter library on your server, and using your backend's admin interface. Or a simple HTML page with a big text box and submit button. Depending on use case, this can be fine. The cognitive complexity of integrating with a 3rd-party engine can be more complicated than writing a simple one.

Which brings me to a big point the article missed: Page loading speed is important for search ranking. I have a blog I add to once every other month. It uses HTML and CSS, and I write it in Django admin using markdown. Lots of room for improvement UI-wise, for both reader experience and writing interface. Yet, it's a low-traffic site, and most of the blog entries show up on the first page of Google for relevant keywords. Relevant: It gets a perfect Google Page Speed Insights score, by virtue of being an HTML/CSS page.

I bring this up for 2 reasons: Using a blog engine will probably make it tougher to get fast load times. You can rank high on Google just by having good content and fast load times.