On Sharing Knowledge

We’re filled with many amazing abilities which we consider mundane because we’re so used to them. Some of them are mentioned and described here.

Sharing knowledge is one such an ability – if only a few people were capable of doing it, the group would be inconceivably more powerful than the rest of humanity combined. In a matter of perhaps months, they’d accumulate experience beyond what anyone else could and be able to apply it accordingly, earning the capacity to outdo the rest of existence.

Now, that scenario is perhaps too extreme – and too far removed from our daily lives. But even a slight difference in the capacity to share knowledge can compound heavily in time; this is directly observable by seeing the difference between teams where people are jealous of their knowledge and position and teams where members are more carefree about their information and techniques. It is also observable in the difference between someone dabbling blindly (or just observing people) in a particular discipline or area of knowledge and someone with one or more mentors.

Transfering knowledge through text, sound or performance, and particularly with the more deliberate variants (dissertations, presentations, essays, tutoring, mentoring, demonstration) pushes the learner’s progress in ways that can be non-linear, helping people develop previously unsuspected insights.

The achievement of this insights is so pervasive among hackers – which are a knowledge work oriented population if there is one – that there are terms for different textures of insights: “zenning” and “grokking“. There are people who consistently help achieve insights, and those achieve folk-hero status among hackers. Brian Kernighan and Donald Knuth are two superlative examples of this breed.

We should, then, as a society, embrace, support and boost efforts aimed to sharing knowledge. We do try, really… the school system is facilitating mass, intergenerational knowledge transfer with some success.

There’s been a wave of internet users turned teachers, mentors and sharers that gives me hope. Systematic efforts like Open Source Ecology and Khan Academy fill me with hope. The sometimes pell mell efforts by individuals sharing info on subjects as diverse as personal appearance and cooking make me ecstatic.

Yes, books are there, and other media. But this is a new kind of effort, which takes the power of the internet and the services currently running on it (such as search and hosting) to reach an amazing number of people who can remix, enrich and reshare knowledge with thousands of points of view from all walks of life. The potential for amazing results are huge, as the knowledge being shared grows exponentially.

There is potential for things to go wrong, which I will write about in the future. Usually, you should avoid sharing dangerous information. How to build explosives, or break into computer systems, or do harmful stuff.

For all other things, please, do share. Teach, learn. Due to the accumulation of the effects, our future can be exponentially better – or worse – depending on this.

Want to learn programming?

Derek Sivers has been a great inspiration for me in many aspects. My now page was basically his idea – there’s a whole movement around what people are focused on doing at the moment, and the sort-of community feeling keeps me accountable.

Some time ago, Derek wrote about how nice it would be to just have someone tell you what to do, and the fruit of that line of thought is is “Do This. Directives – part 1” article, which appears to be the first of a series.

I don’t yet have directives; not hard and fast ones. I used to have a page up with things you should read and work through, which would level you up. It’s more in the style of How To Become a Hacker.

I’ve not taught many people to code, so I don’t have the crystallized view of what, exactly, would get you to become a competent programmer. While that comes along – I pretend to teach many people to code in the near future – here’s a rendition of my advice on becoming a competent programmer:

  • Work through Learn Python the Hard Way. Internalize the mechanism for learning.
  • Read How to Become a Hacker and follow its advice
  • Work through Nand2Tetris
  • Work as much as you can through seminal works, like The Art of Computer Programming and Structure and Interpretation of Computer Programs
  • Join usergroups in your vicinity.
  • Get something done – something nice for yourself. At this point you should’ve already.
  • When you make mistakes: Identify them. Catalogue them. Learn to avoid the whole category of the mistake, if possible. Share it, that others may learn to avoid it.
  • Stop saying you’ll do it. Stop wondering whether this has something to do with what you want to do. Stop making to do lists. Start. Now. Hurry.

See you on the other side 🙂

Innovation conundrum

Coordinating people is hard; I think it’s the next step from giving away information that allows for wealth creation in particular niches.

Even if you have a small group of enthusiasts who are discovering how to clobber a particular set of problems, once a subset of those have become trivialized hardships ensue: who’s going to do the now boring work? Or take the now easily grasped fruits of work?

In the digital/computing realm, there’s still enough stuff that needs to get done out there that this is no big issue. In the physical realm, the issue is further complicated by lack of access to raw material that enables the execution.

Being able to work out deals or mechanisms that allow people to feel content doing their part, enabling the exploitation of “already solved” areas without hindering the discovery of new solutions is very valuable. Companies with good R&D departments that help the business thrive while not suffocating innovation manage to do it.

In order to be able to share wealth properly, we need to find good solutions to this innovation conundrum, which can be summed up in two points:

  • solutions make whole areas at the same time boring and exciting (for different kinds of people)
  • tensions arise in resource allocation, both between parties that want to exploit the newly discovered improvements and between the “exploiting” and “innovating” camps.

Avoiding Arguments

Sometimes arguments are not crucial to your ends.

As a means to get people to understand you, correct your ideas, help you shape the lens through which you see the world, arguments are amazing. But sometimes you just need to get something done.

Sometimes, you’re committed to a particular opinion, and are certain enough of your correction that you don’t want to waste time arguing.

I put a high price on certainty – the more certain you are, the more you should be willing to bet, be it in money, comfort or the possibility of winding working twice as much if you’re wrong. If you’re really certain, sometimes you just have to put your money where your mouth is, and commit. Offer to carry the burden.

“I’ll have our back if something goes wrong”

“I’ll be responsible for this, if we make it this way”

“If we go through this path, it will be so much easier, I’m willing to take a bigger chunk of work”

At other times, this won’t work – mostly because someone else is equally invested in a way to do things which is incompatible with yours. Offer the other person the chance to take responsibility; put them on the spot. If they don’t step up – well, I sure hope you’re right, because things are most likely going down your way.

Retrospective: Clean Code – Boy Scouts, Writers, and Mythical Creatures

Yesterday I gave a talk on Clean Code, based in content by Uncle Bob and Geoffrey Gerriets.

I had some technical issues – so I had no access to my presenter notes, damping my performance somewhat… and after I’d taken such pains to learn from Geoffrey’s talk at PyCaribbean on Code Review, Revision and Technical Debt.

The subtitle for my talk was: “Clean Code, Boy Scouts, Writers, and Mythical Creatures”.

It starts out by talking about the features of clean code, as described by Uncle Bob and his interviewed few in his book Clean Code – and comparing each group of aspects to physical things we can look up to, like a Tesla Model X, a pleasant beach, or a bike… all of which share traits desirable in our code.

Then going on to the maxim of “leaving the campground better than we found it”, with a nice example of some code taken from the IOCCC and how much more legible it became merely by reindenting it,  putting in relief the long term impact of little incremental changes.

The latter half of the talk was derived from lessons learned at Geoffrey’s talk: the process of a professional writer, compared to the process of a professional coder, and how they’re alike; the lessons form the writers’ day to day can be applied to our coding: design, write, revise, rewrite, proofread; some attention was given to the way that reviews may be given. The mythical creatures section –  which represent the different stages at which a developer may find himself – are an aid to this latter part of the talk by pointing out patterns of behavior that identify what may be important or not for a certain developer at a certain point in their growth. The advice to treat things that may be beneath a developer’s level as trivia and/or minutiae, as well as the advice on focusing and choosing improvements to point out instead of “trouble” may be the best of this part of the talk.

After realizing I’d burnt through the presentation and posing some questions to the audience, we discussed some interesting points:

  • How can code comments make code cleaner or dirtier?
  • How can rewrites alter our coding behavior?
  • How can we find time to have a re-writing flow if the management doesn’t know any better?

The mileage may vary, of course, so several people pitched in and we didn’t draw any firm conclusions, only presented ideas to try, which was interesting.

In the end, we came out with some good ideas on how to keep code from stagnating… hopefully our future selves will have ever fewer messes to deal with :^)

Retrospective: Reasons why you should love emacs

Last Saturday I was at Dominican College O&M’s campus at La Romana, as one of the speakers for the “OpenSaturday” series of events.

This was a complete success: full-room, engaged audience, excellent speakers.

I had the opportunity to give my first talk on emacs.

It was delivered using org-tree-slide-mode for one part — which was really cool for the audience and for me, too.

On the second half of the presentation, I used org-mode and demonstrated custom “ToDo” states and timestamps, org-mode html export (C-c C-e h H), syntax highlighting, Immediate mode, and Emmet mode. Of course, I demonstrated having multiple buffers open in several windows at the same time.

It was all in a hurry, because it was a 10-minute talk; I couldn’t demonstrate the keyboard macros – which would’ve been nice, as I was going to demonstrate an extraction of html form item names and the generation of php code to get it from the $_REQUEST superglobal; this makes use of emac’s ability to use search and all functions as part of the macro, which I know for a fact several editors can’t do.

The show-stealer was Emmet mode – I actually thought people would’ve been more surprised at noticing that the presentation was within emacs, but they weren’t. As many are CS students who are learning HTML, seeing html>(head>title)+body>div#content>ul>li*5 grow into the corresponding tree blew them away.

I’m planning to enhance that presentation to fill a 45-minute slot featuring keyboard macros, elisp functions + keybindings, and select parts of my .emacs file. Perhaps the presentation will be accompanied by a “Reasons to love Vi” by one of my colleagues, which would be sweet.

In any case, a great Saturday – hopefully things will keep on being fun.


I usually don’t have internet on my phone unless I’m home.

I started playing a recent freemium game aiming to be an e-sport.

The game has offline notifications.

This decimated my capacity to properly concentrate, little by little. I can now appreciate the reason many decry this as the era of distraction, of people looking down at their phones all the time. Not to misrepresent my stance: I’d noticed people walking around carelessly, too concentrated on their phones; it’d not really worried me, as once upon a time I did that, only carrying books around instead of a phone.

What I hadn’t noticed is the barrage of notifications, at seeming random times; the concatenation of stimuli in near-random intervals that create a tick-like habit of constantly checking the phone, fomenting a mental nag.

Any kind of worthwhile work – which is any work not to be automated just yet – takes time and focus; it probably needs introspection and analysis. Otherwise, it should be automated as much as possible until we find the need to analyze and meditate anew.

In any case, I’ve since uninstalled the application, which had no option to deactivate the offline notifications. I’ve also uninstalled a few other applications, which I liked to use from comfortable places at my home. And I took some days to cleanse.

Now that I’m not twitchy with check-my-phone-itis, I feel a lot better, and will keep posting – because now I can think through stuff, and remember better.

In case there’s any doubt, I’m saying that constant nagging severely impaired my focus, productivity and overall quality of life. You may be affected, too. Run an experiment on living without constant notifications running you, and see what happens. As for me… well, it seems not to be my style at all.

Hyperbolic Discounting

There are many ways to observe and explain the behaviors I described in the previous article. Hyperbolic discounting is a way to think about the issue.

On the one hand, we have the thought that people tend to push things they don’t like further in the future, which is basically what thinking about “low time preference” gets you.
On the other, thinking about hyperbolic discounting allows you to analyze the tendency for people to choose what they’d like now, even in exchange for things they’d not want later. In other words, we tend trade “good times now” for “bad times later”, such as partying hard in exchange for feeling beat, cranky and in pain tomorrow.

This may have useful insights to apply when trying to calibrate time preference. Perhaps reframing the future situation or doing a mental excercise that allows us to feel as if the bad times are going to happen before the good times do, we’d be able to help balance our decision making tendencies.

There are some good reasons for hyperbolic discounting – such as increasingly lower certainty about the outcomes when the chains of event are spread on very long stretches of time.

In any case, today I ran a tiny experiment to improve my productivity without varying my time preference – I killed all the distractions and sat down to work. It was good for most of my work session, but I was filled with anxiety that things may be happening which were important for me, and I’d not find out because I got disconnected. I’ll keep the experiment running for a few more days and see what happens; I expect that I’ll get used to the pattern and stop feeling anxious.

I still got more done than usual, which is nice. I hope the pattern continues.

On Time Preference

Time preference is a concept used to describe how much or little is a person willing to postpone a gratifying outcome in exchange for an improved outcome.

If the time preference is “high”, it means a person is willing to trade more future benefit in exchange for immediate results. A common example is: “would you rather have 10 dollars now or 100 in a year?” People with a high enough time will have choose the smaller amount of money now, while people with a low enough time preference will choose the higher amount of money later.

In other words, a higher time preference means a lower capacity for delayed gratification. The amount and variety of situations where having a low enough time preference leads to improved results is overwhelming; from optimized spending of money to optimized allocation of time for diverse tasks, including following through with plans which require a lot of time working before the reward arrives.

Knowing about this – being able to name this phenomenon and think about it, allows us to identify it and plan for it. If you lead a team where some members have higher time preference, you may want to look at a way to introduce intermittent rewards which are not too far away from each other. This is, I believe, what “gamification” is all about.

If lower time preference teammates are present, make sure they understand the big picture, the end result of work. As this is usually easier to do than gamifying processes, lower time preference team members can be easier to work with. Unless, for some unfathomable reason, you can’t share the end goal. Then do gamify, because for all that people can delay gratification, if there’s no light at the end of the tunnel, having some small gratifying moments mixed into daily work can work as a motivator.

I have found that my time preference is too high for my taste, and that this is one of the reasons I have felt the need to build upon my discipline. In hindsight, I may have been able to notice this sooner if I’d had the right information – the signs were everywhere – which is why I’m writing on the topic out here.

I’ll try to set up some experiments, with two goals:

  • To deal with my too-high time preference (gamifying stuff, most likely)
  • To lower my time preference

I’ve not seen any papers on these kinds of experiments, but I sorely need to do this, so I’ll look it up. I specially don’t have a clue on what to do to lower my time preference, so I’ll need to think about the what and the why, to try and get a clue about the how. Any ideas, don’t hesitate to hit me up.

On programming productivity

Measuring programmer productivity is notably hard. It’s the topic of numerous, variable length publications.

Much of coding can be succintly cuantified and estimated; time should probably be spent automating those tasks, as those are the boring, repetitive, well-defined ones, like creating a CRUD or converting some programming-language-level construct into a interface-level-representation such as JSON or XML.

The other part is hard to estimate, mostly because it combines several tasks, like getting to know the domain, figuring out what needs to get done and actually doing it in a polished manner.

Some things that are usually oversimplified in attempts to measure programmer productivity, sometimes to hilarious effect: amount of lines of code, time spent sitting at the computer, and amount of artifacts produced.

All of those means of measurement can backfire hideously by creating the wrong incentives (lots of boilerplate, woolgathering, overengineering, overestimating work length).

Here are a few important measurements that can be made to help track this elusive statistic:

  • Explain your work to your teams regularly. Have them rate it. Keep a history. State what’s being solved, why it was solved in this particular way, what tradeoffs were involved, any difficulties you ran into, and how you overcame them. Ratings on two indicators are crucial: problem complexity and performance. They should include justifications to help you home into better practices.
  • Keep track of all the bugs in your code, the stage at which they were noticed, and the time that fixing them required.
  • Keep track of the references to your code, especially if you’re writing tools.
  • Have your peers rate you on helpfulness and knowledgeability.

If you encounter any unintended side effects or incentives, please let me know. Up to now, the only bug I’ve found for this kind of process is the popularity-contest-like aspect it can sometimes take. Thus the objective numbers I slid in there to help balance. If you find other ways to improve on this, let me know.