The purpose of this post is to answer: “when do I use or not use the Turkish accusative?” Most resources on the accusative describe it as a case ending applied to a definite direct object. Some say it’s the equivalent of when you use “the” in English. I found these definitions to be vague and often actively misleading.

Much of this knowledge is thanks to the Türkçe Öğrenelim Discord. Feel free to join the community and support them on Patreon.

Prerequisites

This post is not intended for complete beginners of Turkish grammar. It will not explain any constructions or cover the basics of the accusative; there are ample other resources.

Why this post?

Finding a comprehensive resource for the accusative tops the list of my frustrations in learning Turkish (thankfully the Discord exists). I haven’t found a single public resource on the internet that goes in-depth into accusative usage. All of them try to summarize it in a single sentence by providing some type of rule or guideline – this guideline is usually ambiguous or incomplete. That is to say, if your goal is to use the accusative in all scenarios without making mistakes, no existing online resource achieves this.

My hope is that this article will get you close to there, though I can’t promise that I know Turkish well enough to cover all cases. The most thorough resource that I know would be the discussions in Turkish: A Comprehensive Grammar. I’d say, however, that one gets too detailed at some point. It’s worth a read if you care about this though.

Examples of incomplete accusative definitions

Below are some examples from different sources in defining the accusative. I’ve included these to contrast how trusting these definitions can lead learners astray. Thinking of the accusative as the case for definite direct objects is not incorrect, but it certainly isn’t comprehensive. The purpose of this article is to cover cases where the “direct object” definition does not suffice.

• “Nouns that are affected by the action of a verb use the accusative case.” (Turkishaholic)
• “In Turkish, the direct object gets a suffix when it is definite. The direct object is definite when it refers to a specific object or a specific collection of objects that is known to the addressee.” (elon.io).
• “This is used for direct objects - the object that is receiving an action (the apple begin eaten, the wine being drunk, etc.). Note that cases only apply for things that have “the” in front of them in English (as the nominative covers ones that don’t).” (Duolingo Wiki – ew)

With plurals

The definitions above all seem to apply that the accusative provides specificity, but with plurals, its role is reversed. For most cases, adding the accusative makes a plural general; the lack of accusative makes it specific.

To put it another way, to express a general group, there are two options: plural with the accusative or singular nominative.

Plural accusative vs singular nominative

Insanları tanımayı seviyorum.
Insan tanımayı seviyorum.
I like to get to know people (people, as a general group).

---

Gömlekleri sever misin?
Gömlek sever misin?
Would you / do you like shirts (generally speaking of shirts)?

A plural without the accusative is specific:

Plural without accusative, specific

Dün ona yeni gömlekler aldık.
Yesterday, we bought some new (specific) shirts for him.

However, there are some cases where plural accusative is specific rather than general. I’m actually not sure what the rule is that distinguishes the example above or below. If you know, then please let me know, and I’ll update this section.

Plural accusative, specific

Gömlekleri sevdin mi?
Did you like the (specific) shirts?

Overall, this counters the oversimplified definition that the accusative is used to mark a definite object. The definition of the accusative as parallel to English “the” is especially egregious to me.

To close it off, as expected by the simple definitions of accusative, using it with the singular makes the object specific, not general (note that there are again exceptions that are so detailed it’s not worth mentioning here, see Turkish: A Comprehensive Grammar 22.4.3):

Singular accusative vs singular nominative

Gömleği sever misin?
Would you / do you like the (specific) shirt?

---

Gömlek sever misin?
Would you / do you like shirts (generally speaking of shirts)?

This discussion on the Turkish Discord is useful (and this section is borrowed from there).

With numbers

Most beginners of Turkish learn the rule, “no accusatives with bir or numbers.” However, this turns out, again, to be an oversimplification.

Indefinite numbered items

Bir çocuk gördüm.
I saw a child.

---

Iki kitap aldım.
I bought two books.

Referring to specific objects in context

The accusative can be used with numbers when referencing a specific object that is previously referred to in context.

For example, when you delete a message on Facebook, it says: “Bir mesajı sildin.” You had previously clicked this message; you know exactly which message is being deleted.

As explained on the Turkish Discord:

Accusative with bir

Bir mesaj sildin
You deleted a message (just any message)

---

Bir mesajı sildin
You deleted a message (that specific one)

Another example adapted from Turkish: A Comprehensive Grammar, 14.3.3.2, uses the accusative when the books were referenced and known to the listener as part of the first sentence, which can be thought of as a form of definiteness.

Referencing items in context

Kitaplarımı bana verdi, ama iki kitabı unuttu.
He gave me my books, but he forgot two of them.

With the possessive (but not compound nouns)

When using the possessive with a number, it will still take the accusative.

Possessive, number, and accusative

Bir kıtabımı ona verdi.
I gave him a book of mine.

Note that without the possessive, there is no accusative:

Non-possessive with number

Bir kitap ona verdi.
I gave him a book.

With question words

The accusative form of question words such as ne (“what”) and kim (“who”) will occasionally be seen. This can be used more specifically in place of a word that would normally take that spot in the sentence with the accusative. It often makes sense in response to somebody.

Examples

Ne yaptın?
What did you do?

---

Neyi yaptın?
You did what?

---

Kimi aradın?
Who did you call?

---

A: Zaten biliyorum.
I already know.
B: Neyi biliyorsun?
What (exactly) do you know?
A: Bu bilgiyi biliyorum.
I already know this information.

In the last example, I don’t think that saying “ne biliyorsun” would necessarily be incorrect, but neyi offers a certain amount of precision, in response to the verb (biliyorum) that speaker A used.

With verbal nouns

For example, when using any verbal nouns, such as yüzme or yaptığın, these will take the accusative if the verb requires it. As far as I know, these will not appear without the accusative (again, under the “direct object definition”, this was confusing to me. What does it mean for a verbal noun to be definite?)

Examples

Yüzmeyi biliyorum.
I know how to swim / I know swimming.

Almost all Turkish learners will learn how to express wanting to do a verb. This could be considered to an exception to the verbal noun accusatives above (since the infinite is considered a noun). However, there’s an exception to the exception!

When another word appears between the infinite and istemek, then it takes on the accusative -mA form rather than the infinite.

istemek can take the accusative

Seni dövmek istiyorum.
I want to beat you up.

---

Seni dövmeyi çok istiyorum.
I really want to beat you up.

Accusative and distance from the verb

This is actually a more general rule for the above. A word cannot be in the nominative and far from the verb. For example, observe the insertion of the word çok below and in the previous example.

Wrong

Kedi çok seven bir köpek
A dog that loves cats

Correct

Kedi seven bir köpek
A dog that loves cats

---

Kediyi çok seven bir köpek
A dog that really loves cats

“You just have to know”

There are some cases where you just have to know that the accusative is required or not. For example, as a foreigner, one of your most common phrases:

A common phrase

Türkçe biliyor musun?
Do you know Turkish?

---

Türkçe biliyorum.
I know Turkish.

It does not use the accusative. Why? I’m not sure if there’s a sensible explanation. To me, it makes more sense that Turkish is definite here; it refers to a specific language, Turkish. But this is simply the way it is: there is no accusative.

In another example put forth in the Turkish Discord, the opposite is true with the verb sevmek. The accusative would be used here this time to refer to the Turkish language specifically. It would be incorrect to drop the accusative here.

Accusative with sevmek

Türkçeyi seviyorum. I love the Turkish language.

But it can also be used without the accusative:

An explanation in the Discord

“Türkçe seviyorum” could be used in a context where you like doing something IN Turkish. Like “in which language do you like watching series?” You could say “Türkçe seviyorum.”

Conclusion

This is by no means meant to completely cover the cases of using or not using the accusative, but hopefully it clarifies specific situations where the “definite direct object” definition is insufficient.

Finally, even if you don’t get these correct in speech or writing, don’t sweat it: what you want to express will probably be understood. Language is approximate. People definitely aren’t writing in perfect grammar on the internet – go check out some Turkish YouTube comments.

Goal

The problem that I’m describing occurred in the process of creating Memm, a tool for studying for the MCAT.

The goal: move blog.memm.io => memm.io/blog (apparently better for SEO purposes).

• memm.io: runs on Next.js
• blog.memm.io: hosted on Amazon S3, using Gatsby

I want memm.io to continue hosting the main site, while only paths under memm.io/blog will actually point to a different underlying endpoint, e.g., http://MY-S3-BUCKET.s3-website-us-west-2.amazonaws.com/.

Problem

When navigating to memm.io/blog and clicking on a link, everything worked fine. However, if the page was refreshed at memm.io/blog/my-slug, it would redirect to memm.io/my-slug. This also meant that linking directly to a blog post would not work, changing the path strangely.

Additionally, my Gatsby had its pathPrefix config set to /blog, which meant there were a variety of static assets that were supposed to be loaded (e.g., http://MY-S3-BUCKET.s3-website-us-west-2.amazonaws.com/foobar.css) that were similarly 404ing due to Next.js’s strange rewriting behavior.

This is a problematic next.config.js (see Next.js documentation for where this goes).

async rewrites() {
  return [
    {
      source: '/blog/:slug*',
      destination: `${BLOG_URL}/:slug*`,
    },
  ];
},

Solution

This leverages a new feature supported in Next 9.5 and above called rewrites.

We’ll explore more in depth why this is happening, but since most people reading articles just want the solution, I fixed it with something like this in my next.config.js

{
  async rewrites() {
    return [
      {
        source: '/blog/:slug*/',
        destination: `${BLOG_URL}/:slug*/`,
      },
      {
        source: '/blog/:slug*',
        destination: `${BLOG_URL}/:slug*`,
      },

    ];
  },
  // Causes next.js to add trailing slashes to end of URLs.
  trailingSlash: true,
}

Using withCss, withSass, withLess

It should also be noted that my next.config.js uses Ant Design, and therefore it has a bit of fiddling with the CSS/Sass/Less loading. In another possible bug with the @zeit/next-css package, trailingSlash does NOT work within the nested withCss call, although strangely rewrites works. This is probably also a bug given that rewrites works but trailingSlash doesn’t, although I didn’t file it – withCss is technically a deprecated package; they shouldn’t be expected to support newer features of Next.js to be compatible with it.

Note how in the code below that rewrites is within the withSass but the trailingSlash must be outside of the withCss call in order to work.

const withCss = require('@zeit/next-css');
const withLess = require('@zeit/next-less');
const withSass = require('@zeit/next-sass');

const BLOG_URL = 'http://MY-S3-BUCKET.s3-website-us-west-2.amazonaws.com';

module.exports = {
  ...withCss(
  withSass({
    ...withLess({
      // Other stuff...
    }),
    // https://nextjs.org/docs/api-reference/next.config.js/rewrites#rewriting-to-an-external-url
    // https://github.com/vercel/next.js/issues/14930
    // In the end, we need this with trailing-slash to work properly. Otherwise
    // it does a 302 and when you refresh blog pages it messes up.
    async rewrites() {
      return [
        {
          source: '/blog/:slug*/',
          destination: `${BLOG_URL}/:slug*/`,
        },
        {
          source: '/blog/:slug*',
          destination: `${BLOG_URL}/:slug*`,
        },

      ];
    },
  })
  ),
  trailingSlash: true,
};

Cause

I’m still not 100% confident in my explanation of the issue, but I think it goes something like this:

• Next.js by default removes a trailing slash when it doesn’t exist, according to the trailing slash documentation. That means memm.io/blog/ becomes memm.io/blog under the default settings.
• Amazon S3 in contrast, does a 302 redirect when there is no trailing slash. I think that Next.js rewrites doesn’t play nicely with 302. This is also mostly unconfigurable: see this StackOverflow question

Somehow, with the problematic config, this causes two redirects that causes Next.js to remove the /blog/ from /blog/my-slug and simply go to /my-slug. It’s possible this is a bug with Next.js rewrites, but it could also be an intended interaction given the quirks of the two opposing redirect rules.

This article contains advice for students in different stages of their programming career, from entering the bootcamp to landing their first development job. It describes some keys to success:

• As a bootcamp student
• As a programmer
• As a job applicant
• As an employee

My hope is that this will be a resource for all students of the Re:Coded bootcamps (and possibly other bootcamps, but it’s catered to my experience).

For the students: as with all improvement, simply hearing or reading it once isn’t enough to build good habits.

Table of Contents

• As a bootcamp student
  • Learn to read technical writing
  • Stop watching so many videos
  • Be emotionally aware
  • Don’t compare yourself to others
• As a programmer
  • Be able to explain every variable
  • Stop assuming
  • Learn to spot the difference
  • Focus on debugging skills
• As a capstone project member
• As an employee
  • Do a good job
  • Seek new things
  • Don’t be overly eager for the first opportunity

As a bootcamp student

Learn to read technical writing

From the first day, students should focus on their technical reading skills.

In programming, videos will bring learners 30% of the way there on basic concepts. But after a certain point in the journey, videos won’t even be present for topics one has to research. Software development is a heavily reading focused process: when leveraging a new library, working in a framework, understanding an application with private code, and so on.

I’m not saying that videos shouldn’t be used at all; they are excellent at teaching the foundational concepts (see the next section for caveats). However, many students skimp on improving reading skills, thinking that the dream of learning from videos will carry on forever. Reading skills must be developed in parallel.

There’s a reason that programmers want people to RTFM, not WTFV.

Stop watching so many videos

To learn football or piano, can this be achieved by mostly watching videos? Coding is no different.

Videos are good for introducing basic concepts. They are also good for building familiarity when typing alongside the video. But after a certain point, improving isn’t about watching more videos: it’s about doing the activity (coding) and identifying mistakes (see the debugging skills section). This is the general loop in all skills, not just coding.

It’s no coincidence that the students that plateau the most are the ones that are adamant about watching videos, repeatedly reaffirming that they learn better by watching videos (a statement true for most of the population). In the finite time available in the bootcamp, it takes away from the time to practice application.

Students frequently tell me this: “I understand the concepts but I’m having trouble when I actually write code.” At this stage, the solution is not to watch another video to reinforce the concepts; it’s to practice writing the code (though arguably the first step could be done by following step-by-step from a video). There is no substitute for writing code.

Even though most students seem to understand that piano and football can’t be learned by watching videos, I believe that, because coding happens on a computer, some get stuck in the video mindset, making it feel different from other “tangible” skills such as instruments. Hey, we do real things with our keyboards.

Be emotionally aware

I encourage all students to think carefully about the best ways they can support their peers’ experiences. The bootcamp can be a stressful experience for a lot of students. Students grapple with their own self-image and ability to learn, and each student plays a role in impacting the experiences of others through their actions.

Let’s take, for example, the phrase: “this was easy.” In my opinion, even if the activity was actually easy for the student, an emotionally aware but advanced student would focus on the hard parts nonetheless – showing even the struggling students that each person has difficulty with something.

This is simply one example, and it doesn’t imply that students shouldn’t present advanced work or express their opinion, but often there is a clear separation between students who are aware of how their behavior affects the mentalities of the rest of the class and those who are not aware. Students should consider how their words may affect other students’ mentalities. The goal is to create a better learning experience for all students.

Don’t compare yourself to others

Comparing yourself to others is usually unproductive. While it’s a natural reaction, try not to do it.

Everybody can compare themselves to another person. When you start programming, there’s already somebody who will learn faster. When you get your first job, there’s another entry level developer out there with a higher salary. Simply focus on improving yourself.

As a caveat, comparisons can be productive, but this depends on your personality and mindset. In my experience, the comparisons that my students make are mostly not productive.

Productive: “This person is doing well. I’m inspired. I’m also going to strive to reach that level of skill.”

Not so productive: “This person is doing well. I feel really behind and unsure, I’m not sure if I’ll be able to do this. Everybody else does it better.”

As the CS50 course says on one of their very first slides: it’s not about where you end up relative to your peers, it’s about where you end up relative to where you started.

As a programmer

Be able to explain every variable

When code isn’t working, I advise students to strive for this state: if I point to some part of the code, the student should be able to correctly explain the type and the approximate contents of every variable.

One of my most common questions to students is this: “What does this variable contain? Is it a string, a number, an array, an object?” Especially in the early parts of the bootcamp, I usually receive the wrong answer.

Take it slowly: students should build an understanding of each variable’s contents, double-checking that understanding with logging. For students that feel they are plateauing, I advise them to achieve a more intimate understanding of their own code: make sure that every variable’s value is understood. See the next section about assumptions.

Stop assuming

Don’t assume that the code or variables do what they should be doing, and use the console liberally.

All programmers are familiar with this sequence of events: after a long period of debugging everything else, even though you were so, so, so sure that this variable contained some value….well, it didn’t. It had something else.

When I help students with activities, one of my most common actions is to simply tell them to log a certain variable, and that generally sets them on the right path. But there’s nothing magic about this; it’s simply that I don’t assume the variable is working as intended. Often, the student chose not to log it because they assumed that a variable contained something without checking it themselves. The instructor simply went “to double check.”

I often say that programming is a humbling art: when we debug, we have to assume that we are wrong, revisiting our own mental image of the code.. One of the most poisonous thoughts can be being overly sure in yourself: “I’m sure this variable contains X, nah…no need to check it,”

Learn to spot the difference

In coding, where we often work with example code or existing code, “understanding the difference” between two pieces of code is a crucial skill.

I explicitly draw attention to this skill because developers leverage this frequently. For example, when reading the documentation for a library, looking at code on StackOverflow, using teammates’ code as a guideline, etc. All of these will ultimately involve “spotting differences” in code, whether to fix or adapt.

Examples

• My function is giving a syntax error, but the function in the demo works. What’s the difference?
• One of my pages is working, but the other is not. But they have the same structure. What’s the difference?
• This example code works, but my code doesn’t. What’s the difference?

Sometimes spotting the difference can be as small as a single character. Sometimes we can’t be sure if the difference is the cause of an issue. But the mentality here is to be suspicious of everything; any perceived difference could be the cause. I often hear this: “I saw this this difference but I didn’t bother to investigate it, it couldn’t have been that!” From the last section, we know how this turns out. Don’t assume.

Focus on debugging skills

Debugging skills – finding mistakes in code – are extremely important in programming. Many students begin with the misconception that the majority of programming is about writing code and later fixing a few small mistakes here and there. The truth is usually the opposite: most of the time is spent fixing mistakes in the code!

Debugging is a methodical, iterative process in which we learn from our mistakes. I encourage all students to put in an active focus in improving their debugging. I write this because it’s often something that students passively develop, but I want to highlight an explicit focus on debugging skills here. Take every bug fix, and try not to repeat the same mistake.

This is related to why videos are limited in their helpfulness. Videos usually teach how to write code for a certain concept, but they don’t focus on the correction of mistakes. See this StackExchange question on effectively debugging code.

As a capstone project member

After the first three months, students participate in a “capstone project” with sprints and code reviews, managed by a lead engineer from Re:Coded. This is meant to mirror the real development process.

I will simply share the mental checklist I go through when I evaluate a student on the capstone projects, in order of most important to least important (though all of them are important).

1. Did they learn from their mistakes in code review and pull request preparation, infrequently making the same mistakes?
2. Did they review their peers’ code thoroughly and in detail, applying principles from their own code reviews?
   • Or are most reviews simply one small comment followed by LGTM?
3. Did they respond in a timely manner as both a reviewer and reviewee?
4. Do they habitually proofread their code reviews after asking for a review?
   • Or are log statements, wrong newlines, failing tests, typos, etc. frequently present?

Answering no to any of the main four questions above indicates an area of improvement. In my eyes, how well a student did in this project essentially maps to “how much yes” or “how much no” for the answers above (nobody is perfect).

All of these are less about technical knowledge and more about the care one takes in their work. This type of quality and attention is noted in the workplace.

As an employee

Do a good job

There is no substitute for doing good work and achieving results at a workplace. Focus on excelling in work – writing clean code, being a good communicator, being a good teammate – and it will open up more opportunities.

Somebody who does good work is valued. And somebody who is valued generally has more agency in their life – agency to choose a team, a company, a project, and to some extent, a salary.

Seek new things

Say yes to new projects, new technologies, new teams. This will pave the way for being a well-rounded developer.

After “learning to learn”, one should embrace the challenge of learning a new technology or framework. Over-comfort should be discomfort; it’s a sign that it’s time to go seek new knowledge. Nobody wants to be doing the exact same thing for 25 years.

Of course, there are a few caveats, such as a draconian boss that wants to milk 18 hours a day from you, career risks from moving to new teams, and so on – but to have a fulfilling career, one should keep the general principle in mind.

Don’t be overly eager for the first opportunity

Know your value. A lot of my students, even the ones that excel highly in the course, have the mindset that they’d love if someone offered them a job. When I hear this, I worry that they might simply snap up the first job that they’re offered, consequnetly giving up on comparisons with other opportunities on culture fit, learning opportunities, or salaries.

Keeping this mind, I encourage students to understand their worth and make their best effort to explore options, rather than immediately settling for the first. While we should all be grateful for the opportunity for employment, my graduated students are often surprised by the level of demand for developers. In short: you’re probably more valuable than you think you are (economically speaking).

As a disclaimer, this is completely dependent on the person’s financial and life situation. In this particular case, most of my students spent four months in a coding bootcamp and generally aren’t in financially urgent situations, consequently having the luxury of spending time for a job search.

Description

Unit testing GraphQL resolvers in TypeScript can be quite tricky to get right with the correct typing. This posts illustrates some example code of setting up calls directly to the resolvers.

The code below here works with GraphQL Code Generator to generate types for your resolvers. This article does not cover how to set up GraphQL Code Generator; it assumes that you have a working setup with your resolvers.

Instead of writing raw GraphQL queries (which can be seen in my post about testing middlewares), we show a typesafe way to unit test GraphQL resolvers. Much of this code is based off what was written in graphql-code-generator issue #1763 by kamilkisiela.

Code

// You need to set up your resolvers using GraphQL Code Generator types. This
// isn't in the scope of this article, so you'll have to check its
// documentation.

// You probably want to put these helpers in a common file such as testutils.ts
// in order to use them between different test suites. You don't really need to
// read the code below.
//
// The types below help us properly type mockedResolvers so we can write unit
// tests that directly call resolvers from graphql-codegen. I took it from this
// link below.
// https://github.com/dotansimha/graphql-code-generator/issues/1763
type MockResolverFn<TResult, TParent, TArgs, TCtx> = (
  parent?: TParent,
  args?: TArgs,
  context?: TCtx,
  info?: any
) => Promise<TResult> | TResult;

type MockStitchingResolver<TResult, TParent, TArgs, TCtx> = {
  fragment: string;
  resolve: MockResolverFn<TResult, TParent, TArgs, TCtx>;
};

export function mockResolver<TResult, TParent, TContext, TArgs>(
  resolver: Resolver<TResult, TParent, TContext, TArgs>
): MockResolverFn<TResult, TParent, TArgs, TContext>;
export function mockResolver<TResult, TParent, TContext, TArgs>(
  resolver: Resolver<TResult, TParent, TContext, TArgs>,
  isStitching: boolean
): MockStitchingResolver<TResult, TParent, TArgs, TContext>;
export function mockResolver<TResult, TParent, TContext, TArgs>(
  resolver: Resolver<TResult, TParent, TContext, TArgs>,
  useStitching?: boolean
):
  | MockResolverFn<TResult, TParent, TArgs, TContext>
  | MockStitchingResolver<TResult, TParent, TArgs, TContext> {
  if (
    isStitching<StitchingResolver<TResult, TParent, TContext, TArgs>>(
      resolver,
      useStitching || false
    )
  ) {
    return {
      fragment: resolver.fragment,
      resolve: (parent, args, context, info) =>
        resolver.resolve(parent!, args!, context!, info!),
    };
  }

  return (parent, args, context, info) =>
    resolver(parent!, args!, context!, info!);
}

function isStitching<T>(resolver: any, useStitching: boolean): resolver is T {
  return useStitching === true;
}


/**
 * In this example, we have an object called `signup` that has the
 * `MutationResolvers` type from graphql-codegen.
 */
import { signup } from './signup';

// Set up the parent and context args to your resolvers as appropriate, either
// at the top or on a test-by-test basis.
const RESOLVER_PARENT = {};
const MOCK_CONTEXT = {};

describe('cancel signup works', () => {
  it('tests for an exception case', async () => {
    const expectToThrow = async () => {
      return mockResolver(signup.cancelSignup!)(
        RESOLVER_PARENT,
        {
          reason: 'foo',
        },
        MOCK_CONTEXT
      );
    };
    expect.assertions(1);
    return expectToThrow().catch((e) => {
      expect(e).toBeDefined();
    });
  });

  it('tests the return value of the resolver', async () => {
    // You can also set up other mocks as needed, then assert that they were
    // called later on.
    const result = await mockResolver(signup.cancelSignup!)(
      RESOLVER_PARENT,
      {
        reason: 'foo',
      },
      MOCK_CONTEXT
    );

    expect(result.someFieldOnReturnResult).toBe("some test assertion");
  });
});

Description

In this test, we essentially set up a new set of resolvers from scratch using the schema by loading all GraphQL schema files from a directory. By using makeExecutableSchema to create a schema and addMockFunctionsToSchema, we mock out the endpoints.

My application is using graphql-yoga, although this is actually irrelevant to the test environment (you’ll notice no references to it here).

In this example, I use an external Express GraphQL middleware resolver: graphql-shield, a permissions layer for GraphQL.

Drawbacks

A huge drawback of this approach is that we need to type out GraphQL queries as strings without having them typechecked. I didn’t find a good way to have typechecked queries here, although it may be possible somehow with GraphQL Code Generator (if you find a way, please comment below).

Note that it’s possible to individually unit test any rules that you use in the permissions as well (independent of GraphQL).

Code

/**
 * An example of testing a GraphQL middleware. In this test, the resolvers
 * themselves have no actual implementation.
 */
import { makeExecutableSchema, addMockFunctionsToSchema } from 'graphql-tools';
import { graphql } from 'graphql';
import { applyMiddleware } from 'graphql-middleware';
import { mergeTypeDefs } from '@graphql-tools/merge';
import { loadFilesSync } from '@graphql-tools/load-files';
import permissions from './permissions';

const SCHEMA_DIRECTORY = './src/schema';

let schemaWithMiddleware: ReturnType<typeof applyMiddleware>;

beforeAll(() => {
  const typesArray = loadFilesSync(SCHEMA_DIRECTORY, {
    extensions: ['graphql'],
  });
  const typeDefs = mergeTypeDefs(typesArray);
  const schema = makeExecutableSchema({ typeDefs });
  addMockFunctionsToSchema({ schema });
  // `permissions` here is the call shield() in GraphQL shield. Its type should
  // be compatible with applyMiddleware for graphql-middleware.
  schemaWithMiddleware = applyMiddleware(schema, permissions);
});

const Queries: Record<string, string> = {
  // An example of a GraphQL query you can write here. As mentioned in the
  // article, the inability to get static typing here is unideal.
  INITIALIZE_CARD_SESSION: `
    mutation {
      initializeCardSession(selector: { scheduleDayId: "foo" }) {
        session {
          id
        }
      }
    }
    `,
};

describe('test suite', () => {
  it('tests a single aspect', async () => {
    // Set up mocks etc here for the implementation of the middleware if needed.
    const mockContext = {};

    const result = await graphql(
      schemaWithMiddleware,
      // You can inline the query here or declare it at the top of the test if
      // you wish.
      Queries.INITIALIZE_CARD_SESSION,
      null,
      mockContext,
    );

    // You can access the result of the resolver like so.
    // Note that we are simply testing the middleware here; the actual resolver
    // has no implementation since we used addMockFunctionsToSchema().
    expect(result.data).toBeFalsy();

    // In this example test, we are testing our permissions middleware in
    // properly returning an error.
    expect(result.errors).toBeTruthy();
    expect(res.errors!.length).toBe(1);
    expect(res.errors![0]!.message).toEqual(
      expect.stringContaining('You need to be an admin')
    );
  });
});

This post has four parts:

1. Why is this bootcamp different from other ways people learn coding?
2. Two teaching philosophies
3. Concrete strategies for practitioners
4. Miscellaneous thoughts

Differences from traditional bootcamps

In this section, I set the context for this bootcamp and discuss some important differences to keep in mind between this bootcamp and other coding class settings, primarily with respect to time and money investment. The purpose of this background is to start the reader thinking about how these might affect the students’ mentality.

The Istanbul Bootcamp

The bootcamp is approximately five months, with three months of classes and approximately two months of a final project. The students are mostly Turkish and Syrian in nationality. The class size is approximately 24. The male-female ratio is approximately 60-40.

During the application process, the students are asked to do an HTML/CSS exercise, but otherwise, no previous coding experience is required. However, some students certainly have more existing experience than others, which has the potential to demoralize students.

From universities

Compared to universities, there are two primary differences in the bootcamp:

1. Students do not pay for the bootcamp
2. Students are not graded in the bootcamp

I encourage the reader to consider this question: “why do students in university make an effort?”

From paid bootcamps

Compared to paid bootcamps, the students are not paying a large sum of money. The tuition of HackReactor is $18,000. That’s quite an investment.

Ramifications

We’ve established some of the differences between this bootcamp and other similar venues of teaching coding. Next, let’s consider some consequences of these discrepancies.

In this section, I won’t discuss solutions. I will simply posit some salient problems.

Ease of quitting

In this context, the threshold for quitting is much lower than in university or paid bootcamps.

Our bootcamp students frequently broach the idea of quitting during stressful times, likely because the sunk cost is low. In contrast, in university or paid bootcamps, the threshold is higher, because the student doesn’t want to lose three years of money/time invested or ten thousand US dollars, respectively.

Lack of motivation to do assignments

Consider this hypothetical: if a university had no grades and no exams, how many students would do the assignments as compared to a university that had these?

Even in considering this hypothetical, one can see the problem. There is no external motivator or metric for our bootcamps’ students. Students should only be removed from the bootcamp for particularly egregious behavior, but it is certainly not taken lightly – part of our ethical responsibility is to encourage them psychologically.

One of my favorite phrases, for all parts of life: “you can’t make anyone do anything in this world” (barring duress and so on).

Propensity to complain

In general, students in our bootcamps like to gripe about various parts of the bootcamp: homework, projects, process, class, etc. Whether this is due to a cultural or a venue difference, I can’t say.

However, I do believe that one reason for this propensity for complaining is the aforementioned lack of investment, which emboldens the students. While complaining is not inherently dangerous, a cycle of complaining potentially causes students to demotivate each other and consequently increases the risk of quitting.

Note that there is a nuance between feedback and complaining, and instructors should still objectively evaluate complaints for genuine feedback.

Summary of differences

The summary of these differences is this: for our bootcamps, the student has invested neither money nor time. The only way to motivate these students is to foster an intrinsic interest in participating in the bootcamp.

The definition of “fostering intrinsic interest” will be expounded at length below.

Outside the scope of this post: the filtering qualities of interviews are also important in influencing student motivation.

Precursors on philosophy

Before we continue into more concrete strategies, I want to discuss two of my driving philosophies for teaching.

Treating students as relationships

The first driving philosophy: the skills that I apply for teaching are no different from those that I apply for a significant other or close friends. That means understanding another individuals needs, desires, life state, past experiences in the class, etc. What will make this person happy? What is this person looking for? How can I provide these things?

I truly believe the following statement to be true: the success of this particular coding bootcamp only slightly depends on how you teach the material, it depends almost completely on how loved and motivated you make your students feel. In this particular context, when the emotional environment is correct, the students’ hard work and enthusiasm will follow.

This is not to say that coherent instruction does not make a difference – it does. But in an art that requires self-research and emotional discipline from students, a caring instructor with mediocre teaching skills will be far more impactful than an emotionally-neutered instructor with excellent teaching skills.

Maximizing impact for time

The second driving philosophy: find time-cheap but psychologically-impactful ways to treat students.

Consider this question: given that I have N students, how can I make them all feel loved and motivated while minimizing the average amount of time I spend on an individual student?

The things that I describe below, for the most part, will not eat up your time. I wouldn’t do them if they did. But with this “one weird trick”, five to fifteen minutes of your time can make all the difference in the world.

For what it’s worth, this graph represents all aspects of my life, not just teaching. It makes life a bit easier, in my humble opinion, to hunt for these optimizations.

Fostering intrinsic interest

Intrinsic interest means that the student cares, in their heart, about doing well in the course, completing the assignments, and learning the material. A non-exhaustive list of where intrinsic interest comes from:

• The student feels cared for by the instructors
• The student feels pride in their work
• The student respects the instructors as people
• The student wants to continue despite hardships in coursework

In the absence of any other external motivators, our bootcamps have no choice but to rely on intrinsic interest. This section focuses on providing concrete strategies for intrinsically motivating students. Each section simultaneously posits a principle and pairs it with a description of a real, implementable strategy.

This post is not meant to be a solely theoretical exploration of what motivates students; these actions are intended to be executed by practitioners.

The illusion of individual attention

I call this the illusion of individual attention, because in a class of 24, it’s not possible for you to truly give sustained individual attention to every student. However, you can perpetuate the idea that you are trying your best to get individual attention to every student.

In a class of this size, students don’t expect individual attention. In fact, I find that most students are very understanding of the fact that the instructors are trying to juggle between the students.

Surprisingly, the students’ understanding of this is something that you can capitalize on. When you do show a student individual attention, their awareness of the resource constraints causes them to appreciate your efforts even more, consequently inspiring them.

The ultimate cost of the actions below are very low, but they mean the world to the students. Recall our efforts to maximize impact for minimal time.

Concrete actions

• Initial one-on-ones: Have a one-on-one with each student at the beginning of the course.
• Availability for one-on-ones: Allocate one to two hours each week for 20 minute one-on-ones with students. Even if they never capitalize on it, they appreciate the fact that it’s possible.
• Occasional check-ins: Occasionally message students randomly to ask how they’re doing or what their thoughts are. It takes less than two minutes of time to message ten students.

Constructing a serious environment

The environment and tone that the teaching staff sets is by far one of the most important things to do. If you seem to be lax about their performance, they will certainly be lax about their performance.

I’ll cover this section with an anecdote.

The way I came to understand this is a bit amusing, in my opinion. After a few strict lectures to the class, a number of students approached me concerned about their performance or actions in the course. (Slightly unrelated note: when you give strict talks to your whole class about assignments and such, I realized that every student thinks you’re talking directly about them, even if they’re doing completely fine).

While my external self had always taken the class very seriously – and my internal self, of course, to a certain extent – I was truly surprised by how worried these students were about their performance in the class. My initial reaction was: “It was just a prank bro. I’m just a kid that likes to breakdance (not a strict teacher trying to berate you).”

The reason that this surprised me so much was that, previously, I did feel like I had trouble motivating my students to do their work. After all, recall the differences that we established in the beginning. There are no grades. There is no invested money. That’s not to say my students wouldn’t take it seriously, but why are they taking it this seriously?

But then I realized, that I had unintentionally stumbled upon something that I’ve always known in my relationships and friendships: If you are proactive about taking something seriously, the other person will be much more likely to take it seriously. Don’t sit around waiting for the other person to be the one to do so.

Concrete actions

• Communicate your investment: “I take your education very seriously, and I expect you to take it seriously too.”
• Show with your actions: Words only mean so much in this world. Show your students you take it seriously in the quality of your teaching and your interactions with your students (see all the other sections).

Professionalism and personalization

Professionalism

The more professional your content is, the more it reinforces students’ belief in the authority and legitimacy of the classroom.

Suppose the contrasting hypothetical: your slides are poorly written; your assignment instructions have no consistent formatting; your in-class activities are full of typos. Inevitably, your students will start learning from other content on the internet, and they’ll come to the following realization: “Wow, the teaching materials that our teacher is giving us are shit quality.”

Among my students in particular, I have noticed how captivated they are by the professional and formal aspects presented by the organization’s onboarding and branding. To capitalize on that captivation, this professionalism needs to be continued in the classroom.

Concrete actions

• Professional content: All slides, assignments, and course material should be formatted professionally and flawlessly. Minimize typos.
• Agenda slides: Show an agenda slide at the beginning of each class. It provides a sense of official-ness, like university.

Personalization

Students like the idea that the organization is doing something for them. Just for them. This doesn’t mean that you have to write the assignment from scratch, but it should at least be presented in a manner that suggests that you’re thinking of the student. Recall the goal: make the student feel cared for.

Compare the following two situations:

Positive impact

Teacher: We thought about where the class currently is, and the teaching staff designed this activity for you all based on your feedback and struggles. Please do this activity.

Student: Wow, the teacher put in so much effort for us!

Neutral impact (but probably negative if chronic)

Teacher: Here’s a link to this site, please do this activity.

Student: Sure.

Concrete actions

• Revamp outside resources: Avoid chronically linking to other resources for activities. Either put them in your own document or write your own, giving proper attribution as needed. Even the act of putting it in your own document pushes this edge.
• Emphasize your effort: Mention to your students how the material was made by your organization on their behalf. Let them know you made an effort for them.

Projects that express self-identity

In the absence of grades, one of the best motivators for effort is to allow students to express themselves through their work. Humans like expressing themselves. Humans like to build things, look at them, and say, “This is me. I did this.” This is a fact, and we can capitalize on this fact in order to incentivize students.

When ten groups of students do assignments that all look almost exactly the same, the student does not think, “This is me. I did this.”

My own students have constantly surprised me with how much effort they put into projects. For example, they come into office hours and talk about the hours working on something (styling, a special feature they came up, etc.) that was outside the stated project requirements. Part of this is because I personally would never do anything beyond the minimal requirements, but part of it is because, until I was blown away repeatedly by this phenomenon, I had never realized the power of allowing students to invest their identity in their work.

Concrete actions

Devise coding projects with open-ended interpretations (in styling or functionality).

Different project designs can have different degrees of self-identity; I would argue that some non-zero amount is necessary for every project.

For example, the final project of our course was “the board project”, which required only the very general concept of boards and items that could be put on boards. The ultimate result was a wide array of projects with a personal touch: to-do lists, cookbooks, course project trackers, and the students ultimately invested much more time than if we had assigned a “to-do list project.”

Social cohesion

When the social aspect of the class is strong, students try harder. Part of it is that they enjoy the class, but part of it is that most people don’t want to be known by their friends as the student who doesn’t try.

So the question is this: how do you encourage people to like each other? To be honest, as instructors, we don’t have much agency here; you can’t make people form bonds. However, you can try your best to facilitate situations where it can happen.

Concrete actions

• Project partners: Select project partners with the intent of forming bonds between students of similar levels
• Promoting thought: Ask students who their favorite people to work with are (not for any particular reason other than for them to ponder this question)
• Allocate time for small socialization: Encourage socializing and jokes in class, allocate “empty time”
• Use office hours: Leave time in office hours for students to chat with each other

Expression of belief

Coding bootcamps can be quite intense for some of the students. There will come a time when some students don’t believe in themselves or their ability to understand the content. And when that time comes, it’s not important whether or not you believed in them, it’s important whether or not you communicated that you believed in them.

I again emphasize the illusion of individual attention.

Concrete actions

• Individual messaging: Identifying students that are struggling, and telling them, directly to their face (via Zoom, this is 2020), that you believe in them. Offer them the option to meet one-on-one.
• Humbling your journey: Show that you, too, come from humble beginnings. Whether that means you went through a bootcamp yourself, or that you struggled a lot when you started coding, show the students that their struggle is normal. For example, I showed my students emails from my first two months in coding where I sent emails to my friend raging about bugs in my code. I had multiple students tell me that this humanized my journey despite the pedigree.
• Inspirational speeches: Be liberal with the inspirational speeches in class. They never stop feeling weird to me, but it matters.
• Emphasize first exposure: Tell your students that when you show them something for the first time, they’re not expected to understand it. A phrase my students are familiar with: “This is just a first exposure.”

Other takeaways

These are miscellaneous addenda that don’t belong in the categories above, but these are points I would tell myself if I could travel back in time. In the end, these happened naturally, but I didn’t codify them into thoughts until the middle of the course.

Teaching a way of thinking

I encourage you to ask yourself this question: “at the end of the course, who do I hope my students to be?”

It’s not my place to say what the right or wrong answer is. If you’re a teacher, you set the goals. But by the way, there is a wrong answer, and that wrong answer is: “a student that knows JavaScript and React.”

The right answer is that the student:

• is no longer scared to learn a new technology or tool
• never compares himself or herself to other people again
• is unfazed by setbacks, even when a small bug costs five hours of time (instead of thinking, “programming is not for me”)

I’m certain this is not a novel idea I’m proposing; most successful introductory computer science courses, such as CS50, operate along the same mentality.

But I’d like to note something interesting here. None of the things above have to do with specific knowledge of a subject; they all pertain to how the students think as people.

With these goals in mind, here are some modes of operation:

• Constantly introduce new things: Spend the course bombarding students with new things. Just as they start to feel comfortable with something, you introduce something (perhaps only slightly) new on top of it.
• Demo your thought process: When feasible, walk the student how you thought about the problem. “You see, I just Googled this thing.” “I worked backwards from this variable to find the issue.”
• Comfort your students: When your students finally fix a bug that took them forever, comfort them psychologically. Tell them it’s normal. Emphasize your belief in them.

Trust the process

The students will learn the material eventually – trust the process. I’ll admit that even I wasn’t sure whether my students were learning anything at some point. There were times in the course when almost all of the students seemed completely lost in all of the in-class activities (to be fair, I was also pushing the pace very quickly).

Luckily, I had my trusty teaching partner Ammar, who informed me that these struggles were normal. In the same way that I tell my students, “Hey, this is normal,” Ammar’s evaluation sealed away any concerns I had. In the end, I trust Ammar’s judgment completely, given that he’d experienced two bootcamps before me.

I’ll also say this: in-class activities are a very short amount of time to exercise real exploration beyond basics. The core of the learning will come from the multi-week projects that students do. That’s the real shit, pardon my French. And if the students are invested in completing projects, the learning will follow.

Conclusions

At this point, I’d like to highlight a critical observation: none of these actions take much time. They are simply small flourishes to the interactions with students.

But if you’ve ever played any skill-based game, then you’ll be familiar with this concept: the people who are the best at anything in life are those that push all the smallest advantages. The best chess players leave no tradeoff unpunished. The best football players leave no misstep unexploited. Capitalizing on small edges differentiates one who is the best at something and one who is average.

Finally, achieving anything in our lives is a function of our goals, and it’s good to recall our broader goals. In whatever context you teach in, I encourage you to refresh your goals. For Re:Coded, they would be this:

• To teach students the programmer mindset (how to learn, debug, etc.)
• To empower students to obtain and excel at a development job

And to achieve these goals, we should not simply be settling at teaching our students React and JavaScript. The question is not where can we take the students, but how far can we take them?

And for that reason, I urge you to never be complacent with your students.

One hour of your time per week could be the difference between your student hating or loving the course.

Two hours of your time per week could be the difference between your student landing a frontend job or not.

Three hours of your time per week could be the difference between your student landing a job on a weak currency or a strong one.

Calculate the margins, and remember the graph.

Şile is a popular place for the residents of Istanbul to escape for a day trip. Technically, Şile is part of Istanbul, although it’s quite remote. The bus ride is about two hours away; by car, it is about 45 minutes.

Bus Line

Taking any bus that is prefixed with 139 is okay, all of them stop at Şile first but their continuing routes after Şile may differ.

The IETT site gives a description of the stops; however, as explained below, the bus stop location is incorrect on the site. Also note that this link only shows the 139 bus, but the 139A, 139T, etc. also run, meaning that there is approximately one bus to Şile every hour.

The bus has various stops in the Şile area, though the bus terminal is a safe bet for a place to get off.

Bus Stop Location

Do not wait at the Üsküdar Marmaray bus station. The correct location for this intercity bus is the Şemsipaşa stop (Google Maps link), which is about a block west. There, you will see a paper with times for the bus to Şile.

A ticket is required for this bus. The place to purchase the tickets is about a two minute walk from the bus stop (Google Maps link). At the time of writing (July 2020), a one way ticket was 14.50 lira. If you don’t speak Turkish, you probably can’t get on the bus without a ticket, although I’ve been told it’s possible to sit on the floor if the bus is full.

If you try to buy too close to the departure time, it’s possible that the bus may be full.

It may be possible to buy online, but the author of this article doesn’t know how.

There are a few performance optimizations:

• React.memo makes it so that even if the parent rerenders but the Latex does not change, the component does not rerender (reference).
• The MathJax typeset() is only called when rawLatex changes. Technically, this is unnecessary, as the React.memo should mean that it only rerenders when the prop changes.

You can either load MathJax in the head or load it dynamically in other ways. With Next.js, I was running into issues with using the <Head> tag; see how to dynamically load scripts in React.

/**
 * Combined with dynamic script loading, this component allows us to render
 * MathJax. Uses MathJax 3.0. It takes an approach similar to the article below:
 *
 * https://engineering.classpro.in/render-latex-in-react-using-mathjax-f9742504678
 *
 * but then adapts based on MathJax 3.0:
 *
 * http://docs.mathjax.org/en/latest/web/typeset.html#handling-asynchronous-typesetting
 */

import React from 'react';

const getMathJax = () => (window as any).MathJax;

const typeset = (selector: () => HTMLElement) => {
  const mathJax = getMathJax();
  // If MathJax script hasn't been loaded yet, then do nothing.
  if (!mathJax) {
    return null;
  }
  mathJax.startup.promise = mathJax.startup.promise
    .then(() => {
      selector();
      return mathJax.typesetPromise();
    })
    .catch((err: any) => console.error(`Typeset failed: ${err.message}`));
  return mathJax.startup.promise;
};

interface LatexProps {
  rawLatex: string;
}

const Latex: React.FC<LatexProps> = ({ rawLatex }) => {
  const ref = React.createRef<HTMLSpanElement>();
  React.useEffect(() => {
    typeset(() => ref.current!);
  }, [rawLatex]);

  return <span ref={ref}>{rawLatex}</span>;
};

export default React.memo(Latex);

This is a modification on the code presented in this article. The script adds a script tag to the page and optionally calls a callback. It will not add the script again if it is already loaded. If a callback was provided, then it removes the script from the page when the component unmounts (so that the callback can be called again).

/**
 * Dynamic script loading hook.
 */
import React from 'react';

// If no callback is provided, the script will not be removed on unmount. This
// kinda matters if the script loading is not idempotent (for some reason
// MathJax is not, which is one of the scripts I was using this for) or
// if you need the callback to happen again.
const useScript = (
  scriptUrl: string,
  scriptId: string,
  callback?: () => void
) => {
  React.useEffect(() => {
    const existingScript = document.getElementById(scriptId);

    if (!existingScript) {
      const script = document.createElement('script');
      script.src = scriptUrl;
      script.id = scriptId;
      document.body.appendChild(script);

      script.onload = () => {
        if (callback) {
          callback();
        }
      };
    }

    if (existingScript && callback) {
      callback();
    }

    return () => {
      if (existingScript && callback) {
        existingScript.remove();
      }
    };
  }, [scriptUrl, scriptId]);
};

export default useScript;

This post talks about the concept of “fiilimsi”, which are nouns, adjectives, or adverbs derived from verbs. In English, for example, these include gerunds (“Running is fun”) or participle adjectives (“The dog that I saw”).

This post is not intended to be a comprehensive resource of all fiilimsi. There are three categories of fiilimsi:

1. isim-fiil: verbal noun
2. sıfat-fiil: verbal adjective
3. zarf-fiil: verbal adverb

There’s a noticeable lack of English language resources on the internet about certain Turkish language topics. There’s a few articles about verbal derivations but only with minimal details. I hope this post fills that niche.

Almost all of this material was derived from a lesson on the Türkçe Öğrenelim Discord. Feel free to join the community and support them on Patreon.

Prerequisites

This post is not intended for complete beginners of Turkish grammar. Fiilimsi builds on many of the foundations of Turkish grammar. This post assumes prerequisite familiarity in the following topics, and as such will not be explaining any of the following in example sentences:

• Possessive
• Buffer letters, consonant mutation, vowel harmony
• Infinitive form
• Subjects and objects in Turkish

There are sentence examples and grammar derivations that utilize the following, though it’s possible to grasp the basic idea without a strong understanding of these:

• Simple present tense, past tense
• Dative, locative, accusative cases
• Future tense
• Reported past tense

Isim-fiil: Verbal nouns

-mak/mek: Infinitive as a subject

Infinitives are the “dictionary form” of a verb ending with -mak/mek, e.g., bakmak (to look).

Usage

The verbal noun infinitive form:

• used as subject
• cannot be declined – that is, no suffixes are added to it

Example (a line from this song)

Eğlenmek güzel şey.
To have fun is a beautiful thing / having fun is a beautiful thing.

It should be noted that there are many other uses of the infinitive, but here we’re talking only about its usage as a noun derived from a verb.

-ma/me: Gerund form

The gerund form is constructed by adding -ma/-me to the verb root (alternatively, one can think of simply removing the k from the infinitive).

• yapma (doing)
• bakma (looking)
• sorma (sormak)

Usage

The gerund form:

• used as object
• can be declined

Examples

Kitap okumayı seviyorum.
I love reading books.

Dans etmeye başladım.
I started dancing.

Tip: The -ma/-me suffix is also used for the negative conjugation, but do not confuse it with the gerund construction. They can actually stack, for example anla-ma-ma is the noun “not understanding” (anlamak – to understand).

Declension exception: ablative

There is one exception where we use the infinitive instead; for the ablative form (-dan/den), we still use the infinitive form. This also violates the “no declension infinitive” rule. In the example below, eğlenmekten is the object.

Example

Eğlenmekten keyif alırım.
I enjoy having fun.

Likely this is because the gerund form causes ambiguity with -meden/-madan (eğlenmeden), which is also a verbal adverb suffix.

Declension exception: locative

The locative can also be used interchangeably in some contexts. In the example below, both are valid uses of the verbal noun as an object.

Examples

Böyle yapmada sorun yok.
Böyle yapmakta sorun yok.
There is no problem in doing this.

However, you cannot use the genitive suffixes with the infinitive, so for the example sentence below, there is only one valid construction (yap-ma-n-da, with the n coming from the second-person genitive).

Examples

Böyle yapmanda sorun yok.
There is no problem in your doing this.

To summarize, you cannot use the accusative, dative, or genitive suffixes with the infinitive, but you can use the ablative and locative.

Native speaking: gerund and infinitive

There’s a tricky exception that’s technically not correct but will be seen in daily speech. People add (gerund + possessed) suffixes as a way of creating a verbal noun in lieu of both the gerund and infinitive forms above.

Subject example

Denizde yüzmek eğlenceli. (gramatically correct)
Denizde yüzmesi eğlenceli. (seen in daily speech)
Swimming in the sea is fun.

In this example, we have yüz-me-si, which adds the gerund and possessed suffixes, respectively.

Object example

Denizde yüzmeyi seviyorum.
Denizde yüzmesini seviyorum.

In this example, we have yüz-me-si-n-i, which adds the gerund, possessed, -n- possessed buffer, and accusative suffixes, respectively.

-ıs/iş/uş/üş: “the way of”

DISCLAIMER: “the way of” is not always the exact meaning of this suffix; it can vary phrase by phrase. However, it can give a general idea.

• yapış (the way of doing)
• bakış (the way of looking)
• soruş (the way of asking)

There are two words derived in this manner that are very common on signs: giriş and cıkış (entrance and exit).

Examples

Bana bakışını sevmiyorum.
I don’t like the way you looked at me.

Onun çıkışını gördün mü?
Did you see how he left? / Did you see the way he left?

Sıfat-fiil: Verbal adjectives

-(y)an/-en: Subject participles

In English, you’ll see this grammar concept associated with the terms relative clause and participle.

We use these to form a verbal adjective that describes a noun. It is called the subject participle because the described noun is the subject performing the action.

Examples

evime gelen misafir
the guest who comes / is coming / came to my house

uyuyan adam
the man who sleeps / is sleeping / slept

Negation

Negation works as one might expect.

Example

uyumayan adam
the man who is not sleeping

Tip: In practice, the -y- buffer will always be there since -ma/me end with a vowel.

Tense

The tense is implied by context. It can take the present continuous, simple past, and simple present (aka wide present) tenses.

-dIk and possessor suffix: Object participles

Recall that -dIk notation indicates it could be -dık -dik -duk -dük. The d also mutates to t when appropriate (consonant mutation).

This adjective is called the object participle, because the noun described by the verbal adjective is the object of the verb. Because of this, we also need to specify who is performing the action of the verb; this is done by the possessor ending.

Examples

okuduğum kitap
the book that I read / am reading / read (the past)

okuduğun kitap
the book that you read (…same tenses)

Tip: In practice, the k in -dIk almost always mutates to a ğ since all of the possessor endings start with a vowel. The only exception is when the plural is added to onlar, as below.

Examples (with onlar)

onların okuduğu kitap
onların okudukları kitap
the book that they read / am reading / read (past)

okuduğun kitap
the book that you read (…same tenses)

Negation

Negation again works as one would expect.

Example

bakmadığım adam
the man who I am not looking at

Tense

The tense is implied by context. It can take the present continuous, simple past, and simple present (aka wide present) tenses.

Usage with sonra

You will also see this suffix used with the word sonra (“after”), but without the possessed ending.

Example

O kahvaltı yaptıktan sonra bir sigara içer.
After eating breakfast, he smokes a cigarette.

Notably, it is not symmetrically used with önce, which uses the -mAdAn suffix with verbs with our previously described gerund form.

Example

Uyumadan önce kitap okurum.
Before sleeping, I read books.

Future and reported past participles

Building upon the two forms we learned above, we can create both object and subject participles using the suffixes of both the future and reported past tenses. These tenses won’t be covered here, so this section can be skipped if the reader is not familiar with them.

Understanding of these derivations follow easily with an understanding of the -acak/ecek future suffixes and the -mış/miş/muş/müş reported past suffixes.

Examples (future tense)

konuşacak adam
the man who will speak

konuşacağı adam
the man he/she will talk to

adam konuşacak
the man will talk (normal future tense)

Examples (reported past tense)

kitap okumuş çocuk
the child who (apparently) read books

boşanmış kadın
the woman who (apparently) was divorced

Other verbal adjectives

There are a bunch of other verbal adjectives, often with different meaning. There’s a Turkish page containing some of them here, but they’re less important and often vary in meaning phrase-by-phrase.

Zarf-fiil: Verbal adverbs

This is not intended to comprehensively cover all zarf-fiil, but it covers a few of the most common ones.

-eli/ali: Since

This suffix means “since” in the sense of time passing (not “since” as in the word “because”, which can also be used in English). It can only be used events happening since a specific time duration.

Example

Okuldan geleli beş saat oldu.
It has been five hours since I came from the school.

If you want to express the concept of “since” relative to an event, then the verb is repeated in the past tense.

Example

Türkiye’ye geldim geleli birçok kişiyle tanıştım.
I’ve met many people since I came to Turkey.

Subject of the since-clause

The subject is optional, but it can be used to clarify the subject of the since-clause when it cannot be derived from context.

Examples (with pronoun)

Sen okuldan geleli beş saat oldu.
It has been five hours since you came from the school.

-madan/meden: before (with önce) / without

Meaning “without”

Example

Maske takmadan dışarı çıkmak yasaktır.
It is forbidden to go out without wearing a mask.

Meaning “before”

Example

Ben polisi aramadan buradan ayrıl.
Leave this place before I call the police.

With önce

In the section on -dIk, it was explained that “(verb + dIktAn) sonra” could be used to say something that happened after an action. The -madan/meden suffix serves is often seen with önce. With or without önce is essentially the same (to my understanding).

Example

Çalışmaya başlamadan önce bir kahve içerim.
Before studying, I drink a coffee.

-madan/-meden modifying a negative verb

There is a second construction using -madan/-meden. In this one, if the modified verb is negative, then the adverb happens first in the sequence of events. This is a bit confusing to explain but easily clarified with equivalent examples. Note the negative suffix in the verbs below.

Example

Kitap okumadan yatmadı.
Kitap okudu ve yattı. (equivalent)
He read a book before he slept.

A direct English translation can be a bit weird due to the negatives.

Question example

Siz ne yapmadan okula gitmiyorsunuz?
What do you do before going to school?

The example could literally be translated as, “you don’t go to school before doing what?”

This video (in Turkish, albeit slow Turkish) is a good explanation of this negative construction. Credit goes to this video for the examples above.

-ar -maz / -er -mez: as soon as

Note that the title isn’t precisely correct, the set of suffixes is the same as those used in the simple present tense, which has a ruleset not within the scope of this article. One can think of this construction as simply the positive and negative simple present tense third person forms in succession.

Like -eli/ali, the subject is implied by context, but can optionally be clarified by a pronoun.

Example

(Biz) Dışarıya çıkar çıkmaz yağmur başladı.
As soon as we went out, it started to rain.

Example constructions

yapar yapmaz
gelir gelmez
görür görmez

-(y)arak/erek: “by”

This adverb indicates that something was achieved in a certain manner.

Example

Türkçe öğrenerek ne yapmayı planlıyorsun?
What do you plan to do by learning Turkish?

A good way to remember this is the word bilerek, which means “on purpose.” But with the literal translation of the suffix, it would mean “by knowing.”

Negation

Simply add -ma/-me with a y buffer. For example, istemeyerek (unintentionally, reluctantly, “by not wanting”).

-ıp/ip/up/üp: two actions in succession

Again, notice that the subject is implied in the example sentence below. The suffixed verb is the one that occurs first.

Example

Konuyu anlatıp pratik yapacağız.
We will explain the subject and then do practice.

Usually, there is only one usage of -ip in a sentence.

-ip durmak: idiom

-ip durmak means to keep doing something all the time.

Example

Öksürüp duruyor.
He’s constantly coughing.

Difference from sonradan

Sonradan (“afterwards”) can ostensibly express the same set of sentences, but the connotation is slightly different. With -ip, the implication is that one thing happened very quickly after another, while with sonradan, the time gap could be wider.

Further reference

The end of Unit 10 in The Delights of Learning Turkish is a decent English language resource for these verbal adverbs.

I bought my SIM card in Fatih. I’m actually not sure if what I got was a good deal. Turkcell offers all types of short-term deals for tourists as well. I visited three stores in Fatih and they all gave me approximately the same rate (some trying to squeeze +/- 10 lira) without the option for any smaller plans.

These rates are for foreigners. You’ll see advertisements for cellphone data at amazing prices, but these require a Turkish bank account.

Plans

My plan was 20 GB data for 120 lira (around 20 USD at the time of writing). However, it should be noted that the 20 GB is for one month only.

Although the SIM card lasts for multiple months, you do need to top up in future months. The top-up is at a rate rate that I don’t remember, but it’s much cheaper than the initial upfront cost.

I didn’t really keep track of the SMS and call time in the plan, though that’s included. It’s 2020, use WhatsApp :)

Long-term stays

It should be noted that the SIM card situation for long-term stays (more than 120 days) gets much more expensive. You have to pay a foreigner registration fee that’s more than 200 USD. I won’t go much into it here, but you can read about it on this page.

Purchasing

Bring your passport. It took about ten to fifteen minutes for the guy to finish registering everything.

Usage

In order to respond to listings (at least housing listings, in my experience), you do need access to a Turkish cellphone number. The site will ask you to enter a verification code that is texted to the Turkish number before you can respond.

Housing

Sahibinden’s housing search is top-notch. In addition to the filters that one would expect such as flat type and price, it also allows filtering by furnished/unfurnished, renting from owner/broker, building age.

On a separate topic, finding housing in Istanbul has a number of options. I’d recommend reading this article, particularly on the difference between renting from a broker and an owner.

Note: I do dispute one part of this article. They say that renting through an owner usually has higher quality furnishing. At least in Sisli, my experience was the opposite: broker flats tended to be newer and have better furnishing. Most importantly, there were way more broker listings than owner listings, which meant that the options were “better” for my specific needs based purely on a higher volume of selection.

Avoiding shady housing deals

Like Craigslist, Sahibinden actually includes a warning about housing scams, though it’s in Turkish. This notification is mostly common sense: don’t wire money to anyone you haven’t actually met.

I also found that some ads seemed to reuse pictures from other ads (e.g., two flats in different locations with the exact same pictures and different owners). Usually, one of them (I believe) is a scam. Longer-term accounts have a small award image for how long they’ve been on Sahibinden (e.g., 11 years); the shady ones had no such image. I’m not saying all accounts without the award are scams, but if you run into two ads with the same pictures, the legitimate one is probably the certified one.

My friend that lives in Istanbul also told me a few other things to watch out for when using Sahibinden for housing:

• Renting daily flats through Sahibinden is difficult (even short- to medium- term can be a bit of a hassle, as many owners want stable tenants. However, when renting from a broker, they do like short-term tenants because they usually charge the full broker fee of one month’s rent).
• Posters will often post really nice looking pictures but the apartment actually looks a lot worse in person.

The best ATM is HSBC (only 1000 lira at a time, mixed denominations).

The Best ATM: HSBC

At the moment, HSBC has no extra fees and serves mostly 100 TL bills with some 50 and 20 TL.

In February 2020, QNB used to allow large transactions, no fees, and serving only 100 TL bills, but this is no longer the case as of June 2020.

Depending on the ATM, they may try to apply DCC, so when the DCC menu comes up, make sure to click Istemiyorum (it was on the left side), which means: “I do not want.” Make sure you say no to DCC. DCC is very bad (Google it).

See the table below for a relative comparison.

ATM Comparisons

Credit for this table goes to some anonymous user on Reddit, who I’m actually, very truly grateful for taking the time to write and do this exploration. As of February 2020, I can verify that at least some of these were true, as I tried about five ATMs in central Sisli.

If you have any updates or additions to this table, please add them below.

Fees on the card side

This is not really an advertisement, since I don’t really make money from this blog.

In addition to the fees charged by the owning bank of the ATM, the owning bank of the card might also have foreign transaction fees. I use Charles Schwab (for my god-bless USA of bank account), which has no fees. It also waives ATM fees, but I’ve actually never been sure if that works for international bank fees such as the ones above.

If for whatever reason this inspires you to sign up for Schwab, I have this referral link.

Deploy stage environmental variable

In this example, we are using Apex Up, which automatically generates an environmental variable UP_STAGE. Depending on your deployment process, you can pass in the stage in a similar way.

We also pass in the following environmental variables:

• BACKEND_URI_STAGING: The expected domain of the GraphQL backend in staging
• BACKEND_URI_PROD: The expected domain of the GraphQL backend in prod

In next.config.js in the root directory of your Next application:

// Set up environmental variables for deployment. 
// UP_STAGE comes with UP (https://github.com/apex/up-examples/tree/master/pro/env-static)
let backendUri = 'http://localhost:4000';
let cookieDomain = 'localhost';
if (process.env.UP_STAGE === 'staging') {
  backendUri = process.env.BACKEND_URI_STAGING;
  // Using a domain like foo.com includes all subdomains of foo.com.
  cookieDomain = 'stage.foo.com';
} else if (process.env.UP_STAGE === 'production') {
  backendUri = process.env.BACKEND_URI_PROD;
  cookieDomain = 'stage.foo.com';
}

if (process.env.UP_STAGE && !backendUri) {
  throw new Error('No backend URI found for : ' + process.env.UP_STAGE);
}
console.log('Using backend URI: ' + backendUri);

module.exports = withCss({
  // target: 'serverless',
  env: {
    upStage: process.env.UP_STAGE,
    backendUri,
    cookieDomain,
  },
})

This is based off the with-ant-design example in Next.js.

Next configuration

In next.config.js in the root directory of your Next application, add the following:

/** See https://github.com/zeit/next.js/tree/canary/examples/with-ant-design */
const withCss = require('@zeit/next-css')

module.exports = withCss({
    webpack: (config, { isServer }) => {
    if (isServer) {
      const antStyles = /antd\/.*?\/style\/css.*?/
      const origExternals = [...config.externals]
      config.externals = [
        (context, request, callback) => {
          if (request.match(antStyles)) return callback()
          if (typeof origExternals[0] === 'function') {
            origExternals[0](context, request, callback)
          } else {
            callback()
          }
        },
        ...(typeof origExternals[0] === 'function' ? [] : origExternals),
      ]

      config.module.rules.unshift({
        test: antStyles,
        use: 'null-loader',
      })
    }
    return config
  },
});

In babel.config.js:

module.exports = api => {
  return {
    presets: ['next/babel'],
    plugins: [
      [
        "import", {
          libraryName: 'antd',
          style: 'css',
        }
      ]],
  };
};

Example usage

We are able to import from both antd and antd/lib/<component>.

/*
 * An example that imports top-level components from 'antd' and also imports
 * from files under 'antd/lib'.
 */
import { TreeSelect } from 'antd';
import { TreeNode, TreeSelectProps } from 'antd/lib/tree-select';
import React from 'react';

const TreeSelectView: React.FC<TreeSelectProps<string[]>> = (props, ref) => {
  return (
    <TreeSelect
      {...props}
      treeCheckable
      treeData={{}}
      treeDefaultExpandAll
      style={{ width: 300 }}
      showCheckedStrategy="SHOW_PARENT"
      ref={ref}
    />
  );
};

export default React.forwardRef(TreeSelectView);

This can extend to arbitrary conditions on the queried user, such as redirecting if the user does not have an active subscription.

The following Typescript module implements a general HOC that redirects based on authentication state by querying the user from the GraphQL backend. It then includes two examples:

• If the user is not logged in, redirect to /login
• If the user is logged in, redirect to /dashboard

Example HOC Usage

import { NextPage } from 'next';
// CHANGE THIS: Export to the appropriate path.
import { withLoginRedirect } from '../lib/auth';

const RequiresLoginPage: NextPage = () => {
  return <div>You're logged in</div>;
};

// If the user isn't logged in, this will redirect to `/login`.
export default withLoginRedirect(RequiresLoginPage);

Implementation

import React from 'react';
import { NextComponentType, NextPageContext } from 'next';
import Router from 'next/router';
import gql from 'graphql-tag';

/**
 * YOU DEFINE THESE.
 *
 * These variables should be set by you to query for the user and the types
 * appropriately. I recommend using GraphQL codegen
 * (https://graphql-code-generator.com/) to generate types from your schema and
 * queries from other files so that they can be used like so:
 *
 * import { User } from '../generated/apollo-client-types';
 * import {
 *   LoggedInUserDocument,
 * } from '../generated/apollo-client-types';
 *
 */
interface User {}
const LoggedInUserDocument = gql`<YOUR QUERY FOR USER OBJECT>`;

/**
 * A function that queries for the logged in user before rendering the page.
 * Should be called in getInitialProps. It redirects as desired.
 *
 * It allows for redirecting both if the user is not logged in (e.g., redirect
 * to login page) or redirecting if the user is logged in.
 *
 * If not logged in, redirects to the desired route.
 *
 * The return value indicates whether logic should continue or not after the
 * call.
 */
const redirectBasedOnLogin = async (
  ctx: NextPageContext,
  route: string,
  redirectIfAuthed: boolean
): Promise<boolean> => {
  const isLoggedIn = await ctx.apolloClient
    .query({
      query: LoggedInUserDocument,
      // Prevent caching issues when logging in/out without refresh.
      fetchPolicy: 'network-only',
    })
    .then(({ data }) => {
      if (!data || !data.loggedInUser) {
        return false;
      }
      return Boolean(data.loggedInUser);
    })
    .catch(() => {
      return false;
    });

  const shouldRedirect = redirectIfAuthed ? isLoggedIn : !isLoggedIn;
  if (shouldRedirect) {
    // https://github.com/zeit/next.js/wiki/Redirecting-in-%60getInitialProps%60
    if (ctx.res) {
      ctx.res.writeHead(302, {
        Location: route,
      });
      ctx.res.end();
    } else {
      Router.push(route);
    }
    return Promise.resolve(false);
  }
  return Promise.resolve(true);
};

/**
 * General HOC that allows redirection based on authentication. We should not
 * expose this: instead export specific routes and redirect combinations.
 */
const withAuthRedirect = (route: string, redirectIfAuthed: boolean) => <P,>(
  Page: NextComponentType<NextPageContext, {}, P>
) => {
  return class extends React.Component<P> {
    static async getInitialProps(ctx: NextPageContext) {
      const shouldContinue = await redirectBasedOnLogin(
        ctx,
        route,
        redirectIfAuthed
      );
      // Only continue if we're logged in. Otherwise, it might cause an
      // unnecessary call to a downstream getInitialProps that requires
      // authentication.
      if (!shouldContinue) {
        return {};
      }
      if (Page.getInitialProps) {
        return Page.getInitialProps(ctx);
      }
    }

    render() {
      return <Page {...this.props} />;
    }
  };
};

/**
 * HOC that redirects to login page if the user is not logged in.
 */
export const withLoginRedirect = withAuthRedirect('/login', false);

/**
 * HOC that redirects to the dashboard if the user is logged in.
 */
export const withDashboardRedirect = withAuthRedirect('/dashboard', true);

Found this helpful or have suggestions? Leave them in the comments below.

Typing Next.js getInitialProps HOCs is tricky, and I had trouble finding an example online.

Versions

At the time of writing, this was using Next 9.

Initializing ReactGA

In your production code, you will initialize react-ga once: most likely whenever your page layout is mounted.

In unit tests, you will receive a warning if ReactGA is not initialized:

ReactGA.initialize must be called first or GoogleAnalytics should be loaded
manually

Instead of initializing manually in each test, we can initialize for all Jest tests globally for our frontend by

In jest.config.js in the root level (note that <rootDir> is intentional; it’s a keyword in the Jest config):

module.exports = {
  setupFiles: ['<rootDir>/lib/testutil/setup-jest.js'],
};

Next, we have lib/setup-jest.js (or whatever path you prefer). Per the setupFiles documentation, this should run exactly once before each test file:

/**
 * Run once before every jest test file.
 *
 * Suppresses warnings related to ReactGA.
 */
import ReactGA from 'react-ga';

ReactGA.initialize('dummy', { testMode: true });

Test example

Note that we reset the apiCalls before each test still (perhaps there is a clean way to get a global beforeEach, but I didn’t see one that didn’t require some level of hackery).

/**
 * An example of a Jest test in Typescript.
 */
import { fireEvent, render } from '@testing-library/react';
import ReactGA from 'react-ga';

describe('analytics', () => {
  beforeEach(() => {
    ReactGA.testModeAPI.resetCalls();
  });

  it('correctly sends timing analytics', () => {
    const { getByText } = render(
      <MyView />
    );

    fireEvent.click(getByText(/somebutton/));

    // An example of testing the timing call.
    const timings: number[] = [];
    for (const call of ReactGA.testModeAPI.calls) {
      if (call[0] === 'send' && call[1].hitType === 'timing') {
        timings.push(call[1].timingValue);
      }
    }
    expect(timings).toEqual([2, 3, 5, 9]);
  });
});

When set up, MockedProvider asserts that any requests that are passed in its setup are called. That is, if you pass in that certain queries are going to be called with certain variables, the test will fail if it’s not called in exactly the same way.

Wrapper library (without Redux)

import { MockedProvider, MockedResponse } from '@apollo/react-testing';
import React from 'react';

interface TestConfig {
  apolloMocks?: MockedResponse[];
}

export const ApolloWrapper = ({
  apolloMocks = [],
}: TestConfig) => ({ children }: any) => {
  return (
    <MockedProvider mocks={apolloMocks}>{children}</MockedProvider>
  );
};

Wrapper library (with Redux)

Redux is commonly used with react, and one can also set up a provider with a store. Note that we use typesafe-actions in this example.

/*
 * These Redux functions should probably be in a different, production library,
 * but they're included here for illustration.
 */
import { combineReducers, createStore, Store } from 'redux';
import { StateType } from 'typesafe-actions';
import { myReducer } from 'path/to/my/reducer';

const rootReducer = combineReducers({
  reducer: myReducer,
});

export type RootState = StateType<typeof rootReducer>;

const makeStore = (initialState = {}): Store<RootState> => {
  return createStore(rootReducer, initialState);
};

// Test wrapper code.
import { MockedProvider, MockedResponse } from '@apollo/react-testing';
import React from 'react';
import { Provider } from 'react-redux';
import { Store } from 'redux';
import makeStore, { RootState } from './store';

interface TestConfig {
  initialState?: Partial<RootState>;
  store?: Store<RootState>;
  apolloMocks?: MockedResponse[];
}

export const ReduxApolloWrapper = ({
  initialState = {},
  store = makeStore(initialState),
  apolloMocks = [],
}: TestConfig) => ({ children }: any) => {
  return (
    <Provider store={store}>
      <MockedProvider mocks={apolloMocks}>{children}</MockedProvider>
    </Provider>
  );
};

Test example

This is an example of a test written using Jest.

import gql from 'graphql-tag';

test('does what it should', async () => {
  const mocks = [
    {
      request: {
        query: gql`<your expected query here>`,
        variables: {
          myVariable: 'foo',
        }
      },
      result: {
        data: {
          // Mock out the return response here. You can also have `result`
          // return a function if you want to do more complicated things.
        },
      },
    },
  ];


  const { getByText } = render(
    <MyComponentWithApolloQuery  />,
    {
      wrapper: ReduxApolloWrapper({ apolloMocks: MOCKS }),
    }
  );

  expect(getByText(/someSubstringRegex/)).not.toBeVisible();

  // This test will implicitly fail here if Apollo is called, for example, with
  // a variable value for `myVariable` other than `foo`.
});

Errors and warnings

Client not in context

For some reason, MockedProvider would not work properly for me in React Testing Library the way that was suggested by the documentation. I kept getting this error:

Invariant Violation: Could not find "client" in the context or passed in as an
option. Wrap the root component in an <ApolloProvider>, or pass an ApolloClient
instance in via options.

In the end, this Spectrum thread helped me to resolve the issue.

Add typename warnings

I never really figured out how to solve these when I was using GraphQL codegen, as the fragments that are generated don’t contain typenames. You’ll likely see warning below, for which I’ve currently not solved this issue (though there are some solutions proposed here).

You're using fragments in your queries, but either don't have the addTypename:
        true option set in Apollo Client, or you are trying to write a fragment to the store without the __typename.
         Please turn on the addTypename option and include __typename when writing fragments so that Apollo Client
         can accurately match fragments.

I usually try to Couchsurf when I travel, though it’s not always possible depending on the popularity of the destination. At the time of writing, I’ve stayed with about ten hosts through my travels.

This post is targeted towards people who are curious about using Couchsurfing as a guest but unsure what to expect from the experience.

Is Couchsurfing safe?

The most common question is: is Couchsurfing safe?

The answer is yes, but use caution. You’re signing up to stay in a stranger’s home, so you definitely want to research your host beforehand. A well-reviewed host is a pretty safe bet.

Couchsurfing works on a reference system; both hosts and guests provide references after the exchange. Personally, I only look for hosts that have a decent number of references (five or more). By definition, this also increases the chances that they’re willing to accept guests.

However, navigating references can be tricky. Even if a guest had a slightly bad experience, negative references are rare; guests don’t want to receive a negative reference in return. This has two implications.

First, even a single negative reference, for both a host or a guest, is considered a major red flag – something very egregious must have happened. Second, finding out whether a host is problematic requires carefully reading reviews. Since guests may tiptoe around directly negative feedback, it’s important to analyze for any hints of negativity dispersed among compliments (e.g., host was too controlling, didn’t show up, etc.).

As an unfortunate reality of the world, Couchsurfing can be more difficult for females. Many articles describe unwanted solicitation from hosts. My recommendation is to prefer female couchsurfing hosts, although those are harder to find. Otherwise, carefully read other females’ reviews for a particular host.

What do you do with your hosts?

There’s no definitive answer - it completely depends on your host.

Different hosts have different personalities, schedules, budgets, and so on. All of them will talk to you, but not all will actually hang out. Your host is not obligated to be your tour guide.

A non-exhaustive spectrum of hosts:

• Hosts that don’t hang out outside of home, often because they host couchsurfers non-stop and can’t afford time-wise to show every guest around the city
• Hosts that work during the day and want to get dinner in the evening
• Hosts that will spend a whole day to take you somewhere or show you around

To illustrate this concretely, here are things I’ve done in the past with my hosts:

• Hiked at a national park and got stuck (Taiwan)
• Walked around for an hour and had a beer (Copenhagen)
• Went to a Noel Gallagher concert (Copenhagen)
• Talked for a few hours, staying only one night (Petah Tiqva)
• Cooked dinner (Venice)
• Ate ramen at home (Seoul)

What are the accommodations?

Similarly, your accommodations vary depending on host.

Hosts will be very annoyed if you treat Couchsurfing like a hostel or hotel. Be considerate, clean up after yourself, and so on: they’re not obligated to provide any services. After all, they’re letting you crash in their home for free. In this vein, most hosts do not give their guests a key, rightfully not wanting a stranger to freely have access to their home.

A few examples of my past accommodations:

• A couch, many times
• Shared a bed with my host, twice (not in any sexual fashion)
• A private room with a bed in a penthouse apartment (super rare, obviously!)
• A guy who had 10+ couchsurfing guests in his apartment at any time with people sleeping everywhere

What can I do to find a host to stay with?

Couchsurfing is a two-way street. The host needs to want you to stay with them, and you need to want stay with the host. From their perspective, they’re inviting a stranger into their home, so you want to present yourself as a respectful and considerate guest.

Couchsurfing hosts, especially in popular destinations, are often spammed with grammar-mangled, copy-pasted requests. Your goal is to stand out from this crowd.

Write a personalized, well-constructed message

Writing a personalized message request will maximize your chances of finding a host. Hosts want to know that you’re asking to stay with them, not just mass-spamming for a free stay. In fact, many hosts’ profiles will ask guests to include some “passphrase” statement to ensure that the requester has actually read the profile.

When I write a request, I always start strong with a few sentences personalized to the host’s profile, then I write a short two or three sentence copy-paste about my visit in the city. If the host wants to find out more about me, the rest is on my Couchsurfing profile.

Here’s an example of a message I sent that introduces me briefly, indicates that I read their profile, and states that I’m flexible about hanging out. The first paragraph is personalized (the host’s profile mentions something about Latin dances); the second one is copy-pasted.

Hey (host name),

My name is Louis, I’m also in IT (I work in the USA as a programmer). I’m going to be in Istanbul for a few days before I travel to Erbil to teach breakdancing, would you be willing to host me for two nights? Unfortunately, I don’t know any Latin dances :(

I’ve couchsurfed many times in the past, and I’m a very respectful and clean guest. I’m also down to hang out or not depending on your schedule – these are weekday dates so I expect you might be working. My schedule is very open to spend time together, except that I may be meeting up with other dancers one of the nights.

Have a well-fleshed out profile

If you are trying to find a host for the first time, having a populated profile is crucial. Again, from the perspective of the host, they can only base their opinion on what they see: profile, messages, references. Although I’ve never hosted, I’ve been told by previous hosts of three profile factors that often contribute to accepting requests:

• References: It’s chicken-and-egg, but it’s hard for hosts to host you if no one is vouching for you. For those starting off, ask any friends who have Couchsurfed in the past to leave a reference. Another option is to meet up with someone in the local Couchsurfing community and get a reference.
• “Proof of existence”: My profile contains a link to this site and my YouTube channel. I’ve had multiple hosts tell me that simply poking around these links made me more trustworthy.
• Couchsurfing verification: Couchsurfing has an option to upload and verify your identity for a fee. One of my previous hosts said that they have a strong preference for verified profiles. I’ve never done verification, but it helps a lot if your profile is just starting off.

Should I bring a gift?

Gifting is universal across cultures, and I recommend bringing or buying a gift for your host – even something small like candy. It’s the thought that counts.

Concluding thoughts

Overall, I’ve had extremely positive experiences with Couchsurfing and would highly recommend it to anyone. I’ve made countless great memories through Couchsurfing, but I’ve only had one “bad experience,” where the host was very controlling. Even that was still fun overall.

In my mind, there are two minor downsides to Couchsurfing:

• Social requirement: during my travels, I sometimes just don’t feel like socializing.
• Less schedule flexibility to go “home.” Since most hosts don’t give you a key, you often have to coordinate with your host. This is especially bad if you’re jetlagged, and you need to get creative to find a place to sleep during the day.

I’m a semi-experienced Couchsurfing guest, but my experience is still a small sample of that of more experienced individuals, such as the power hosts who have hosted over one hundred guests.

If you have any other questions about Couchsurfing, feel free to leave them in the comments below.

This post describes what to expect when going from the Dharamshala Airport to MacLeod Ganj, Dharamshala, India – the central tourist area of Dharamshala.

We took a taxi from the airport to McLeod Ganj for 800 rupees, though the exact price depends on the location of your residence. Go to the prepaid taxi booth and talk to the booth. There will be a number of drivers and a clerk outside of the stand. The drivers may try to circumvent you from speaking to the booth, ignore them temporarily and get the slip signed off. In our case, we ended up getting a lower price confirmed by the booth.