Alessandro Bahgat's Blog

Visualizing Ukkonen's Suffix Tree Algorithm

Mon, 09 Mar 2026 15:31:00 GMT

Learning algorithms from books

I learned most of what I know about algorithms by poring over a copy of Introduction to Algorithms I got while in university. The book is very well known, especially among folks who got a formal education in computer science.

If you have studied it, you know the book: it is over a thousand pages long and it weighs enough to double as a doorstop.

I worked through large sections of it, pen in hand, trying to trace through increasingly complex algorithms, building intuition for their behavior and tradeoffs. The book covers the theory in great depth: correctness proofs, recurrence relations, asymptotic analysis.

But there was often a gap between reading an algorithm and truly understanding it. The book would present pseudocode, sometimes a few diagrams showing state at key moments and theorems about performance characteristics. The work of tracing what actually happens was left as an exercise to the reader. I did that work with pen and paper, drawing trees, crossing out nodes, scribbling indices in the margins. It worked, eventually. But it was slow, error-prone, and the understanding felt fragile.

Implementing from a paper

Years later, I ran into this gap again. I was working on a programming puzzle that required near-instant substring search over a large dataset. After some research, I settled on a Generalized Suffix Tree: a data structure that indexes all suffixes of a set of strings, enabling $O(m)$ lookups where $m$ is the length of the search pattern, even over an extremely large corpus.

The algorithm I chose for building the tree was Ukkonen’s, described in a 1995 paper. The paper is well written and includes the full algorithm in pseudocode:

One of several pseudocode snippets from Ukkonen's paper, describing the update function. Clear on paper, but its translation to working code is much more verbose than this.

It took me a few hours to get right. Not because the pseudocode was wrong: it was precise and correct. The difficulty was that the algorithm manipulates a tree in non-obvious ways. There is an “active point” that walks around the tree. Suffix links connect internal nodes as shortcuts. Three different extension rules fire depending on what is already in the tree and what is being added. The pseudocode tells you what to do, but building an intuition for why it works requires watching it happen.

I did what I always did: I sketched trees by hand. I traced the algorithm on the string cacao, then on banana, drawing and redrawing nodes and edges as each character was processed. When my Java implementation finally produced correct results, I was relieved, but my understanding of the algorithm still felt like it had been assembled from fragments.

The biggest frustration was that I had no way to inspect what my code was actually building. I relied on the usual bag of tricks: print statements, breakpoints, inspecting memory structures one by one in a debugger. But that is like understanding a forest by looking at one tree at a time. What I wanted was to see the whole data structure after each operation — to watch the algorithm work.

The visualization I wish I had

That idea stuck with me: build the algorithm in a language where rendering the data structure is easy, then step through the construction visually. JavaScript and D3.js are a natural fit: the algorithm produces a tree, and D3 is very good at drawing trees.

So here it is. The visualization below builds a suffix tree for the string banana using Ukkonen’s algorithm, step by step. Use the playback controls to move through the construction. The gold-highlighted node is the active point. Dashed arcs are suffix links.

Press play to watch the tree being built

Add a string to begin building the suffix tree.

The paper describes the core logic across Sections 2–4. Here is test_and_split, the procedure that decides whether the tree needs to grow, which is a companion to the update function we showed earlier:

Procedure test_and_split from Ukkonen's paper. It returns true when the next character is already in the tree (the end point), and false after splitting an edge to make room for a new branch.

A few things to watch for in the visualization — each one corresponds to something in this procedure:

Branching in update: when test_and_split finds no existing transition for the next character, it splits the edge if needed and update creates a new leaf. These are the moments where the tree visibly grows.
Reaching the end point: when test_and_split finds that a transition for the next character already exists, the algorithm has reached what the paper calls the end point of the current phase. All remaining suffixes are already represented implicitly, so the phase stops. This is the key to the algorithm’s $O(n)$ time: the end point can only move forward through the string across phases, bounding the total work.
Suffix links (the paper’s suffix function $f$ ): if an internal node has path-label $x\alpha$ , its suffix link points to the node with path-label $\alpha$ . The update procedure follows these links to jump to the next insertion point instead of walking from the root every time.
Finally, the ”$” terminator converts an implicit suffix tree, where some suffixes may end mid-edge, into an explicit one where every suffix terminates at a distinct leaf.

Adding more strings

A generalized suffix tree indexes multiple strings. Each string is added with its own terminator, and the tree grows incrementally. Below, panama is added after banana. Step through and notice how much of the tree structure already exists from the first string.

Press play to watch the tree being built

Add a string to begin building the suffix tree.

Searching

Once the tree is built, searching for a pattern means matching characters along edges from the root. The visualization below has both strings pre-loaded. Try searching for ana, then try pan, ban, xyz.

Press play to watch the tree being built

Add a string to begin building the suffix tree.

Try it yourself

An empty tree, yours to experiment with. Add strings, watch the construction, search for patterns. Use the scroll wheel to zoom and click-drag to pan if the tree gets large.

Press play to watch the tree being built

Add a string to begin building the suffix tree.

Beyond suffix trees

What excites me most is how well this generalizes. The gap between an algorithm on paper and an algorithm in memory has always been one of the hardest parts of learning computer science. Textbooks give you static diagrams. Debuggers give you one node at a time. Neither shows you the whole picture in motion.

Browser-based rendering, interactive SVGs, and JavaScript engines fast enough to run non-trivial algorithms client-side make it possible to close that gap for almost any data structure. Red-black trees, B-trees, tries, skip lists, hash tables with open addressing: all of them would benefit from this kind of treatment. Not as a replacement for the theory, but as a companion to it. Read the algorithm, then watch it work.

There is an obvious question lurking here: why bother learning algorithms at all when you can ask an LLM to write one for you? I think the question misses the more interesting possibility. LLMs are not just code generators; they are learning accelerators. You can ask one to explain a single step of an algorithm, to walk through an edge case, or to generate a diagram of how components interact. When I started working in a new codebase recently, the fastest way for me to build a mental model was not reading code or documentation. It was asking an LLM to produce component and sequence diagrams: a much higher-bandwidth channel for understanding, at least for the way I think.

That is the real shift. Not that machines can write algorithms so we don’t have to learn them, but that they can teach us in ways that adapt to how each of us actually learns. Through visualizations, through diagrams, through conversation, through whatever representation makes the concept click. This post is one example. The next one might look completely different, tailored to a different person and a different way of thinking.

We write fewer algorithms from scratch in our day-to-day work than we used to. But we still benefit from understanding them, whether it’s to choose the right data structure, to debug performance issues, or to evaluate tradeoffs. And for those of us who enjoy algorithms for their own sake, the tools for learning them have never been better.

The original Java suffix tree implementation is open source on GitHub. For the full backstory, see the project page and the story of the programming puzzle that started it all. Ukkonen’s original paper remains the definitive reference for the algorithm.

The Velocity Paradox

Mon, 23 Feb 2026 20:30:00 GMT

We’ve all been there. You sit down with an AI agent on a Saturday morning to hack on a side project and it feels like magic. Ten minutes in, you are blown away by how quickly the agent can turn even poorly organized thoughts into working prototypes. You feel like you could do this all day.

And clearly, many of us do: we’re rediscovering our passion for side projects, and every day a thousand bespoke ToDo apps are born, perfectly tailored to the unique needs of their creators.

At the same time, if you’re in an engineering leadership role, you’re also seeing your stakeholders dabble with agentic coding. They are shipping side-hustles on the weekend, and respectable work applications in an afternoon. Some of them might even look at you with ill-concealed suspicion. They want to know why their “pet feature” is stuck in a two-week cycle when they just whipped up a functional prototype over coffee.

And they aren’t entirely wrong. AI agents have been writing 100% of my code for several months now. Informed by the wins on my side-projects, I wanted to see how much faster we could build at work. During the holiday break, I spent a few hours having Claude write a non-trivial feature that touched our database, cloud infra, mobile app, and the embedded application that runs on our hardware devices at Quilt. What would have taken me a week to write took an afternoon to generate.

Yet it still took weeks to get it tested and merged.

It felt like strapping a rocket engine to a tricycle. Exhilarating, sure, but the road ahead is still full of potholes, and there’s a canyon where the bridge used to be. So why isn’t the 100x improvement in how fast AI can generate code moving the needle on how fast we can ship features and improvements?

Coding was never 100% of the job. But for those of us managing legacy debt, AI doesn’t just fail to solve our problems; it collides with them.

I’ve been at several conferences recently where I met leaders from “AI-native” companies, organizations founded in an age where agentic coding is the baseline. One founder told me they don’t do code reviews at all; their CI pipeline is the reviewer. Another gives agents full control of their production infrastructure. For those of us anchored to a culture that is older than even just two years, these practices feel reckless. Yet even more measured companies are rethinking the fundamentals. OpenAI recently pulled back the curtain with their Harness Engineering article, showing engineering re-architected around AI from the ground up.

For the rest of us, the gap between “generating code” and “shipping value” is becoming a chasm. We are stuck in the Unhappy Middle, where the cost of code is diminishing rapidly, but the cost of review and verification is skyrocketing.

The Unhappy Middle

To understand why the promise of 100x faster progress thanks to AI still feels like an illusion, we have to look at the two forces we’re being squeezed by.

On one side, we have the AI-Natives. These are companies and teams founded in the AI era. They have zero legacy debt, they can approach the craft of engineering with an open mind, and they use the same exact “boring” tech stacks the models were trained on. They don’t have to go out of their way to “integrate” AI; they are born out of it. They don’t have to refactor their code to support automated verification, they never knew a world without it.

On the other side, you have the companies with the slack to reinvent themselves. Shopify’s CEO made headlines when he declared that AI proficiency is now a baseline expectation and that teams must justify why a job can’t be done by AI before requesting headcount. Companies like that (or Google, I bet) can dedicate teams to rearchitect their codebase, tooling and processes and build the scaffolding that is required to make AI work at scale.

Then, there’s the rest of us. I call it the Unhappy Middle.

We support live products and services, with customers trusting us and depending on us daily. The cost of failure is higher than a toy prototype. Unlike your ToDo app, you can’t just throw an agent at a problem and hope it doesn’t break your production environment.
We have accumulated technical debt as we were racing towards product/market fit, and yet never had the resources to pay it back. We have to balance work on infrastructure and developer experience with business priorities like opening new product lines. Most of these target ambitious schedules which (you guessed right) require taking on additional technical debt.
With the age of Zero Interest-Rate Policies well behind us, but not quite with the coffers of a larger company, we always have to be mindful of our runway, are constantly short-staffed and always “do more with less”.

In short, we have to balance the technical complexity of an established company with the reality of a startup. Our survival depends on crossing the chasm as quickly as possible. Not every team is here. If your stack is standard and your tests are green, you may already be seeing the gains. But if any of this sounds familiar, the path forward is harder. Here are some examples from my reality.

Bespoke Frameworks: from Asset to Dead Weight

Before AI, we may have optimized for human speed by building bespoke frameworks, custom boilerplate generators or domain-specific languages and abstractions. For many teams, these were their “secret sauce”: internal abstractions that helped teams move fast in 2022. They came at a price (typically, new engineers have to take some time getting comfortable with them), but they often paid off.

Today, those clever optimizations are anchors holding us back. AI agents are brilliant at standard React and Python because they’ve seen it a billion times. And, at the same time, they are completely illiterate in our proprietary and opinionated internals. Every time I ask an agent to work in our bespoke code, I’m paying an invisible tax: I spend a third of my time fixing hallucinations because our “clever” code isn’t in anyone’s training set. (I wrote more about why this happens in The Ghost in the Training Set.)

And you know what’s funny? That’s often why some of the best engineers I know are unimpressed by AI agents: they focus on the last time they saw Claude trip on a gotcha that’s specific to their codebase and ignore the fact that it can build flawless React in the blink of an eye.

Zero Slack

We know technical debt is there, we always wanted to increase test coverage, we defer refactoring for testability because we need to fit one more feature before the release cut. We know that frameworks need to be standardized to become “AI-hospitable.” But in the Unhappy Middle, you have zero slack. You’re always racing, either to hit product-market fit or to extend your runway, and “cleaning up” feels like a luxury you can’t afford.

This creates a painful tradeoff. In a side project, or a non-critical business app, failure is cheap. For a company with a legacy codebase, complex release processes and addressing user-critical needs, the stakes are considerably higher. Without the slack to build automated guardrails, we’re left with manual human review and auditing.

And that’s where the 100x speed gain from AI goes to die.

When Generation Outruns Verification

We often think of the craft of software engineering as composed of several loops, each covering a different stage of the lifecycle, from idea to product. A good visual to illustrate this is the slide below, from a talk Addy Osmani gave at LeadDev New York 2025.

From Addy Osmani's talk at LeadDev New York 2025

At the center is the Inner Loop: the tight cycle of thinking, coding, building and testing. This is where “flow” happens. Surrounding that is the Submit Loop, where your code goes through linting and code review, and the Outer Loop, where it finally gets deployed and gets tested in the real world.

The promise of AI-assisted engineering is to effectively collapse the Inner Loop. When an agent can “Think” and “Code” a cross-stack feature in a single morning, that center circle feels like it’s spinning at the speed of light.

But for those of us who are still in the Unhappy Middle, that loop is often broken before it even starts.

The Broken Inner Loop

The first problem teams are likely to encounter is a broken Inner Loop. Before AI, back in the day when code was expensive to write, tests were the first aspect of a healthy architecture to be sacrificed (or, in the best case scenario, deferred). When we skip writing tests, it’s common to end up with code for which it’s hard to write tests in the long run.

When you can’t give an agent a deterministic way to verify its own work, the feedback cycle doesn’t feed back into the AI, it feeds back into you. The agent isn’t looping, it’s just throwing code over the wall and waiting for you to tell it what happened.

In the best scenario you can imagine, the loop is closed by automation. The agent writes code, runs a test, sees the failure and iterates until it’s green. The feedback is a tight, self-correcting circuit.

Without a way to automate verification, you’re just making a mountain of work for yourself, or accepting to take an enormous amount of risk by shipping code that hasn’t been properly tested.

You were promised AI agents working for you to help you be more effective; instead, you are working for your agents. Not only is it not fun, it’s also a huge waste of your time because you are 100x slower than a software agent.

In my world, this isn’t just a metaphor. I feel it physically. At Quilt, we make hardware devices, and you can’t throw prompt engineering at the physical world. If a test requires me to get up, walk to a test bench and manually press a button, the inner loop isn’t just broken; it’s wide open.

And there are even worse consequences downstream.

The Slowing Submit Loop

Before AI agents were this capable, the high cost of writing code carried a hidden benefit. If an engineer spent two days wrestling with a complex feature, they effectively distilled a lot of context information into their brain. By the time they put a change up for review, the author was the deepest expert on those 200 lines of code.

That’s not how it works today.

As wonderful as the democratizing effect of AI agents is (they enable engineers to contribute well beyond their historical area of expertise), it comes with downsides.

If an agent can’t automatically verify its changes, and the author is not the most experienced engineer in the area affected by a change, the bulk of the burden of audit and review will shift to the reviewer.

On the average team, code reviews are assigned to the most experienced engineers in a given area or domain. In this new world, these folks are getting overloaded with more code to review. Worse, they can no longer assume that the author has the same depth of knowledge about the code that reviewers historically could take for granted.

At the extreme, this has multiple effects:

Because the agent did the heavy lifting, the human author may have a shallower understanding of the “why” behind specific implementation choices.
The reviewer is now receiving 10x more code, but with 10x less intent provided by the author. If the reviewer didn’t (or couldn’t) do a thorough review themselves, it’s 10x more code reviews of a higher intensity. Think more of a forensic audit than a style check.
In a legacy codebase with bespoke frameworks, this can be extremely challenging. If neither the author nor the reviewer fully understands the “clever” choices the AI made, they can’t distinguish between valuable additions and hallucinations, and therefore are taking a high risk shipping this to production.

The practical consequences are tangible. Code ends up spending more time waiting for review than in development (this is what happened to my proof of concept I mentioned earlier). Your most experienced engineers struggle to be productive themselves because they are drowning in code reviews.

But the most worrisome part is what this does at an emotional level.

From Craftspeople to Janitors

If we take the patterns above to the extreme and let them fester without fixing them, then we are taking on a huge organizational risk by turning our most senior engineers into Janitors.

Instead of going to a challenging workday where, at the end, we experience the joy of having created something new, we now have to pore over someone (or, rather, something) else’s code to spot issues and problems. Some engineers feel like they are being paid to clean up AI hallucinations.

This can be deeply demotivating. No one likes being a linear bottleneck downstream of a stage that is accelerating at exponential speed. This is even more difficult at the speed this shift is happening, as many people are mourning the loss of the craft, made worse by simplistic takes about how the world of tomorrow needs fewer engineers.

I still deeply enjoy coding but I recognize that, even in the best of days, a lot of the code I wrote was boilerplate needed to wire together different application components. A very common micro-kitchen joke from my time at Google was that we were all just highly-compensated Protocol Buffer translators.

We miss the 20% of the code we used to write that was high-leverage and intellectually interesting, and forget the other 80% that was toilsome and repetitive.

From Janitors to Gardeners

If you treat every AI-generated PR like a chore to be cleaned up, you are a Janitor. To move fast in a legacy codebase, we need a considerable change in mindset. If you allow me another metaphor, we need to start treating our codebase less like a perfect jewel to polish and more like a plot of land to tend to.

I’ve been thinking about this metaphor for a while. As you scale an organization, you can’t afford to micromanage; you provide structure and support so that decisions happen organically, aligned to what the business needs. The same applies to codebases.

Playing into the metaphor, a gardener may focus their attention on a few things:

Tending the Soil

Hospitable Ground — Transforming AI-Hostile codebases into an AI-Hospitable playing field requires investing in reducing technical debt, so that AI can’t hide behind it. It may mean moving away from bespoke patterns that routinely trip up agents, or making them work reliably. It means standardizing on a well-defined and documented set of abstractions, instead of having 3 different ways to set up an API server because we never finish migrations every time we deprecate an old pattern.
Nutrient-Rich Soil — Agents are great at brute-forcing their way to a workable solution, but very often they struggle because the codebase lacks information beyond the code itself. Code written in haste often lacks documentation about “Intent” and the “Why” we made decisions. If we don’t expose context about tradeoffs and historical decisions, our agents are operating with limited information. Well structured agents.md files are a good start. Checking in architectural guidelines and making them discoverable is increasingly paying off. Ironically, if you keep your design docs locked in Google Docs, your agent is blind to them (hey Google, when can we have MCP access to Google Docs?)

Scaffolding and Direction

Scaffolding — You don’t tell plants how to grow and expect them to listen; you provide scaffolding and support. In software, this can be types, interfaces and architectural boundaries. Well crafted designs that reduce coupling and abstract complexity behind well-defined interfaces are how you give agents a way to grow that is aligned to what you need.
Resilience — Automated tests, lint checks and verifications are much more helpful for AI agents than they are to humans, as they enable both faster iteration speed and more confidence in the review stage of the submit loop. In the gardening metaphor, this is akin to the sturdy fencing that protects your plants from critters.

I find it ironic that many of the principles above are ones that practitioners have been advocating for under the banner of clean code, test-driven development and many others. We might callously shrug at the idea that we struggled to adopt them for the sake of our human co-workers and are now prioritizing them for the sake of our AI-agents. But the truth is that in the last decade, writing effective tests and good documentation cost us time: the time to think about them, and the time to type them. With AI agents being this capable, the typing cost is approaching zero. What remains is the thinking, and that was always the valuable part.

Building the Dark Factory

By now, it should be obvious that if we use AI only to automate the “Coding” stage of the development loop, we may not only struggle to make our team more effective, we may even hurt their effectiveness.

In the same talk by Addy Osmani I referenced earlier, he goes on to show several areas where AI can be effectively adopted to improve developer experience. In my day-to-day work, I’ve had considerable success using AI agents to troubleshoot bug reports and infrastructure alerts from our production fleet. The gains are real.

From Addy Osmani's talk at LeadDev New York 2025

There is a growing conversation in engineering circles about “Dark Factories”: fully automated systems that run without human intervention. In the age of AI, our job is no longer to write the code; it’s to build the factory that builds the code.

Some high-leverage areas to start:

The Verification Machine — Good test infrastructure should be the top priority. Well-written tests enable AI-agents to have much faster inner loops, but they also greatly help with faster code reviews. With good test scaffolding, you don’t just ask “Will this code work in this scenario?” You can ask an agent to demonstrate the expected behavior via a unit test.
Address common tripping hazards for agents — You likely have a few areas where agents routinely struggle. Don’t just scoff when that happens, and use it to say “AI isn’t quite there yet”. Ask yourself why agents are struggling. Is it because of inconsistent patterns? Lack of context or documentation? Because your bespoke framework requires 1 year of experience in your own codebase to master? Making sure agents don’t make the same mistake twice should be part of our responsibilities.
Reducing human dependencies for mechanical tasks — Invest in building reliable automated end to end tests that rely on production-like observability to spot issues and regressions. Wherever manual testing is required, ask yourself “what would it take for this test to happen automatically?” In a hardware company like Quilt, this means augmenting our ability to perform more tests in software.
The Lights-Out Goal — Aim to have a “Submit Loop” so robust that if tests pass and the architectural boundaries are respected, the code is “shippable” by default. Even if that goal feels unrealistic (e.g. for code that is security-critical or that runs on devices that are hard to recover), ask yourself “What would it take for me to be 100% confident in a change without needing to review it?”

A word of warning: don’t confuse building the factory with building more features. If you ship 10x more features without correspondingly improving your infrastructure, you’re taking on a compounding liability. If AI agents today are enabling you to move even just a bit faster than yesterday, aim to put some of those velocity gains towards your scaffolding, instead of putting everything on more features.

Crossing the Chasm

The Unhappy Middle is a trap, but it’s also an opportunity to rethink what engineering leadership looks like.

This requires a fundamental shift in our ego as developers. Instead of ‘pwning’ the agent every time it trips on our proprietary abstractions, we need to ‘own’ our codebase and make it more AI-hospitable. If the smartest AI in the world can’t understand your code, it might not be the AI’s fault, but it might be a sign that our “cleverness” has become our biggest liability.

If we don’t cross the chasm quickly and change our mindset about how we write software, we risk being buried under our own AI-generated slop. The first step is to stop prioritizing just features as our primary output and start prioritizing the speed and accuracy of the factory.

It is notoriously hard to get organizational buy-in to address technical debt. The key is to reframe: this isn’t about “cleaning up” to pay off debt, it’s about investing in tooling to accomplish 10x velocity.

And even then, there are harder questions ahead. If you actually succeed in building the “factory,” you’ll quickly find that the technical bottleneck has evaporated, only to leave you with an organizational one. A 10x software factory is effectively useless if it’s embedded in a 1x decision-making process. And it is possible that we are approaching a Great Filter-like event for companies in the business of software — one that separates those who adapt from those who drown. But those are topics for another day.

For now, the goal is clear: stop just auditing lines of code and start building the systems that define the future of our industry.

Let us begin.

The Ghost in the Training Set

Sat, 14 Feb 2026 08:00:00 GMT

Over the last several weeks, I’ve had to spend time setting up Model Context Protocol (MCP) servers. As the ecosystem matures, it is already navigating its first major paradigm shifts. Specifically, in early 2025, the recommended transport for MCP over HTTP shifted from Server-Sent Events (SSE) to Streamable HTTP.

To my surprise, the agents I use most (Gemini and Claude) kept reverting to SSE. They were well “aware”, at least as much as a machine could be, that Streamable HTTP was the new standard (they could competently answer questions about it) but they were haunted by the statistical momentum of their own training data. When it came time to actually generate code, they defaulted to the pattern they had seen thousands of times before.

The Invisible Weight of Training Bias

Taking a step back, this makes perfect sense: LLMs don’t just “read” instructions in a traditional sense: they weigh them against their internal probability map. If most of the MCP implementations they had seen were built over SSE, that gives them a huge bias in that direction.

Once I started noticing this pattern, I had found it more and more often: LLMs seem to struggle more with bleeding edge patterns and technologies (again, their training dataset has more examples built on deprecated patterns than newer standards).

This is a sneaky pattern, because we don’t naturally think about how old (or new) a model’s training set is, so we can’t realize this is happening unless we pay attention. If you’re working on a bleeding edge domain and you’re not careful, you may find yourself with an agent offering you a beautiful implementation that is actually a frozen snapshot of last year’s best practices.

The challenge grows with the uniqueness of your environment. This problem is even worse with codebases that adopt bespoke frameworks and patterns for which there is no published precedent. Agents thrive on Common Knowledge, and they struggle with Private Context. When we use bespoke patterns, we are essentially moving the agent into a zero-shot environment without even realizing it. The result is a performance degradation that looks like a “dumb” model but it is actually a lack of statistical grounding.

From Prompting to Infrastructure

You may be tempted to try to overcome this through prompting, and try to give strong instructions to anchor your agent towards the new standard by including strong language in your prompt (ALWAYS use Streamable HTTP when implementing MCP services). You need strong anchors to overcome strong biases. But prompts are often lossy, inconsistent and error-prone.

A more sustainable strategy is to start including these guardrails into your agents.md¹ files, or even better in tooling infrastructure. For example, Claude includes an /mcp-builder skill, which serves as a specialized instruction package anchored on the most recent standards, ensuring you land with a well-functioning implementation that overcomes the inherent bias in the models. In contrast, if you tried building an MCP server with Gemini now you may find yourself surprised by a perfectly functional implementation built on the deprecated 2024 pattern.

The Trap of “Contextual Debt”

Just like code accumulates technical debt, continuously adding to agents.md without ever cleaning up leads to “contextual debt”. Over time, these files become bloated with a mountain of “Don’t do X” or “Remember Y.” Even worse, because you can have agents.md files scattered through your repo, and other .md files as documentation, you can find yourself with clashing instructions that throw agents for a loop in ways that are surprisingly difficult to detect and remedy.

We are reaching a point where our “Instruction Budget” is as important as our compute budget. If you have clashing instructions across multiple .md files, you’re not just wasting tokens, you’re creating “hallucination traps” that are far more expensive to debug than a standard syntax error.

Here are a few things that worked well for me:

Progressive Disclosure: Borrowing from the Claude skills playbook, instead of having a giant instruction file, use a modular approach (e.g., a docs/MCP_STANDARDS.md file linked from your root agents.md).
The “Zero-Prompt Test” Stress Test: Periodically run an agent on your project with a blank instruction file (especially after significant model updates). If performance remains stable, the underlying training set has likely caught up to the new standard. At that point, your manual instructions are no longer necessary; they are cruft. Delete them.
Ownership of Configs: Treat agent configurations with as much rigor as a CI/CD pipeline. Obsolete agent instructions have even more impact on your velocity than obsolete documentation, and ironically, up-to-date documentation is now more precious than ever.

With the rapid pace at which things are evolving, I would not be surprised if in a year, half of these strategies would not be necessary as agents get better. And perhaps they will be superseded by a new set of practices.

Conclusion: Managing the Agent’s AI “Memory”

Regardless of what you might think about the tropes around “software engineering being dead”, it is undeniable that the focus of our job is moving away (or perhaps upward) from writing code.

As we spend more effort managing attention and memory of our agents, in the most sustainable agentic systems, instructions and scaffolding will be pruned as ruthlessly, if not more so, than the code itself.

In this post, we’ll reference only agents.md. Hopefully we’re not far from the day where we don’t need to maintain a separate configuration for Claude. ↩

Receiving Feedback Is A Skill

Tue, 25 Aug 2020 19:35:24 GMT

Delivering feedback is a critical part of my day job as a manager at Google. However, it took me a while to realize that receiving feedback is one of the skills that helped me grow the most in my career.

For many of us, our job is the first setting where we receive developmental feedback from people other than our parents or teachers. That experience may be quite shocking.

I still remember the first time I got professional feedback early in my career. I remember almost every single word that my manager chose to use.

What I remember even more vividly though is the strong reaction that feedback caused in me. Within seconds, I got defensive, I felt like I was being criticized, attacked, unappreciated. I heard what they were trying to tell me, but something inside me kept translating that into a personal criticism. A statement about how I, personally, fell short of expectations.

Good feedback sounds like “here’s one thing you can do better next time”. Better feedback sounds like “here’s one thing that you could do differently to achieve a greater result”.

Embracing that mindset allowed me to accept, process and build on feedback. While I can’t say I prefer criticism over praise, constructive feedback no longer makes me uncomfortable. Instead, I actively seek it.

Changing my mindset around feedback required me to make two key changes:

stop doing things that hurt my ability to improve
start doing things that help build on what I hear

Things I Stopped Doing

Taking It Personally

The main reason I had a difficult time processing feedback is the fact that I often took it personally.

When receiving feedback about something I did, I often read it as feedback about me. Oftentimes, that was not the intention.

Instead of hearing “this email was hard to understand”, I heard “you do not communicate effectively”. When the other party was saying “this piece of code is brittle”, I was hearing “you are a lousy programmer”.

I often ended up reacting defensively. I was unable to hear and processing the actual message I needed to receive.

Most developmental feedback will naturally trigger a defensive attitude. That prevents us from getting the full value of what the other person is trying to tell us. We need to make a conscious effort to not jump to defensive mode, and rather engage in active listening.

Arguing With Feedback

Even worse than taking feedback personally, I sometimes found myself wanting to argue with the person delivering it. I wanted to explain why I disagreed with what they were seeing or try to convince them that they were wrong.

In most cases, arguing with feedback is pointless. Take an example from many years ago.

A colleague approached me and told me “I think the comments you left in this review were too harsh”.

Now, if they cared enough to bring up this feedback, perhaps they were not the only ones. Or maybe my communication style could have had an unintended effect on some people, some time.

Yes, I could have argued with my colleague, perhaps even convince them that my tone was not that bad. Winning the argument might even have felt better.

That would not have changed the my comments did trigger a negative reaction for them. Quite likely, others might have had the same reaction. Knowing that, having that awareness, made me more thoughtful when writing review comments. I can tell they were better received from that moment on.

Arguing with people who are trying to give us feedback, does not help us. Eventually, people will shy away from telling us where we can improve. It leads us to us working with less information about what we can do to get better. In the long run, we miss out on a significant opportunity.

Things I Learned To Do Instead

Being Thankful

A friend of mine once shared a quote that sounded like “feedback is a gift”

Good feedback is thoughtful and timely. Often, it is as difficult to deliver as it is to receive. It is especially difficult for people we are not very close with.

Any yet, some people choose to take a risk. They let us know where we can do better. They do that knowing well that we may feel hurt by what they say.

Because of this, the first thing I do when receiving feedback is thank whoever is giving it. I thank them because they took a risk and did something uncomfortable. I also thank them because what they are telling me has the potential of making me much better.

Good feedback allows us to identify growth areas. Areas where we could invest more to get better at something we have been trying to do. Even those of us that have good self-awareness often need to work hard to find where they need to improve the most.

If someone is coming to us with feedback, they may be sparing us a lot of hard work required to identify areas of improvement.

The least we can do is thank them profusely for the gift they just gave us and get to work.

Following Up

Whenever I receive feedback about something I can improve and want to work on, I note it down. Over time, this list becomes my feedback log.

Keeping a list of the items I am trying to get better at is a way to hold myself accountable. I go through this feedback log every few weeks and reflect on the progress (or lack of progress) I have seen so far.

This helps me making sure I make the most of the feedback I was generously given and use it to gradually get better. I try to spend some time every week to work on some of the most important items on the feedback log.

Doing this helps me well beyond the result of addressing feedback. It also helps me ground my identity as someone who can accept feedback gracefully and use it as a tool to keep growing every day.

Wrapping Up

A few simple changes in perspective helped me change my view on feedback. I went from seeing it as a threat to my own self-worth to a stepping stone to become a better version of myself.

The results of this attitude compound over time as I keep focusing my energy towards addressing the most critical feedback items.

Programming Machine Learning

Mon, 04 May 2020 14:47:47 GMT

I just received my copy of Programming Machine Learning, a book by Paolo Perrotta. I had the pleasure of being one of the technical reviewers of the draft and, while this is not the first book I read about Machine Learning, I must say it became one of my favorites.

Paolo promises, at the beginning of the book, to write a book meant for developers, and he delivers on that promise.

In his words,

This is the book I missed when I got started with machine learning: an introduction for developers, written in our own language. After reading it, you’ll be comfortable with the fundamentals, and able to write machine learning programs.

Programming Machine Learning is a book that teaches the foundations of ML by walking the reader through the process of implementing working solutions for a few concrete and specific use cases, such as predicting sales volume for a pizzeria, recognizing hand-written digits or classifying images.

Each chapter introduces a challenge, lays out the foundations of a technical implementation and explains the theoretical background behind the techniques adopted.

As a result, the book is much easier to follow than many others on this subject: even when diving deeper into the technical or mathematical aspects of any of the topics covered, the reader is able to build on the empirical intuition that comes from having implemented ML algorithms and having seen them in action. Every chapter is engaging, starting from the first ones, about trying to predict pizza sales via linear regression and simple perceptrons, to the last ones, leveraging Keras to classify images.

I found the overall approach quite novel and refreshing. I would definitely recommend Programming Machine Learning, especially if you are the type of engineer who generally enjoys learning by doing.

The programming puzzle that landed me my job

Tue, 01 Oct 2019 03:35:33 GMT

And how solving it required a truly full-stack solution, covering web development, data structures and memory optimization

What to look for when hiring

Mon, 26 Aug 2019 19:09:10 GMT

A while ago, I found myself in the enviable position of having to rapidly grow my team. By then, I had done a large number of technical interviews, so I had an idea of what to look for in strong candidates for Software Engineering positions. However, I felt like I lacked a framework for understanding how likely a given candidate was to succeed if they had joined my team, beyond a very loose definition of “culture fit”.

As I was trying to better understand what I was looking for, I started to think about what I value in the people I work with and to reflect on traits I found to be quite common among some of the most successful people I have worked with over the course of my career.

While I would not expect every person I work with to exhibit all the qualities I list here, I am always positively impressed when I come across someone who exhibits more than a few and equally concerned when I see no hint of any of these characteristics.

Over time, I became quite sensitive to some hints that suggest someone could possess one of the these traits and I learned to probe further whenever I see them.

Here a list of the most important characteristics I learned to value in anyone I work with, regardless of job function.

Intrinsic Motivation

Many of the best people I worked with are motivated by their own desire to improve, regardless of the environment around them. Certainly, having a great team and a lot of attention from their manager will help them as well as it would help anyone else, but being intrinsically motivated means they are able to find satisfaction without relying on artificial nudges from the system around them.

I tend to enjoy working with people who think this way because they are often pushing themselves to get better every day, react better to difficulties and challenges and, as a result, push me to get better as well.

I know I am looking at someone who has this kind of attitude when they show they are driven by things such as:

learning something new every day
mastering a skill or a craft
accomplishing something they thought of as difficult

Having hobbies and non-trivial side-projects (for those of us who are at a point where they can afford the time required) is often a sign of being intrinsically motivated.

Relentless Focus

Success often requires from focusing on the most important things first and almost ignoring everything else.

Effective executives concentrate on the few major areas where superior performance will produce outstanding results. They force themselves to set priorities and stay with their priority decisions. They know that they have no choice but to do first things first—and second things not at all. The alternative is to get nothing done. Peter F. Drucker, The Effective Executive

I found it hard to gauge how good anyone is at focusing on top priorities based solely on casual conversations. One decent proxy, at least for technical roles, are open ended system design interviews. Many good questions involve asking to solve a problem too large to be tackled within the allotted time or with the given constraints. That forces the candidate to narrow down the scope and focus on the most important aspects of the problem and set everything else aside.

Independent Thinking

A couple of the best people I worked with have a way of asking questions that sometimes can come across as blunt or excessively direct. In their case, I have never had a problem with it, since it is tied to what I believe to be one of their strengths: they are not afraid to question a line of thought if they do not fully understand it or if they disagree with it.

In cultures where it is more comfortable to agree with others than to challenge their thinking, it takes courage to express dissent.

I wrote before how much I value a culture where anyone feels free to voice their disagreement: I value even more individuals who are comfortable speaking up regardless of what the environment surrounding them looks like.

This is another trait that is be hard to spot in casual conversations, I have seen this come across as a set of pointed, specific questions aimed at developing a stronger understanding of a topic and then thoughtfully suggesting there might be a different way to approach a problem.

However, there is a fine line between being willing to challenge ideas when they are not rock solid and being contrarian by default: it is hard to work with someone who disagrees with everything on principle.

Fast Learning

The ability to learn quickly and adapt to changing circumstances is one of the most critical skills to have in this day and age. To me, it means that I can trust someone to be able to be asked to do something they have not done before and rapidly get up to speed.

I generally see this through evidence of high rate of improvement; whether it shows as gaining mastery of many technologies in a short time, working across a number of different domains or being promoted repeatedly while at the same company, this shows an ability to adapt to changing circumstances.

Responsiveness and Follow Through

One of the main differences between working with a team and working by ourselves is that when we are part of a team others tend to depend on our output for their own progress.

Oftentimes, managers end being stuck having to play the role of the persistent nag, reminding others of their prior commitments and making sure that any work that was agreed upon is eventually delivered. Clearly, this is a way around a fairly common problem: the average person is not great at following through.

By contrast, the most effective team players I have worked with hardly need any nudges: they will stay on top of their to-do list and consistently deliver anything they agreed to do by the time they said they would, without you ever needing to ask again. If you do ask something of them, they respond right away.

Sadly, I do not know of a way to assess how well anyone would do on this point without speaking to anyone who has worked with them before.

Decisiveness

Many people struggle with decisions, for fear of making a mistake, being proven wrong and fallible or committing to the wrong direction. Whatever the reason, shying away from decisions is rarely helpful.

“In effect, the lack of a decision is the same as a negative decision; no green light is a red light, and work can stop for a whole organization.” Andrew S. Grove, High Output Management

The truth is that many decisions are relatively easy to reverse if necessary but the cost of paralysis is too high for most teams and organizations to afford. High-stakes decisions are rare, but when facing one it is important to treat it as a priority and not linger too long. The worst thing we can do is simply dwell on it and get stuck.

Decisiveness is often the driving force behind the responsiveness in the previous section.

Curiosity and Inquisitiveness

Beyond being a fast learner or being passionate about the specifics of someone’s own job, being curious and inquisitive can be invaluable in understanding one’s own teammates, manager, users and competitors.

By wondering about the “why” behind anything we observe, we develop a stronger understanding of the problem we are trying to solve or the parties and organizations we are working with. An understanding that inevitably helps us be more effective.

“When you get curious and learn how to turn that disagreement into honest questioning, you can learn more about other perspectives on the issue because your team will open up.” Camille Fournier, The Manager’s Path

Oddly enough, at least based on my own experience, it is fairly common to find engineers who are extremely curious about technical topics but tend to be less interested about understanding less technical subjects (such as organizations and other humans). People I worked with who are truly inquisitive tend to demonstrate it by being uncommonly interested in the motivation behind the status quo or previous decisions. They often ask questions such as “Why do we do things this way?”

Communication

So much of teamwork is communication, yet communication skills are often overlooked. It is hard to overstate the importance of communication in teamwork. Effective communication means, among other things,

being able to make one’s point of view understood,
resolving conflicts,
selling our own vision,
making sure others are aware of our work (and why it matters)

Of all the traits I learned to appreciate, this is perhaps the most visible. If you spend even a few minutes speaking with someone and they are an effective communicator, you will notice.

Going the Extra Mile

Many successful people consistently overdeliver. It is quite difficult to have any sort of success by just doing the bare minimum. Sure, one can get lucky once or twice, but solid careers are built on strings of consistent achievements.

I often see this in coming through from people’s passions. It often shows as side projects (work-like activities they chose to do in their own time¹) or initiatives at work that they started without anyone asking them to do so (e.g. 20% projects at Google).

Note that this is not always possible for people to do, depending on their situation. ↩

Visual and HTML Testing for Static Sites

Tue, 06 Aug 2019 11:06:27 GMT

I set up a CI/CD pipeline to test my website for markup and rendering issues. It proved to be so useful that I can not imagine going back.

Zing LED Smart Night Light

Mon, 18 Feb 2019 21:24:08 GMT

Several months ago I was looking for a night light when I stumbled upon Zing’s Indiegogo page.

The main feature I was looking for was for the light to activate automatically when I was walking past it and to turn off a few seconds later. Zing seemed to be able to do this and more: after seeing browsing the site, what intrigued me were the many possibilities for customization, the integration with IFTTT and the fact that each light has a temperature sensor — which I was hoping I would eventually be able to access via API.

Some features, such as automatic path lighting and the locator feature, were not a part of the decision. Others, event notification in particular, I knew I would not use (I am trying to minimize the notifications I get while I am home).

I got a pack of 3 on Indiegogo, hoping to receive them relatively soon. The wait turned out to be longer than I expected (shipping ended up being a few months late due to some complications in the production process) but I finally received my lights in October.

The box the lights come in.

So far, I have been quite happy with them. I liked the fact that each light is configurable and offers a number of settings to customize that will help you make sure it works with your environment and preferences.

I installed three lights (two are in bedrooms and a third is in the master bathroom) and set all of them to a warm, yellow glow. I initially configured the bathroom light to a multi-colored rotating pattern (see the screenshot below) but shortly after I opted for a more relaxing solid color and static pattern.

The Zing app allows configuration of many parameters for the lights, such as the light color, intensitiy, spread (influencing how wide of an area the light would illuminate) and speed (for moving patterns).

Unfortunately, the Android app seems to be lagging behind with respect to the iOS one in terms of functionality — more on this later.

The predictive path lighting feature has been quite disappointing so far. Whenever one of the lights turns on (because you are walking past it), all the other two will turn on as well, almost as if the model powering the feature today wasn’t any sophisticated than “if motion is detected, turn on all lights”. Not a big deal, but it meant that I turned off the feature on the light in the other bedroom, since I did not want any of getting up to trigger the light in our daughter’s room.

I haven’t gotten to try neither the locator or the notification feature advertised on Indiegogo: I am not sure whether they are supported or not.

Unfortunately, the version of the lights I received shipped with an older firmware version that is affected by a couple issues:

some settings (e.g. blue light reduction) are not persisted if the light loses power;
the activity indicator for the WiFi module often flashes blue.

I must say the latter issue is quite annoying in a night light. If you think about it, having a bright blue LED flash unexpectedly is quite noticeable in a dark room and almost defeats the purpose of having a night light.

I am told that updating the device firmware might help with both of these issues but unfortunately the Android application is unable to perform the update so far. I have been in touch with the Zing Support team to understand what workaround are available (other than procuring an iPhone) and I am hoping to hear back soon.

All considered, I have been quite happy with Zing, provided that I manage to fix the issue with the WiFi module.

The features that I wish it had at this point are all related to software and am hoping they might happen soon:

Being able to prevent the lights from turning on at daytime or when the room is already bright enough;
IFTTT/Google Assistant integration;
Being able to access the temperature sensor via API.

If you are curious to check Zing out, they now have an official site.

UPDATE (January 2021) I am still quite happy with the basic functionality of these lights. However, I can’t recommend them if you are an Android user.

The Android application to control the lights has not received any updates in years. It also lacks several features that are present on the iOS version, such as controlling the lights based on a schedule, upgrading the device firmware and more.

Migrating From Wordpress to Hugo

Thu, 15 Mar 2018 00:35:57 GMT

After many years of running my own site on Wordpress, I finally pulled the trigger and decided to migrate to a different stack.

Wordpress had been working quite well for me until I started to run into some with the hosted version and did not want to deal with having to set up and maintain my own server just for this site.

When I found myself, unexpectedly, with some time to spare — rocking my newborn daughter back to sleep in the middle of the night — I took it as an opportunity to learn what kind of options are available for running simple websites in 2018. I had read so much about static site generators and they seemed such a great fit for what I was trying to do, so I decided to give it a shot.

I am surprised to see how far things have made it since when I last looked. If are interested in the current state of things, you can find a pretty good list on StaticGen.com.

I had no shortage of alternatives to consider but I fairly quickly settled on setting my new site up with Hugo.

Thankfully, the migration itself was not too daunting, I was able to complete most of it during the course of a few nights while holding a sleeping baby 😉

In case you are considering doing the same migration, here an outline of the steps involved and a few articles I would recommend.

Decide whether you want to keep the same apperance or you are okay with selecting a theme you like and just exporting your comment. In my case, I decided to switch to a new theme, so I focused on mapping how my existing content would be organized in the theme I was migrating to.
Migrate your content to Markdown that Hugo can process. I found this article useful: Migrating from Wordpress. Requires installing a plugin on your Wordpress site to export content in a format that Jekyll (another static site generator) can process and then transform that to the format Hugo expects

If your site is on wordpress.com, the guide above won't work as is, since you will not be able to install plugins unless you are hosting your own server. I worked my way around this by [exporting an XML dump of my site](https://en.support.wordpress.com/export/), and then starting up a throwaway wordpress server (I did this with cloud9 when they offered a free plan, you can probably get a similar result by running it on [docker](https://docs.docker.com/compose/wordpress/)).

Your site will likely require some fixes at this point. The specifics depend on what it looks like but it is likely that you will want at least to verify that the links between pages are working fine. Images often require some fixes.
My site had a fair number of incoming links from other places. I wanted to avoid breaking them if possible. This is where I was glad I was deploying my site on Netlify, since they offer great support of Redirect & Rewrite Rules, among many other features.
I had a good number of comments on my old site and I wanted to carry them over. For the sake of simplicity, I chose to use Disqus for my comments and thankfully they had a good article about Importing comments from WordPress.

Disqus comments are associated with page URLs, so you will want to make sure your pages are served at the same URLs as before the migration. Alternatively, you can edit the URLs in the export file before importing it following the instructions above.

I have yet to find a technical migration that completes without introducing new issues, so if you ever encounter any bugs on this site, I would ask you to please let me know.

Feel free to leave a comment if you are trying to do the same migration and you run into trouble, I can try to help you out.

What’s wrong with Milan’s Open Data initiative

Thu, 12 Sep 2013 10:38:51 GMT

I spent some time playing with the Open Data published by the City of Milan, aiming to visualize public transport coverage. While I managed to create a heatmap, I was left unsatisfied by the data presentation and format. The initiative is promising but could be dramatically improved by adopting modern standards like GeoJSON instead of Shapefiles and including simple preview capabilities.

Appsterdam Guru Session: Google App Engine for beginners

Sat, 06 Jul 2013 02:21:19 GMT

One of the things I was not expecting when I moved to Amsterdam was its active and vibrant tech community. Appsterdam, a non-profit organization focused around aggregating people with a passion for technology, is probably one of the central forces in this movement.

In my year in Amsterdam I had been to a few meetups organized by people from Appsterdam and always came back home having learned something new. This is why when my colleague Matt (who himself is quite an active Appsterdam member) talked me into presenting a guru session on Google App Engine, I saw that as an opportunity to return the favor.

While I tried to give an overview of App Engine in general (and the Python flavor, specifically), I also wanted to offer attendees the chance to work on some examples that were more interesting than the typical guestbook application that comes with all the tutorials you can find online.

The code examples build on two of the many APIs App Engine has to offer:

the Channel API to build a web page that displays the current cursor position of every user looking at that site,
Google Cloud Endpoints to implement a simple REST-like backend for a webpage.

You can check out the slide deck below and get the code examples from the GitHub repository.

[Embedded content not available in RSS — view on site]

App Engine is a lot more than an advanced infrastructure to deploy applications: the numerous APIs and services it offers can enable developers to build advanced applications with limited effort. I hope this presentation, while just scratching the surface, gives you a glimpse on the possibilities.

Special thanks to Matt for pushing me to do this and Serena for her help with example 2.

Presenting Professional Invaders

Thu, 06 Jun 2013 07:25:00 GMT

A few weeks ago I attended The Next Web Conference in Amsterdam and joined a bunch of fellow programmers for another edition of the Kings of Code Hack Battle, the same kind of event as the one where Bring Your Own Music was born.

Following the usual schedule, after a brief presentation from the API partners (Spotify, SendGrid, Braintree, Deezer, Pearson, Nokia, Rebtel, Bol.com, Smart TV Alliance and LinkedIn), all the attendees started evaluating ideas about what to build.

View this post on Instagram

A post shared by Alessandro Bahgat (@abahgat)

I teamed up with Alexander, a friend of mine I already had the chance to work with back in the days when I when I was consulting.

Having LinkedIn among the sponsors seemed to encourage us to build serious applications for serious professionals, but after discarding a few alternatives that would have been better projects for a Startup Weekend than a hackathon, we decided to take the opposite direction: building the silliest possible thing with the APIs we had access to.

We eventually decided to work on a game and tried to build a Space Invaders clone that would let you throw paper balls at your professional connections.

After some research, we found a well written Space Invaders implementation on GitHub (thanks Calamari) and we started adding the silliness to it.

The first day we focused on getting the game to work as we expected:

each invader would be one of your connections on LinkedIn,
a Boss would spawn every now and then,
the game would have some sort of soundtrack (thanks Deezer),
while in “Boss mode”, the game would have a distinctive appearance (blinking red background and a different theme song).

The second day we turned our attention to features that were just fun to build:

a coin slot where players could buy more coins with their own credit card (API courtesy of Braintree),
an easter egg we planned to use in the demo: attendees could spawn the Boss by sending email to an address we set up for the occasion (thanks Sendgrid).

The video below (3:11) shows the major changes the application went through. It was created by replaying significant entries in the commit log and recording what the game looked like at that time.

[Embedded content not available in RSS — view on site]

We approached the deadline with only one objective: making people laugh. Despite some technical issues (amusing at a tech conference), we managed to demo our hack and people seemed to have liked it: the guys from Sendgrid even decided to award us with a prize 🙂

You play the game here. This version is a slightly different from what we presented at the hack battle, since we decided to keep only the features that made sense if we were to offer it online.

We hope you’ll have as much fun playing it as we had putting it together!

What Van Gogh can teach us about persistence

Mon, 04 Mar 2013 13:33:43 GMT

I visited the Van Gogh museum in Amsterdam recently and, to my surprise, I left the exposition having learned something that matters beyond art.

According to his biography,

Van Gogh began to draw as a child, and he continued to draw throughout the years that led up to his decision to become an artist. He did not begin painting until his late twenties, completing many of his best-known works during the last two years of his life. In just over a decade, he produced more than 2,100 artworks, consisting of 860 oil paintings and more than 1,300 watercolors, drawings, sketches and prints. […]

Before focusing on painting, he worked as an art dealer, teacher and missionary. It wasn’t until he was 32 that he painted his first major work.

He did not have the fortune of being recognized as a talented artist in his young age like Michelangelo and others and yet still he did not let go of his desire of becoming a painter. The thing that strikes most of the museum is the quantity of studies and sketches Van Gogh made throughout his live in order to improve his skills. He wanted to paint so much that he kept practicing and put so much effort in improving that it eventually paid off: he is now remembered as the author of dozens of the most renown paintings of the history of art.

In an age where the reference point to define an accomplishment is starting a company at 16 and become a billionaire at 22, we risk underestimating the value of persistence. Sure, he did not reach fame and success while he was alive, and his life was not what you would define “happy”. But if he had quit because he was not an accomplished painter in his young age, art now would certainly be very different from what we know.

The works of Van Gogh are a proof that there is no such thing as being too late to accomplish something remarkable.

Prettier source code on WordPress.com

Mon, 21 Jan 2013 10:34:50 GMT

Posting source code on WordPress.com is quite simple: the platform already provides an extremely easy to use shortcode called sourcecode, based on a fairly flexible syntax highlighter plugin. By looking at the examples in the documentation page, however, it is evident that the default styling used to render sources is quite old-fashioned and does not fit most modern themes.

While the shortcode offers options to allow users to control many options of the rendering, it does not allow us to configure colors, fonts and size (the default size is so tiny that it is barely readable on high-resolution screens).

When I was writing the previous technical post, I did some investigations to figure out what options are available to post more readable sources if your blog is hosted on WordPress.com and I found out there are basically two alternatives.

Embedding Gists

The easiest option is to rely on Gist – GitHub’s tool for sharing snippets of code – which offers an extremely easy way to embed code in your blog. Just create a new snippet (gist) there and follow the instructions.

Unfortunately, the gist embed shortcode available on WordPress.com is less flexible than what you would get if you installed it as a plugin on your own instance of WordPress, but it will be enough for most cases.

Pros	Cons
Easy to embed source	Suitable for posts with a few (long) code snippets
Code looks good and is readable	Does not always work perfectly with search engines
Easy for readers to access raw code	Does not work with RSS and posts over email

Styling source code by customizing your CSS

While Gists work great most of the time, they are a pain to create and maintain if you are working on a post that should include multiple short snippets of code. In that case, the amount of bookkeeping you have to do is significant (you will have to create and link many small chunks of code) and you may want to be able to manage your code right within the post.

In that case, it may be more practical to fix the CSS theme used by the syntax highlight plugin to make it look post-2010. If you set your own custom CSS on WordPress.com, it will be supposed to be included as the last one to allow you to redefine the styles specified by the theme you are using.

Unfortunately, the CSS used by the syntax highlight module was clearly not written with extensibility in mind, but quite the opposite:

all the style declarations it includes make use of !important,
the plugin will dynamically include its own CSS as the last item in the head node, meaning that it will have preference on the custom one you define.

This makes sense in the original context – the original syntax highlighter offered several themes you could choose from by including different stylesheets, but that feature is not available on WordPress.com – but will make your life more difficult. You will need to add !important to all the CSS declarations you redefine and you will need to use CSS selectors that are more specific than the ones used by the plugin. You will be able to see the final result at the end of this post.

WordPress’s syntax highlight is not perfect, and some things are still quite annoying (e.g. line numbers get in the way if you try selecting and copying source code). Most issues could be addressed by upgrading the plugin to use version 3 of SyntaxHighlighter instead of the outdated version that is in use now, but it is something you will not be able to control unless the folks at Automattic decide to update it.

Pros	Cons
It is necessary to have access to Custom CSS (which is a paid feature)	Hard to copy sources without including line numbers (unless you disable them)
Access to advanced features (highlight lines, toggle line number display)	Search engines index sources with the post content
Source can be styled according to preference	Getting your CSS applied correctly can be difficult (but you can start from here)

What did I choose?

Here is the stylesheet (embedded as a Gist) I am currently using on this blog, based on the pygments theme used to style code at docs.python.org.

[Embedded content not available in RSS — view on site]

You can can see what the final result looks like ~~in this post about User authentication with webapp2 on Google App Engine~~ and in the image at the beginning of this post.

Update: I since migrated this blog to a new system, and am using a completely different way to render source code.

User authentication with webapp2 on Google App Engine

Mon, 07 Jan 2013 07:57:26 GMT

Google App Engine for Python ships with the capability to manage user accounts without the need of any additional library. This functionality is, however, insufficiently documented. This post is a step-by-step tutorial addressing user registration, login, password reset and a few other details.

Beyond keyboard shortcuts

Wed, 19 Dec 2012 08:13:57 GMT

In the age of touch devices, some days it seems like a day will come when we will not have to use a keyboard to interact with computers. A significant part of our relationship with technology passes t...

Story of a hack: Bring Your Own Music!

Mon, 03 Dec 2012 23:19:00 GMT

This post is a summary of the weekend we spent at the Kings of Code 2012 Hack Battle in Amsterdam. What started as an occasion to get to know smart people doing cool things in Amsterdam (something I look for since I moved here) turned out to be one of the funniest experiences I had in a while.

After a brief presentation of the services offered by the hackathon partners (Apigee, Esri, Spotify and Sendgrid) Diderik, Mattia, Mike and I teamed up to build the hack featured here. We started with the most obvious concept we could come up with: putting songs on a map and having people visualize them. We tried to elaborate the concept to include as many of the partners’ APIs as we could, but then we decided for something simpler, something we could build over the weekend.

It took us a couple of iterations to get to the final idea we developed: Bring Your Own Music, a toy application that allows users to control music playback through NFC-enabled objects by using an Arduino-powered NFC reader driving a Spotify app.

BYOM is based upon the idea of attaching Spotify playlists to physical objects, provided they contain an NFC tag, like many of the cards we have in our wallet. Once you have done that, you can then bring your card with you to a party, tap it on an NFC reader, and have a Jukebox Spotify app like the one we built start playing your songs automatically.

If multiple people tap their own cards, the main Spotify playlist adjusts itself according to the general preferences of the party attendees. We even kept playing with NFC-enabled objects and linked Spotify playlists to all sort of cards, like London’s Oyster cards, OV-Chipkaarts and even the disposable tram tickets you get here in Amsterdam.

As Mattia noted,

wouldn’t it be great if passengers could listen to their favorite music when they check-in on trams?

How was BYOM built?

We collected the identifiers of a bunch of NFC cards, OV-chipkaarts and tram tickets using Mike’s Arduino connected NFC reader. We then created a collection on Apigee App Services to store the card ids and URIs of the Spotify playlists we wanted to link to them.

We programmed Arduino to make a call to Apigee whenever a card is tapped on the reader, in order to store the card identifier into a Swipes collection.

At the same time, we wrote a Spotify application that periodically queried Apigee for new swipes and, as soon as a new card was detected, fetched the songs associated to it and merged them into the main playlist (the one the Spotify Jukebox app would play).

What have we learned by it?

We (I, at least) walked away with some important teachings:

focus is more important than ever: there is no point in imagining lots of features if you are not going to finish them. Pick a small set of features and make them work (or almost work: we had the inevitable demo-time malfunctions despite having tried the full example multiple times before presenting),
build a story: having a story (in our case, the party) around your hack helps you focus and helps you when presenting it,
get some constraints: there are thousands of interesting APIs, devices and ideas out there, and even more ways those can be combined. Choose some constraints to ensure you don’t wander off too much (in our case, we wanted to do something with Mike’s NFC-reader)
have fun: while these sounds like rules, they are more of an advice. Do not let them distract you from your goal: having fun.

What about the technologies?

Arduino is indeed an extremely versatile tool and the amount of sample code and libraries available out there is surprising. While it can be a pain to debug at times, the fact that it allows you to add a physical dimension to your hacks is invaluable.

Spotify‘s wise choice to build their application framework on top of Chromium means that developers can leverage the tools they already got to know by developing web applications. The actual app SDK is a JavaScript library you an include and debug using the tools in Chromium. We were able to get started in minutes and, once Andrew put us on the right track (by pointing us at the experimental but more powerful 1.0 API), never hit a wall or get stuck at all.

Apigee App Services is indeed a valuable tool: it saved us a lot of time by taking care of storing our data and, more important, exposing it over the internet with no hassle. (The fact that we were even able to interact with it through an Arduino is not trivial.) It also took away the need of building an admin interface for most basic needs. Quoting Diderik

Apigee allowed us to get so much done on the first day of the hackathon that we could go home and get some sleep for the night.

How did it go?

Not bad at all. We managed to win a couple of prizes: each of us won a 6 months premium subscription to Spotify (thanks Andrew!) and a gift certificate courtesy of Apigee (thanks Tim!). All in all, we did not build BYOM for the prizes, but we were glad to get them.

The most important thing is that we had great fun coming out with a solution that worked and thinking about how to communicate what seemed so cool to us. We had even more fun seeing what the other teams had built (there were some really brilliant hacks indeed). Isn’t that what a hackathon should be about?

Can I see it?

Sure, you can check the source code. Beware: it’s hackathon-grade code, so it probably does not look like the clean code you would normally want to write during the day. If you are curious, here is a video with Bring Your Own Music and all the other cool hacks built at Kings of Code 2012 Hack Battle. (It is a bit dark, but you get the idea.)

Thank you guys for the great weekend!

What you should know before moving to Amsterdam

Tue, 20 Nov 2012 12:05:19 GMT

This post is a bit unusual for this blog: a few months ago I moved from Milan to Amsterdam (curiously, four years after my first visit to the city) and gathered some advice from friends and websites in the process. That information helped a great deal during my first weeks here and ensured that my move was a smooth one. I believe others in the same situation may benefit from the notes I gathered, so I decided to post them here.

As an EU citizen with a job offer from a company that has an office in the Netherlands, my transition was quite easy, but there were still some aspects that took me a while to figure out: I will try to cover most of them within this post. For everything else, you may find a lot of useful information in the links at the end of this article.

Finding an apartment

I had started looking for apartments to rent a couple of weeks before flying in but soon realized it was an exercise in futility. The rental market is extremely dynamic here: properties that are up for rent one day may be gone the day after and new ones show up daily. Because of the high demand, both agents and landlords tend to ignore messages from anyone who is not already in the city. Start looking for apartments during the very last days before moving in: it will give you an idea about the market prices and you will have some chances of getting an appointment to see the places you want to see before they are rented out.

Here a few websites you can start from

Funda – a website affiliated with the national association of real estate agents, it is one of the most reliable sources as the postings are reviewed and usually backed by an agency. The downside is that it is only in Dutch (you’d better get used to that), but you can Google Translate it.
Pararius – you will generally find almost the same postings you found on Funda, but Pararius is translated in several other languages (I mean the interface: the contents of the posting are likely to be in Dutch, clearly) but sometimes you can find posting by landlords that are not relying on an agency (yet).
Craigslist – less popular here than in the US, it is still possible to find a good number of listings for Amsterdam. Beware, however, that a good fraction of them are from scammers after your money or your personal details. If you are willing to invest some time to sift though the garbage, you may find some good deal without having to rely on an agency. You may use this IFTTT recipe to get email notifications of new posts straight in your inbox.

While there are other websites, they are likely to have the same information you can find on Funda and Pararius.

Once you are in Amsterdam you can visit agencies in the area(s) you are considering and tell them your requirements and your expectations. Do not overdo by contacting too many of them, though: most agencies have access to the same properties to rent, and they it is not unlikely that they will propose you the same properties you saw yourself on Funda.

Make sure you visit the areas where you are considering renting: while the city is small and commute is generally significantly shorter than in other European cities, each neighborhood has its own character and perks. Ideally, you will want to see what the place looks like during day and night.

Depending on where you live now, there are some details you may not pay attention to because they are not as relevant in the city you come from. A few examples

tram lines – check whether there is a tram line running right below your window and the area is popular with tourists. The combination of those two is that you will frequently hear the loud bell noise conductors use to scare people away (literally) of the tracks. Most houses are built with bedrooms away from the road so the noise may be less of a problem at night, but still you want to know what to expect.
bike stands – some neighborhoods seem to have a chronic shortage of bike stands. While usually you may be able to chain your bike to a signpost or a tree, it may still be difficult to find a place to leave it if you come back late at night.
parking – if you are planning on driving a car, bear in mind that finding a place to park in Amsterdam is generally challenging, and usually it is not free. You can apply for a parking permit for the neighborhood you live in, but there may be a wait list several months long.
shops – since there aren’t many malls but plenty of smaller supermarkets, you will not be shopping for groceries once per week, but you will find it easier to make smaller purchases more frequently. Surprisingly, butcher shops, bakeries and greengrocers are cheaper (and the food you find there often tastes better) than supermarkets. Having shops close to your place will make your file easier in this sense.

Once you find a place you like, it is time to look at how contracts work.

Understanding the contract

The laws regarding renting in the Netherlands are very protective of tenants. The market is strictly regulated and aspects like the conditions for breaking the contract, the maximum rent and standard contract conditions have to follow certain rules. I found this article to be a good source of information about how the whole system works.

Two important points about the regulations are that, under normal circumstances:

only the tenant is allowed to break a contract,
“temporary” contracts are extremely uncommon.

There is a points system according to which every apartment is given a score depending on many different factors (condition, location and many others), and that score determines the maximum price a landlord is allowed to charge. However, as soon as the score of an apartment exceeds the number points that correspond to about € 650, that apartment is considered to belong to “free market” and the score is not really important anymore. That explains why there is almost no apartment in the € 650 – 900 range: apartments that rent for less than € 650 are usually given to locals who have the patience to apply for rent and go through a wait list, and then there is a second market for expats, who don’t know the system or can’t afford to wait months in order to secure a fair rent. If you have a contract and you are not sure whether it is fair there is a non-profit organization, called Wijksteunpunten Wonen, that can help you: its members will review your contract and give you advice on how to proceed.

Understanding rent costs

Rent prices in the Netherlands can be exclusive or **inclusive of expenses**. Exclusive prices work as you expect: you pay the landlord the base rent only, and you have to pay all the service costs yourself. With an inclusive rent, you pay an estimated amount in addition to the base rent as an advance payment for service costs (like energy and gas). In this case, the landlord is expected to keep an account of the actual costs and settle the bill at the end of the each year (refunding you the difference if you paid more or asking you to pay the difference if you paid less), so that you will not have to take care of setting up the contracts for energy, gas and the rest.

Regardless which option you choose, you will also need to consider that you will be expected to pay all the bills that are in registered in your name (like the taxes for water and for waste disposal). Fees often depend on where you live, you may spend about € 300 per year in addition to the rent. You will start getting those bills by the moment you register as a resident (see the following sections) in your apartment.

If you rely on an agency, be prepared to pay a commission of roughly one month’s rent at least (generally it is calculated on the base rent, excluding expenses, plus 19% tax). This will effectively mean that you will need to be able to pay roughly three times the rent upon entering the apartment (the commission, the first month, and one month’s rent as a deposit).

Looking for shared accommodation

I have been focusing since the beginning in finding an apartment, but there certainly are plenty of options if you want to share a place with someone else. The two options I have been (shortly) considering are Craigslist (again, the same considerations in the previous section apply here) and Kamernet, a well-known website dedicated almost exclusively to rooms for rent. Even more than with apartments, being already in Amsterdam helps: you want to meet your possible flatmates in person and, more important, they want to meet you before making a decision. Do not make the mistake of underestimating the reach of your friends and acquaintances: they may know someone who is looking for a flatmate.

Registering as a resident and obtaining a BSN

Getting a BSN (Burgerservicenummer, a sort of social security number) is a necessary step if you are going to live in the Netherlands: you will need it to get your health insurance, to open a bank account and your employer will need it before they can start paying your salary.

You will get a BSN by registering as a resident in Amsterdam and you are supposed to do so within the fist five days of arrival if you are planning on staying more than four months. If you are a Highly Skilled Migrant (see following section) the process is extremely simple and you can take care of everything you need in one single day at the Expatcenter, provided that you asked for appointment here (applies only to EU citizens).

You will need to provide:

your passport (an ID card may suffice, depending on your nationality)
a rental/tenancy contract or a home purchase agreement

Note that, if you have not found permanent accommodation by the time you need to register you may still register at your employer’s address. Doing so, however, requires you company to provide a stamped registration form that explicitly authorizes you to do so. Note that this is considered by all means a contingency situation, and you will be required to register at your permanent address within three months. If you have a work contract already you can get a registration certificate (a sticker on your passport) as well: you will need it if you want to purchase an apartment or vote, for example. Note that to finalize registration you will have to present your birth (and marriage, if applicable) certificate in long form. You will not need this immediately as you can present it later, but if you have not left your country already, you can get one in advance.

Note that if you are not an EU citizen and/or not have a work contract yet the procedure may differ (even significantly), but luckily the IND (the Immigration and Naturalisation Service) has a wizard you can use to discover what you have to do to get a residence permit depending on your nationality and other conditions. The rules are quite complex but the wizard helps a lot: I suggest you to go through it.

Registering as a resident will kickstart a series of processes that usually end up in you having to pay some money: taxes on water and waste disposal are usually computed from the day you registered and bills will follow you a few days after you moved in.

Note that you may also want to register at you local embassy/consulate as a national living abroad. Specifics depend on your country, but the process is usually straightforward.

Highly Skilled Migrants and the 30% ruling

The Netherlands apply a particularly attractive policy to foreign workers that meet certain criteria: if you are recruited or transferred from abroad by a Dutch company and have a skill set that is rare or inexistant in the country you may be eligible to a tax reduction.

In practice, you can apply for the ruling if you earn more than a certain amount (at the time of writing it means € 50,000 if you are older than 30, € 38,000 otherwise) and your employer is willing to certify that you possess rare skills. Note that you can not present the application yourself: your employer has to do it.

If you present your application within 4 months of the start of employment the tax reduction is retroactive, otherwise it applies from the month after the one you filed your request. If your application is accepted, you will pay at most a bit more than 36% in taxes and will be eligible to a few benefits. You can find more details on the ruling here.

Opening a bank account

Opening a bank account is quite easy: there are less banks here in the Netherlands than there are in other countries and the difference in offering is not significant. If you do not know Dutch yet, you will be interested in banks that are able to deal with expats. The challenge is not in the staff (again, anyone is able to speak good English here) but in the correspondence: you will want to receive communications in a language you understand. ABN Amro is quite good in that respect (even though you will still struggle to find some documents in English) and I know that Rabobank has a special expat desk, but I am sure that you may the same with other banks as well. Just ask what they offer to expats and do not assume anything.

Once you made your choice, you will need:

your BSN,
your passport,
(usually) a copy of your contract or a letter of employment.

Note that if you don’t have a BSN but you still need to open a bank account, the ABN Amro branch at Schipol Airport may be able to open one for you if you commit to communicate them your BSN as soon as you obtain one. Unfortunately I did not know that at the time, otherwise things would have been much easier.

Getting your health insurance

Health insurance in the Netherlands is mandatory, even if you already have a one in your country of origin. You will need to get at least a basic insurance package (around € 100 per month) for your company of choice. The contents of a basic package are regulated by law, insurance companies are not allowed to charge different fees depending on demographics and are not allowed to refuse assistance, regardless of pre-existing conditions. Unlike what happens in other countries, you have to pay for your insurance but your employer may provide additional coverage as part of the compensation package. There are many different insurance companies in the Netherlands but, if you are going to get any additional coverage as part of your compensation, you will probably sign with the ones your employer has agreements with.

Moving around

Amsterdam is a small city, especially compared with Milan, where I used to live until a few months ago. Commute is shorter and there are many different options for moving around.

Public transport

Public transport in Amsterdam is excellent: the network of trams, buses and subway allows you to get to most destinations in a reasonable amount of time and with a limited number of changes. While the regular service stops a bit after midnight, night buses are still frequent enough to be a realistic option (for everything else, there are taxis). You can get public transport tickets at vending machines that you can find at in all the subway stations, but you can purchase them on board of trams and buses as well. If you do so, you are usually surprised by the costs: € 2.70 for a 1-hour ticket (you can use it as many times as you want) and € 7.50 for a day ticket.

It is indeed a lot, but there are ways to pay less. If you get an OV-chipkaart you will pay as you go: the amount will be charged will depend on the distance you travel (with an average of about € 1.50 for a trip across the city). You will have to check by tapping your card against an RFID reader once you board and check out once you get off.

The card itself costs € 7.50 and it can be topped up online, at vending machines at stations and supermarkets. You can get an anonymous card or a personal one which will have your name and photo on it. The advantage of the latter is that you will be able to use it for seasonal passes or have it top up itself automatically with credit from your bank account.

You can travel on trains across all the Netherlands using the same chipkaart you use for public transport in the city, you will only have to visit one of the NS vending machines (the yellow ones) and select your preference between 1st and 2nd class.

Biking

Bikes are a symbol for the Netherlands, and you will find Amsterdam to be perfectly designed for cyclists. Locals prefer biking to any other alternative, and you will find people driving their bike to work regardless of the weather. Once you will have spent more than a few days here you will be inclined to do the same: if you spend most of your time within the city, biking is faster than any alternative.

Get a sturdy bike, as it will need to withstand harsh weather conditions. Do not buy a fancy bike, as it will get more than a few scratches when placed on bike racks (even if you pay attention to avoid that, people placing their bike next to yours will not be as careful as you). Buy a good lock, even if it costs a lot compared to the value of the bike, especially if you leave your bike on the street at night: crime rate in Amsterdam is lower than in other cities, but bike theft is incredibly common.

Driving

Owning a car in Amsterdam is expensive: the road tax is quite high and parking is very limited (bear in mind that even if you have a permit to park in your neighborhood, you will likely need to pay if you drive to another). Given the way the canals affect the road plan, traversing the city by car is generally not the quickest option. Should you decide to bring your own car, you will have to follow a strict procedure: you can find more information here. Depending on the country you come from, you may also have to exchange your driving licence with a Dutch one or get a new one.

Useful resources

I summarized all the information in my possession but I have not covered some topics that may still be of interest to you. The links in this section should provide you with all the information you need.

I amsterdam – by far the most complete and accurate source of information about what you need to know about moving to Amsterdam
IND – the official website of the Immigration and Naturalisation Service
Moving to Amsterdam – a useful section on Internations that contains some more useful information (access is restricted to members, unfortunately)

In addition to that, if you are already in the Netherlands or can plan a visit before moving, consider visiting the Expatcenter in person: they will be able to help you and give a clear picture about what you need to do in order to move here.

Bonus: Here’s a book I’d recommend if you want to learn more about the Dutch and their culture: Why The Dutch Are Different: A Journey Into the Hidden Heart of the Netherlands. It will be a good way to prepare to what you’ll find once you move there.

Acknowledgements 🙂

Most of the information in this article comes from personal research but, even more, by friends that have been through the experience of relocating to Amsterdam. Their precious advice helped me making my move here smooth and painless. Thank you Andrea, Angelo, Matias, Nicola.

On desire paths… and software

Mon, 23 Jul 2012 13:10:00 GMT

Desire paths are a common pattern in landscape design: born as simple footpaths when someone takes a more direct, shorter way to their destination, they often evolve to proper paths and roads after a ...

Alessandro Bahgat's Blog

Visualizing Ukkonen's Suffix Tree Algorithm

Learning algorithms from books

Implementing from a paper

The visualization I wish I had

Adding more strings

Searching

Try it yourself

Beyond suffix trees

The Velocity Paradox

The Unhappy Middle

Bespoke Frameworks: from Asset to Dead Weight

Zero Slack

When Generation Outruns Verification

The Broken Inner Loop

The Slowing Submit Loop

From Craftspeople to Janitors

From Janitors to Gardeners

Building the Dark Factory

Crossing the Chasm

The Ghost in the Training Set

The Invisible Weight of Training Bias

From Prompting to Infrastructure

The Trap of “Contextual Debt”

Conclusion: Managing the Agent’s AI “Memory”

Footnotes

Receiving Feedback Is A Skill

Things I Stopped Doing

Taking It Personally

Arguing With Feedback

Things I Learned To Do Instead

Being Thankful

Following Up

Wrapping Up

Programming Machine Learning

The programming puzzle that landed me my job

What to look for when hiring

Intrinsic Motivation

Relentless Focus

Independent Thinking

Fast Learning

Responsiveness and Follow Through

Decisiveness

Curiosity and Inquisitiveness

Communication

Going the Extra Mile

Footnotes

Visual and HTML Testing for Static Sites

Zing LED Smart Night Light

Migrating From Wordpress to Hugo

What’s wrong with Milan’s Open Data initiative

Appsterdam Guru Session: Google App Engine for beginners

Presenting Professional Invaders

What Van Gogh can teach us about persistence

Prettier source code on WordPress.com

Embedding Gists

Styling source code by customizing your CSS

What did I choose?

User authentication with webapp2 on Google App Engine

Beyond keyboard shortcuts

Story of a hack: Bring Your Own Music!

How was BYOM built?

What have we learned by it?

What about the technologies?

How did it go?

Can I see it?

What you should know before moving to Amsterdam

Finding an apartment

Understanding the contract

Understanding rent costs

Looking for shared accommodation

Registering as a resident and obtaining a BSN

Highly Skilled Migrants and the 30% ruling

Opening a bank account

Getting your health insurance

Moving around

Public transport

Biking

Driving

Useful resources