siavosh's blog

Programmer responsibility

Mon, 13 May 2013 21:16:54 -0700

From Paul Lutus, Confessions of a Long-Distance Sailor

“After I was overruled, I wrote a letter of resignation. In my letter I explained the risks and said I would rather resign than allow dangerous hardware onto the Shuttle. And I pressed my letter into more hands than absolutely necessary. The embarrassment level got pretty high and the managers backed down — I was allowed to make the necessary changes.

Does this make me a hotshot, a moral person? Not really. I wasn’t married, no children to support, I could afford to lose my job for a principle. Besides, I was able to imagine what would happen to me if I caused a Shuttle failure — kids on the street saying ‘There’s the guy who killed all those astronauts and the schoolteacher.’

I didn’t become an engineer just to design things. I wanted to design them right. I was a bit too idealistic for engineering profession, who’s motto is “Ship it.” So I changed careers — I got into computer science.”

This was written more than twenty years ago, and it’s funny that the term “ship it” was as connotative and full of meaning as it is today in the midst of the lean startup movement. When I read this in Paul Lutus’ very engaging sailing travelogue, it made me think about the responsibilities of engineers and programmers to the people who depend on their software. I think this is on the mind of a lot of software developers.

It doesn’t feel like a week goes by without millions of emails and accounts being hacked or a software bug causing massive downtime in a stock exchange or airline. Software’s increasing potential for good is only matched by its equal potential for harm. Testing methodologies and its culture have advanced a great deal in the last decade, but most would agree that its no panacea. Instead some argue the deeper solution is in the languages and idioms we use that make writing code safer (my favorite being Rich Hickey’s philosophies). Yet this too can never protect us if the person who writes the code doesn’t (1) see the potential for harm in their work and (2) does not feel the moral responsibility of saying no to “ship it.” It obviously can get quite messy when livelihoods and politics are at stake, and I doubt we will not all struggle with it in our careers.

I’ll leave with an excerpt of an interview with a famed Japanese woodworker, Toshio Odate:

“Toshio added something very important: there is something else that is not always being grasped by many woodworkers in the craft: the social responsibility of the craftsperson, be they woodworkers, musicians, photographers, doctors, or writers. Each of these persons practices a craft and in that craft they are expected to produce a result that carries with it a social responsibility. And that responsibility is where the person’s skill and even artistry must be used to serve others. For example, if a joint is used to show off a person’s ability to create a showy piece, but fails when it comes to joining two pieces of wood securely and efficiently, that person has failed at their responsibility to society—even if the joint “looks beautiful.” But the craftsperson who makes a solid joint, that looks “good enough,” does its job and holds for decades or centuries to come—that person has fulfilled the responsibility society asks of them. Even if that joint is hidden, it has the spirit of being a good joint…

…once you commit to making a piece for a client, or a family member, that responsibility is there, to those people. It’s your job to make sure your design and your workmanship serve the needs and desires of your clients, and that the techniques and materials you use serve those ends. Anything else is superfluous, and runs the risk of being dangerous, or at best, ugly.”

From Fine Woodworking.

Krenov on art and livlihood

Thu, 25 Apr 2013 16:33:00 -0700

MR. FITZGERALD: What did you advise them? When you were advising the students on how to make a living at this, what would you tell them? How to sell – how would they sell their furniture?

MR. KRENOV: Well, my standard formula was the better work you do, the more chance that you’ll starve.

From Oral history interview with James Krenov, 2004 Aug. 12-13

Should you listen to your user? There's a formula for that.

Wed, 24 Apr 2013 20:59:00 -0700

It’s hard being a developer and not becoming defensive about what you build. Just like a writer or musician, we invest a lot of ourselves in what we create. This is natural but not always helpful, and sometimes it’s downright fatal. So we try to internalize and practice being a good listener when a customer comes knocking on our door with an “idea” or “bug” to report. I use quotes because we all know that some users are, um, not to be taken too seriously. So there’s the rub, cynicism can grow and eventually the day comes where we don’t take any of our users seriously and either they leave us or the bug they tried to tell us about finally does us in. So what’s a developer to do?

Well, it’s your lucky day! After years of battling the contradicting emotions of loving and hating my users’ feedback, I’ve derived a formula representing how much credence you should give them. Take yourself out of the equation, and use this to bring balance to how you listen to a customer’s feedback. The variables above are elaborated below:

a - the importance of the app to the user’s life or work
b - the intimacy of the mode of communication (in-person > phone > email)
c - length of time this user has been using your app
d - average user lifetime
e - Euler’s number
f - fraction of time the user yelled at you or used CAPLOCKS
g - standard deviation for user lifetime
C - your app’s normalizing constant

*This being the internet, I feel obliged to mention this formula is a joke, but hopefully the motivation behind having an objective process to weigh user feedback isn’t.

Krenov on Compromises

Thu, 11 Apr 2013 23:10:00 -0700

“Not long ago someone wrote from far away to ask me, ‘Should I make compromises?’ I read and reread the letter, realizing there wasn’t much I could say to my friend. I ended up by simply suggesting that he try to keep this problem secondary. Let the work have primary importance, let it answer the question. Don’t allow the matter of compromise to become more important than the work. This means the way you work, the things you do and how you do them, your shop, the way you live are in some sort of accord within yourself. You develop a way of living, and if that conflicts with commercial interest, then you must sort it out. Either you adapt your work to commerce or you solve your money problems another way and keep your work what it should be for you. As I’ve said to myself many times before: Try to live the way you are, be the person in your work that you are in the rest of your life. Easy to say!”

James Krenov, The Impractical Cabinetmaker

Redefining the 10x programmer

Tue, 09 Apr 2013 14:06:54 -0700

I think some of us miss the more plausible definition of what’s commonly referred to as the “10x” or “100x” programmer. When I first heard the term, I imagined a mathematical genius speaking code, half human and half machine. There certainly seem to be those folks who are far better and faster programmers as I’ll probably ever be, but I don’t think this fully covers the 10x/100x population.

In my experience, the true astronomical gains in productivity occur not when the programmer produces more code or builds more features faster than everyone else. It’s instead when they make good early design decisions, and don’t produce latent catastrophes. Company productivity often grinds to a halt when they have to pay technical debt that was sown months or years earlier by seemingly smart and productive coders. Like most debt, it tends to compound and amplify over time and the scale of an organization.

From this perspective, you too can be a 10x or higher programmer not just by producing more widgets faster than everyone else, but by producing widgets that stand the test of time and minimize debt. The trick, I think, are the early decisions you and your team make at the beginning of each coding cycle.

Ticking time bomb

Sun, 07 Apr 2013 17:41:00 -0700

Reading the recent article on Markus Persson, I easily related to his recollection of how he started programming by typing snippets of code from magazines. When I was a child, my dad did the same on the family Atari, followed by me trying to type the few english words I knew at the time into the command line to see if they’d result in more spectacle. They did not, but my curiosity had been piqued.

Remembering that isolated programming environment in my family’s living room provided a stark contrast with the present software ecosystem. Today we live in the world of web services, a proliferation of open source libraries, and rapidly evolving platforms, standards and devices. The pace of innovation in software and the sheer prolificness of the community is truly humbling. Yet this interconnectedness and leveraging of power introduces its own costs, namely fragility.

From working atop a high rise of virtual stacks we know little of, to the fact that a piece of hardware’s shelf life is measured in months, as software developers, we are at the mercy of innovation, not just empowered by it. Every programmer can remember a time where a library call was unexpectedly deprecated, a crucial service call was out of commission, or a hardware platform no longer supported by an OS. All dependencies outside your direct control.

If you run your own servers, the situation is not as dire, but mobile and browser development is now dictated by users obtaining “manufacturer” upgrades and features more or less in real time, independent of your best drawn out plans.

The positive effects are well known: faster innovation, more features, better for users, less need for backwards compatibility etc. But I don’t see too many people mentioning the flip side of innovation in the era of interconnectedness, that of disposability, risk and the increasing costs for software maintenance. In my own experience, there have been numerous times where feature development has been significantly put on hold to test new iOS versions and code around deprecated library calls. At times it looks like there is a ticking time bomb inside all our code, it’s just a matter of when it’ll explode. So we wisely channel more and more resources to keep up with our dependencies. It’s a chronic situation, punctuated by acute episodes of pain.

I guess the lesson is to never get comfortable or even entertain the notion that your code is like a bridge or building that will stand the test of time. The only way to mitigate it is to embrace best practices in design, testing, and engineering. My feeling, which is a limited one obviously, is that software maintenance costs aren’t going to go down anytime soon, if anything they feel like they’re going up.

Some thoughts on woodworking and programming

Fri, 05 Apr 2013 00:04:00 -0700

Never saw this coming, but it all started when I got tired of buying disposable furniture and looked for a sofa that wouldn’t break my back. The more I learned about furniture construction (tip: only buy a sofa with high density foam graded at 2.2lbs or more), the more obsessed I became with the history and craft of woodworking, particularly the hand tool variety.

Fast forward a couple months, and I’ve now completed a weekend course at a private workshop and just started a 10-week evening class at a city museum on using hand tools. All this has made me wonder, what led to this weird obsession?

Last week I overheard our instructor telling a student that a lot of software engineers sign up for the courses because “it’s so different than what they normally do.” This is obviously true, in woodworking you do physical work. You get gnarly blisters and you’re mostly on your feet. Couple that with precise measurements and the engineering aspects of furniture design, and you get a nice hobby and exercise for a soft handed programmer who sits too much.

Yet that explanation, as a sort of break from a day job or physical exercise didn’t really feel like the whole story. What I really feel is happening is we crave a true craft, and no matter how much people refer to it as such, programming is not a craft (curiously, mathematicians rarely feel the need to call theirs such a thing).

Data structures and algorithms can be beautiful but we don’t use our five senses to really construct them, we use our minds and work with 99 layers of abstractions over the circuit board. Which is fine, but it’s not exactly comparable to the notion of a traditional craftsmen wandering their hands along a few beautiful cocobolo logs, smelling the sawdust, and hearing the hand plane shave off hair thin shavings. What’s the difference in this picture? This woodworker is seeing, smelling, touching, hearing, (and if they really desire it, tasting) their raw materials. That’s almost all the five senses, and the layers of abstractions/separations are no where to be found! If ours is indeed a craft, it is a deprived one.

Famous woodworkers like James Krenov and George Nakashima strived to “work closer to the wood.” There is an inherent positivity to working and living close to our senses, maybe something along the lines of truth and wisdom, but that’s just a guess.

If nothing else, our senses need to be nourished.

14 lessons after five years of professional programming

Tue, 02 Apr 2013 22:59:00 -0700

In no particular order:

1. When performance is an issue, if you can calculate or process it at the application layer, then take it out of the database layer. order by/group by are classic examples. It’s almost always easier to scale out your application layer than your database layer. As true for MySQL on your server as it is on the sqlite in your handheld. EDIT Some great comments on HN for this one so I felt like I better clarify: we only do this for certain queries not to improve necessarily the client response time, but to relieve load if the query is battering the DB and making it a significant bottleneck for ALL clients.

2. Concurrency, avoid it if you can. If not, then remember that with great power comes great responsibility Avoid working directly with threads if you can. Work at a higher level of abstraction if possible. In iOS, for example: GCD, dispatch and operation queues are your friends. The human mind was not designed to reason about infinite temporal state—I get nauseous thinking about how I learned all this first hand.

3. Minimize state as much as possible, and keep it as localized as possible. The functionalists were/are onto something.

4. Short composable methods are your friend.

5. Comments are dangerous since they can get out of date and mislead, but so is not having them. Don’t comment the trivial, but strategically write paragraphs if needed in specific sections. Your memory will fail you, as soon as tomorrow morning, even after coffee.

6. If you feel one use-case scenario will “probably be ok”, that’s the one that’s going to lead to catastrophic failure a month in production. Trust your paranoid gut, test and verify.

7. When in doubt, over communicate all concerns with your team.

8. Do the right thing—you usually know what that thing is.

9. Your users aren’t stupid, they just don’t have the patience for your cut corners.

10. If an engineer is not tasked with the long term maintenance of the systems they build, view them with suspicion. 80% of the blood, sweat, and tears of software occurs after its been released—that’s when you become a world weary, but wiser “professional.”

11. Checklists are your friends.

12. Take initiative to purposeful enjoy your work, sometimes this will take effort.

13. Silent failures, I still have nightmares. Monitor, log, alert. But be wary of false positives and the inevitable desensitization it leads to. Keep your system senses clear and alert.

14. At the end of the day, we’re paid to manage complexity. Work accordingly.

*Side note: talks by Rich Hickey and Clean Code by Robert Martin have been very positive recent influences on my work.

woodworking

Sat, 02 Mar 2013 21:15:00 -0800

“Personal work habits should be forged and tempered like fine steel tools until they are effective, are performed with control, and are as safe as possible. Then, they can be enjoyable and result in good work.

Good work cannot be produced unless the work is enjoyable; making a thing should bring pleasure, not pain. The work must never be rushed to completion, but done with care and patience. Above all, one should truly enjoy one’s work. It is important to remember that wood is a living thing—one must understand its properties and not oppose them. Whenever work is forced, it either ruins the piece, damages the tools, or injures the worker, so work must always be done with the utmost care.”

-From the “The Complete Japanese Joinery”

Survey results: cultural fit

Sun, 03 Jun 2012 13:26:00 -0700

The results are a bit surprising as I’d expected them to have much less variance than they do. If you haven’t already, feel free to take the survey and the results below will update accordingly. One point this reinforces is that there is no single ideal culture for technology companies to strive for (at least given the attributes below). Every company wants to attract smart people who can get things done, but there are many different cultures that can do that. Given the current entrepreneurship renaissance and intense competition for talent, startups shouldn’t all rush to get a ping pong table and sponsor nightly beer soaked happy hours. There are many different types of engineers, and companies can use that to their advantage and nurture a culture that is truly their own.

Loading…

It's the culture stupid

Thu, 31 May 2012 21:13:00 -0700

Before I begin, please take 3 minutes and fill out this survey on cultural fit. I’ll write another blog post trying to summarize the results. Thanks in advance.

More and more, I hear about people leaving their current jobs due to cultural reasons. Just today, there was a post-mortem on HN by a former Google employee describing in detail the technological culture clash he experienced. When a productive employee leaves a company, it signals a failure by both parties. The employee could have asked more questions before accepting the offer, and the employer could have been more transparent and screened better.

At my current company, we spend equal time on technical screening as we do on cultural fit. When I interview candidates, I ask non-surprising technical questions, but I also try to delve as much as I can into their motivations and expectations. I ask questions like the following:

What you are lacking in your current position?
What is your ideal interaction levels with your engineering, sales, and operations colleagues? With the customers?
Of all your past projects, which are you most proud of and why?
Describe to me your ideal work environment?

If I hear anything that strongly contrasts with our company culture, I delve in deeper, and try my best to be completely transparent as well. From my personal experiences, I believe this is unusual. Most companies/startups consider a beer with the team at the end of the interview cycle sufficient to know enough about someone. It doesn’t hurt, but it treats cultural fit too much as an ambiguous, unknowable thing. It’s not as black and white as asking someone FizzBuzz, but I feel that most companies can be more systematic and explicit in their criteria. The cost in time, money, and morale of not doing so is too large.

Career decisions are often life changing, for better or worst. We owe it to ourselves to be more honest, transparent, and explicit about our culture—on both sides of the interview table. Please share any methods you use for cultural screening on the HN comment thread.

Kickstarter - Light Table

Thu, 31 May 2012 12:20:30 -0700

Kickstarter - Light Table:

Just supported it, hoping it reaches their high goal by tomorrow.

Jonathan Blow - Game developer (of Braid)

Sat, 05 May 2012 23:31:00 -0700

I’m not really a video game person except on the rare occasion, but I’d read so many great things about the game Braid, I paid the (ridiculously low) $3.99 on the Mac App Store and started to play it. A very unique, atmospheric game with a very distinct vision of what a game can be. So I started to find some talks and interviews by its creator, Jonathan Blow. Here’s some of my favorite:

The Most Dangerous Gamer

Video games and the human condition

How to program independent games

Also, the other game I’ve been playing has an interesting creator as well:

Interview: Andreas Illiger, creator of Tiny Wings

Is there anything more disposable than yesterday's paper?

Mon, 02 Apr 2012 15:22:00 -0700

I don’t remember a lot of things from my unfinished Ph.D. studies, but I do remember an exchange with my advisor. I was in his office giving him a status update on some task, and our conversation turned to how some other lab had recently had their worked covered in the L.A. Times. With a belittling smile, he said you can value their work by looking at the medium it was published on. And there’s nothing more disposable than yesterday’s paper.

Tech industry publications and personalities are publishing content filled with bold, young, supremely confident claims of value and quality. From proclamations of recent epiphanies to freely offered advice, the internet is saturated by those wanting to create personal brands. Some is worth reading, but most is not because there is in fact one thing more disposable than yesterday’s papers: yesterday’s blog post. You can’t even recycle it.

The deluge of electronic media has spawned countless companies that filter or curate content so people can discover things of value. Even after the complex algorithmic or crowd sourced curation, I am still surprised how easily I forget most things I read. Very little leaves any imprints despite all my attempts at setting the filters just right. This can be very demoralizing, considering all the time invested.

Reflecting on my advisor’s remarks, I’ve rediscovered the value of time and the things that survive it. They are described by words like classic, foundational, and timeless. These words are earned, and not by SEO optimization. So now I filter by the ultimate content filter: time. I look at everything I read through this lens, add the necessary grains of salt, and ask myself a simple, objective question: how old is it?

Good talks that are stirring my thoughts

Mon, 19 Mar 2012 23:00:08 -0700

Bret Victor: Inventing on Principle
Rich Hickey: Persistent Data Structures and Managed References, Hammock Driven Development, Simple Made Easy
Iain McGilchrist: The Divided Brain

The genius of @RealTimeWWII

Sun, 18 Mar 2012 23:45:57 -0700

Maybe I’m just late to the party, but I accidentally discovered @RealTimeWWII on twitter. It basically tweets notable and intimately revealing moments from the second world war to the day and time for a period of six years, starting in 1940. Simple and brilliant.

I mostly use twitter as a source of news. One of the most active sources I follow is BBC breaking news. So interspersed between Syria’s government crackdown and NATO woes in Afghanistan, I get tweets like the ones I’ve pasted at the bottom of this post. The diversity of the tweets is amazing. From the educational to the poignant, from the profound to the trivial, from the ominous to the entertaining, the tweets are masterfully written, but there’s something really new that has kept me thinking why I’m so excited about it.

The medium adds whats new:

On pure coincidence, some of the historical tweets are laid adjacent to contemporary tweets about similar political or war related events that give you new perspectives
It becomes immensely entertaining because you know where it all ends, but other than some major battles and some characters this is as close as many of us will get to a time machine
Why is this NOT a poor man’s history book? This real time nature of the tweets give an incredibly novel way of injecting our intuitions of time into the history, making it more real and more intimate. Our reasoning about the period gets to be clearer and less distorted by our distance

The educational and entertainment values are immense, and I wonder what other stories can be told this way and what other variations exist. If you have any interest in history, and you’re not following @RealTimeWWII, you’re missing out.

Some sample tweets:

Make it slower and harder for your users

Sat, 17 Mar 2012 15:30:00 -0700

Our industry is obsessed with making things faster. Yet when it comes to the formulation and exchange of ideas, faster is not always better. Thinking about the fragility of ideas, and the lack of deep thought in modern software design methodologie s, I wondered if this is in fact how our entire society is perceiving communication: think less, produce more, and do it all faster. The result is apparent to anyone looking at YouTube comment threads.

In the case of forums and comments, imagine if instead the user is forced to wait, say five minutes, before being able to post a response. Probably 80% of users wouldn’t return once their time is up, but the remaining 20% would be very motivated and have had a chance to think even more about what they were going to say, and possibly changed their mind in the process. Optimistically in the end, the volume of the conversation would be far less, but of higher quality.

This is just a hypothesis. Slowing down the pace of conversation, putting a greater emphasis on listening rather than speaking are timeless lessons we’ve all learned in real life. I’m hoping we can rediscover this on the web.

A quote of a quote of a quote

Tue, 13 Mar 2012 23:54:36 -0700

This is attributed to a HN comment by Jun8:

“Many people have written about it but I think Paul Bowles nailed it in The Sheltering Sky:

‘Death is always on the way, but the fact that you don’t know when it will arrive seems to take away from the finiteness of life. It’s that terrible precision that we hate so much. But because we don’t know, we get to think of life as an inexhaustible well. Yet everything happens a certain number of times, and a very small number, really. How many more times will you remember a certain afternoon of your childhood, some afternoon that’s so deeply a part of your being that you can’t even conceive of your life without it? Perhaps four or five times more. Perhaps not even that. How many more times will you watch the full moon rise? Perhaps twenty. And yet it all seems limitless.’”

The perils of gamification

Fri, 09 Mar 2012 17:08:00 -0800

My thoughts on this aren’t fully fleshed out, but it’s been bothering me that I don’t hear too much about whether thoughtless gamification of products is a good thing.

There are different definitions of gamification, but for the sake of this post I’ll assume the following: “The art and science of using game mechanics in non-game businesses to increase efficiency, customer loyalty and engagement.”

My family moved to the US when I was 7, and shortly after I noticed how my teachers were very preoccupied with making learning exercises into games. I clearly remember after a couple years of this, that something did not feel right. More and more of my classmates expected things to be fun or quickly lost interest. For example, if long division wasn’t made to be fun, it really wasn’t worth doing. If the game wasn’t setup properly, or a more fun (real) game was around, they lost patience and blamed the game or lack there of. Everyone suffered from this approach.

When you’re deciding whether to play Angry Birds or Tiny Wings, you choose the most fun one. This is a valid criteria because having fun is its own end. Yet when it’s clearly not a game, everything becomes contingent on the game being well designed, long lasting, and (quickly) gratifying. This seems very perilous to me, because every game gets old and you risk doing a lot of damage not just to your product, but to your users as well.

If you are a product designer reaching for the hammer that is gamification, you should stop and give it some reflection. If you can’t make the truth or essence of your product compelling enough without it, then it might not be worth doing.

I want to work in batches, please let me!

Thu, 01 Mar 2012 12:10:44 -0800

Now, I’m philosophically against multi-tasking and the inevitable ADD that arrises, but since society seems to encourage this, I’ll go ahead and be a hypocrite.

I’ll start with an example: so many times I want to be working on two emails at the same time. Sure, you can pop multiple windows out, but that’s too much hassle. Or worst, I can keep saving things as drafts and going in between them. What I really want is to open multiple emails in a list and have them all visible and just go through them in any order I please: serially or in parallel. Fewer clicks, and less mental state tracking. What’s important to notice is that even the possibility of having to maintain more state in my brain depresses me.

I think this points to a design that I’d like to see more of. Take any app that opens a task item of some sort, and ask yourself: would it help my user to do multiple SIMILAR things at the same time? Then, how can I show all of them on the screen simultaneously?