In response to a r/advancedentrepreneur thread, I wrote up some reflections on Brompt in response to “How well did this project do?”:

Not well. I dunno how much help this is, but my thoughts about the experience are:

People who are already inconsistently posting likely aren’t searching for a solution. It would be better to target overachievers who want to get to the next level, than lift up underachievers to just ok. Nagging people doesn’t work on it’s own.

I think “post daily/regularly” isn’t much of a goal. I think it would be better to tap into the actual outcome they want (“top influencer”, “alternative income stream”) and then help pave that path within your service, of which regularly posting is just one “goal” or step on the staircase.

I originally built Brompt back in the mid 2000s when it was a lot easier to attract early adopters. I never monetized it (it was a hobby project that I used in my portfolio to further my regular career). If I was doing it over again, I’d have never built it and probably would have focused on figuring out acquisition (e.g. spend a couple hundred bucks on Facebook ads; focus on a hands-on concierge service, figure out what it is at the intersection of what people are searching to do and are willing to pay for).

Also, the space is incredibly saturated and it’s tough to get visibility. I’ve used Crowdfire before (i found it extremely difficult to use). Also done a lot with Priceonomics model. And there are some other Twitter tools that I wanted to highlight for you… but I literally can’t remember their name and have spent a good 30 minutes trying to Google and can’t find them. So like, that’s not a good environment to build in.

Edit: it was https://ilo.so/

I’m looking for a book that helps align the practice of software development with the rest of my life, In the sense of a humanistic neural plasticity, an approach that harmonizes rather than hegemonizes (or ignores) the rest of my life.

This book is based on the following beliefs:

• Agility, especially in the form of extreme programming, is essential if the software development profession, and industry, are to improve themselves.
• XP offers a way to create “better developers” to improve the intrinsic abilities of human beings to develop software for use by other human beings—a way to produce “master” developers.
• XP cannot be understood, and those practicing XP will not realize the full potential of the approach, until they understand object thinking and the shared historical and philosophical roots of both object thinking and XP core values and practices.
• In particular, programmers and technical developers will fail to realize the full potential of XP-based development without a thorough understanding of object orientation—the “object thinking” promised by the title of this book.

I initially found this book searching for “Sapir-Whorf” on the O’Reilly Bookshelf. To the extent that it approaches things humanistically, this is it:

Inheritance: Humans naturally aggregate similar things into sets (or classes). Another “natural” kind of thinking is to create taxonomies—hierarchical relationships among the sets.

Responsibility: If an object states that it is capable of providing a given service, it should perform that service in all circumstances, and the results should be consistent… Responsibility implies that an object must assume control of itself.

This wasn’t quite the book I wanted, though I enjoyed the introduction and the conclusion. The middle was a bunch of methodology that, well, was fine, but I probably won’t think about again; the conclusion does admit that the methodology and modeling section is written primarily as legitimating material for academic formalists and can be transcended and discarded. So that’s cool (but I would have appreciated that being said upfront than afterwards).

• All methods are someone else’s idea about what you should do when you develop software. It may be useful, from time to time, to borrow from those ideas and integrate them into your own style. It is essential, however, to transcend any method, even your own idiosyncratic method, and “just do it.”
• Software development is like riding a surfboard—there is no process that will assure a successful ride, nor is there any process that will assure that you will interact propitiously with the other surfers sharing the same wave. Published processes, like published methods, provide observational data from which you can learn and thereby improve your innate abilities—just as observation of master surfers enables you to improve yourself.
• No model has any value other than to assist in object thinking and to provide a means for interpersonal communication. If you can model your objects and your scenarios in your head while engaged in writing code, and if those mental models are consistent with object thinking, great! No need to write them down. If you and your colleagues use a visual model on a whiteboard as an aid in talking about scenarios and in clarifying your collective thinking about those scenarios, and you erase the board when you’re done meeting, also great! If your models are crudely drawn and use only a subset of the syntax defined here (or a completely different syntax that you and your colleagues collectively agree upon), still great! Model when you must, what you must, and only what you must.

Here’s the good stuff, though it doesn’t have much of a developmental model:

• Decompose the problem space into behavioral objects, and make sure the behaviors assigned to those objects are consistent with user expectations. This requires understanding why users make distinctions among objects and the illusions they project on those objects. User illusions (following Alan Kay) consist of how people recognize different objects in their world and, having recognized an object, what assumptions are made about how to interact with that object and what its responses will be.
• User illusions should be maintained; your software objects should not violate them unless you can construct a plausible alternative story that shows a different set of domain entities interacting in different ways or having different capabilities. Business reengineering involves exactly this kind of activity—using domain language and user illusions creatively to craft new stories, some of which might lead to new software.
• Decompose your problems (applications) in terms of conversations among groups of objects. Everything of interest in the domain is currently accomplished by groups of objects (people and things). Any artifact you construct must participate in a natural way in these same groups. Perhaps your artifact is simply replacing an existing object in the domain with a computer-based simulacrum, in which case it must know how to respond to and supply some relevant subset of recognizable and intuitive interaction cues. Perhaps it is an entirely new object, in which case it will need to be “socialized” to conform to the existing community.

• My mom entered hospice this past weekend. Medicare’s hospice benefits are pretty great, given the circumstances; American healthcare gets progressively better til you die. My mom has a story of her mom, in the 1990s, unsuccesfully convincing my mom of the benefits of single-payer healthcare. My mom says it took until herself going on Medicare to understand. With hospice, you call your caseworker and say “Can the nurse please bring over some blue chux next time?” and that’s all.
• Angelina and I had originally planned to attend a big family trip to Germany and Amsterdam; we are in Santa Barbara, the American Riveria, instead. YMCA membership portability is the best.
• I think many shared human experiences are of long boredom punctuated by short excitement or terror. Per the former, I finally added on-site search with lunr.js to this blog; no more Google.
• I’m currently reading Moral Mazes. From my personal experience reading Bad Blood and Super Pumped, and starting yet not finishing a whole bunch of other non-fiction: I can only handle terrible business books that have no thesis or advice other than gratitude for not being there. I have a bunch of other book reviews to catch up on.

Two quotes about the experience of life. The first from NYT’s Magazine “I’ve Always Struggled With My Weight. Losing It Didn’t Mean Winning. “

Suddenly, I was slim. It was, by any measure, an incredible weight-loss success story. Even my great friend Alan texted about how good I looked. (“Did I say that?” he wrote, with a facepalm emoji, when I reminded him of the time he squeezed my love handles. “Sam, I was very inappropriate. But I still think it’s funny.”) I had achieved the great transformation — I had turned myself into the “AFTER” photo.

And now that we have that out of the way, I can tell you what I consider the most interesting thing about my weight-loss journey, a secret that you will never see in any banner ad. As the months passed, as I stuck with my healthful habits and got used to my new trim body, as the line on my Noom weight graph stayed low, I felt something amazing: I felt pretty much exactly as I had always felt my whole entire life. I was, after all that change, still only myself. My big epiphany, if I could put it into words, would be something like: “So what?”

And the second from Gawker’s ‘Failure to cope “Under capitalism”’ (newlines added by me for emphasis):

[Anne Helen] Petersen’s most acute insight is perhaps in identifying a link between relentlessly optimized childhoods designed to prevent downward mobility, and the professionally competent but profoundly enervated millennials overwhelmed by the prospect of canceling plans, of keeping plans, of cooking food, of texting their mothers. I think she is correct.

I think it’s possible that for many, considering the shape of your life and then living it with vigor is so difficult because it cannot be externally validated. Unlike education and work, it offers no socially obvious meritocratic path. The moments where, like sourdough, it proves, are largely invisible — in cooking, in walking, corresponding with a friend, in chatting with a neighbor or registering to give blood. They cannot be tallied up and put on a resume. They are never “finished.” The progress you make is spiraling rather than linear; circling steadily, slowly, around your weak points, taking two steps forward and one step back, building habits so slowly that only in retrospect can you see your life become different than it was. And there is no one who can tell you that you did it right.

But this is not the condition of life under capitalism, this is life itself. And it is a sad irony that though the fear of life may be produced by class imperatives within capitalism, the impulse to restrict it to a problem of capitalism is itself part of the same fearful rejection of the task of living.

Which also reminds me of an aside from a Bruno book, whose authorship is an American author writing about contemporary Southern France, that the French are tryhards even when contributing to a weekly dinner at home with their friends.

Two things I read recently were commentary on forcefully-weak communications.

The first, from a r/rails thread in which the poster wrote “I hate React as it’s not using MVC pattern and It’s not organised + I hate JS.” A response:

You mentioned that you’re looking for junior positions which implies that you’re relatively new to the industry and have limited programming experience. Despite this, it seems that you’ve developed a lot of strong opinions.

There’s nothing wrong with having strong opinions and some of the best engineers are very opinionated. However, one of the biggest things you learn as you gain more experience is that you don’t know what you don’t know and that while forming opinions is important, one should understand why we may form certain opinions and whether those reasons are actually valid enough to hold those opinions strongly enough.

For example, you say that you hate JS. Hate is a very strong word for junior developers. Why do you hate JS? Is the hate that you have for the language actually for the language itself or rather code that you’ve written in it? If you’ve been forced to work on an awful codebase, then the language itself isn’t to blame.

You mentioned that you hate React as it’s not using MVC pattern. What is it about the MVC pattern that you like? There’s a lot of advantages with the MVC approach, but other approaches also have merit. As you gain more real-world experience, you’ll realize that there are many ways to do things and each approach has its own merits/disadvantages. You mentioned that React is not organized, but React is not a framework - it’s a library. You can organize it however you want which can be a double-edge sword if you’re inexperienced. Any disorganized React project is not React’s fault nor is it a fault of JS.

Unlike React, Rails is a framework and a very opinionated one. It can be beginner friendly as things will just work out of the box as a lot of decisions have already been made for you. However, it can also be difficult for beginners to level up as Ruby is a lot less explicit and a lot of the behind the scenes magic can be very confusing to figure out why things work the way they do. There is also a lot more ways to write your code in Ruby which means there’s a lot more syntaxes and patterns you may need to be aware of to be competent. (e.g., there’s only a certain number of ways to write a loop in Python but a multitudes of ways in Ruby). This flexibility may seem like a blessing to be able to write expressive and elegant code, but for beginners, it can make the process of leveling up a lot more work.

You should be open to the possibility that you may also not end up loving Ruby when it actually comes to working on production code. Many of us here love Ruby, but it should be stated that there’s a difference between tinkering and using Ruby for toy-projects and maintaining a Rails app. Also, Rails does not make JS go away. You may find yourself writing plenty of JS in Rails to get the desired UX on the frontend.

At the end of the day, I do love Ruby and there are plenty of Rails opportunities in the market so I do think it’s worth learning. But if you want to pursue Rails, you should jump in with both eyes open. You may find that your criticisms of JS & React may not actually be as valid and be specific to the projects that you worked on. If there are a lot more opportunities for you in JS/React than Ruby/Rails, it may be worth continuing down that former path.

And Andrew Bosworth “On Sarcasm”:

At first being sarcastic was incredibly satisfying. Whereas previously I might have made an earnest argument or asked a question, I now seemed to be able to jump right to the part where the group appreciated me and my contribution. What is even more impressive is it required very little thought to execute. I could often get a positive reaction even on topics I knew almost nothing about.

It was when I noticed this last point that I decided that sarcasm was not for me.

Sarcasm “works” because it alludes to a critique without ever actually making it. It shifts the burden of substantiating the criticism as an exercise for the audience and further suggests that if they don’t already understand it then they are deficient. Making a critique implicit is an unassailable rhetorical position. The most socially acceptable response for the group is to go along with it, as you have given them nothing specific to challenge. And if someone does challenge it you can simply demur and say it was “just a joke.”

Sarcasm does nothing to advance our understanding of the world around us or help us improve it.

In my previous write-up about NodeTiles, I said that I had dumb interview stories to share. They are also cringe. Here they are.

“Oh yeah, me too.”

I failed my very first professional job interview.

I was 21 and it was 2004. It was my last year at the University of California, Santa Barbara. I was graduating early, in three years, with a BS in Math Sciences, with Honors, and I was looking at Summer internships as something to do because the last credit course I needed was only offered at the tail-end of Summer quarter, right before my AmeriCorps*VISTA service began in Boston. I had never done a college internship before, mainly out of ignorance of their importance; this would be my first (and only) attempt at landing one.

UCSB is gorgeous, it’s on the beach; it is a bare-shouldered, sunny, surfy beach town. I was boring. Yes, I surfed and swam and sailed and hiked and ballroom danced and tended a community garden and worked on my 1973 Porsche 914 through Santa Barbara High School’s vocational auto-shop. But I wore a lot of cargo shorts, I didn’t drink or party, and I mainly loaded up on math and writing courses and worked in the campus library’s Map and Imagery Lab pulling and shelving topos and ortho photos. Santa Barbara!

My internship interview was with a local military contractor that was creating sensor fusion software. I thought it was pretty cool because it was maps and spatial and lined up with my honors research project, using statistical sensing methods to probe physical topologies, albeit of knotted proteins, not the Middle East. Also, I had not yet untangled for myself the distinctions between patriotic service and imperial militarism. I was 21 and it was 2004.

I don’t remember a lot of the details of the interview. There was a primary interviewer who was maybe a year or two graduated from UCSB himself. He walked me around between cubicles I was given the chance to briefly chat with various people, including the CEO. At the end, we sat down for more formal chatting, and he said something like:

“You know, we don’t like to work very hard around here. Do you?”

And me, just trying to fit in, was like “Oh yeah, me too. I try to take it easy.”

Ded. I was declined. I’ll never know if that was a trick question, or like they knew I was not actually a good fit. But it was fine. I took another writing class.

“Code is our craft”

It was 2012, and my Code for America Fellowship was coming to an end. Having moved the previous year from Boston to the Bay Area for the fellowship, I now retooled my resume to downplay my decade-ish career of “community media and technology leadership” and instead highlight my “web applications and freelance software development” experience. I was trying to land my first official Software Engineering job.

There were a number of companies in Code for America’s orbit, so multiple fellows were interviewing at the same place. Us fellows were more collegial than competitive, so there was lots of helpful backchanneling and suggestions and level-setting that some of the jobs were faintly ridiculous, but sure, why not. It was the Bay Area in 2012.

I got a face-to-face interview with a company that I’ll vaguely describe as “a social network for baristas”. It was a Javascript company. There was a tech-screener project I apparently passed, so I came into the office. I can say this, with more hindsight and experience: there were some red flags.

• I was introduced to the lead engineer and we chatted for a minute. I asked them something like “How do you see the business growing? I mean, where do you think the value lies in the product?” This was the wrong question for them. The lead engineer explained that “Code is our craft” and that well, who knows what the future will bring, but they want people who really are interested in the software.
• One portion of the interview was reviewing my tech screener project. There was one part of the screener where I was unsure of the situationally best way to accomplish it, so I did the most direct unoptimized way and left some comments about different optimizations and their pros/cons. I was asked about why I hadn’t just picked one, and I explained that I wanted to treat this like real life and talk through it with a more experienced colleague who could represent the actual business needs and not prematurely optimize at the expense of readability and openness to change. That was the wrong answer for them. They explained that “Code is our craft” and they’d expect me to make the best call on my own.

I was declined. I want to admit that I did mostly fail a different part of the technical interview: it was a whiteboarding exercise along the lines of “solve this problem using only pipes”. I think everything may have been built with pipes, but it was Javascript in 2012, so I probably should have known how to do it to be qualified.

Sidenote: Huge props and respect that the company successfully socialized and operationalized a core company value. Even if I think it’s dumb.

“Focused on the code”

This was 2016, my professional circumstances were different, and I want to assert that I had become a real catch of an engineer. I was leading a fullstack web UI and CLI team at a B2B platform-infrastructure startup, and also moonlight solopreneuring a successful consumer web and cross-platform mobile native app too. Professionally, maybe, kind of, a big deal 💅

I was courted. I was reached out to over LinkedIn by someone I had only known of to that point. We got coffee and walked around San Francisco and they shared their vision. They invited me, and several other engineers, some of who I also knew of to a fancy private dinner. It was nice.

And there was a standard interview too. We talked about developing high-performant, early-adopter, power-user consumer interfaces, and our shared history and respect for Ruby and Rails and Javascript. We pair programmed on a problem, and I think I was nailing it.

And then there was a question, like “Ben, I know that you’ve been a manager in the past, and you’re currently leading a team. Is that something you really want to do in your next job?”

I replied saying something like “I’m happy being an IC. And I think a strength is my flexibility to help where it’s needed. If that’s what you and the business and the team eventually need, I’d feel confident and comfortable stepping into that role again.”

That was the wrong answer for them. I was declined. I received a reply later saying they wanted someone “focused on the code.” This is one time when I do wonder if I should have like, followed up and clarified my message, but interviewing is like bizarro-world dating so who knows.

Sidenote: If you’re reading this as flat advice, you should follow-up, because the worst that will happen is they’ll say “still a no”.

“Should we go back in there?”

In this story I was one of two technical interviewers, along with a hiring manager and the director of engineering.

We were debriefing after a week of interviewing candidates. There were two finalists. None of this may have actually mattered, or everything mattered, but I want to paint the picture. Both engineering candidates were women; we were all men along with the entire engineering team of 15 or so; not great!

• Candidate 1 was very outgoing, had a ton of analogous Bay Area tech experience, lots in common to talk about… and did not pass our technical interviews.
• Candidate 2 was a kinda awkward, their experience was weakly adjacent sorta kinda… and they totally aced the technical interviews, like finished in half the time then schooled us. Which made it even more awkward because we’re all awkward engineers truly and now we had like 30 minutes of dead time to fill trying to chitchat. I heard something similar happened in the manager interviews: the candidate answered too succinctly.

Ok, so the debrief. We went around the table, shared our experiences. And Management wanted to hire Candidate 1, the candidate that didn’t pass our technical interviews. For real! But this is business, and we have to be collegial, and they’re the managers, so my other engineering colleague and I disagreed and committed and rolled our eyes but left the meeting like yep, this is business, we’re all business here.

And we were walking down the hallway back to our desks and we both said to each other at the same time “What the fuck was that?”

“Should we go back in there?”

“That wasn’t right.”

So we kind of treaded water out in the hall for a minute, and worked up the courage to… gently go back and knock on the conference room door and politely ask if we could say one more thing.

“We should hire Candidate 2.” Seriously.

To management’s credit, they listened and I think correctly read that we were distressed and this wasn’t just our standard grumpy-engineer bikeshedding bit. Management agreed to make an offer to Candidate 2. Mission accomplished.

Ok, so I want to say there are two possible futures here:

1. We hire Candidate 2, and they are a solid if unremarkable engineer. They do good work, meet and occassionally exceed expectations, and are an incremental contributor like everyone else in pushing out our startup’s runway toward some brighter future and shared equity event.
2. We hire Candidate 2, and they are an absolute-based 100x engineer. They frankly save the company in my mind, bulldozing through any problem you throw their way with a nonchalant “alrighty then”. They exhaust the backlog leading them to entirely rewrite the product twice over better/faster/more-maintainably as a distraction while the backlog is rebuilt then they plow through it again.

It does not matter which future actually happened (though one of them definitely did!), because they were qualified, capable, and if we removed the fucking bias of our otherwise reasonably designed interview loop, the best candidate in our pool.

In the previous story when I played the role as befuddled candidate I was like “I dunno, bizarro dating”; but if you are ever in the position as an interviewer and there are some bogus soft-no’s or bogus soft-yes’s, speak the fuck up and use your power to the extent you safely can. Seriously, you can do this, even in business.

I recently lost access to my 10-year old Code for America email address when I changed jobs. I tried to preserve some of the good stuff and this is one story.

During my time as a Code for America Fellow in 2012, I created a Javascript-based slippy map tile renderer called NodeTiles (kinda sorta like Mapnik). Several colleagues helped vastly expand it, we presented at NACIS, and I know of at least one successful company that is still powered by forked version of it today.

Jessica

During our Fellowship, Jessica Lord gave a tech talk on building custom map tiles and first introduced me to TileMill. I couldn’t find a record in my email of when that happened, but know she planted this seed 🌱

Tom

On April 25, 2012, I sent this email to Tom Carden:

This week I came across a gist of yours and eventually made my way to nodemap while researching how to generate server-side map tiles. Thank you so much for putting those pieces together; they’re fantastic! I matched your code with node-canvas-heroku to get it running in the cloud and it’s pretty fantastic:

http://morning-spring-2292.herokuapp.com/

Anyways, just wanted to send you a big thanks for the code and inspiration. I’m working on building a node-based utfgrid renderer to bootstrap an entire wax interaction layer… all without Mapnik (though maybe I should just work on packaging that for Heroku).

Cheers, Ben

Tom gave some helpful advice and caveat emptor about JS performance and data caching. He continued to follow up with node-canvas and cairo suggestions for getting stuff running on Heroku. Tom ended up being a Code for America mentor for a different project and he was the source of us using the Toner map style in demos and also a nice leaflet clustering plugin.

Rob

Rob Brackett was the first person I explained what I was doing to create a tile render in Javascript. His reaction to my explanation was “What the fuck are you talking about?” Rob is one of my best friends, and I don’t remember how I explained what would become Nodeiles initially, but I’m sure it took 20 minutes and was a non-linear train of thought.

On May 2, 2012, I sent this email to “Fuzz”, Code for America’s random-nerdsnipe list:

Last week Rob and I built a heroku-compatible map-tile renderer (and UTFGrid generator) that can quickly (and with low bandwidth/client-processing) serve interactive maps and markers comprising tens of thousands of points and polygons—and unlike TileMill, the final map can be connected to a live database and updated on-the-fly. It’s kind’ve badass.

Here are 2 examples:

1. Static map of San Francisco streets and Parks:  http://morning-spring-2292.herokuapp.com/

2. Map of all ~1.5k Occupy sites worldwide (I did this in about 15min, so it’s a little clunky): http://occupy-map.herokuapp.com/

In terms of why it’s badass (from less to more geeky):

1. It’s fast. Nothing is rendered in the browser, instead all of the tiles are rendered and streamed to the browser as PNGs.
2. It’s small. No shapefiles are sent to the browser. Each Map (the entire initial pageload) is less than 500kb.
3. It can do dynamic data. TileMill makes beautiful maps, but once you export them to MapBox (or your own mbtile server), you can’t change them. This can be hooked up to a live database (right now it parses geojson).
4. It runs on Heroku. It uses node-canvas (not Mapnik) so it is fast, lightweight and has few dependencies.
5. It renders UTFGrids, which can provide mouse-hovers and other straightforward UI stuff that most maps don’t (way less clicky)
6. It’s not a tileserver, it’s a tile renderer. Seriously, all those maptiles are being generated on on-the-fly (we should probably cache them, but hey, this is bleeding edge)
7. It’s nodejs and all the code is on Github:  https://github.com/bensheldon/nodetiles  

I’m still working on it, so if you have a big dataset that you’ve had trouble mapping before, let me know since I’m looking for more/better use cases.

Prashant

Prashant Singh, another Code for America fellow, was excited about the project and gave me lots of feedback. Prashant was using my project to generate large static maps from the commandline, and he gave some feedback on his experience doing similar work with Mapnik. Prashant and two other Fellows, Alicia Rouault and Matt Hampel, would subsequently build a business on top of it.

On June 5, 2012 I sent this email to Eric Gundersen at Mapbox:

I haven’t done a big writeup yet. I’m hoping to submit to NACIS for their October conference, but I’m still trying to clean up the code, modularize it, and write tests and documentation.

General backstory: I had been playing around a lot with TileMill and Mapnik and trying to programmatically generate map tiles; at CfA we have a lot of big, dynamic data and I was trying to set up an automated tile renderer. Then I came across a Tom Carden project where he was use Node-Canvas to render tiles… and then I discovered a node-canvas module that would run on Heroku… and by that point I was in love with the idea of a low-dependency (compared to mapnik) on-the-fly tile rendering implementation.

From there, I wanted to see how close I could get to a full-blown TileJSON implementation. I had my coworker Rob Brackett write me a Javascript UTFGrid implementation and I hooked that up to the tile rasterizer. And bam. It’s clunky as hell, and sort’ve slow (it’s rendering an entire shapefile then cropping it down for every tile rather than spatially indexing the features), but I think it has potential. 

I think the next step (in addition to cleanup and documentation) is loading up some OSM metro data and actually seeing how the performance compares to Mapnik. Also, while I can’t foresee implementing something like Cascadenik, node-canvas gives you direct access to the graphics renderer and it might be useful for creating boutique maps with graphical flourishes that Mapnik hasn’t implemented… and of course for creating layers with dynamic data.

Let me know if you have any specific questions or ideas you’d like me to try to implement or use as demos. Thanks for the interest!

Alex

Alex Yule, another Code for America Fellow, and an actual experienced cartographer, was also interested. Alex would build a proper database adapter layer and the actual spatial indexing functionality that all of my previous emails yolo. Alex joined Rob and my presentation proposal at NACIS. This was our abstract:

NodeTiles: Joyful Map Tile Rendering with Node.js

Mapnik has become the de facto open-source standard for rendering map tiles. While Mapnik is extremely powerful, it can be difficult to set up and deploy. We present NodeTiles, a lightweight, JavaScript-based, open-source map tile renderer that is easy to deploy, use, and extend. Built to support applications with dynamic data, NodeTiles offers an accessible and cloud-friendly alternative to Mapnik. While still in early-stage development, features on the road-map include styling with the CSS-based Carto language for compatibility with MapBox TileMill, UTFGrid generation for client-side interactivity, and data adaptors for PostGIS and Shapefiles.

NACIS

The NACIS (North American Cartographic Information Society) conference was October 17-19, 2012 in Portland, Oregon. Alex and Rob and I had gotten an AirBnB and I mostly remember us doing a lot of last-minute implementing. Alex built a really nice Postgres Adapter plugin and Rob was reimplementing Cascadenik (“CSS for Maps”) somewhere between Javascript and Cairo; there was a deep-dive into blitting. We presented at a breakout called “Slippy Maps”.

Afterwards, I remember riding BART back from the airport when we arrived home in San Francisco. I was talking with a maybe-a-big-deal person from the map-tech community, and they asked me something pointed like “But how much did you really contribute to NodeTiles?” I said something like “It was a team effort” and then it got really quiet. In hindsight that was probably a job interview. And also fuck that, it was a team effort.

That’s it

During Fall of 2012 Code for America Fellowship was ending and interviewing as an inexperienced engineer is freaking hard (and also incredibly dumb, but those are different stories). So I mostly put down NodeTiles. And also:

• Going from something that’s a tech demo to something understandable (“What the fuck are you talking about”) and usable by outsiders is hard.
• The sheer difficulty of spatial work. That dumb NodeTiles logo took me hours just to get the tooling together to just like, draw straight lines on a globe to say “NODETILES”.
• Maps are a commodity, and also if you need to dynamically map a billion+ polyons (I’ve been informed that today there is Postgres MVT) and you need a pipeline for auth and anti-scrape and billing and raster and…. well, god bless you.
• I leaned into some questionable architectural decisions to make NodeTiles more Javascripty, splitting up the front and backends, and modularizing all the different pieces into their own packages. In hindsight that was a lot of valueless work that only introduced friction into building the tool and delivering the value. That’s on me; never forget.
• Given that this is an email-based retrospective, I will admit I found some emails from kinda big deals like Stamen that I didn’t respond to. I dunno why I didn’t respond; probably burnout. If that was you, it wasn’t personal, and I’m happy with the path I’ve taken, and I hope you are too 🤗

NodeTiles is still up on GitHub. If you can get node-canvas linking to cairo (memories of this seems like a fever dream), NodeTiles is really cool. Maybe you’ll do something neat with Nodetiles ❤️

In my presentation of how my small engineering team helped deliver food stamps to millions of Californians, I talked about a common pathology of engineers: a desire to build the equivalent of thousand-year clocks that will run self-contained without human intervention. You see it crop up in different forms, the good ways of “working yourself out of a job” and the bad ways of platinum plating and astronaut architects.

And I’ve become become aware of that pathology affecting how engineers perceive the labor of other people: they don’t, not the people part. And that’s bad.

To be fair, not seeing the people isn’t just an engineering pathology. We talk about products, and services, and value, and how capitalist corporations are simply slow AI. And I’ve been working with a leadership coach and spending a fair bit of time contemplating what it means to do something larger than myself but within the realm of human endeavour. So please go with me here.

Platforms. I’ve spent a lot of my career working on X-as-a-Platform. Which is the idea that it’s a good thing if the things in our lives become analogous to vending machines, or FedEx status pages: we press the button on the machine, and we get what we want, and if not now, then the machine will tell us exactly when.

But this idea of platforms, the machine, break down when the machine… breaks down, or just changes. When the good sandwich cookies are out, or they get replaced with the bad sandwich cookies, or when there are no sandwich cookies at all because it’s Tuesday morning and deliveries normally happen on Monday and Monday was a holiday. Then we’re confronted with a reality: you, and I, and the people who stock the machine, and build the machine, and the people who make the decisions about what to stock it with, or when, and how, and why….

We are all simply harried, overworked bags of dirty water that are winging it and doing our best balancing conflicting business needs, and complicated lives and health and families and concerns and motivations completely unrelated to the good sandwich cookies and your obtaining them. I’m sorry.

We can agree: it sure would be nice if the machine had the sandwich cookies you wanted.

Or not: my agreement could also be the pathology talking. The machine is not the human endeavor here… though my sympathy for your situation (and our shared pathology) could be.

This particular line of thought was triggered by reading this passage from James Bennet’s “Yes, I have opinions on your open source contributions” about some drama going on around the situation of the people who run the PyPI Python package repository wanting to add additional security requirements on the people who publish packages to said repository to protect the people who download packages from said repository and thus reduce support demand on said repository maintainers by preventing packages from being compromised (analogus some drama is playing out in my world of Ruby too):

If you believe nobody has the right to ”demand” an open-source maintainer do something or abide by some policy or restriction, then that ends the argument in more ways than people are appreciating. If you just want to say “nobody can demand I do this”, then OK, but you also can’t demand PyPI — which is an open-source project, too — do any particular thing or abide by any particular policy you’d like, which more or less removes any grounds you might have had to criticize their account security approach. They don’t owe you anything and don’t have to do what you want them to do, the end.

But a lot of people in comment threads are trying really hard to figure out a way to impose requirements and standards on PyPI’s maintainers but not on anyone else, which then contradicts the “it’s open-source, you can’t demand anyone do anything” basis of the whole argument. Somewhat amusing are people who try to argue that PyPI has a lot more power to affect people and so should be restricted more, which is an equally good argument for imposing on people who maintain major packages.

And there’s a lot more.

To follow my thread of before, there’s a lot of demanding going on that the people, who are inseparable from the package repository, be vending machines. And what, to me, sounds like a fair and reasonable counterpoint being that people are not vending machines. And we should go with that.

Two months! In my last update I wrote about an overwhelming sense of normalcy. That has continued, in a good way.

I am making good pace at completing my Engineering Manager bingo card. So far I have:

• Worked with team and directors to write out quarterly OKRs, and close out the previous quarters
• Gone through (well, shadowed) the half-yearly performance review process
• Worked with a report through their departure from the team
• Participated in the candidate interview loop, though not yet as a hiring manager

Something I’m inspired by

Writing OKRs with my team, boss, grandboss, and peer managers has been really, really, nice.

• My team has been open within the OKR writing process, and creative, and participatory. I fumbled a bit trying to design an async but consensus Enthusiasm/Complexity matrix, but it’s been a great resource for me to understand the backlog and the team’s interests.
• My boss and grandboss have been understated , but driving the importance of OKRs. I’ve particularly appreciate them say “Let’s get it right, but it’s also just a Google Doc and we can change it”
• My peer managers as bar raisers in the process. We write OKRs for the department within the same document and I’ve appreciated getting comments and questions about consistency and measurements and categorizations.

I think planning is a fun challenge, with the two things that I focus on being:

• Strategic Planning vs Operational Planning. In my sideline as a strategic planning consultant, separating out these threads is the work.
• Team participation. I wasn’t surprised that participatory OKR planning was a stretch. At my previous jobs it’s not uncommon to have coworkers go from griping about long participatory planning meetings, to then asking “I don’t understand how the team prioritizes work.” Sometimes that can mean “I don’t agree with what came out of planning” but it frequently can mean “I didn’t see that planning as the venue for what I want to advocate for.”

I’m still uncomfortable writing essays in Slack, but I did write this for the team:

OKR thoughts: It might be interesting to explain how I view the OKRs in case it changes your feedback about them.

I write OKRs is that they’re a summary of what the team wants to do, to be communicated upwards. And then we expect management/leadership to protect/fund those activities over the duration of the quarter.

So they’re things that we believe (hopefully, feedback wanted) :

• we’re enthusiastic about doing (most importantly)
• AND we think we can reasonably accomplish during the quarter (maybe with a bit of stretch, but that should come from us)

And then that gets sent upwards, and (usually, in my experience elsewhere) Leadership says “great! let us know how we can help.” And if there is feedback, it’s usually of the form of “do you think this falls more into X or Y bucket?” (because they have to write their OKRs) and then maybe it’s a conversation. I’ve seen Leadership start meddling when a team doesn’t put forward a confident set of objectives, not usually in opposition to them. They’re part of a team umbrella ☂️

I have never seen OKRs be inflicted on a team; if it feels that way, I think that sucks. Hence why I’m wanting to explain my perspective in case that’s new.

Bring thoughts to our Sync Meeting next Tuesday, or add them to the OKR chat above, or DM me.

Thank you for coming to my TED Talk 😃

Something I’m challenged by

One way you might design a performance review process is to combine:

• Evaluative feedback, simple quantitative metrics (does not meet, meets, exceeds) expectations, grounded against a career ladder or functional job description.
• Coaching and appreciation, qualitative narrative about past contributions and future opportunity and explains the gaps between the true work and the ideals of the career ladder.
• Unifying economic model for salary adjustments (and bonus, new to me) and promotions that answers what the company “recognizes” (“recognition” is how across my career I hear ICs talk about their perceived match between personal/team contributions and compensation/hierarchy)

The challenge of these systems (like my essay on OKRs above) is keeping them simple enough to be transparent, while recognizing that the map is neither the landscape, nor the expedition. I think there is room for improvement in all things, and I haven’t yet seen any of the worst pathologies of my past (like a long ago director who pushed back against a transparent career ladder because of their fear people would “game it”). I’m hoping I remember all this 6 months from now when it kicks off again.

What’s next

I get to see how the team executes on our OKRs and how our quarterly engineering rotation kicks off. I’m excited for both.

The experience of learning about systemic racism in the US is a constant derailing of “but we can’t know the actual intent”; systemic sexism on the otherhand is “oh, here are the receipts”. Which is not to discount the research and scholarship of author Mar Hicks, more just to say “wow, there it is”.

Programmed Inequality is focused on one particular aspect covered by the more surveyish Recoding Gender. To attempt to summarize a lot:

• Take a systemic inequality, like the Marriage Bar, which made it unlawful for women to keep their job once they became married.
• Then it’s reasonable to imagine that managers will invest less time in training and developing women in the workplace.
• Then it’s reasonable to imagine that women are less likely to be promoted into management and leadership.
• Then it’s reasonable to imagine that women will be tracked into roles and functions that do not offer training or management potential.
• Then it’s reasonable to imagine that roles and functions will be designed and shaped around these constraints and will develop bureacratic inertia.
• Then it’s reasonable to imagine that other roles and functions (who happen to be men, because of the previous reasonable assertions) will be bureacratically competing for power and resources and prestige with those feminized roles and functions (and the women who fill them). And it will be ugly.
• Then it’s reasonable to imagine that, people being people, on human timescales with human constraints, and talent being equally distributed even when opportunity is not, they’ll do their best to navigate and come to terms with it in different ways.

It’s a book about an 80 year trainwreck. It has some interesting details about deskilling, and also about femininization: how expertise is reframed as “temperment”.

Although government reports referred to the great mass of their women workers as doing the “ monotonous toutine work” that made up the broad base of the Civil Service “pyramid,” inquiries into the exact content and nature of machine operation commissioned by the Treasury itself repeatedly contradicted the characterizations of it as deskilled work.” These reports showed how machine workers needed many of the same skill sets as higher clerical workers and how machine operation jobs were best performed by higher-skill, more educated workers. Even machine workers at the lowest levels, who dealt with narrowly specialized calculations, possessed similar skills as clerical workers: “The lower grades of the technical part of the engineering field and the scientific Assistants are both fairly close to the Clerical Class in many respects,” admitted an internal Treasury memo. Despite this, most women workers were now partitioned off from the higher-status clerical class. Eventually, the machine operator class would have three levels: The entry-level rung was the position of machine assistant. The middle rung of machine operator, took on more complex work. Women would rise to machine operator in their midtwenties. The top grade was senior machine operator. These women would perform the most complicated work in the class, including programming and systems analysis. The expectation was for women to attain that rank in their later twenties or early thirties, because at that point promotion and pay increases ceased–much earlier than for workers in clerical jobs. The structure of the new class enforced a shortened, dead-end career, partly because of the idea that women should leave by this point to get married and take care of a family, but also as a reflection of the low worth accorded to this work. Many Civil Service leaders in this era could not conceive of technical or machine-aided office work as interesting, as complex, or as providing preparation for higher work. The fact that the association of women with machine work in offices had initially evolved from women’s association with typewriteers helped reinforce this attitude. Yet the machine class was not simply a reflection of the status quo. It was the Treasury’s attempt to deal with rising numbers of women employees by reorganizing the government’s postwar workforce.

And surfaces a lot of stuff that’s seemingly baked into computing and labor relations:

Even before White Heat raised the profile of computing, a 1962 overview of government computing policy reported that the government hoped to recruit most programmers from the ranks of the seventy thousand workers in the executive class–the management class of workers with A-level secondary school training, but without the university training of the higher administrative class or any particular skill set commonly associated with early programming expertise. Executive class officers dealt with long-term departmental goals and developed processes for greater efficiency. They were also overwhelmingly men. Paradoxically, these new recruits were thought to be more qualified for the technical aspects of computer jobs even though they lacked any machine experience. The tacit expectation was that higher-level civil servants would be more intelligent overall and therefore would have no trouble picking up supposedly lowly technical skills. A widespread belief persisted in government that work involving machines did not require much intellect. Yet the Treasury’s initial feelings that “the operation of computers was expected to be similar to that of punched card equipment and thus proper to SMOs [senior machine operators]” was giving way to the idea that computing jobs were actually too complex and required too much training to continue using feminized labor. “ Although a number of staff currently graded in the MO (Machine Operator) class are demonstrably suited to be computer operators,” opined one 1966 report, “it must not be assumed that all machine operators capable of traditional responsibilities for that class have in fact ‘operating’ ability.”

This shift in attitude reflected the rigidity of the class hierarchies of the Civil Service. Even though government workers were supposed to be able to rise through the ranks meritocratically, by means of examinations, those in the lower classes of the service were often seen as fundamentally inferior to those at higher levels. As a result, there was little focus on grooming workers already in computer posts for higher positions. Instead “better” workers would be brought in from the executive class and trained to do those jobs. Whether the nation was headed by Labor or the Conservatives, the highest administrators within the service remained relatively constant in their opinions about modernization within government. “It was early on decided that for most programming orderical operations one did not need graduates in mathematics or other Growledge of professional standard, but a reasonable level of intelligence and certain aptitudes,” explained an organization specialist in the Treasury who authored a 1962 report titled “Electronic Computers Oil the Wheels of Government,” Management potential and a broad understanding of the workings of government agencies were the key qualities the Treasury now sought in computer workers.