Nathan Dao

I wrote this post on 15 Nov, 20171 minute read

In the final slide of his talk in Clojure/Conj 2017, Rich Hickey mentioned this quote:

The true function of logic … as applied to matters of experience … is analytic rather than constructive; taken a priori, it shows the possibility of hitherto unsuspected alternatives more often than the impossibility of alternatives which seemed prima facie possible. Thus, while it liberates imagination as to what the world may be, it refuses to legislate as to what the world is. - Bertrand Russell

When presented with a problem, it is sensible to come up with a logical solution, in which the logic was reverse-engineered from our past experience, or proven by someone else.

It is easy, on the other hand, to dismiss non-sensible options.

Yet, occasionally, the reason for them being non-sensible is because we have not realized their different mechanics, which only become obvious in retrospect.

How many times have we asked ourselves this question: “Why didn’t I think about that before?”

The whole language is there all the time. There is no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime.

Running code at read-time lets users reprogram Lisp’s syntax; running code at compile-time is the basis of macros; compiling at runtime is the basis of Lisp’s use as an extension language in programs like Emacs; and reading at runtime enables programs to communicate using s-expressions, an idea recently reinvented as XML.

As a novice user of Clojure and Emacs, right after reading this statement, bits and pieces of knowledge I had about Lisp immediately “clicked”.

The article was introduced to me from his tweet yesterday. I certainly learned a few things from DHH’s point of view, and found it extremely worth sharing.

Here are some snapshots from the article:

I wanted to put down roots. Long term bonds with coworkers and customers and the product. … The most satisfying working relationships I’ve enjoyed in my close to two decades work in the internet business have been those that lasted the longest.

I keep seeing obituaries of this kind of longevity: The modern work place owes you nothing! All relationships are just fleeting and temporary. There’s prestige in jumping around as much as possible. And I think, really? I don’t recognize that, I don’t accept that, there’s no natural law making this inevitable.

…

I wanted a life beyond work. Hobbies, family, and intellectual stimulation and pursuits beyond Hacker News, what the next-next-next JavaScript framework looks like, and how we can optimize our signup funnel.

I wanted to embrace the constraints of a roughly 40-hour work week and feel good about it once it was over. Not constantly thinking I owed someone more of my precious twenties and thirties. I only get those decades once, shit if I’m going to sell them to someone for a bigger buck a later day.

…

Our definition of winning didn’t even include establishing that hallowed sanctity of the natural monopoly! We didn’t win by eradicating the competition. By sabotaging their rides, poaching their employees, or spending the most money in the shortest amount of time… We prospered in an AND world, not an OR world. We could succeed AND others could succeed.

More than 3 months ago, I decided to join the maintenance team at Futurice.

Our company is filled with solid programmers. Learning from their code seems to be too good an opportunity to pass on, and so far, I am happy with the experience:

To my surprise, the majority of my day to day work involves developing new features for current projects, and little bug fixings. I feel fortunate to have talented business people in our team, who make sure the projects we get are not merely collections of bug tickets.

Maintaining a software project means living with others’ technical decisions. The real challenge comes when the choices are not aligned with current trends and our preferences. In many cases, taking into account deadline and budget constraints, there are certainly areas of the codebase I would improve on. However, the realization have usually been: those seemingly disreputable technologies are not that horrible after all. I ended up enjoying working with many of them. Don’t judge a project by its programming language or library choices, judge it based on implementation. True art emerges from practices, not tools.

People in our maintenance team are generally less picky about what they want to work with. They appreciate bleeding edge and hardly grin over legacy. I guess many of them have long ago experienced and realised the point I mentioned previously.

Many have very interesting outside work hobbies. Hanging out with them during lunch is a lot of fun. I enjoy deep technical conversations, but being able to engage with my colleagues on personal topics seems to bring us closer.

As an interesting observation in our team: a majority of them are older, more senior and more knowledgable in life. Hardly anyone shows the need to prove themselves. Sometimes, their quietness speaks volumes.

Lastly, we don’t call ourselves the “maintenance team”, but Futucare. I like that name a lot.

3 months is a short time, but I sure have learned a good deal being around this group of great, decent individuals.

The blog contains more than 2,700,000 words, delivering the equivalent of more than thirty full-length books. The blog doesn’t exist to get you to buy a book… sometimes I think I write the books to get people to read the blog.

I haven’t missed a day in many, many years–the discipline of sharing something daily is priceless. Sometimes there are typos. I hope that they’re rare and I try to fix them.