The best study habits according to science

I am studying for the AWS Certified Developer – Associate certificate, and I don’t have all the time in the world to study. Needing more bang for my studying buck, I searched for study tips based on Cognitive Science and Psychology. These tips are new – at least, new to me. And they are powerful. Here they are:

  • Put a positive frame on your notes.
  • Read your notes out loud.
  • Speaking of reading your notes out loud – try to engage all five senses when studying. (Sometimes you can’t engage every sense. For example, I’m not going to go out and taste an AWS server. But I can engage my sense of sight and sound when studying.)
  • Have you ever read something, written it down word for word, and promptly forgotten it? A great way to prevent this is to read, rephrase, then write. Rephrasing forces your brain to pay attention.
  • Change Up Your Study Spaces for Better Recall

Happy studying!

A Study Tip Based on Cognitive Science

When Nixon said “I am not a crook,” Americans saw him as a crook.

Because negating the frame activates that frame.

I am studying for the AWS Certified Developer Associate exam. And I realized that I have been taking notes all wrong.

I caught myself writing “ObjectNotFound is not,” and stopped. I stopped and crossed that out.

Just like “Don’t think of the elephant” makes you think of elephants, “No AWS data center is cold” makes you think that data centers are cold. Our minds forget the negative word “no,” and are left with a strengthened memory of data centers being cold.

To remember that all AWS data centers are warm, write that all AWS data centers are warm. Through repetition, your brain will come to associate “AWS data centers” with “warmth.” That’s what you want. You don’t want your brain to associate “AWS data centers” with the word “cold.”

And we can throw in a little repetition for good measure. So repeat after me. “All AWS data centers are warm.”

Phrasing notes in the positive will make it easier to remember the correct info. And that will cut down on required study time, it will improve test scores, and generally make life much easier.

Jerry and Larry Know How to Focus

“Let me tell you why my tv series in the 90s was so good, besides just an inordinate amount of just pure good fortune. In most tv series, 50 percent of the time is spent working on the show, 50 percent of the time is spent dealing with personality, political, and hierarchical issues of making something. We spent 99 percent of our time writing. Me and Larry [David]. The two of us. The door was closed. It’s closed. Somebody calls. We’re not taking the call. We were gonna make this thing funny. That’s why the show was good.” – Jerry Seinfeld,

Always Leave a Note

Today I would like to share a helpful little tip. It will help you avoid problems in the future. But first the backstory.

My team is new to the company. Our average tenure with the company is about six months. And with a new team, it always takes time for the team to bond. And we’re doing great.

Anyway, to establish some norms, we use Working Agreements. Working Agreements can be helpful if done right.

We keep Working Agreements short and sweet. Three to five is plenty. And we review them during Sprint review. We ask questions like “are we living up to them,” and “are they helping.” And we have seen a lot of success from working agreements.

One of our Working Agreements states that we need to peer review pull requests within two days. How awesome is that?

I opened a pull request which took a manual process and automated it to cut toil. Don’t get me started on toil. For now, suffice it to say that toil is terrible and eliminating toil is good.

Unfortunately, the manual task got ahead of the code as the pull request waited for reviews. I had to update the pull request again and again.

That’s usually a preventable problem, but sometimes it’s not. If you can’t prevent it, at least leave yourself a note. When you create a pull request, leave a note at the top of the pull request description. It can be short and sweet. “Don’t deploy until I update foobar.” Or “not safe to merge until we merge that other thing.”

That little trick will allow us to avoid problems. Have you noticed that the best engineers have the best habits? That’ll be a blog post for another day.

API Development: Additive, not Subtractive

“It’s important to think of API evolution in terms of growth and increasing flexibility. Graceful API evolution is additive in terms of functionality, and subtractive in terms of requirements. While change is inevitable, planning for a graceful API evolution is a good way to minimize changes that break things. For example: required input may become optional, but not the other way around.

Here is more.


The Big Picture: Big changes need big focus.

Let’s talk about focus today because the ability to focus is a superpower. We used to call it sticktoitiveness.

I’m going to talk in pretty general terms today. But this applies to software engineering and leadership.

So let me tell you some stories.

Finance in College

When I was in college, I was somehow struck by an all-consuming passion about the stock market. I loved it. I loved everything about it. It was an “eat, sleep, and breathe” kind of thing. I would read all the time. I would read 6, 7, or 8 hours a day. I would check out dozens of books at a time from the library. I read academic articles, I read textbooks, I read popular nonfiction books.

I was totally consumed. I was able to turn that focus into something amazing – ten years of self-employment. That was such an incredible experience.

Speaking for myself and the typical student – you can get away with a lot of irresponsibility in college. I was able to ignore distractions and focus. Finance took over 80% to 90% of my time.


Fast forward a few years, and I am ready to move on to something else. When I was wrapping up my career in finance, I was scattered and not sure what to do. And I still needed to spend time on finance. So I studied different things in my free time. Here a little, there a little.

This went on for months. And nothing came of it. I didn’t get really good at anything.

Software Engineering Apprenticeship

One day I wised up. Tired and frustrated, I realized that I needed to get good at something. I needed to focus.

Software Engineering looked good. A friend in Florida offered to teach me. Within a couple of weeks, I accepted. I packed up my apartment in Los Angeles, I shipped my car, and I bought a one way ticket to Florida. I was going to be Software Engineer apprentice with one of my good buddies.

I was one block away from Beverley Hills, surrounded by beautiful cafes and bakeries. I moved to the marshy swampland just south of Orlando. Imagine that. It was a huge change. From French cafes to a dirty Wal-Mart. From Teslas and Maseratis to rusted out pickup trucks.

I only knew one person and I wasn’t making any money. It was an unpaid apprenticeship. But it was such a fun experience. And I was able to put 80-90% of my time an focus and attention towards learning Software Engineering. It’s hard to focus in Los Angeles. There was always a new restaurant to try, a new place to go, a new thing to see.

Anyway, I put 90% of my time into software engineering. And I got really good, really fast. (If I do say so myself) I was building side projects on my own within a couple months. I went from zero to side project in 2-3 months. I got a full-time paid position within a few months.

I have had a great career so far. And I attribute most of it to my focus in the early days. Since that first job, I have been a Team Lead, I specialized in DevOps, and I built many side projects. And I’m just getting started.

It is so much easier to get good at something when you can focus on it. 5% here, 5% there, is a sure way to make yourself frustrated. You won’t see any real progress.

So for those who don’t have much going on, that is a good situation to be in if you want to make a change. It is hard to make changes. It takes a lot of activation energy to build something new or start something new.

If you have 5% here, 5% there, it might not even be worth it to try. It might be more profitable say no to 5% things until you have enough time to focus.

Let’s end with a Warren Buffett quote.

“The difference between successful people and really successful people is that the really successful people say no to almost everything.”

Slow Down

Asymmetric payoffs

Heads, you break even. Tails, you lose. Would you take that deal? Heads you break even, and tails you lose?

That’s a terrible deal. We should avoid that at all costs. So let me talk a little bit about that in terms of software engineering.

In software engineering, people want reliability and consistency. With any other kind of engineering, it’s the same way. We want our cars to just work. We want our computers to just work. People do not want to hire software engineers who break production. I think that’s about as universal as you can get.

People will vividly remember fixing production, reverting pull requests, and stuff like that, and they will not be happy.

So what we need to do is focus on reliability and consistency.

There is not going to be much benefit to rushing, because people mostly won’t notice. And there is going to be a pretty big downside to rushing. Rushing is bad. Rushing increases the odds of mistakes.

Caution and measure will win you treasure.

Say, one day, you rush something out a couple hours faster than expected. Does anyone notice? If your company is like most companies, no one notices.

Essentially you are rushing for no benefit while increasing that odds that you make mistakes.

People will not remember if you do something one hour faster than expected, but people will remember the dumpster fire you caused by pushing broken code into production. And people will see that it takes you twice as long as everyone else to get your code through quality assurance.

It is much easier to avoid mistakes than to cover yourself in glory by rushing.

Companies lose money, companies lose customers, and companies look bad when things break. So we really need to put more emphasis on avoiding mistakes. And that will benefit our careers as well.