If You Haven’t Worked Remotely Abroad, You’re Missing Out.

It’s no secret that remote work (also called telecommuting), growing by leaps and bounds in the last decade, has allowed the modern employee to work from some interesting places: a home office, a café, or even at the airport. Yet, when I’m given a privilege, I like to see how far I can make it work to my advantage.

I’m talking about working and living abroad for a while while continuing to pursue your career at your home country.

coffee and croissants, breakfast for champs
coffee and croissants, breakfast for champs

A lot of us might dismiss the idea initially, coming up with excuses why we could never do it: a house, our family, a language barrier, or simply the sheer amount of work involved with moving. I’m here to convince you why you’re wrong, and what you could be missing out on.

To give you some perspective, my wife and I decided to move to Argentina last October, having spent the last 6 years in Dallas, TX. As a software developer, I was worried about things like a good Internet connection or the perfect office setup. What I didn’t realize is the ridiculous financial advantages, opportunities for personal growth, and overall benefits such an experience would present.

Here is my short list of amazing benefits you get when working abroad, in no particular order:

1) Cheap Weekend Vacations – By being closer to your chosen destination, you can take many more trips and excursions, without having to pay for that costly international airplane ticket multiple times. Over time you can become an expert in that destination, covering a lot more ground than you would have with a short two week trip. My wife and I have taken weekend trips to Buenos Aires, as well as down the Atlantic coast of Argentina, and plan to go down to the end of the world to see glaciers and penguins, as well as partake in delicious wine and food in Mendoza.

2) Find Time To Do Your Best Work – Have an open source project you’ve always wanted to spend a few months working on? That book you’ve always dreamed of writing but can’t seem to ever fit into your busy, hectic schedule? Many artists know that escaping to another city or country gives them the time, inspiration, and perspective to work on their magnus opus. If you choose a place where costs of living are much, much lower, you can discover that precious time you never seemed to have before.

working from the breakfast bar at our first apartment
working from the breakfast bar at our first apartment

3) Force yourself To Become Better With Fewer Tools – Many of us with office jobs live within the comforts of our dual screen monitor setups, aeron office chairs, and adjustable height desks. Going abroad means choosing the tools that are the most important, and becoming better at working with just those. If you only have a 15″ screen, you’ll learn to work with every pixel. You’ll figure out how to pack the optimal backpack. (Mine has my Macbook Pro + Apple Magic Mouse + Logitech K750 Keyboard). You’ll learn to work from a quiet home, a loud café, or a moving bus. This may sound like a lot of work. But excellence comes from hard work and struggle, and such an exercise will improve your ability to focus and get stuff done without having the perfect work conditions.

4) Learn How The World Really Works – You can learn a lot about world economics, globalization, market forces, and how others live when you leave your home country. In our particular case, I felt like a got the equivalente of a PhD in economics after arriving in Argentina, a country that suffers from 30% annual inflation, has a parallel market for exchanging dollars (called the blue dollar), and is running out of American dollar reserves, which backs their currency. (Although this sounds a bit scary, trust me, everybody’s fine, and things are cheap). By simply contrasting the new country with your own, you start to question assumptions you made about how the world works, deconstructing the economics, politics and culture of your own country in the process.

5) Save Money For That Future Goal – Maybe you imagine having a villa in tuscany one day, or dream about owning sailboat you can to take around the world. Many of us have dreams that slowly evaporate because of high living costs in large (though totally awesome) cities like New York, San Francisco, or London. By leveraging exchange rates and differences in the cost of living, you can make your income last a lot longer. Just to give an example, according to this site, the cost of living in Buenos Aires is 77% cheaper than San Francisco.

5) Enjoy A New Food, Culture, and Language – Life is short, the world is large and much less homogenous than many of us Westerners would like to believe. From tiny island nations in the Pacific Ocean, the mystic mountains and Buddhist monks of Tibet, all the way to the quaint villages of Central America, there are cultures, traditions, political beliefs, and ways of living we can learn about and from. Having a homebase abroad allows you to  learn about your immediate surroundings, as well as explore nearby cities and countries. For example, with a home base in Seoul, one could easily explore other countries in Asia like Japan, China, or Thailand.

6) Have an Excuse to Simplify Your Life And Find Freedom – As Joshua and Ryan from TheMinimalists.com point out

“If you desire to live with less material possessions or not own a car or a television or to travel all over the world, then minimalism can lend a hand. But that’s not the point. Minimalism is a tool that can assist you in finding freedom.”

Taking at least a year or two to move somewhere will make you evaluate what’s important in your life, often ridding yourself of burdening personal possessions that only clutter your life and your home. Because you can only carry so much on a plane, you’ll have to make deliberate decisions of what you should take. Later on, if you find out you do miss something, you’ll see how far you can go without it. And finally, if you realize you really do need it, you’ll appreciate having it all the more.

So, are you ready to reward yourself with a benefits package from a new job?

 

This is in response to this Toptal Blog

My review and favorite videos for NDC Oslo 2017

I attended the NDC Oslo developer conference this year, and had an absolutely amazing time. Here’s my brief, bullet-pointed review, along with some of my favorite talks.

The good

  • Extremely well organized — had an overflow room where you could switch between talks if you weren’t sure which to attend
  • Included a good number of soft-skill presentations; provided a nice variety
  • Good speakers — a good mix of “celebs” like Troy Hunt, Jon Skeet, but also other great, lesser-known ones
  • Good food! Great coffee! (they had booths with pour over and pretty good espresso)
  • Easy to get to — arriving from the airport to the city is a breeze
  • I left the conference feeling refreshed and motivated to do cool things — more than any other event I’d attended.

The bad

  • Norway can be a bit pricey, depending on where you’re coming from, especially when you consider the taxes
  • On that note — the final cost of the ticket surprised me a bit, because of the 25% of VAT.  The cost for the 3-day conference pass was published at 12,900 NOK (about $1508 USD), but the final ticket cost was $1,948.60 USD
    • However, with food and other goodies, I thought it was pretty good value overall
  • It wasn’t hard to find good hotels for $100 – $150 a night.

All the videos are now available on YouTube

Some of my favorite talks:

Microservices and Rules Engines – a blast from the past by Udi Dahan
Udi describes times when encapsulation breakdown in a micro-service oriented architecture — and how rules engine can be a nice solution to them.

State of .NET Performance – Adam Sitnick
ValueTuple; Span (working with unmanaged memory); ValueTask. Pretty good stuff.

C# 7 – Jon Skeet
A nice refresher on all the latest lang features. He ran a bit out of time, unfortunately.

Beyond step-by step debugging in Visual Studio – Tess Fernandez
Tess describes using procdump to debug your applications; DebugDiag to diagnose, as well as WinDBg to analyze.

Using C#’s Type System Effectively – Benjamin Hodgson
Benjamin’s talk about expressing ideas (in particular, an abstract expression tree) using C#’s type system. Really good!

Banish Your Inner Critic – Denise Jacobs
A really inspiring talk to help us unleash our creative side and help us build stuff without so much self-criticism. She’s an amazing speaker.

Emerging Web Security Standards – Scott Helme
Talks about Same-site cookies, certificate transparency

Hack Your Career – Troy Hunt
Troy takes you through the story of his recent career, and some of the steps and tricks he used to become happier and more successful.

Norway was also very pretty 🙂 I recommend the Norway In a Nutshell Tour, if you have an extra day or two.

A post shared by Arie Litovsky (@arie_speaks) on

A Culture of Trust

We live in a time when software developers change jobs every 12 months.

Usually, about two years into a job, I start dreaming of greener pastures with better pay and more interesting work. Working at Stack Overflow has been the exception to that rule. In the wake of the recent Amazon exposé and my 2 year work anniversary, I’d like to share some thoughts about what it’s like working at Stack.

Some background: I am not one of the founding developers of Stack Overflow. By the time I arrived in August 2013, the core Question & Answer (Q&A) team (our most popular product) was well established; the site had been around for four years already.

On Turnover

During the two years I’ve worked at Stack Overflow, only three web developers have left the company. Of the three, two of them left to work on a startup, and one of them – Matt Jibson – went to work on a technology stack he was more interested in. The day he left, Matt tweeted:

//i.imgur.com/SuGuOVo.png

Our lack of turnover speaks for itself.

On Continued Employment & Trust

During my two years at Stack Overflow, I have gained a solid understanding of its many facets. I’ve learned about our mobile apps, our core Q&A product, our technology stack, the Stack Overflow Careers product, and even sales. However, I feel I’ve barely begun to make an impact on the company.

Having spent a year and a half on the mobile team, I recently decided to change teams, eventually finding a balance of fit and interest in our Careers product.

Tenure with a company is extremely valuable for both parties. You build trust and rapport with your co-workers. Today I feel comfortable and familiar with all of my fellow developers, product managers, and even the VPs and “C-level” execs (who are very accessible). On a typical day, I’ll talk to sales representatives in the morning while making espresso, chat with our office managers and assistants, and say hello to our incredible chefs. I would talk to the walls too, if only they’d give me interesting insights about the company. I’m working on that.

Some business folks that I’ve worked with in the past don’t like to talk. Isn’t it better to be secretive about your work and get ahead of your co-workers in this dog eat dog world?

We have a good answer for that. In the book The Five Dysfunctions of a Team, Patrick Lencioni explains that many of the basic problems of a modern team are structured in a pyramid. It’s similar to Maslow’s hierarchy of needs, but from a corporate perspective. At the base of Lencioni’s pyramid is the absence of trust:

Patrick Lencioni's 5 dysfunctions

Clearly, if you don’t trust each other, the bottom dysfunction isn’t resolved, and thus the upper dysfunctions just crumble under a bad foundation. On the other hand, when you do trust people you work with, you can avoid feeling any of the following:

  • This person will think my idea is stupid, and will conclude I am stupid.
  • This person will steal my idea and take the credit.
  • This person doesn’t really know me, and will misunderstand / undervalue my perspective and background.
  • I’m too shy to share since I barely know her/him.
  • I don’t want to share my idea with this person. I don’t trust him/her.

This means that the best ideas in a dysfunctional company are never shared. People are afraid to speak their mind freely, and thus the flow of information (which is essential to a business’ success) is slowed down.

It Isn’t Just Trust

For me, trust has led to a deeper knowledge of the organization, its products, and our business goals which allows me to work with confidence and propose ideas without fear. I would never have gained that knowledge without communicating with my co-workers. I recall many talks shared over lunch where I listened intently and asked lots of questions without being afraid of appearing dumb.

In my case, developing trust has been key to my success. I am proud to see a few recently hired co-workers who are more trusting than I was, and therefore are having an impact on the company sooner than I had. By letting yourself become vulnerable, you begin to build trust with others.

This is what we do at Stack. We make sure people aren’t afraid to challenge each other, and are comfortable in constructive conflict. Challenging a co-worker that you haven’t built trust with can seem aggressive and cut-throat, because she or he isn’t sure of your motives.

Side thoughts:
I’m sure I’ll read this post in 10 years and laugh, but right now it’s hard to imagine finding a better place to work. Actually, I hear this a lot in our office. People regularly quip, “I never want to leave”. When the company’s mission is about serving the software developer community and creating a healthy community of learning, it stands to reason that the company will treat, not only its developers, but all of its employees in a fair and humane way. Stack does this by giving its employees all the tools that we need and simply getting the hell outta our way.

Want to work with me? Stack Overflow is hiring.

Thanks to David Haney (@haneycodes) for editing / proofing

From Mobile Back To The Web

Developers will generally agree that learning the latest and hottest set of technologies will help you advance your career and avoid getting left behind. In addition, most of us know that specialization in one technology stack triumphs shallow knowledge in many others.

In this post, I’d like to share my more unusual — though not unique — experience of how going from mobile development back into web development kept me sane and helped me feel more fulfilled at Stack Exchange. With such a huge professional investment in the mobile world, the higher demand and average pay of mobile developers, you might wonder why I would even consider switching to the not-as-hip ASP.NET stack (as most mobile developers’ see it).

My background

A mobile developer’s desk at Stack ExchangeA mobile developer’s desk at Stack Exchange

I’m part of a small, but lucky subset of developers who graduated from university in early 2009 — a time when the US recession was still looming in the mind of every college student preparing themselves for a bleak job market. On the other hand, this was only about 9 months after Apple had released the first iOS SDK, and only 3 months after Google released their rival product, the Android SDK.

Neither of these facts seemed to have much effect on my first job. The mobile revolution hadn’t quite come in full force.

Instead, I worked at a company in the supply-chain management space where I spent 11 months at work using a custom Eclipse build that was souped up in-house, with a little bit of Javascript on the frontend using Ext JS. Getting my machine ready to develop took about a week; build times powered by Ant were painfully slow (on the order of 5 minutes), especially on the aging desktop that had been passed down to me by some poor soul.

During these idle periods of my (quite sad) first experience in the real world, I had plenty of time to work on a new skill. I had fiddled with the iOS SDK during my second year of college, when a friend was working on an early medical translation app for the iPhone. I never got very far with it, and my studies took over. However, this time around, I had ample time to read documentation, write some test code, and even release my first App Store app for studying with flashcards!

Things really got going in 2010, when, with the little experience I had developing on mobile phones, I got a different gig at an up-and-coming, mobile-only shop in Dallas. The subsequent three years were a period of non-stop learning and growth — our modest shop grew from 10 developers to over 50. I had ample opportunity to learn the subtle art of mobile development on both the code and UX ends. It was definitely a special time to work in the field, as businesses need their apps done yesterday, and there were many big-brand projects that were featured or promoted on the Apple App Store.

At one point I even spent a summer working on my own startup, creating an educational math app for the iPad.

The Stack Exchange mobile app

When I came to work at Stack Exchange in mid 2013, I was the first iOS developer to be hired. Kasra Rahjerdi had recently joined to work on Android, and Brian Nickel was hired soon after to work on iOS as well. We already had the comprehensive Stack Exchange API, but only a rudimentary app that some employees started working on. We rolled our sleeves, dug in, and released the first iOS version in May of 2014.

After some time, I got an itch. I needed a change.

There were several, very good reasons for this. After working on it for over a year and half, the iOS app was approaching a level of extremely high polish. We were beginning to fix very small and uncritical bugs (a good problem to have). With two iOS developers at the helm, we were competing for the little work there was to do. A piece of software can always improve, but that doesn’t mean those improvements have any bearing on real business goals. In our case, creating new, shiny yet important new features often required lots of work on the backend, which was under the responsibilities of the Core Q&A team, who are often busy working on more urgent things. This started to become a little frustrating, and not very fulfilling.

At the same time, I got a little sick of working within the iOS ecosystem. (One can only drink the kool aid for so long). I had been doing it for almost four and a half years, and while that may not seem like a lot for some you oldtimers, I was tired of doing the same type of iOS apps – a CRUD app that consumes an API with lots and lots of UI work.

I thought about switching roles several times, but I was pretty hesitant. Our iOS team was small; I didn’t want to seem like a quitter, and, to be honest, I didn’t have a lot of experience on the .NET stack. The only related experience was using Web Forms back in 2006 during an internship, but Stack Exchange uses the well known ASP.NET MVC framework.

Maybe I underestimated myself. I also wrongly assumed that the web had changed way too quickly in the period I wasn’t working on it. Mobile was definitely changing fast, and it was fun (but also time consuming) to stay up to date with yearly SDK releases (and some big design changes), so I thought I would lose years of experience in the process.

How The Change Happened

One fateful morning, I received the following e-mail from our VP of engineering:

David’s E-mail about hiring plans

Whatever doubts I had about moving teams were set aside, and I seized the opportunity to explore a new tech stack and team. Obviously this was not a new practice at Stack Exchange — we’ve had several developers move and create new teams like our ad server team or the data science team that works on the providence project. We’ve even had a few brave souls who have become engineering managers. However, that simple suggestion by our VP was the catalyst (or kick) that I needed to get out of my comfort zone.

I decided to join the Careers team. I liked the potential to build new feature quickly, coupled with a smaller audience size (which gave me a little more room for error and learning).

Getting Up To Speed

I feel pretty good ramping up to “not quite mastery, but can get things done” within a month or so. With the aid of some excellent setup scripts, I had a working and running development instance of Careers in less than a day’s time. The scripts are simply a series of batch files that lead you from a fresh-windows install through installing Visual Studio, cloning all the necessary repos, setting up the MS SQL database instance, setting up Redis, Elastic Search, and even IIS.

A screenshot of one of our setup scripts

I spent the first week pouring over a book on the ASP.NET MVC Framework. I had used C# quite a bit in a previous internship, so had no trouble there. I still felt a bit rusty on my frontend chops, especially when it came to newer JS frameworks, so I spent a little bit of time playing with Angular JS, as well as attending the O’Reilly Fluent conference in San Francisco (paid for by Stack Exchange, of course). Like many others, Stack Overflow was integral to filling in any gaps and learning by example, which I think really helps cement everything in.

By joining the Careers team, I also swiftly got exposed to a different set of products and got to know some new faces. I think this gave me a broader perspective, but also fostered my sense of belonging and purpose in the company. As part of a small team, and especially working remotely (and from a different country!), I felt a bit insulated at times; this is great when you have your work cut out for you, as I did while working on the Stack Exchange app, since you can focus and get things done. On the other hand, joining the larger Careers team gave me access to an organizational and product knowledge that is difficult to get otherwise.

First Steps

My first task as a Careers developer involved allowing our customers to buy job listings of different durations online. Until then, customers could buy 30-day listings by themselves, but would need to call a sales person to get a 60-day, 90-day or longer listing. Our checkout funnel was also promoting the idea of buying in bulk, and while this is still possible (and cheaper per unit!), we know that longer listings tend to make our customers more successful in completing a hire.

The new checkout formThe new checkout form, now with longer listings

These two small, seemingly innocuous changes involved touching quite a few parts of the codebase, since the assumption of a 30-day job listings was sprinkled here and there. Though not a particularly interesting problem technically, it was small enough in scope that I could complete it quickly, learn a lot about our codebase, talk to many different people throughout the organization, and get get something shipped within a few weeks. The actual implementation only took 2-3 days; the feature was shipped a littler later while waiting on some verification from our marketing team for new prices, and some updates to localized copy.

Conclusions

I haven’t abandoned the idea of working on iOS — far from it. Taking a break to explore some other areas puts me in a great position, say, if we wanted to create a Stack Overflow Careers-focused mobile app. And while I don’t recommend changing teams or project around every month, keeping our roles interesting, relevant, and exciting is something every developer can control and benefit from.

MagicalRecord Review

Many iOS developers are familiar with the Core Data library MagicalRecord (MR), written by Saul Mora from Magical Panda Software. After using it during the development Teaching Table, I wanted to share some of my experiences with it.

At a glance

These are the things MagicalRecord sets out to solve for you:

  • Easy Fetching of objects
  • Multi-threading (background saving)
  • iCloud support
  • Data Importing

I think the first two points are MagicalRecord’s strongest suit. If you want to simplify a lot of your fetching code, this is the library for you. It also thoroughly provides support for background threading and parent/child contexts, although I personally haven’t tested it fully (more below).

In terms of iCloud support, well, it sets up the basics for you, but it’s well known that, as of this writing, CoreData with iCloud is pretty difficult to implement. (See Daniel Pasco’s talk here or this post). This is obviously not the framework’s fault, but merely a problem it wraps and does not fully address. Basically, just because it supports iCloud, it doesn’t mean you should assume it will work out of the box.

Finally, data importing is a relatively new feature which still needs documentation, but it should allow you to import data from NSObjects. The typical usecase would be importing JSON/XML data into your database. Saul has a post with explanations and examples.

Background

The decision of whether to use Core Data deserves a whole post on its own, so I won’t discuss that here. I’ll assume you’ve done your homework and decided that Core Data is the right fit for your project.

I initially chose to use MR in order to save time writing a lot of boiler-plate code for Core Data. I had worked on several projects with Core Data in the past, and knew how to setup the stack from top to bottom, but found that for this project I had more important things to focus on.

Setup

After you import MagicalRecord, all you have to do is choose a stack (in-memory store, auto-migrationg SQLite store, etc), and it does the rest of the work for you.

//Methods from MagicalRecord+Setup.h
[MagicalRecord setupCoreDataStackWithAutoMigratingSqliteStoreNamed:@"MyStore"];
//OR
[MagicalRecord setupCoreDataStackWithInMemoryStore];

This is done with one of the many class methods of the MagicalRecord class. Most everything else is automatically setup for you (or lazily initialized) including persistent stores, managed object contexts, etc. Obviously, these are pretty standard setups, but if you want something a bit more complex like multiple persistent stores, you would have to add a lot of code yourself.

Expressiveness

I think most of the power of MagicalRecord, like other Active Record libraries, comes in its expressiveness. If you wanted to fetch for a set of objects, you normally have to write about 10-15 lines of code. Matt Mallagher saw this early on and wrote some very convenient categories on NSManagedObject to be able to query using a single line:

[[self managedObjectContext] fetchObjectsForEntityName:
@"Employee"withPredicate:@"lastName == %@, lastName];

MagicalRecord simplfies this a step further:

[Employee MR_findByAttribute:@"lastName" withValue:lastName];

You’ll notice a few main differences:

  • The NSManagedObjectContext (MOC) isn’t specified – MR in this cases uses a default one, although many alternate methods allow you to specify one explicitly.
  • In the first approach, the method is operating on the MOC; this is the classical way of fetching in CoreData, which places emphasis on the managed object context. The second approach operates on the Employee model. This shifts the focus to a model-centric design, and, in this case, makes no mention of a MOC at all. It’s important for any iOS developer using CoreData to understand how MOCs work, but this approach does make the code a bit easier to understand when glossing over it. We can see that we’re working with ‘Employees’ instead of directly with a whole dataset.
  • This particular method constrains you to a very specific type of query, namely, checking for equality for a particular value (lastName in this case). Again, more general methods are provided, such as MR_findAllWithPredicate:, which gives you all the flexibility you may need, but it’s nice to have some options to make your code more readable and shorter.

In terms of expressiveness, MR provides a whole slew of convenience methods to do just about anything in CoreData – including creating and saving MOCs or even easily initializing your own NSFetchRequests. Its API is pretty easy to follow, and once you work with it for a few days, you’ll be able to save a lot of time and code.

Multi-threading

MagicalRecord has been updated to leverage most of iOS 5 Core Data concurrency support (such as private queues, child/parent contexts). In all honestly, I ran into issues early on with this approach, especially when I tried implementing an undo feature with NSUndoManager. Because I don’t have enough experience with these APIs, and the fact that the library was not completely tested for it (as evidenced by recent commits), I decided to completely turn off background threading (for my project). I did this with a few simple changes which you can see here and here. I hope to try the normal threading setup in the future and see if it works well.

My Advice

I know most of you won’t listen to me, but I would highly suggest using MagicalRecord only once you’ve written a good chunk of Core Data code and understand how it works. Like any other framework, if you understand the technology below it, you can easily resolve any issues that may come up, all the while writing less code and leveraging others’ hard work.