Yes, there’s an em-dash in the title. Yes, I wrote that. By hand. No, I will not stop using em-dashes in my regular writing.

I’m starting to see threads on Reddit and other places where people are alleging the use of AI simply because someone dared to write well, or used appropriate punctuation & typography. And then others reply, saying they’ve started introducing errors in their writing intentionally, to ward off AI Detector bots that seem to think that all well-written text must be AI-authored because humans don’t write that way.

Reminds me of that old joke about a Japanese factory that received an order for widgets which said 3–4 out-of-spec widgets out of a 1000 would be OK, so they dutifully produced a batch with a note: “Our tooling was unable to manufacture the 3-4 broken pieces you asked for, so we had to craft them by hand; here they are.”

The AI is the plagiarizer, not you

AI writes like good writers, not the other way around. LLMs were trained on our hand-written, painstakingly-edited text, so the AI is the plagiarizer, not you. Don’t self-censor your own writing for fear of some half-assed AI Detector claiming you used AI to express your thoughts.

This is broken on so many levels. First, AI Detectors are made from the same probabilistic dust that AI Generators are made from. (And it’s probably a VC-funded startup trying to sell hook you onto a monthly subscription to some snake oil.) There’s really no way to tell with any amount of certainty whether some text was machine-generated or human-authored. (Insert spiderman meme here, with multiple spidermen pointing fingers at one another).

Second, bowing to these stochastic parrots only serves to reinforce the wrong stereotype that only an LLM can produce good prose. This is a false meme we need to fight back against, and the sooner the better.

Good Writing Matters; Good Typography Matters

I’ve been using proper typography in my writing for decades, and I’m not about to stop any time soon. Ever since TeX introduced me to em-dashes (—), en-dashes (–), proper left- (‘) and right-quotes (’), and my personal favorite, the interrobang (‽), I’ve been making sure to use the correct typographical entities in all my writing.

Not just in academic papers or formal blog posts; if I’ve sent you an email or chat in the last ~20 years, you can go back and confirm that I used right-quotes for apostrophes (like this: don’t, not don't), and proper left-double-quotes and right-double-quotes for quotations (like “hello”, not "hello"), not straight double-quotes. (Those are reserved for programming use cases.)

These are only a tiny bit harder to type than the simpler characters that show up on a single key on your keyboard. E.g. on macOS,

• “ is Option + [
• ” is Option + Shift + [
• – is Option + -
• — is Option + Shift + -

It’s even easier on Android and iOS: just hold down the corresponding keyboard keys for longer than usual, and it’ll show you a pop-up with a palette of symbols.

TeX deserves credit for introducing me to proper typography, and for showing why it matters so much. TeX makes it automatic to the point where using proper typography is the well-lit path, and using bad/wrong typography takes additional effort. When you write three hyphens in LaTeX (—), it automatically produces an em-dash. Two hyphens (–) become an en-dash.

Good typography matters. Even though your readers might not notice your attention to detail at every word, they can tell when something looks polished, and when something feels off. Typefaces matter, design matters. And writing well continues to matter.

The Actual Advice

The reason we’ve come to associate em-dashes and en-dashes with LLM-generated text is because LLMs tend to over-use them. An LLM will use an em-dash even where a comma would be more appropriate. It’s like a child who just learned a new word and wants to use it every chance they get.

Be the human writer who understands the nuances among the different kinds of hyphens/dashes.

Maintain your own voice & style, and feel free to use AI to correct typos and punctuation. But don’t let it think for you, or switch up the punctuation to use uncommon marks where they don’t belong.

Most importantly, don’t dumb down your own writing—both prose and typography—to avoid being flagged as an LLM.

From an AI skeptic turned cautiously-optimistic vibe-coding engineer, here are a few specific engineering tasks that can be accelerated using AI.

Slightly Larger Tasks

After the brief warm-up with smaller tasks, I started delegating slightly larger tasks to LLMs.

Stuff I don’t use every day

For a couple projects in Go, I needed to author more complex SQL queries than I’m used to. I haven’t needed to do SQL in any advanced capacity for my day job for a while, so my syntactical knowledge has become a bit rusty. Having an LLM provide a fast first draft ended up being a good accelerator. Of course I made my own edits to it, but the overall structure was better than I might have created myself.

LLMs as a better-integrated StackOverflow

A lot of my browser history has been filled with Stack Overflow links. Some of them useful, many not. LLMs are a game-changer here, because in addition to having ingested all of StackOverflow, they’re also aware of the very specific context of the code that you are trying to write. And it saves me the effort of looking at my error messages, verbalizing them into a question, pasting it into Google, clicking on to StackOverflow, browsing through a bunch of 10-year-old code snippets, and then coming back and tweaking my source until it works.

The “edit → compile → test → lookup error message → go to StackOverflow → fix code” loop is much faster with LLMs.

Writing tests

For every person who loves to write tests, there are 10 others who don’t. Vibe coding is a great aid for those other 10. Are all the generated tests of decent quality? Mostly yes, but some may not be. But the fact that tests exist is by itself a big deal.

For personal projects, I’ve often skipped writing proper tests, but with LLMs I have no excuse not to. I do look over all the generated tests and typically find a few things to tweak or a few more things to add, but having the scaffolding and the skeleton already set up, built, and tested makes that job a lot easier.

Handling edge cases from the get-go

Good test cases already include proactively testing edge cases. But even when asked to author code, I found that agents were better at proactively recognizing and handling edge cases.

If I were the one writing that code, I’d likely have done a first pass for basic functionality, then a second pass to cover all the exceptional cases. The LLM handled it in a single pass, even without having asked it explicitly to do so.

Unexpected win: Migrating code from one language to another

I provided the LLM with a skeleton for a Go language project (that I had developed manually) and an older project of mine using the Ktor framework for Kotlin, and asked it to migrate the Ktor code to its Go equivalent.

It was surprisingly accurate and actually worked well. It did not compile at the first attempt, but the things that were causing it to not compile were absolutely trivial to fix. From beginning to end, it took me about one tenth of the time to use the LLM to bootstrap the project than it would have otherwise. In fact, if it weren’t for the LLM, I would have procrastinated on this migration for far longer, and likely never actually have gotten around to it in the first place. So that’s a win right there.

Hopefully that’s enough encouragement for you to try this out.

It’s not all rosy, though, and here’s what I found didn’t work well for me.

A quick discussion of the Bad Parts

Don’t trust it blindly

Doing a deep, thorough code review of whatever it generates is essential to getting the most out of this tool. Think of it as an IDE on steroids. Or a junior engineer who is still learning the ropes. You would not let them commit code to production without any oversight, so don’t do that with an LLM either. Obvious issues are security-related and the lack of maintainability when LLMs keep piling on bad code on top of bad code.

Auto completions are super annoying

And mostly wrong. I have turned off auto-completions altogether, only access LLMs in explicit Agent Mode (through the side panel, mostly).

Low-quality LLM-powered auto-completions were worse than having none because they were actively distracting me from whatever I was trying to think and type, and causing confusion in my mind, slowing me down.

Source control is your friend

Although you have the option to accept or reject changes after each agent interaction, it goes without saying that you need proper source control to ensure that the changes that the LLM agent is making are sane. Only after a thorough code review does a commit get made. Any changes made after the last commit are easily reviewable in isolation. This is not unique to LLMs or vibe coding; this is just how good software engineering should already be.

Next Steps

I haven’t yet fully given the LLM full reign of my projects. A lot of people have an LLM generate an architecture and an execution plan and have it go run with it without supervision; I haven’t quite gotten that far yet; that’s a topic to explore further in 2026! So far I have only delegated mid-level to lower-level tasks to the LLM and I’m sure at some point I will feel comfortable enough to go a couple levels higher as well.

Pretty much every technology has had its good parts and its bad parts. Vibe coding may be new to the game, but it shares more than a few fundamental characteristics with others that came before it. From an AI skeptic turned cautiously-optimistic vibe-coding engineer, here are a few specific engineering tasks that can be accelerated using AI.

LLM-assisted programming (as with all other things AI) is clearly polarizing, but whether you like it or hate it, you won’t be able to ignore it for long. After having been a skeptic of automatically-generated code for a while, I begrudgingly gave it a try sometime around an year ago. There’s a lot of how-to discussion online about vibe coding for non-engineers, but not much for engineers. (“vibe engineering”?)

But… hear me out

You’ll find a lot of threads on social media about managers forcing engineers to use LLMs, which has the opposite of the intended effect, because nobody likes being dictated to, especially about their own areas of expertise, and especially from people with less perceived expertise in those exact areas.

At the end of the day, treat it as the tool it is. Use it for what it does well. And skip using it where it doesn’t add value.

This article is an attempt to catalog my experiences of what I found it to be actually good at. It’s also a path to slowly getting used to LLM-driven engineering, one small step at a time.

This is authored from the perspective of an engineer who knows how to code and is mostly using an LLM to speed things up. If that describes you, great! If you are not familiar with coding or are just beginning to learn, I strongly encourage you to spend the time to understand the language and framework of your choice. Because in the long run, that will get you much farther than an LLM ever can.

My setup

Just so you can contextualize this, here’s my setup. The precise set of tools I used is not critical; the broader discussion applies well no matter what tools you’re using.

• For personal projects, I’ve been using GitHub Copilot with Gemini 3 Pro as well as Claude Sonnet/Opus 4.5 in VS Code and in JetBrains IDEs (mostly Android Studio, but also IntelliJ IDEA). Since most of my projects are solo side projects, there’s no code review involved.

• At work, I’ve used various internal tools that all rely on models from the Gemini family and integrate with Google’s internal code authoring & code review tools.

Start small

If you’re just getting started, it might feel overwhelming to trust your full workflow to an LLM. The best thing is to start small with low-risk low-impact assistance before you move on to more hands-off Agent Mode tasks.

Generate commit messages

I’ve found automating commit messages to be an excellent way to get your feet wet. You’re still writing all the code, but by letting the LLM draft up commit messages, you can see for yourself how well it understands what you’re trying to do (or not), which may (or may not) eventually convince you to let go and let it drive deeper, more involved tasks independently.

Unexpected change in my behavior: After delegating commit messages to an LLM, I found myself creating smaller commits: E.g. previously, I often updated multiple dependencies at one go: grouped into a single (or a few) commits. Now I typically create one commit per dependency, and the LLM-generated commit message includes details of exactly what changed, and the version each dependency was updated to. Doing this manually would not have been the best use of my time, but with LLMs, the effort I spend is lower than some reasonable threshold, so this has become worthwhile.

(Why not dependabot? Because I like to test each change before committing it, even for minor semver updates).

Automate boilerplate code

One clear win I found for vibe coding was to generate boilerplate: config files, scaffolding, that kind of thing. An LLM by definition is good at pattern recognition and pattern repetition, so boilerplate is something it can accomplish pretty quickly.

(Of course if you can eliminate boilerplate entirely, that should be the first thing you do.)

Generate extremely simple code snippets

When I know the exact logic I want to use for a particular function, vibe coding is like a bicycle for the mind. The kind of thing you’d say to an intern, and they come back a few hours later with code that does what you wanted. Maybe not in the exact same way you’d have done it, but that’s where you come in.

Automated migration from deprecated code

I begrudgingly deal with Gradle for Android development, but that tool is generally a nightmare to deal with, with constantly changing APIs. Every time I update to the latest Gradle version, a bunch of things are deprecated, and a bunch of things stop working. Now I just paste the error message into an LLM, and have it fix it. It generally works.

Extract meaningful info from Screenshots via OCR

I have also found a good use case for personal (non-programming) tasks.

While Tesseract & others are high-quality tools of the pre-LLM era, LLMs have more than caught up, and are able to extract info in a better structured way than plain OCR-based tools ever did.

You can paste a screenshot into an LLM as context. Ask it to extract information from it. Then act on it. And paste the processed results into your source code or a data file. All of this is much quicker than massaging that same data by hand over multiple steps.

Taking screenshots of (HTML) tables on the Web and pasting them into a spreadsheet is made much easier by passing it through an LLM. You would think that pre-LLM tools would also be good at this kind of structured yet mechanical copy/paste & format conversion, but LLMs are miles ahead.

Continue on to the next part

(This got too long for a single post, so I split it up into two.)

There are a lot of guides & docs about what you should do to get promoted, but not much about the typical mistakes most people make, despite following all that other advice.

In order to not get promoted, …

How You Work

• Read all the design docs
  • While not making forward progress on the specific task assigned to you.
• Build an awesome system
  • Without writing a design doc for it first.
• Start a design doc
  • But never finish it.
• Finish a design doc
  • But build something completely different, and never update the design doc afterwards.
• Write a design doc
  • But skip sharing it with others on your team.
• Write a design doc and share it with others
  • But fail to respond to any of the comments left by others.
• Write a design doc, respond to comments
  • But skip following up with approvers/reviewers, leaving the doc unapproved for a long time.
• Write a design doc, follow up with approvers/reviewers and discuss open comments offline
  • But skip documenting the final resolution with rationale and closing the comments
• Write a design doc
  • The week before Promo Packets are due (yes, I have seen this happen and it’s obvious from version history…)
• Write great design docs
  • But fail to set permissions so the promo committee could view the doc + version history + resolved comments.

How You Collaborate

• Be a great engineer
  • But an awful collaborator. (At higher levels, your collaboration skills become more important than pure technical skills.)
• Be a thorough code reviewer
  • But nitpick to the point that folks can’t submit any code
• Do community work: interviews, mentorship, hiring committee, etc.
  • But not have enough time left over for core technical contributions
• Do a lot of glue work
  • But only glue work, ignoring core technical contributions on which you’ll be evaluated
• Do your own tasks diligently
  • But refuse to help others because your plate is always full
• Contribute to a bunch of random projects
  • But fail to be recognized as an owner / authority / point of contact for any one of them
• Attend a lot of meetings
  • With little to show for the time spent in them
• Take full credit for partial contributions
  • Promo committees can easily see if two or more people are taking credit for largely-overlapping work. Be precise in what you are claiming as your own, & explain the role of collaborators if you want to get promoted.

Launches

• Run into an issue during launch
  • But instead of highlighting how you fixed it, what you learnt and how you grew from it, attempt to cover it up in the promo packet.
• Stay up nights and weekends
  • Without identifying or articulating process changes to make it unnecessary to stay up nights and weekends in the future.
• Build and launch an awesome system
  • But apply for promo before the launch has been validated in Production (no metrics ⇒ no promo)
• Build and launch an awesome system with metrics
  • But fail to explain why it was impactful, or why the metrics matter
• Apply for promotion with a decently-strong packet
  • But 6 months too early, while there are still gaps in your next-level readiness in specific areas

Manager Related

• Have a career goal or career development questions in mind
  • But fail to have regular in-depth career conversations with your manager
• Work on projects assigned by your manager
  • Even though you hate them, without providing this feedback to your manager so they could instead reassign you to something you are passionate about
• Have a perfect story crafted for your career trajectory
  • But end up reporting to a manager who cannot convincingly narrate it to a committee
• Have a great packet written by your manager
  • But fail to get feedback from a few others to make sure it’s airtight
• Be the senior-most person in every room
  • With no senior collaborators who can attest to your readiness at the next level

Mindset

• Obsess about promotion
  • Such that every decision at work becomes about whether it will get you promoted or not (Seriously, this does not help at all. Makes things worse for you, your manager, and your team if promo is the only thing on your mind).
• Obsess about promotion
  • Ignoring your personal life, family, friends, and overall happiness. Your ultimate goal should be happiness; career progress is but one element of it.
• Assume you are ready for level L+1
  • When the overwhelming majority of your peers, collaborators, and your manager repeatedly try to tell you that you aren’t. (Listen to others, read between the lines, and don’t assume you know better)
• Do great work in some months
  • But slack off in other months. A consistent growth trajectory is key.

Org

• Keep working hard
  • But on the “wrong” team 🤷
  • Wrong is subjective, but if you’ve been on a team for > 12-18 months and have not had any major launch or impactful delivery to show for it, that’s not good for your promo case.
• Be ready for promo
  • But in an org full of other strong performers, who are all ready for promo in the same cycle.

So you followed all the advice in this doc, applied for promo, and failed. Now here’s how you might get rejected again the next time.

Got rejected?

• Fail to get promoted
  • And be sad about it for more than 2 weeks. Take some time to get over it, then get over it.
• Go up a second time for promotion after a rejection
  • But fail to directly address the areas for development pointed out by the previous committee/session

Or, if eventually you do get promoted…

Congratulations!

Though, keep in mind: If you do get promoted when you are not fully ready, you risk not being able to meet your expectations at the next level. This can have much more serious consequences than if you had not been promoted in the first place (and thus continued to be measured against previous-level expectations).

Not every version is a major release, so we also don’t want to show a large in-your-face message every single time the app is updated.

Some features are important enough that if existing users found out about them, they might start using the app more. But if they’ve abandoned the app (installed, but not using it), they won’t even find out about the new features if they never opened the app.

This is where having a well-defined version structure comes into play. If you haven’t yet read my post about managing your Android build’s major, minor and patch versions individually, now is a good time to do that! This post relies on that structured versioning approach.

Here’s how my app does it. People seem to like it, we’ve heard zero complaints about any of it, and we see bumps in usage when highlighting new features.

• For a patch release, do nothing. Ideally, a revision release (or patch release) only fixes existing bugs & makes unimportant improvements to the overall UX, so let those speak for themselves.
• For a minor release, show an in-app snackbar with a button to open the full changelog. Never open the full changelog, which interrupts the user’s flow.
• For a major release, show a low-priority notification with no vibration and no sound, showing a brief snippet for the new features.

Here’s the code:

Android can tell us when our app gets updated. This is the perfect callback to hook into.

public class PackageUpdateReceiver extends BroadcastReceiver {
  @Override
  public void onReceive(Context context, Intent received) {
    if (Intent.ACTION_MY_PACKAGE_REPLACED.equals(
        receivedIntent.getAction())) {
      onUpgraded(context, BuildConfig.VERSION_CODE);
    }
  }
}

Make sure your AndroidManifest.xml is set up for receiving these broadcasts, by subscribing to the system standard broadcasts for android.intent.action.MY_PACKAGE_REPLACED.

<receiver android:name=".PackageUpdateReceiver">
  <intent-filter android:priority="1000">
    <action android:name="android.intent.action.MY_PACKAGE_REPLACED"/>
  </intent-filter>
</receiver>

The first thing we do in onUpgraded is to check if we should show a notification.

private void onUpgraded(Context context, int versionCode) {
  if (shouldNotifyOnUpgraded(context, versionCode)) {
    notifyOnUpgraded(context, versionCode);
  }
  maybeShowSnackbarOnNextAppLaunch(context, versionCode);
  // This must be the last line in the method; previous methods 
  // use this value to determine the “old” version installed.
  Prefs.edit(context).putInt(Prefs.INSTALLED_VERSION,
      versionCode).apply();
}

showNotifyOnUpgraded checks if the major version of the app has changed from the last one recorded. Pretty straightforward.

/**
 * Notify the user if and only if the major version (first component
 * of major.minor.patch version) is strictly greater than the 
 * current version. This ensures that we notify the user no more
 * than once every major version.
 */
private boolean shouldNotifyOnUpgraded(Context context, 
                                       int versionCode) {
  // If user has opted out of notifications, never notify.
  if (!Prefs.get(context).getBoolean(
      Prefs.NOTIFY_ON_UPGRADES, true /* defaultValue */)) {
    return false;
  }
  int lastMajorVersion = 
      Prefs.get(context).getInt(Prefs.INSTALLED_VERSION, 0) / 10000;
  int currentMajorVersion = versionCode / 10000;
  return currentMajorVersion > lastMajorVersion;
}

Now comes the actual notification. In the interest of clarity, we leave out the bits where we use an image loader to grab a bitmap off the main thread, and highlight only the call to the NotificationManager.

private void notifyOnUpgraded(Context context, int versionCode) {
  PendingIntent openedPendingIntent = PendingIntent.getBroadcast(
      context, 0, new Intent(
          Constants.Actions.ACTION_UPGRADE_NOTIFICATION_OPENED),
          PendingIntent.FLAG_UPDATE_CURRENT);
  PendingIntent optOutPendingIntent = PendingIntent.getBroadcast(
      context, 0, new Intent(
          Constants.Actions.ACTION_UPGRADE_NOTIFICATION_OPT_OUT),
          PendingIntent.FLAG_UPDATE_CURRENT);
  NotificationCompat.Builder upgradeNotification = 
     new NotificationCompat.Builder(context)
          .setSmallIcon(R.drawable.ic_whatshot_grey600_24dp)
          .setLargeIcon(bitmap)  // Code left out for clarity.
          .setAutoCancel(true)
          .setContentTitle(context.getString(R.string.new_features))
          .setContentText(context.getString(R.string.app_version))
          .setContentIntent(openedPendingIntent)
          .setPriority(Notification.PRIORITY_DEFAULT)
          .addAction(new NotificationCompat.Action(
              R.drawable.ic_whatshot_grey600_24dp,
              context.getString(R.string.whats_new),
              openedPendingIntent))
          .addAction(new NotificationCompat.Action(
              R.drawable.ic_remove_circle_outline_grey600_24dp,
              context.getString(R.string.dont_show), 
              optOutPendingIntent));
  NotificationManager notificationManager = (NotificationManager)
      context.getSystemService(Context.NOTIFICATION_SERVICE);
  notificationManager.notify(UPGRADE_NOTIFICATION_ID,
      upgradeNotification.build());
}

@Override
public void onReceive(Context context, Intent receivedIntent) {
  if (Intent.ACTION_MY_PACKAGE_REPLACED.equals(
      receivedIntent.getAction())) {
    onUpgraded(context, BuildConfig.VERSION_CODE);

  } else if (Constants.Actions.ACTION_UPGRADE_NOTIFICATION_OPENED
      .equals(receivedIntent.getAction())) {
    cancelNotification(context);

    Intent showWhatsNewIntent = new Intent(
        context, MainActivity.class);
    showWhatsNewIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    showWhatsNewIntent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK);
    showWhatsNewIntent.addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP);
    context.startActivity(showWhatsNewIntent);

  } else if (Constants.Actions.ACTION_UPGRADE_NOTIFICATION_OPT_OUT
      .equals(receivedIntent.getAction())) {
    cancelNotification(context);

    Prefs.edit(context).putBoolean(
        Prefs.NOTIFY_ON_UPGRADES, false).apply();
    Toast.makeText(context, 
        R.string.upgrade_notification_turned_off, Toast.LENGTH_LONG)
        .show();

    Intent showSettingsIntent = new Intent(
        Constants.Actions.ACTION_SHOW_SETTINGS, null /* uri */,
        context, MainActivity.class);
    showSettingsIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    context.startActivity(showSettingsIntent);
  }
}

Finally, for changes to the major version or the minor version, we will show a snackbar inside the app. For that, we don’t do any actual processing inside PackageUpdateReceiver; we simply set a SharedPreference that the main Activity (or Fragment) reads. If true, it shows a snackbar and then clears the bit.

/**
 * Set up a SharedPreference for whether to show a “What’s New”
 * snackbar the next time the app is launched. This is done for all
 * minor versions, which, by definition, have a user-noticeable
 * feature. This is not shown for patch versions (e.g. going from
 * 1.2.7 to 1.2.8) because patch releases are bug-fix-only or minor
 * enhancements only.
 */
private void maybeShowSnackbarOnNextAppLaunch(Context context, 
                                              int versionCode) {
  int lastMajorMinorVersion =
      Prefs.get(context).getInt(Prefs.INSTALLED_VERSION, 0) / 100;
  int currentMajorMinorVersion = versionCode / 100;
  if (currentMajorMinorVersion > lastMajorMinorVersion) {
    Prefs.edit(context).putBoolean(
        Prefs.SHOW_WHATS_NEW_ON_NEXT_LAUNCH, true).commit();
  }
}

Throughout this example, Prefs is a singleton convenience wrapper for the SharedPreferences class. This is what it looks like:

public class Prefs {
  private static SharedPreferences preferences;

  private Prefs() {
  }

  /**
   * @return A read-only instance of this app’s default
   * {@code SharedPreferences}.
   */
  public static SharedPreferences get(Context context) {
    if (preferences == null) {
      preferences =
          PreferenceManager.getDefaultSharedPreferences(context);
    }
    return preferences;
  }

  public static SharedPreferences.Editor edit(Context context) {
    return get(context).edit();
  }
}

Update: I posted a new article which uses the setup from this article to inform your users whenever an app is updated with new features.

As you know, every Android app must declare an app’s versionCode (a monotonically increasing integer for each version of the app), and versionName (a text description which can really be anything, but is usually a human-readable version string of the form x.y.z (major version, minor version, patch level). An app’s versionName is usually shown within the app in the About screen, and in other places, such as when sending a bug report. Here’s how you can specify everything in exactly one place and use it everywhere needed.

Define individual components of the version number

Start off with defining individual components of the version number—major version, minor version and patch level—as separate Gradle variables. This is the one place you’d update the numbers for every version you release.

module/app.gradle:

def versionMajor = 2
def versionMinor = 4
def versionPatch = 1

Compute values for versionCode and versionName

Then have Gradle compute the versionCode from these three components as a place-value-based number. The versionName is a straightforward string concatenation of the three components.

module/app.gradle:

android {
  defaultConfig {
    applicationId “com.you.app”
    versionCode versionMajor * 10000 
                + versionMinor * 100 
                + versionPatch
    versionName “${versionMajor}.${versionMinor}.${versionPatch}”
  }
}

This will, for example, assign a version code of 20401 for an app with version 2.4.1. That gives you the possibility of 100 minor versions for every major version, and 100 patch levels for every minor version. Seems enough, right?

Generate a string resource

Next, have Gradle generate a string resource for you automatically, which you can use in your about app’s XML layouts & Java code (as @string/app_version & getResources().getString(R.string.app_version) respectively).

module/app.gradle:

buildTypes {
  debug {
    versionNameSuffix ".debug"
    resValue "string", "app_version",
             "${defaultConfig.versionName}${versionNameSuffix}"
  }
  release {
    resValue “string”, “app_version”,
             “${defaultConfig.versionName}”
  }
}

Identify your debug releases

The code snippet above adds .debug to the versionName of all debug releases, so if you see one of these in your logs, you’ll know this wasn’t a release that your users saw — phew! The resource value isn’t automatically updated when we add a versionNameSuffix, so we handle that separately for the debug build type.

Check your generated AndroidManifest.xml

Now if you look at your generated AndroidManifest.xml, you’ll see that it has the correct auto-generated versionCode and versionName. Note, this is under the build/ directory, not the one in your app/ directory.

build/intermediates/full/debug/AndroidManifest.xml:

<manifest xmlns:android=”…"
   package=”com.you.app”
   android:versionCode=”20401"
   android:versionName=”2.4.1.debug”>

Show the version in your About screen

If you use a Preference-based About screen, simply use the generated string as the preference value.

about.xml:

<Preference
    android:summary="@string/whats_new"
    android:title="@string/app_version" />

Use it everywhere you need to identify a specific release.

You can use it in the subject of your “Send feedback” email, or as part of your analytics reporting, or in your app upgrade tutorials. And if you need to read it into a Java variable, that’s as straightforward as getResources().getString(R.string.app_version).

FeedbackUtils.java:

static void sendFeedbackEmail(Context context) {
  Intent emailIntent = new Intent(Intent.ACTION_SENDTO,
      Uri.fromParts(“mailto”, "support@example.com", null));
  emailIntent.putExtra(Intent.EXTRA_SUBJECT, 
      context.getString(R.string.email_title, 
          context.getString(R.string.app_version)));
  emailIntent.putExtra(Intent.EXTRA_TEXT,
      context.getString(R.string.email_body));
  context.startActivity(Intent.createChooser(emailIntent,
      context.getString(R.string.send_feedback)));
}

res/values/strings.xml:

<resources>
  <string name="email_title">Feedback about App %1$s</string>
  <string name="email_body">Hello!</string>
  <string name="send_feedback">Send feedback</string>
</resources>

Why not BuildConfig?

There is another approach that recommends putting these fields in BuildConfig, which makes it available to your code as a generated Java source file, BuildConfig.java.The problem is, there is no associated XML string, so using it in layouts, menus, preferences, and other strings is not straightforward. By exporting it as a string resource, you gain the flexibility to use it either as a resource or as a Java string.

Automate everything that is not primary to the task at hand

And spend that saved time on new features!

A seamless user experience when upgrading

When a user decides to buy your app, they can simply tap a button and be upgraded instantly. With two separate apps, they must uninstall the free one and then download the paid one. Whatever progress they may have made so far (saved data, trained models) will be lost.

Preferences are maintained even after upgrading

No additional work is necessary for a user’s preferences to be shared between the free app and the paid app, because it’s the same app.

With the two-app approach, users either have to start from scratch, losing all their settings, or you, the developer, have to take additional steps to ensure that preferences are correctly migrated. And even then, the experience is not seamless, since users now have to authenticate or perform import/export steps themselves.

With a single app, this is a non-issue, and offers the smoothest user experience. If you have a server-less app, this will save you the effort of having to stand up any kind of server-side support.

Launcher clutter & icon placement

Some apps require you to have both the free and the paid version installed on the device for the whole system to work correctly in paid mode. This means that both apps appear separately in the launcher, most likely next to each other. Tapping on the wrong one elicits a message to the tune of “hey, this is just the key; go open the other one instead.” This is not a good user experience.

A single app provides a single entry point, and eliminates any user confusion stemming from duplicate apps. During the upgrade, if users take the time to place your app’s icon on their home screen, they no longer have to remove and replace that icon with the paid app’s icon. Everything just works.

Maintaining two app variants is hard

Although you can configure Gradle to build multiple flavors of your app, you have to take extra engineering steps to ensure that both build and work correctly as expected. Testing efforts are duplicated (or at least 1.5x) with two separate APKs.

Bad for SEO (Search Engine Optimization) & ASO (App Store Optimization)

There are now two listings on the Play Store, splitting the SEO juice you’re getting. Reviews, reports, and inbound links to your app get divided between the two versions.

Easier to pirate a full-featured APK

If the paid version offers all the features unlocked, users may find it easier to pirate that APK elsewhere and offer it to others unlicensed. Since in-app purchases are activated within the app, and it’s possible to require license verification with your own server, those are harder to pirate than full-featured APKs.

Also, IAPs cannot be refunded on Google Play (unlike purchased apps, which can be refunded within a 15-minute window for full price). This can cut down on piracy from users who would otherwise download the paid APK (after paying for it), then copy the APK off the device, refund it, and then reinstall from the copied APK.

Multiple price points possible with IAPs

Any more than two separate apps and the multiple-app model fails to scale well. But with a single-app-with-IAPs, it’s easy to set up per-feature prices in addition to a strict dichotomy between Free and Paid. Some features might be worth a lot more, such that even most Paid users would not care about them. It’s possible to charge only those users who are likely to need that feature, while keeping the rest of the app free/cheaper for everyone else.

Offer value, not annoyance removal

Don’t charge your users simply to remove an annoyance (such as ads). Charge them to use a feature they would love using (and love to pay for using). Offer a time-limited trial of the paid version so they’ll know what to expect. The code is in there already (since it’s a single app!), so just unlock it for the first 24 or 48 or 72 hours, and let them get a taste of what the full-featured version looks like. Keep them aware that this is a time-limited trial, and offer them incentives to upgrade even before the trial period is over. And then, if the user chooses not to purchase, just lock the feature up beyond the trial period.

What’s your experience so far?

If you’ve experimented with these issues, I’d love to hear what your experience has been! What do your users say about your app? What hypotheses have your analytics confirmed / failed to confirm?

TheNextWeb argues that changelogs for each client update should be “useful”, but that’s sometimes neither possible, nor desirable.

There are several reasons for this.

The release train model

Many large app publishers follow a release train model. They don’t wait to push app updates until a new feature is ready. They’ll push every two weeks (as Facebook say in their release notes), or once a month, or at some other predetermined interval.

This ensures that important bug fixes unrelated to upcoming features are not held up for indeterminate amounts of time. It makes sure that delays in one feature do not impact other unrelated features. If a feature is ready for a particular release, it gets enabled in the shipping release; if not, it gets cut from that release and can be enabled in the next one.

In such a release model, it’s hard to write accurate release notes and keep them accurate throughout the release testing phase. It risks leaking confidential features before they’re ready. It risks raising user expectations and then shattering them if a feature does not make the cut.

Server-side feature rollout

Some features in large apps are controlled server-side. Client apps are published according to each platform’s review delay timelines. iOS apps need to leave time for a review by Apple. Android apps need time for review by Google. Coordinating all of these to launch a feature at a specific time is tricky.

New features are often rolled out in stages. When feature rollout is controlled server-side, it can be enabled for 1% of users first, then 10% and so on, up to 100%, across Android, iOS, and Web. Managing this rollout entirely server-side is much easier than trying to do it client-side, e.g. through individual app store staged rollouts.

For the 90% of users who have not yet seen a feature enabled when the rollout is at 10%, the changelog will be flat out incorrect. It’s best to leave it out and announce the feature in-app when it’s enabled for that specific user.

A/B experiments

Even after a feature has been rolled out widely, there will be tweaks made between individual users. If you start listing all the combinations of A/B experiments going on at any given time, the combinatorial explosion will make the changelog impossible to read or parse.

Some A/B experiments must be kept secret from the users; if you reveal too much about what is being tested, you tend to skew the results of the experiment. Such experiments need to be kept away from media attention as well, lest a subset of potential users in affected buckets go on to read about them. There is nothing nefarious in this; just proper experiment design that requires that participants not be aware of what is being evaluated.

Upgrading across multiple versions

What should a changelog say when you go from version 1.0 to version 6.0 in one fell swoop? That sometimes happens, if app update checking mechanisms have been misconfigured, or an app requires manual approval for updates.

In such cases, what should a changelog meaningfully say? Should it aggregate all changelogs between 1.0 and 6.0? Should it show only the delta between 5.9 and 6.0? It’s just not feasible or practical to list exactly the set of things that are new in the most recent update because you may never know the baseline from which the user is upgrading.

Humor is part of branding

Changelogs that make me chuckle are a nice touch on otherwise bland days. Some brands explicitly espouse humor as part of their branding. Including playful funny text (well, funny to some, perhaps) is their way of strengthening their brand, of grabbing the attention of new users, and subtle advertising. What’s the harm in that?

Instead, prefer in-app promos or mentions

Not all users will read changelogs, so even if they contain useful information, it will likely be skipped. If you want to convey to your users when a new feature is ready for them, or want to highlight how to use it, prefer to use in-app mentions or promos. A quick text field with a line or two of text, or a bubble with a link, can be far more informative than putting that same information in a changelog.

Of course, make sure you don’t interrupt the user flow or annoy them with these promos.

If you have a Canon 5D Mark II, and looking to geotag your photos, here’s a solution cheaper than the official Canon accessory — it happens to be a Canon compact camera.

Every place has its memories, and every memory its place. Having information about places embedded in photos and videos serves to link the two. We’re in an age where capturing every bit of metadata is certain to lead to interesting applications in the future. I’ve been geotagging my photos since 2006 or so using a Garmin eTrex series GPS logger. These days, many cameras have built-in GPS hardware and loggers which make the job trivial — just turn the option on. But not many SLRs have them yet. Canon sells a kit for the 5D Mark II which is insanely expensive. (US$699 retail — crazy, right?)

My solution: I recently bought a Canon PowerShot D20, which is an awesome camera in its own right. It has a GPS logger that can be turned on and left on even when the (rest of the) camera is off. And its effect on battery life is minimal enough that I could get about two–three days’ worth of photos & logs on a single charge. Of course, you could use any

Next, I used GPS Visualizer’s Convert to GPX tool to convert from Canon’s GPS log format to GPX, a fairly standard format. I tried GPSBabel, but I couldn’t find the right format to pick as the input format (despite a lot of Googling), so it never worked for me.

After that, I used GPSPhotoLinker, a great tool for Mac OS X, that reads tracks and waypoints in GPX format, and embeds that info into a set of photos as EXIF tags.

Once thus embedded, almost all photo tools that are geo-aware can make use of this info. You can see them on a map on Flickr, view related photos on Panoramio, and what have you.

1. www. We’ve spent enough time with the World Wide Web to know that web pages reside on the WWW. Adding those four characters to the beginning of every single URL not only requires users to type them in every time, but also requires 4 extra bytes in every single database that stores URLs. Think for a moment how many bytes that would be. Get rid of them! And after you do that, make sure all your www. URLs redirect to the non-www. version.

2. Port numbers. Unless your site is under test, there is no valid reason for hosting it on a non-default port (i.e., a port other than 80.) Apache on Mac OS X has a performance cache that runs on port 16080, and makes every URL of the form https://your-site.com:16080/. Unless you find a mechanism to run the performance cache on port 80, it is a good idea to dump the cache. It’s not worth the confusing URL (to most users, if not to you.) Standard well-known port numbers are there for a reason.

3. Index filenames. Filenames such as index.php and default.asp do not give us any more information than the rest of the URL. Drop them.

4. Details of the server-side technology. Your users don’t need to know what software you’re running behind the scenes. They couldn’t care less about whether your pages are .php, .jsp, .aspx or .do. It’s best to configure your server to hide these extensions, and then make sure none of your URLs contain them.

5. Special directories for special scripts. You no longer need to place your scripts in a cgi-bin. Get rid of that directory and any others like that. If your server requires you to do something like that, either find a way to configure it correctly, or upgrade to one that will let you do that.

6. Document maintainers’ names. Often, when each document has an assigned maintainer for some duration of time, those documents end up being in that particular person’s web space. Later, when the maintainer moves on or someone else takes over the maintenance, you’re left with a different URL than what you started with. To avoid this, it’s best to categorize documents by topic and subject instead of under ~username/document.html.

7. Internal database IDs. Sure, your content management system needs those IDs to locate your content, but your users don’t need to know. If it takes an extra database lookup to get the ID from the URL, then so be it.

8. CMS Module Names. Use a CMS that is intelligent enough to render a page without needing all sorts of information stored in the URL. Joomla is particularly notorious at this. What does this URL tell you about where it will take you?

   https://www.joomla.org/content/section/1/74/

   Now what if it were:

   https://joomla.org/news

9. MiXeD-CaSe NaMeS. Don’t confuse your users by-Mixing-Upper-case-and-Lower-case-Characters-in-the-URL. Stick to lower-case letters, and don’t make them guess. If your user actually types in a URL in mixed case, normalize it on the server and serve the appropriate case.

10. Random gunk. Unless you are a URL-compressor service such as Tiny URL or SnipURL, forget using random characters in your URL. Nobody wants to visit https://yourdomain.com/WijHyYQnVPWNs and guess what it might lead to.

11. Session IDs. Make sure no user-session-specific identifiers end up in your URLs. This makes sure that users can pass on URLs to other users via email or IM, be able to bookmark them, and be sure that they represent a single resource. There are better places to keep session state in.

12. Punctuation. Avoid punctuation that might make it difficult for people to tell others about your wonderful site over the phone. The only punctuation you may have is a hyphen (“-“) and HTML entities that have special meaning (e.g. ?, #, :, + and @). No underscores, commas, periods, brackets, parentheses, braces, quotes, less-than, greater-than, equals, or pipes.

13. Database query details. If your web pages have even a hint of database query language in the URLs, you should be on The Daily WTF.

14. Repeated domain name. If the address of your web site looks like https://your-site.com/your-site/your-page.html, then you should have a chat with your web hosting provider about how to shorten it to https://your-site.com/your-page.html.

15. Inconsistent naming. If you sell several products, then make the subdirectories below each product name exactly identical. If someone were to replace a product name by another, the rest of the URL structure should still continue to function. In other words, strive for consistency in naming.

16. Missing content at each level. When a URL is several levels deep, users should be able to chop off parts at the end (“hack the URL”) and still be able to get to a usable page. E.g. if you’re a news site, and if an example URL looks like: https://my-news-site.com/2008/05/21/news-story.html, make sure you include a list of news articles from 21 May 2008 at https://my-news-site.com/2008/05/21/, and a list of links to daily articles for the entire month of May 2008 at https://my-news-site.com/2008/05/.

There are some easy technological solutions to make this work. Many of these do not require you to change the underlying file system structure or database structure.

But most of this comes with discipline: there is nothing here that is technology magic. It is just an application of common sense to a common domain (no pun intended.) Google mod_rewrite and content negotiation to get started.