Subscribe: Laughing Meme
http://laughingmeme.org/feed
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
ago  back  book  code  culture  folks  make  software  technical  things  time  tools  work  write  years ago  years 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Laughing Meme

Laughing Meme



Just another WordPress weblog



Updated: 2016-07-15T01:51:19Z

 



Don’t pave the paths used by the unhappy cows

2016-07-15T01:51:19Z

Today I had the line “lets not solve cultural problems with technology” attributed to me. That sounds like something I might say. (or more likely I’d say something like, “wheee! let’s solve those cultural problems with technology” and everyone would assume I was being sarcastic, but to the same effect) The funny thing is interpreted […]

Today I had the line “lets not solve cultural problems with technology” attributed to me. That sounds like something I might say. (or more likely I’d say something like, “wheee! let’s solve those cultural problems with technology” and everyone would assume I was being sarcastic, but to the same effect)

The funny thing is interpreted in an unsubtle way this mantra runs exactly counter to one of my other philosophies of team, namely: Be a tool building culture.

I tried to tease out the nuance of these two ideas today, which is to say:

You can’t solve your cultural problems with technology, but you can support your culture with technology.

If your teams don’t respect each other and can’t communicate, a microservices architecture that decouples deploys isn’t going to solve your problem, it’s going to make it worse. Its going to entrench your dysfunction deep into your code where it is harder to fix.

On the flip side if you have a culture that already values transparency and inclusion, than building tools to make it easier for people with different styles, levels of seniority, and in different geographies to participate in conversations reifies that value. And given that culture isn’t a binary, making positive outcomes the easiest and default approach creates positive feedback loops.

Which was succinctly summarized by one of the people I was talking to as: “Pave the cowpaths, just don’t pave the paths used by the unhappy cows.”




I have some questions about mobile, geo, and platforms

2016-02-08T15:04:52Z

At some point blogs professionalized to the point where they became the province of answers rather than questions. This blog post isn’t an answer, it’s a question. At the first (and only?) O’Reilly P2P conference I remember seeing Ward Cunningham give a lightning talk on how to ask a question on a wiki (and by […]At some point blogs professionalized to the point where they became the province of answers rather than questions. This blog post isn’t an answer, it’s a question. At the first (and only?) O’Reilly P2P conference I remember seeing Ward Cunningham give a lightning talk on how to ask a question on a wiki (and by extension the Internet), “You write down everything you know, and the Internet will correct your mistakes.” I’ve heard many folks repeat this, cynically, but as I recall Cunningham’s telling it was joyful, what a generative and generous way to ask a question. I’m a product of the web. I started working professionally in software development the year the web was created, and I’ve been working on the web in one capacity or another for 20 years. It shapes my imagination. And one of the truths on the web is the switching cost is low. I don’t have to discover and download software, learn a new tool, navigate some gated garden of experiences. If I want to use an experience, or switch experiences it’s a simple click away in the universal client that has come installed on every computing device for most of the last two decades. This obviously doesn’t describe either desktop apps, or mobile apps. Swarm (and Dodgeball before it) briefly had a feature for messaging folks you know who are in your general geographic vicinity. It’s not a common behavior. Especially as we’ve aged. And it probably isn’t a feature that ever makes sense in areas less dense than a major city. And certainly not useful if you don’t know a large number of folks using Swarm. Any way, the feature was removed due to lack of usage. Which as a once-and-former CTO I understand, but as someone with the problem, “I have some rare and unexpected free time and I’d love to see someone who is also at loose ends”, I’m frustrated. In late high first bubble “portals” arose. Websites dedicated to being able to satisfy all of your needs: weather! sports scores! stock tips! tv schedules! horoscopes! email! what else is there to life! Even pre-Google that was a pretty dumb strategy. Even then switching costs on the Web were low and the portals were doomed. Now however there are a number of things about portals that feel like they’d make sense. If you’ve managed to get someone to download, install, configure and authorize your native app it feels like the natural pressure would be to accumulate more and more features, your crappy email/stock/horoscope features in the installed app vs a better version in an app you haven’t installed (and can’t discover due to the paucity of our current generation of app stores — definitely pre-Google there) Why haven’t we seen this? Why do we see something like the Facebook app demonstrate comparative discipline? Why doesn’t Google Maps offer to fulfill all my possible geo needs, the rare behaviors as well as the common ones? (the obvious answers around cost of development are irrelevant in this late-stage stacks era we find ourself in) Why hasn’t Twitter tried turning itself into a portal in its darker hours? I want the feature of being able to message nearby friends who are at loose ends for the once or so a month that I find myself inclined to use that feature, and the maybe 2-3 times a month I might be able to join someone else’s broadcast short notice plans. My first thought of course is, if it isn’t going to be part of Swarm someone should build just that app. And now we run into the challenge of high switching costs in native mobile. There is essentially no chance that anyone other than Foursquare will be as effective at getting my friends to use their purpose built app, especially for a use case which j[...]



When does conversational commerce make sense today?

2016-01-28T17:12:32Z

If you’re interested (even just professionally) in ecommerce, and you’ve been paying attention, than you’ve been thinking about chat based UIs and commerce for a while. For a quick refresher, you could read the blog post Chinese Mobile App UI Trends. It all got a little frothy this week (I don’t blame Chris, he’s part […] I’ve spent the last few years rather flippantly stating, “Technical debt doesn’t exist.” What I was trying to say was, “I’m deeply uncomfortable with how our industry talks about this thing, I think it’s probably harmful, but I don’t know quite how to express what I mean. Also, given that everyone seems to be really focused on this tech debt concept, I’m kind of worried that the problem is me, not the term or the industry”. When I first heard Peter Norvig say, “All code is liability”, that felt closer to right. The other week I was sitting in the car, waiting for the baby to wake up, and bantering on Slack on the topic of tech debt when my pocket computing device died, and I was forced to finish my thoughts on paper. These are those notes. Technical debt exists. But it’s relatively rare. When you start arguing with someone about technical debt, you’ll generally encounter a definition like: Technical debt is the choices we made in our code, intentionally, to speed up development today, knowing we’d have to change them later. Hard coding a variable because currently there is no plan to change it is a common example of technical debt. Similarly not modularizing a function. This is a fairly clear, succinct, and easy to reason about definition, that describes a phenomena that exists relatively rarely. Relatively rare compared to what? Compared to the amount of technical debt we ascribe to the codebases we work on. How then do we explain the overwhelming prevalence of technical debt we encounter when we talk to people about code? The term is being abused, or at least dangerously overloaded. “tech debt”: an overloaded term There are at least 5 distinct things we mean we say “technical debt”. Maintenance work Features of the codebase that resist change Operability choices that resist change Code choices that suck the will to live Dependencies that resist upgrading 1. Maintenance work As technologists we often intentionally or unintentionally use the term “technical debt” to describe to other teams (technical or otherwise) the necessary ongoing maintenance work a codebase needs. In this case the wide recognition and acceptance of the term is useful shorthand for buying breathing room. But it comes at a cost. We end up pathologizing something which is normal, often casting an earlier team as bumbling. A characterization that easily returns to haunt us. 2. Features of the codebase that resist change When we program we’re writing down a very explicit and exact description of a solution to our current best understanding of the problem we’re trying to solve. Over time both the problem we are trying to solve and our understanding of it will inevitably change, often dramatically. When that happens some percentage of our very explicit and exact description is now wrong, and a liability. Taken to the logical conclusion, given time, every line of code is wrong and a liability that will need to be dealt with. Therefore the second common meaning of “technical debt” is the features of the codebase we encounter in our work that make it resist change. Examples of features that can make a codebase resist change include: poor modularization, poor documentation or poor test coverage. Just as easily though an abundance of modularization (and complexity) or an abundance documentation, and tests encoding the now the incorrect old behavior can apply a strong downward pressure on change. A little discussed and poorly understood design goal for code is disposability. Given change, what design patterns can we follow that allow us to quickly expunge incorrect behavior from our codeb[...]



Optimizing for Learning

2015-11-08T22:18:50Z

I gave two similar keynotes back to back in San Francisco in September. One at Github Universe, and one at the Code for America Summit. I felt like I was bit rusty after taking over two years off to focus on the inward facing work at Etsy, but folks enjoyed them. This is the CfA […]

I gave two similar keynotes back to back in San Francisco in September. One at Github Universe, and one at the Code for America Summit. I felt like I was bit rusty after taking over two years off to focus on the inward facing work at Etsy, but folks enjoyed them.

This is the CfA version:

width="560" height="315" src="https://www.youtube.com/embed/a772VLZ4ot8" frameborder="0" allowfullscreen>

And some photos from the GHU one:

(image)

(image)




Five years, building a culture, and handing it off.

2015-09-01T21:56:28Z

After 5 years, the time has come. This is my last week as Etsy’s CTO. Five years ago I joined a tiny site, with a struggling software product. I wasn’t sure how long I’d stay. I was coming off 5 intense years helping scale Flickr. But I had some theories about engineering I wanted to […]After 5 years, the time has come. This is my last week as Etsy’s CTO. Five years ago I joined a tiny site, with a struggling software product. I wasn’t sure how long I’d stay. I was coming off 5 intense years helping scale Flickr. But I had some theories about engineering I wanted to test, and Etsy had a nascent team with some great folks who were up for the challenge, though a number of the odds were stacked against us. Theory 1: Nothing we “know” about software development should be assumed to be true. Most of our tools, our mental models, and our practices are remnants of an era (possibly fictional) where software was written by solo practitioners, but modern software is a team sport. Theory 2: Technology is the product of the culture that builds it. Great technology is the product of a great culture. Culture gives us the ability to act in a loosely coupled way; it allows us to pursue a diversity of tactics. Uncertainty is the mind-killer and culture creates certainty in the face of the yawning shapeless void of possible solutions that is software engineering. Culture is what you do, not what you say. It starts at the top. It affects everything. You have a choice about the culture you promote, not about the culture you have. Theory 3: Software development should be thought of as a cycle of continual learning and improvement rather a progression from start to finish, or a search for correctness. If you aren’t shipping, you aren’t learning. If it slows down shipping, it probably isn’t worth it. Maturity is knowing when to make the trade off and when not to. I had some experience with this at Flickr, and I wanted to see how far you could scale it. My private bet was that we’d make it to 50 engineers before things broke down. Theory 4: You build a culture of learning by optimizing globally not locally. Your improvement, over time, as a team, with shared tools, practices and beliefs is more important than individual pockets of brilliance. And more satisfying. Theory 5: If you want to build for the long term, the only guarantee is change. Invest in your people and your ability to ask questions, not your current answers. Your current answers are wrong, or they will be soon. Five years ago, continuous deployment was still a heretical idea. The idea you could do it with over 250 engineers was, to me at least, literally unimaginable. Five years ago, it was crazy to discuss that monitoring, testing, debugging, QA, staged releases, game days, user research, and prototypes are all tools with the same goal, improving confidence, rather than separate disciplines handled by distinct teams. Five years ago, focusing on detection and response vs prevention in order to achieve better, more reliable, more scalable, and more secure software was unprofessional. Five years ago, suggesting that better software is written by a diverse team of kind people who care about each other was antithetical to our self-image as an industry. Five years ago, trusting not only our designers and product managers to code and deploy to production, but trusting everyone in the company to deploy to production, trusting engineers to meet customers, and trusting teams on the edges to use data to make their own decisions went against everything we’d been taught about how we were supposed run a software development company. Five years ago, rooms of people excitedly talking about their own contribution to a serious outage would have been a prelude to mass firings, rather than a path to profound learning. And five years ago no one was experimenting in public about h[...]



More thoughts on the Keyboardio Model 01

2015-06-15T15:17:33Z

I’m super excited about the Keyboardio Model 01, and glad to see their Kickstarer is live (go back it now!), even if I squirm to see my bits in the video. Given that I recorded nearly an hour of video about my experience using the keyboard, I tend to think the best bits of the […] I’m super excited about the Keyboardio Model 01, and glad to see their Kickstarer is live (go back it now!), even if I squirm to see my bits in the video. Given that I recorded nearly an hour of video about my experience using the keyboard, I tend to think the best bits of the interview didn’t make it into the their final draft. Here are some more thoughts I met Jesse nearly 15 years ago at Diesel Cafe in Somerville, MA when I walked up and introduced myself and asked him about his crazy keyboard setup. I’ve always preferred working out of coffee shops to hermetically sealed fortress of solitude like setups and ergonomics is one of those things that gets compromised. Jesse was already bridging the gap, but 15 years ago the results weren’t pretty. (sort of Snow Crash gargoyle-ish) Most popular ergonomic keyboard designs are worse then useless, and the ones that aren’t seem to assume you’re very stationary spending 8-10 hours a day in your designated parking space (probably with a fancy chair, desk, dual monitor setup, etc) — they’re big, heavy, clunky things. And at the end of the day they’re still designed for typing prose. The Model 01 is different. It’s small enough that I can throw it in my low profile Osprey day pack which is my standard navigating the crowded streets of New York bag, along with a laptop, a book, and a notebook. And it’s lovely from the smooth milled maple, the custom keycaps, the rainbow backlit keys, and the solid metal backing. (that said it isn’t light with all that solid maple and metal) The Model 01 is a tool for a craft, the craft of programming. When I think about great craft people, I think about how their tools become extensions of their hands. You keep your tools sharp and well oiled, you invest the time into customizing your editor (except for the folks always flitting to the latest and greatest which feels like the opposite of craft), but a keyboard that is a sharp, well designed tools, that’s designed to be customized and repaired, and also takes into account how hands actually work is something new. I’m sure folks will get value from the Model 01 for tasks other programming. But it’s hard to overstate how poorly thought out the current offerings of keyboards are for programming, with our statistically unusual range of characters, forcing a ton of stretching and reaching, the activities that cause RSI. I’ve been using the keyboard for about 2 weeks. I’m definitely not entirely comfortable with it yet. For some reason my right hand slips left and I have a habit of hitting the Return key instead of H meaning my sentences look like t is wit weird spaces in t em. I do love the functions keys, the no reach navigation and bracket keys. The delete and space keys come very natural. Still getting used to reaching for the shift keys. Looking forward to having time to do immersion as I’m right now flipping back and forth between the Model 01 and my laptop keyboard. It’s been a while since I’ve learned a new layout, so many of the alternative layouts like Dvorak promise typing speed increases which is one interesting. I’m looking for typing sustainability not typing speed. And despite threatening to, I haven’t hooked the butterfly programmable button up to deploy … yet. [...]



“Engineering capacity for an economic revolution”

2015-04-20T00:15:55Z

“Engineering capacity for an economic revolution” That’s what my LinkedIn profile says I’m up to if you check it. That means a lot of things. One of the things it means is I believe that software is important, doing software well is important, and when we invest at getting good at human centric, thoughtful, sustainable […]

“Engineering capacity for an economic revolution”

That’s what my LinkedIn profile says I’m up to if you check it. That means a lot of things. One of the things it means is I believe that software is important, doing software well is important, and when we invest at getting good at human centric, thoughtful, sustainable software development we’re increasing capacity in the system, and we should share what we learn. Internally we call this a spirt of generosity.

I think at Etsy we’re currently doing the best work we’ve ever done in digging into the how and why of software development and leadership, and when I look across the team I see an amazing pool of folks who someday (hopefully far in the future) will flow out and change how this industry works.

But this week I’ve been feeling reflective, and it got me thinking about all the folks who are already out there on that journey.

A totally non-comprehensive list of companies where folks who used to work at Etsy are now either founders or senior engineering leaders (managerial or otherwise) includes:

  • Abacus
  • AltspaceVR
  • First Look
  • floship
  • Handy
  • Hinge
  • Julia Computing
  • Justworks
  • liwwa
  • Radico
  • Ringly
  • Signal Scienes
  • SoundCloud
  • Stripe
  • Tumblr

For a small company with a low turnover rate that feels like a high impact list, and I’m proud of the capacity we’ve added to the system.

If I missed some feel free to add them in the comments.




A little bit on the technical track

2015-01-12T02:05:55Z

I’ve got a post I want to write in response to Dan’s post on the technical track which I think does a decent job of laying out the issues, but doesn’t cover all the challenges and I think is poor on the solutions. Barring significantly more focus and free time dropping from the sky, this […]

I’ve got a post I want to write in response to Dan’s post on the technical track which I think does a decent job of laying out the issues, but doesn’t cover all the challenges and I think is poor on the solutions. Barring significantly more focus and free time dropping from the sky, this clip from a recent fireside chat I did has my recent, if somewhat opaque, thinking on the topic and is the closest I’m going to get to a blog post. 2 minutes and 25 seconds.

width="560" height="315" src="//www.youtube.com/embed/iY5AQTy5Wfk" frameborder="0" allowfullscreen>

(also this is about 90 minutes into the fireside chat sitting on really uncomfortable chairs, going to get those replaced before the next extended QA session we do)




2014 End of Year Booklist

2014-12-31T03:36:18Z

Read Rick’s, Rachel’s and Diana’s year end book list, and got inspired to write up my own. 2014 was a year of extenuating circumstances, the most obvious being the arrival of Anwen 9 hours before it began, but numerous others large and small abound. Reading this year was centered around escape, even oblivion, in short […]Read Rick’s, Rachel’s and Diana’s year end book list, and got inspired to write up my own. 2014 was a year of extenuating circumstances, the most obvious being the arrival of Anwen 9 hours before it began, but numerous others large and small abound. Reading this year was centered around escape, even oblivion, in short doses, and re-reading featured prominently. (also I finally forwent the urge to build a Kindle exporter as part of this process and just used clippings.io which did the job well, though seems to have hit a problem after downloading nearly 2400 highlights) Additionally I’ve probably missed a couple which I didn’t highlight anything in (or read exclusively in dead tree) The Old Ways: A Journey on Foot by Robert Macfarlane Pilgrim paths, green roads, drove roads, corpse roads, trods, leys, dykes, drongs, sarns, snickets – say the names of paths out loud and at speed and they become a poem or rite – holloways, bostles, shutes, driftways, lichways, ridings, halterpaths, cartways, carneys, causeways, herepaths. In Ireland there are hundreds of miles of famine roads, built by the starving during the 1840s to connect nothing with nothing in return for little, unregistered on Ordnance Survey base maps. In the Netherlands there are doodwegen and spookwegen – death roads and ghost roads – which converge on medieval cemeteries. Spain has not only a vast and operational network of cañada, or drove roads, but also thousands of miles of the Camino de Santiago, the pilgrim routes that lead to the shrine of Santiago de Compostela. In Scotland there are clachan and rathad – cairned paths and shieling paths – and in Japan the slender farm tracks that the poet Bash? followed in 1689 when writing his Narrow Road to the Far North The Cuckoo’s Calling (Cormoran Strike Book 1), Robert Galbraith (aka JK Rowling) displayed a multitudinous mess of life’s unnecessities. The Silkworm (Cormoran Strike Book 2), Robert Galbraight (aka JK Rowling) Startide Rising (Uplift Trilogy Book 2), David Brin The Uplift War (Uplift Trilogy Book 3), David Brin Tamsin, Peter S. Beagle She’s got a daughter, too, my cousin Barbara, and we were always supposed to be lifelong buddies, but the first time we met, when we were maybe two years old, we tried to beat each other to death with our toy fire engines, and it’s been downhill from there. The Peripheral, William Gibson “Terrorism,” said the rental. “We prefer not to use that term,” said Lowbeer, studying her candle flame with something that looked to Netherton to be regret, “if only because terror should remain the sole prerogative of the state.” Ancillary Justice (Imperial Radch), Ann Leckie Ancillary Sword (Imperial Radch), Ann Leckie Country Driving: A Chinese Road Trip, Peter Hessler The Slow Regard of Silent Things (The Kingkiller Chronicle, Book 1), Patrick Rothfuss You might not want to buy this book. Memory (Vorkosigan Saga Book 10), Lois McMaster Bujold There’s no place like home. I didn’t say there was nothing better. I just said there was nothing like it. The Winter Long: October Daye #8, Seanan McGuire “The day I get a vacation is the day the world ends,” Chimes at Midnight: Book Seven of Toby Daye (October Daye), Seanan McGuire “A knight of the land Courts asking a Duchess of the Undersea to save a King of Cats,” Fool’s Assassin: Book One of the Fitz and the Fool Trilogy, Robin Hobb “I w[...]



Annoyed by “The Peripheral”

2014-11-11T16:51:41Z

I enjoyed reading William Gibson’s latest, as I’ve enjoyed reading nearly everything he’s written, and as I anticipate enjoying seeing him and James Gleick speak tomorrow night. However as I finished “The Peripheral” the overwhelming sensation I was left with was annoyed. Below are spoilers. There were a number of moments that bothered me, but […]

I enjoyed reading William Gibson’s latest, as I’ve enjoyed reading nearly everything he’s written, and as I anticipate enjoying seeing him and James Gleick speak tomorrow night.

However as I finished “The Peripheral” the overwhelming sensation I was left with was annoyed.

Below are spoilers.

There were a number of moments that bothered me, but in 3 quick bullets.

  1. The literature didn’t need another implacably evil bearded Arab villain. Even is he is half Swiss.

  2. The literature didn’t need another heroine whose happily-ever-after is signified by getting pregnant.

  3. It goes against everything I look for in a Gibson novel to basely indulge a maybe-the-future-will-take-pity-on-us-and-save-us fantasy. It left me with the sensation that the author is deeply scared, which while reasonable, isn’t what I expect from the typewriting steely eyed prophet of the future.

Lots of good moments, and interesting world building, again the near future work, especially the near future rural poverty in a cheap printing/fabbing future was interesting.




Pumpkin Pudding

2014-10-27T00:17:01Z

Back when my dad drove his big yellow truck, delivering food for the food bank, he sometimes dropped me off at the Live Oak Senior Center industrial kitchen. And every October I remember peering over the edge into the bowl of an industrial stand mixer taller then I was at a truly giant vat of […]

Back when my dad drove his big yellow truck, delivering food for the food bank, he sometimes dropped me off at the Live Oak Senior Center industrial kitchen.

And every October I remember peering over the edge into the bowl of an industrial stand mixer taller then I was at a truly giant vat of pumpkin pudding.

And while I’m telling myself this pumpkin flavored Chobani yogurt is kind of a pumpkin pudding, it really isn’t.




“Wolf” narrative considered harmful (also biologically unlikely)

2014-09-03T01:11:31Z

Rands’ “The Wolf” post floated across my Twitters this morning. My immediate reaction was that it was misguided to the point of being potentially harmful. That was 16 long hours ago, but I’m going to see if I can pull the strands of that thought back together. Michael mentions he’s had the fortune to work […]Rands’ “The Wolf” post floated across my Twitters this morning. My immediate reaction was that it was misguided to the point of being potentially harmful. That was 16 long hours ago, but I’m going to see if I can pull the strands of that thought back together. Michael mentions he’s had the fortune to work with several “wolves” in his career. I’ve worked with a bunch, including teams compromised of nothing but (I guess you’d call that a “pack”). The problem is the post plays into the fantastical narrative of the lone wolf. But here is the secret. No one is a lone wolf. Or at least not completely. “Wolf” is the story that many people want told about them, and that on good days they tell themselves, but in the dark of the soul, we all need help and have doubts. By celebrating the narrative construct rather then reality you perpetuate the dangerous tendency towards isolation that is inherent in this archetype. I’m playing the long game, and in my perspective sooner or later one of two things is going to happen to your isolated “wolf”: either they’re going to run into a hard enough problem that they’re going to need more help then they know how to ask for, or in their bid to maintain their Harvey Keitel-like facade they’ll eventually isolate themselves from new challenges and dead end their usefulness. So let’s pull back the curtain a bit and understand the archetype: they’re passionate about solving hard problems, and generally they have a few favorite problems they like to gnaw on. That deep personal investment in the solution is what pushed them to develop their skills past the point of their peers in the first place, and also where they find the personal clarity they need to opt out of the clarifying bureaucratic structure of the larger org. With that passion can come narrowness, often expressed as hyper rationality. Pro move: keep supplying hard problems off center of their primary focus. they’ve developed a toolkit. A preferred language, set of scripts, investigative processes, checklist, whatever. And they come back to it over and over again. That disproportionate impact they have, it isn’t magic, its craftsmanship. They’ve mastered their tools to the point where the tools are an extension of their hands. They might see everything as a problem to be solved in Lisp, or via experimentation or machine learning or wireshark. They might have written their own text editor that lacks features what you and I consider non-negotiable, but doesn’t seem to impair their progress. The best of these folks literally generate tools, turning their own idiosyncratic but highly effective approach into tools that the wider org can use. Pro move: create a space and a culture that celebrates investing in tools. Everyone should hone their craft, and a few great tool builders makes everyone if not a 10x programmer, maybe an 8.5x. they’re convinced they’re right. Or at least, they’re convinced often enough that they’re right that they appear convinced all the time. A banal outcome of this is hill climbing. The toxic outcome is stagnation with a hugely talented individual stuck because they don’t know how not to be right. You owe your high impact individuals to surround them with people who challenge them. If they’re really a “wolf” they’re likely to try to wriggle out of this. Pro move: they care about impact, so make the road t[...]



AWS Redshift: “Missing newline: Unexpected character 0x4f found at location 3”

2014-07-21T15:07:26Z

I was trying to bulk load some data into Redshift this weekend using the copy command and I got this error message that no amount of Googling turned up a hit for. It was particularly strange given the hex value specified was for that exotic character the capital-O (as is OMG). stl_load_errors listed the offending […]

I was trying to bulk load some data into Redshift this weekend using the copy command and I got this error message that no amount of Googling turned up a hit for. It was particularly strange given the hex value specified was for that exotic character the capital-O (as is OMG).

stl_load_errors listed the offending raw_line as being “.LZO”.

Anyway, this particular error message is documented here for the next person who forgets to toss lzop on to end of their copy command and tries to Google it

to be explicit you’ve got:

copy some_table from 's3://some_bucket/data.lzo' CREDENTIALS 'some_credentials' delimiter '\s' timeformat 'auto';

and you need

copy some_table from 's3://some_bucket/data.lzo' CREDENTIALS 'some_credentials' delimiter '\s' timeformat 'auto' lzop;




Communication Skills

2014-05-17T23:47:50Z

A great deal of negativity has been directed lately at the practice of hiring for culture fit. I find this troubling because its a central tenet of Etsy’s hiring. This pithy insight was shared with me yesterday by one of our senior most engineers, and I slept better last night. “As time passes, I focus […]

A great deal of negativity has been directed lately at the practice of hiring for culture fit. I find this troubling because its a central tenet of Etsy’s hiring. This pithy insight was shared with me yesterday by one of our senior most engineers, and I slept better last night.

“As time passes, I focus more and more on interviewing for communication skills over technical skills.

Even the most brilliant engineer can get off course. But a great communicator might move slower, but they will always be moving in the right direction.”

(actually I didn’t sleep better last night, but that was the baby’s fault, not anxiety about contributing to oppression.)




Shell trick for the perpetually distracted

2014-05-16T18:25:15Z

Manager time is the schedule that sub-divides your day into 15 minute blocks. It’s the internal clock in your head that knows when you’ve reached the end of a 30 minute meeting without checking the clock. It’s a trained form of ADHD, and it’s the opposite of maker time. One of the things I find […]

Manager time is the schedule that sub-divides your day into 15 minute blocks. It’s the internal clock in your head that knows when you’ve reached the end of a 30 minute meeting without checking the clock. It’s a trained form of ADHD, and it’s the opposite of maker time.

One of the things I find I need in manager time is a quick way to regain my context. I’m way behind on adopting a proper getting things done framework, but it wouldn’t help with this one thing I wanted to post about today anyway.

I keep two copies of most of the Etsy code base locally. The one I use constantly, which is for quick reference when a technical question comes up, and the one I use almost never which is where my various half hearted attempts to compress a quick hack into a 15 minute block live.

git gives me the tools to make it very painful when I get confused about which directory I’m in.

So in prep for hoping to finish up a quick hack during hack week (didn’t happen) I shaved a small attention starved yak. Namely changing the color of my terminal when I’m in workspace, which is the hacking directory. It’s a parallel to prompt hacks I’ve had for years that change based on host, but it uses osascript (command line AppleScript) for simplicity in scripting Terminal.app

set_bg () {
  osascript -e "tell application \"Terminal\" to set current settings of window 1 to settings set \"$1\""
}

function cd {
  old_wd=$(pwd)
  builtin cd "$@"
  pwd=$(pwd)
  if [[ "$pwd/" =~ /workspace/ ]] ; then
    set_bg "Red Sands"
  elif [[ "$old_wd/" =~ /workspace/ ]] ; then
    set_bg "Basic"
  fi
}

Override cd, if we entering workspace, use the profile “Red Sands”, if we’re leaving workspace switch basic to “Basic”.




Explaining to the phone how to be a CTO

2013-12-06T02:03:55Z

The other morning I was sitting stuck in traffic … which an odd experience in New York, but for a few reasons I’ve actually been driving to work lately, profoundly surreal as a New Yorker, and not recommended. Back to the story. I was sitting stuck in traffic, and the last thing I’d seen before […]

The other morning I was sitting stuck in traffic … which an odd experience in New York, but for a few reasons I’ve actually been driving to work lately, profoundly surreal as a New Yorker, and not recommended.

Back to the story.

I was sitting stuck in traffic, and the last thing I’d seen before being stuck in traffic was the question, “How do I learn enough to become a good CTO?”

So below is the first blog post I ever tried to write via Siri. I thought about leaving in all the misidentified words, but the point wasn’t comedy. It still came out quite brief and almost certainly incomplete and incoherent:

It’s a leadership role, which means you need to develop a theory of leadership. It’s a spiritual role which means you need to be able to speak and write. It’s a role that fundamentally trades on credibility, so having been part of a team that did something that actually worked is key both for the reflected credibility but also because it’s important to have the certainty about what something working feels like.

It’s a role we learn by trial and error so you need to find a trusted community to compare notes with. You need to develop an empathy for the customer and interest in the business so whatever interdisciplinary pursuits do that for you is part of your training.

Finally being right more often then you’re wrong helps, but is less critical then you’d imagine.

It isn’t the 1st engineer either literally or metaphorically though that person is sometimes called the CTO. It isn’t the engineering manager in chief, though often you end up doing that job as well (but that’s a VPofE).

Software development scales non-linearly with clarity and excitement so your job is removing unnecessary ambiguity and drag. holding the narrative of what engineering means at YourCompany.

That’s how you learn to be a CTO.

And now that I’m typing this in to a textbox here on web, I’ll add, get good at managing your psychology




Slow Twitter

2013-11-17T23:16:45Z

My brother tweeted recently, “making sure I have a working implementation of Logo is part of setting up the nursery, right?”. I feel the same way about building the just the right photo sharing site and Twitter client. But I’m RESISTING. And I’m very proud of myself for it. The Twitter client I want (and […]

My brother tweeted recently, “making sure I have a working implementation of Logo is part of setting up the nursery, right?”. I feel the same way about building the just the right photo sharing site and Twitter client. But I’m RESISTING. And I’m very proud of myself for it.

The Twitter client I want (and have wanted for years, but I want it more now) is at least fairly straightforward, and I’m hoping someone has either already built it or will get inspired. I think of it as “Slow Twitter”.

Twitter works great when you’re constantly checking it. Or when you don’t follow that many folks. But once you’re distracted you start missing stuff. In fact you only see the people who tweet constantly. And they’re often the most banal.

What I’m looking for is an app (and I include websites in that word, I’m old fashioned) that shows me who has tweeted since I lasted accessed it, with access to what they’ve tweeted, sorted in reverse order of the likelihood that they would have tweeted during the period of elapsed time aka probably sorted by ascending rolling average tweet frequency.

Anyone?




5 Approaches to Handling Bugs We Tried Before Our Current Approach

2013-11-01T21:37:43Z

don’t write bugs once you write a piece of code you own it forever and your top priority is fixing the bugs in it assign teams to own every section of the site, allow them to make sure no unapproved changes happen to those areas have a bug fixing team delete all code over a […]
  • don’t write bugs
  • once you write a piece of code you own it forever and your top priority is fixing the bugs in it
  • assign teams to own every section of the site, allow them to make sure no unapproved changes happen to those areas
  • have a bug fixing team
  • delete all code over a year old, switch to a new language, rewrite it



A quick knot in a few Flickr threads

2013-10-19T13:06:55Z

Paul Mison’s Maximum Viable Product feels like a more clever (if more cheeky) way to get at what I was trying to say with my notes on Flourishes and Minimal Competence (and Competence found), and threads the needle of recent 4up from Aaron and The Flickr We Lost from Dan. I don’t have much conclusion […]

Paul Mison’s Maximum Viable Product feels like a more clever (if more cheeky) way to get at what I was trying to say with my notes on Flourishes and Minimal Competence (and Competence found), and threads the needle of recent 4up from Aaron and The Flickr We Lost from Dan.

I don’t have much conclusion as much as a sense there’s a thing there that I’m still trying to get my hands around.

The other piece I wonder at about this is the role of sophisticated testing and measurements and being the user.

I hear that engagement is way up in the wake of Flickr’s changes, and I know I’ve been gone a long time and things have probably changed, but I can’t help but be struck how unsophisticated we were at measuring things at Flickr — in part because we were a tiny team, and in part because we relied on our instincts. It makes me wonder what’s guiding the current work.