More on Locus of control and Self-efficacy

How you look at situations may reinforce tendency/attitude. Moreover, it shapes the impact you really have by shaping your actions.

There are a whole host of factors influencing your attitude towards a particular situation, from broad cultural tendencies to particular cognitive biases. Reinforcement is one of these factors – it is what happens when you have a stimulus folowed by another with some frequency.

For instance, if you get praised when you get good grades, or if you lose every time you try to beat a game, or if you sometimes win a small lottery prize.

This is something that works on many levels; if you tend to talk in a certain manner – or hear a certain kind of comment – about a particular topic, those thoughts and feelings towards the topic are reinforced.

So what’s that got to do with Self-efficacy and Locus of control?

We’re surrounded by people who look at situations from a certain point of view, and react to them in a particular way. This gets under our skin and shapes the way we view who’s responsible for things and what things we could make happen.

The excercise I want to propose Today is different to the one in Yesterday’s Post in that it’s more related to meditation, as opposed to prediction.

Take a situation you hear people talking about in a way that shows an externalized locus of control and minimized self-efficacy, in particular a social situations, and try this thought experiment:

Think about a solution that could be implemented if everyone involved could be simultaneously, magically coordinated. Then think what would happen if only half the people involved could be magically coordinated – what kind of solution could work? Then think how that kind of effect – the effect the solutions would have – could get to just a small group of people.

Now, bring into perspective the size of impact that a single person could have. What would anyone need to have an impact? Change maybe a tiny sliver of the situation? Is this within your reach? What would be within your reach, and how much change would it be able to make?


If it is within your reach and doesn’t imply costs which you’re unwilling to sink into the situation for the impact you think you’ll have, make a prediction and give it a shot. Otherwise, you still will have a better picture by thinking in a different way about an issue, in particular when it’s something that “the government” is expected to fix – I’ve found that “the government” is a gateway to externalizing locus of control.

Let me know of your thought experiments, and if this makes you think differently – or not.

Brief comment on Locus of Control and Self-efficacy

Locus of Control and Self-efficacy are two of the four dimensions of core self-evaluations. I want to take some time to talk about them becuase I think good calibration on these may help with the other two dimensions, and have a big impact in life.

Let’s define what I’m talking about:

Locus of control is where you think that responsibility for events is. So you may think “It’s my fault”, denoting internal locus of control, or “It’s X’s fault”, denoting external locus of control.

Self-efficacy is how much you think you can do. “I can communicate effectively”, “I can’t finish things I start”.

There are tendencies in people to be in a part of the spectrum in either dimension… overestimate or underestimate their ability, or their responsibility. Getting these evaluations properly calibrated is key to taking action, backing off, and selecting what to think about when analyzing a situation.

I am pretty sure that these can impact the other two dimensions – too much self-efficacy and too internal a locus of control can lead to high neuroticism and low self-esteem when things don’t go as planned. Too little and too external, and it can lead to high neuroticism and low self-esteem when things don’t go as hoped for.

Some recalibration may be achieved by applying the technique I mentioned earlier; set your sights on some event, predict what you think will happen, and do your best to get things to be different. It can be a work project’s outcome (it will be average? Do your best to make it great!), or a personal relationships level (you think you can’t hang out with people next weekend because you’re socially awkward? Do your best to get people to hang out with!).

I encourage you to especially try and change small things that you think can be better – if you turn out to be able to make them better, then it’s amazing. Otherwise, you’re still a person with good feelings and intentions.

Gather the data and think about your outcomes. Your triumphs and failures will help you better gauge and estimate your impact on events around you.

Note: this article’s recommendations are not backed up by solid research efforts, but by the mental model the author has of the workings of the phenomenae described and self experimentation. If you try this, please share your experience, that this information may be further enriched.

Discipline (progress)

I started this “Daily Writing” category of posts talking about discipline and kickstarting a path of discipline cultivation that is going to grow throughout the year.

This is the 18th post of the callenge, out of 260 articles I’m supposed to write this year, and I want to talk about the difficulties and progress I perceive in this path. I maybe should’ve done this write up five posts ago, or eight posts in the future, to have a nice 5% or 10% advancement towards the goal, but well, I didn’t.

Up to now, I’ve completed every single day. There have been some close shaves, posts that come out near midnight. I attempted to change my working hours to no avail; either I’m blocking myself without noticing or I’m most productive during the night. I will want to look into this later, but some of the likely culprits are: I’m more creative during the night hours, I’ve had more time to think about a subject, or I work best when close to a deadline. I’ll set up some experiments to test these hypothesis.

The major difficulty up to now has been consistently finding topics to write about, even though when I find a topic it lasts for a while or makes me think of others. The 9 post series talking about development environments is a transparent example; the segue from tips to cement your knowledge (which mentions github), to Using GitHub without knowing git, to HATEOAS is a bit less clear, but it’s still there. Even less transparent is the link between To get better, start now, Dunning-Kruger is misunderstood and Cognitive claibration.

And this post, which hails back to the first one, makes it all of five topics I’ve covered (the one on backups is too loosely related to the Rationality-oriented posts).  So, one thing I plan on doing to improve my discipline building routine is to add a weekly activity, likely on Saturdays, to plan the next five posts.

It has been alternatively easier and harder to write. I thought motivation might become an issue, but it hasn’t yet. Unplanned activities have hindered me more: staying up too late, wanting to read a book too badly, staying late at work. Those have drained me or distracted me, making it much harder to get up and start writing, or feeling sure about what I’ve posted. As a measure of precaution, I’m trying not to go back to older posts too much; the amount of time spent tweaking those older articles is sure to eat up a lot of time, and their purpose to build discipline while sharing knowledge has been fulfilled.

Seeing as this has gone relatively well, I plan on adding another new task (right after my third week of post-planning): going to the gym and getting fit.

I feel comfortable writing every day about any topic, so I still won’t place any constraints on that front. Setting a length constraint feels artificial at this point, too. Business as usual.

Lessons learned? Up to now, none. Just confirmed that what you fear will be trouble may not be, and trouble can come from unexpected places. Moderating my unplanned activities should help take the edge of writing these pieces.

Hopefully, either the year of writing won’t have any surprises, and my mental model of how discipline is cultivated is accurate, or I will notice on time to make this effort worthwhile.

Cognitive Calibration

Today’s topic is elaborating on implications deriving from Yesterday’s, so you may want to read that (The important takeaway is that we’re often not properly calibrated to deal with many things, even though we may feel we are).

Calibration is the relationship between a measurement and reality. When talking about cognitive calibration, then, we refer to the relationship between our beliefs and reality. A good way to know about it is to systematically make your beliefs pay rent, as Eliezer Yudkowsky would say, in the form of predictions. Those who fail to make it should be evicted, and your belief system updated.

Here are some steps we will want to follow in order to be able to track our calibration – or lack thereof:

  • Try to predict stuff you feel pretty certain about. Do it properly, as precisely as you think you can get it. It’s good to make sure to note as many measurable features as possible, such as timing and degree of certainty.
  • Do this a lot. It is a good idea to carry a small organizer/planner just for this, and mark in the day you suppose something will be due, what it is and how certain you are. Another good idea is to use predictionbook.
  • Tally up your results. You may notice miscalibration. Predictionbook sadly doesn’t help categorizing predictions, but try and do that.
  • When you notice miscalibration around a particular topic, try and understand why. Examine your motivations for optimism or pessimism, cross-check possible biases you may be subject to, and, in line with the Dunning-Kruger study, learn more about the subject.

This reads easy, but it takes some honesty and work to do well. If you start on this path, you won’t have to take my word on whether you become better calibrated, because you will have your stats to tell you that. If you’re not moving forward – by all means, reach out to me (My e-mail is in the about me page) and at the very least we can bounce ideas on why.

There are two ways in which your beliefs can be adjusted: you may change the level of certainty in your predictions, or you may change the predictions you make. Both are hard to do, but practice makes perfect.

Dunning-Kruger is misunderstood (or the importance of going to the source)

Typically, the Dunning-Kruger effect is understood as the tendency of people to highly rank themselves in areas in which they have no competence.

What you’d glean from the wording is that unskilled people rank themselves higher than skilled people.

Well, the data and graphics in the study (which you can get here) don’t lead to that conclusion. Indeed, it doesn’t address how you could discern someone who is highly skilled or not based on their self-asessment, which is what the conclusions in the second paragraph, the conclusions we’d take from the wording used to explain the effect, imply.

What does it state, though? That unskilled people are badly calibrated, and when they get better at a particular skill they can better predict their own performance.

In fact, there’s a sweet spot in the third quartile of performance where people seem to be best calibrated, whereas the best in a particular field tend to underestimate their ability.

There is another aspect covered in the paper which may be considered: that unskilled people tend to underestimate other people’s performance. So, if we don’t know the skill level of someone in a particular area, we shouldn’t really trust their assessment of other people. This is very different a conclusion from what we see in our day-to-day interpretations of this paper; because people who talk about papers and think they understand them don’t always do – they may be miscalibrated and thinking their understanding is better than it actually is.

Thus, the study steers us towards a peculiar worldview: in order to trust someone’s opinion on a subject, we should have their skills in high esteem. But in order to have a good calibration of their skill level, we should have a certain skill in the specific area. This is an argument for scholarship and erudition, learning all we can, even if it is just enough to decide who we trust. The best way to build that understanding in matters of scientific breakthrough, critical thought, situational analysis and data analysis is to go to the source.

To help everyone augment their level of competence in this area and better decide whether they choose to trust someone in a particular area, such as interpreting well-known phenomena or re-casting what we think of a particular event (or paper), it is a good practice to leave the sources used. So go, read the paper (14 pages only), and start a healthy discussion. It is the only way to improve our skill in the area, and learning who we can trust to gain new knowledge for us.

A brief note on backups

Backups are important – I guess mostly anyone has heard about that and can say at least a reason why. Avoiding loss is the main theme of the topic.

It is important, though, to pay attention to the backups we perform. Some people may know what I’m talking about: you should make your backups regularly, and check that they’re properly executed, that you can actually restore the information.

It is unusual, though to have people backing up a lot of important things. We’re mostly covered by the cloud now, although I’d also recommend local backup media, just in case.

Take some time this weekend or the next to set everything up, if you can: get some external hard disk drives, dust off your account(s) for whatever cloud data storage service(s) you’re using, and make sure your important data is backed up. Please, remember that cloud services can be broken into and can fail, just like your local media. The trick is to have several copies – redundancy.

Some items to look out for:

  • Personal Contacts
  • Important pictures
  • Important texts you may have written
  • Important e-mails
  • Your library of legally purchased software
  • The license codes for your legally purchased software (if applicable)

Also, remember that the access to the services you use on the net is important and needs to be backed up. Make sure you have a secondary e-mail set up to be able to recover your primary e-mail, or your phone set up for the same purpose. Try and enable two factor authentication whenever possible, to prevent possible data loss and identity theft. Preferably, have everything be recoverable from your phone or your secondary e-mail, don’t tell anyone about the secondary e-mail, and store the secondary e-mail’s password somewhere you won’t lose it, and without labels, and among other things that you can tell are not your password. Do not use the same password for both e-mails.

After everything is set: make sure the data you’ve backed up is accessible; make sure to refresh the backed up data every so often, even better if you set up an automatic job for that.

Also, try recovering your accounts as if you lost the passwords, to make sure the procedures really work. This may save you a lot of pain when you really, urgently need to access your accounts and the phone where you’d been logged in for so long that you no longer remember the password gets lost or stolen or broken or bricked.

You may be in for a short-term hassle, but believe me, if the day comes when you need to recover any account or service or data, you will be thankful that this bit of hassle is so cheap.

The rules for backups:

  1. Make them early
  2. Refresh them often
  3. Test them ocassionally
  4. Cover all your bases

Have a nice weekend.

To get better, start now.

It’s not uncommon to see people wanting to get better, but failing to do so. I want to address a point which dramatically increases people’s chances to improve in anything and everything they want to get better at.

Start now.

See, in every discipline, there’s a small percentage of people who are absolutely amazing; sometime’s there a single person who is overwhelmingly better than even the runner up. While there’s a lot to say about methods and techniques and aptitude they may have, there’s something that we can copy: we can start working on improving ourselves.

The Rationale

If one of every thousand people who do a particular activity, say, jog, acquire a certain level of awesomeness, like being able to run a marathon, versus none of the people who don’t have physical activity… then, while jogging doesn’t guarantee you’ll be able to run a marathon, it’s orders of magnitude a better situation to be in than having no physical activity.

In other words: In order for your ticket to be drawn, you need to buy into the raffle.

Of course, it’s much better than that; while buying into these proverbial raffles you’re usually already winning: getting fitter, living healthier, working better, getting closer to your goals. The sooner you start, the faster you get there. And if you manage to start now, it means that you’ve managed to value your long term goal over short term comfort, which is something you will need to do time and again in order to become ever more awesome.

The Method – or one of them, anyway

Think about the first thing that comes to your mind that could get you closer to your goal. Start doing that unless you find something better to do.

Think about your goal. Imagine you’re already there. Now backtrack: what did you do to get there? It’s a good excercise to find better next steps.

Think about any kind of person with legendary performance in what you want to improve. Maybe you’ve read about their lives. Maybe you think “It’s too late”, or “It doesn’t apply”, because they somehow got a headstart. This advice still applies, because while you may not become them, you will become a version of yourself you will be happier with.

A little example:

When you think about a master martial artist, think about their method, their story, and think: if they’d been in your place, what could they have done? Maybe start doing just five push-ups every day, so that you can work all the way to Bruce Lee-style, two-fingered push-ups. Even if you never get there, you’re bound to wind up much better than you are right now.

Rethink your strategy every once in a while. Not for giving up, mind you, but to accelerate or maintain the rate of your improvement.

If you’re not getting any better, if your goals aren’t any closer – it’s healthy to take as objective a measure as possible of every performance indicator to find out about this – well, then, it may be time to change your approach radically. I suggest you only give up if your life is going to be better for quitting.

Start now. If you make mistakes, start correcting for them as soon as you take notice. Every little victory gets you closer to your goal, and recouping the little defeats that we inevitably accumulate helps you keep up the pace.

HATEOAS (or: Why your API is not RESTful)

Developers who work on Webservices or any kind of API have most likely heard about the RESTful architecture for APIs.

There is a huge misunderstanding on what it takes to make an API comply with the “RESTful” specification. In part this is because the specification is ambiguous on several points, but what I’ve seen is that there’s a huge amount of misinformation and mislabeling out there.

So, many developers have worked on APIs which respond to HTTP verbs (GET, PUT, POST, DELETE), and operate on resources, CRUD-style, and think that’s what it takes to “be RESTful”. And that’s misguided; merely doing that is not enough. Enter HATEOAS: Hypermedia As The Engine Of Application State. Or: You send “hypermedia” in your responses.

Hypermedia is not something recent developers think a lot about, but have grown up with. It’s a concept of diferent “media” (text, audio, video, images) referencing each other. The references we use are hyperlinks.

In other words: HATEOAS means that, just like when you serve a regular webpage developed in any programming language, you send links pointing to the different URLs where actions can be taken. Indeed, this means that the client application (e.g.: a regular web browser) doesn’t need to have knowledge about the server application’s (e.g.: a regular website’s) structure or organization beforehand, but can invoke its behaviour through access points (e.g.: URLs) sent in the server’s response.

The state of the interactions with the server is, then, contained in the response. To keep it up with the browser+website example, the current state of your interactions with the server is implicit in the html, css, and javascript that the server sent your browser.

What does this mean?

A simple way to state it is that your application should be discoverable from a  single endpoint… just like everything you can do on a website you can discover from going to its main page, without looking at the developer’s documentations. If this condition is not covered, then your API does not conform to the RESTful ideal.

If you’re curious, here’s the paper which first describes REST.

A few more words:

  • REST means “REpresentational State Transfer”. If you Transfer some data (resources, for instance) from the server, but not the operations that can be excercised on it from the state the client expressed in its request, are you transfering State from the server to the client?
  • CRUD-style applications are not the only thing that can be done with RESTful APIs. If this looks weird to you, then it’s a great time to read upon the subject.

Thanks for your attention, more content Tomorrow.

Using GitHub without knowing Git (or: Crash Course on Some of Github’s UI)

The article I wrote Yesterday with tips to cement your knowledge of programming touched upon collaboration with OSS projects on GitHub.

I realize many people will have some difficulty getting started on that, and one of the roadblocks lays in not knowing how to use git. I want to remove it in a simplistic, yet effective way.

Behold, for this is very, very bad to do on large scale (more on that later), but very effective for jumpstarting small work.

We will use the GitHub website to do all our git-related work. We won’t even need to install git.


Find something you want to hack on. In the previous article (link at the beginning of this article) I wrote of a way to find hackable projects in GitHub.

Step 1: Getting the source

After you’ve found your victim (I recommend you use the repo I set up for this purpose), notice that you have the option to download as a zip.

"Download as Zip" button highlightedThis will allow you to download a copy of the repository’s actual state (ie: not the history of the project, but it’s current version).

Take this moment to fork the project, too. It’s the button that says “Fork”, located (at the moment this is being written) at the top right corner of the project’s page.

When you download this, make sure you can get the project to work. That is, compile it, and run the tests (if any), and run the executable. If you find any issues, try to find a solution around them. Read the docs. If the docs don’t cover the solution, and you find it, try to put it in the appropriate file.

If for some reason you think the issue is a project issue, then by all means open an issue. But please, be sure. It’s not fun to have a dozen non-issues, but having them may point out a lack in the documentation.

In any case, if you change any source file in this process, including the documentation, pay heed to step 2.

Step 2: Changing a file

Your improvement to the project will need a change of files. Possibly several changes. Now, there’s a limitation with this approach, and it is that you can only register changes (commit) for one file at a time. If you had git installed in your computer, you would not have this limitation. If you need to change several files for one single logical change, please, learn git first, this is a poor substitute.

Carrying on: if a change implies only one file, you’ve hit the jackpot. A change is a concrete, self-contained unit in this case. For instance: you update the documentation by changing the file, and that’s all you had to do to “cover scenario X and Y”, as opposed to “changed the file x” and then “change the file Y so that now the project builds properly taking into account the change in file x”, which is not nice.

A feature you want to add may require intermediary steps which don’t leave the project broken; in that case, those are several changes – some may be cosmetic, some may be refactors. Commit each separately. This applies if using git to commit several changed files at once: simultaneously commit all the files that you need to in order to leave the project in a better state than you found it. It’s a good practice, grouping the physical file changes by logical steps (ie: first commit to fix indentation, second commit to refactor some functionality into it’s own function, third commit to include new functionality).

It is important to build the project and run all the pertinent tests every time you will commit.

Oh right, to commit:

Go to your fork of the pcommit button in github file pageroject, which you can find in your profile, under the tab “Repositories”, and browse for the file you have changed locally. Select it and click the edit button. Now, copy and paste your file into the text area. In the case of Markdown files (like, this will be a good place to make the change, because it allows you to preview your changes. Otherwise this is not such a good idea and you should be careful. When you finish, write a comment – a clear one-liner of what you did, and a longer explanation below. The form’s shape will guide you.

Choose the “commit directly to master branch” option, and go to your fork of the project.

Step 3: Do Not Mess Up

Download the project again, make sure you’re downloading your fork of the project. Get the project to work. If it works just like your originally modified copy, you did well. Otherwise, you messed up. Try again. Project maintainers will not like the repeat commits, though, so be extra careful. Or learn how to use git. In case you didn’t mess up, it is time to open a pull request.

Step 4: Open a Pull Request

This one is straightforward: go to the original author’s repository (where you Forked from in the first place), and open a pull request by clicking the green “New Pull Request” button.

You may need to press the link stating “compare across forks”. On the selection screen, make sure the author’s repository is the “base fork”, and yours is the “head fork”. Then press the “Create Pull Request” button.

After the Pull Request is resolved (the author may ask you to do some additional changes on your fork), you can safely delete your fork.

This is a quick and dirty way to work with OSS. It will only be useful for trivial changes, like fixing typos or grammar, or other single-file, easy-to-test, hard-to-mess-up changes.

Please, take some time to learn git. This is a good way to get to know GitHub’s UI, though, so feel free to abuse the repository I created for the purpose. I’ll try and check any issues and pull requests as often as possible. I recommend trying to improve on the meager file as practice.

Tips to Cement your Knowledge

There’s a particular joy in learning something (a programming language, how to use a tool, an algorithm), then perfecting it through practice and teaching.

Today I’ll talk of two ways to do both things while building your programmer cred and helping the community. Also, it’s very likely that you’ll hone additional skills while engaging in these activities.


Make sure you learn your tool, task, or algorithm properly. Understand the tradeoffs and caveats. Get it to break a couple of times in different ways, so you get a feel for failure modes. Once you find yourself feeling confident enough, carry on.

Method #1: Hack on random people’s projects

GitHub is a great place to be at. If you find another place like it, please let me know. The main feature here is discoverability. Some months ago I was preparing a talk about a particular module of python’s standard library, argparse.

My main use case for python is writing tools for myself, so I use argparse often. But to make sure I didn’t have the wrong end of the stick, I went into GitHub and looked for python projects which may need argparse. How? I searched for “argparse”, and filtered by issues.

Like this:

github argparse issue




You can further filter for the open ones, which is what you’d want for the excercise. Which is get into a project, read up on it, clone it, add argparse support, and open a pull request. Rinse and repeat a couple of times.

Then follow through: you’ll probably be asked to make some changes, maybe document the usage (if you changed the way the tool is used), maybe write some tests. Ideally, you’ll get the hang of it and start looking for the right things when trying to contribute to more projects, thus needing a fewer interactions for the one feature you learned how to implement to get into the projects which need it.

This helps you grow as a software developer and as a communicator, thus, as a contributor to open source projects. Besides honing your ability to implement whatever you chose to learn.

Method #2: Get involved personally

Find a local user group, and prepare a talk on whatever it is you learned. Teach it to people personally. If not at the local user group, then maybe at school, or at work. Pass the knowledge on, and make sure to note any and all questions that come up, especially if you don’t know the answers right away.

This will help you cement your knowledge, and hopefully earn you a reputation for knowing, teaching, and being cool in general. If there are no local user groups, or for some reason you can’t get involved as much as you want to, consider writing on the subject.

Hopefully someone will stumble upon it when they need it, and that’s more than you bargained for when just learning. Additionally, this kind of public writing gives you some cred.

Just please, please make sure you learn what you want to teach. Don’t copy and paste, and don’t pass along partial knowledge.

A bonus tip: if there are knowledgeable people you can reach (personally, through e-mail, through IRC), then reach out and make sure you have your facts straight. Read the docs. Write code. Only then pass it on.