Category Archives: Software Jobs

Time Zones are the Hardest Problem in Remote Work

I was recently asked for advice on getting US Remote work from outside the US. There are several things you need to figure out, but while most can be worked on, time zone overlap is the hardest to overcome. Even inside the US, it’s an issue.

When I worked at Trello, we were about 70% remote, but almost all of us were in the US, Canada, or Latin America. We required that everyone work NY afternoon hours (12-5pm Eastern US). In the UK, that’s 5-10pm. Practically, this meant we didn’t have very many people in the UK and Western Europe, and I can’t think of anyone more East than that.

After we got acquired by Atlassian, we had some contractors in Ukraine who partially worked our hours. When Atlassian announced Team Anywhere, their remote policy, time zone overlap was a big part of the requirement for long-term remote teams. I personally had to interact with people in Sydney sometimes, and time zones made that painful.

This is just a single company, but time zone overlap was part of the secret sauce that made remote working better for us.

So, if you are outside the US time zones and are applying to remote jobs, I would think about how much time zone shifting you are willing to do. Perhaps you really like working extremely late (my father worked nights when I was young). If you think you’d like it, then I would say that directly in your cover letter. Also, I would concentrate on the part of the US that is easiest for you to overlap with.

I Will Give You Homework

It’s my goal to sponsor (not mentor) people that come to me for help. This means that instead of giving advice, I want to directly help by using my own social capital on their behalf. But, to do this, I have to have some basis for recommending or vouching for them.

I have two strategies for this—direct hiring and homework. If I have work they could do, I hire them to do it. Usually a small project. Their work on that will be the basis of my recommendation.

But, I don’t always have work that is easy to bring someone in on. In that case, after hearing where they are having trouble (usually in job seeking), I give them some tasks that I think would help, and ask them to get back in touch to let me know how it goes. If they do something (not necessarily what I asked, but anything that addresses the underlying reason I suggested it) and follow up, then I will feel a lot better about sponsoring them, usually by setting up informational interviews.

Another Story from an Early Programmer

A few years ago I had dinner with someone who became a programmer in the 1950’s. Today I had a chat with someone who became a programmer in 1970. Here’s a paraphrase of her story.

I was an accountant, and my boss asked me to price a computer and database for the sales team. I talked to a distributer and he gave me a price for the computer, software, and services of about $10,000, which was within our budget.

Before I made the purchase, I made sure it could do what we needed, and I said that the computer would need to be able to calculate logarithms. The salesperson said that this computer could only do addition, subtraction, multiplication and division. To do what I needed, I would need an IBM 360 (which cost a lot more).

This didn’t sound right to me, so I bought a programming book and learned enough to know that (a) computers were going to be a big thing (b) the people working in it right now didn’t know what they were talking about (c) I could do well because I understood it immediately.

So, she left her job and went back to college to learn programming, starting with FORTRAN (spoiler alert: it supports logarithms). She ultimately had a career as a programmer and manager, retiring early.

Costly Signal Theory Applied to Job Applications

If a particular job is your top choice, you should be willing to do more than is necessary to get it. In evolutionary psychology, this is called a Costly Signal.

A costly signal is something we evolved to show genuine fitness in a world where there has been an arms race between deception and deception detection. You prove your fitness to a skeptical evaluator by doing something that is relatively easy for you, but would be too hard for someone less fit. It has to be something that is hard to fake.

Because it can’t be fake, the first step is genuine two-way fitness between you and the job. In a normal job search, it’s likely that you will know this before the employer. So, if you feel like a job would be an excellent choice for you and that you would be the top candidate for it, your behavior should reflect this belief.

The extra work you do should be relatively easy, but not necessarily easy. If it feels like too much work, then that might be an indication that the fit isn’t good. I would caution that some people undervalue themselves. If you have this tendency, then I’d get an opinion from a colleague or mentor of what they think your chances are.

Related articles

Just Started a New Software Engineering Job? Fix Onboarding

If you are about to start a new job as a software engineer, the way to have a big impact day one is to go through the onboarding with the intention to generate a list of improvements that you work on over time.

Here are some things to look for

Incorrect or outdated information. If you find these, just fix them as you find them.
Missing entry-point documentation. Even teams that have good documentation often do not have a document that is useful if you know nothing. Often they don’t go back and make a good “start here” kind of document.
Manual steps that could be scripted. Don’t go overboard, but if you see some quick wins to automate the dev setup steps, it’s a good first PR. It’s a tech debt payoff that is timed perfectly.
Dev Setup Automation bug fixes. If anything goes wrong while running the scripts to set up your machine, fix the bug or try to add in any detection (or better error messages) that would have helped diagnose the issue.

There is usually a lot of tech-debt in onboarding code and documents because no one really goes through them. Sometimes underlying things just change and tech debt happens to you. You are in a unique position to make it better for the next person and have some impact right away.

Keep Track of Your Good Work

This advice is mostly for people starting out in their careers in software engineering.

On your first day at a new job, start a document called “Promotion Packet”. If you are working for a company with published level descriptions, put in the job description of the the next level and include the judgement criteria in your employer’s words.

Find the company’s annual goals, OKRs, KPIs, etc, and ask how they trickle down to your department (and ultimately you). Write this down in your promotion packet as well.

Then, as you are working, look out for opportunities that align with that judgement criteria and the goals.

Finally, critically, keep track of all of those accomplishments with links. Make a digital footprint. For a programmer, that might be:

Code
PR comments
Documents (specifications)
Times where you are mentoring
Participation in decision making

You are specifically looking for places where you are driving outcomes that the company leadership thinks is important and makes the case that you are operating at the next level. In your promotion packet document, you would want to write a two-sentence summary of the accomplishment and then a link to the proof.

I wrote about the general requirements of higher engineering levels in How Senior Software Developers Think. In short, it’s ever expanding scope and leverage.

If a performance review comes up before your next chance at a promotion, then you can use the information in this packet for that.

Look for Ways to Make Your Job Application More Specific

A couple of days ago I wrote about how my most popular blog post (the UML Cheatsheet) was based on a talk I did at a local .NET group. I could not have predicted that it would end up being the most popular thing on this site.

I did predict what the immediate reaction to my talk would be because I had planned for that.

I did the talk because I was trying to get a job at the company (Atalasoft) that hosted the group. After my presentation, I got an impromptu interview with the owner and the Chief Architect (and was offered the job a couple of weeks later).

It’s a lot of work for a single job application. It doesn’t scale, which is the point. But, their job description was perfect for me, so I was willing to go all out. Doing that let them know that I thought we were a good match.

This is an example of what I was getting at when I wrote that your resumé and your cover letter should make no sense. They should be so specific to the intended recipient that no one else would understand them. In this case, I saw a chance to make it even more specific and took it.

Noticing Opportunities Using an AI Agent

I believe that Randomness is the Great Creator, which means that, to me, the universe is a random, unknowable thing that will offer us infinite variety. We can know our intentions, our goals, our wishes and pattern match the randomness against what we need. Some call this manifesting, but I think of it more like exposure and noticing.

It’s a way of taking advantage of the Baader–Meinhof phenomenon.

[which] is a cognitive bias in which, after noticing something for the first time, there is a tendency to notice it more often, leading someone to believe that it has an increased frequency of occurrence.

You don’t need to make opportunities happen more often if you can learn to notice them. So, tune this bias to things you want to notice. If you tell others your intentions they will be tuned on your behalf and think of you.

When I do this, I also enlist “AI” agents.

In 2005, I decided to look for a new job. I was in a non-profit, writing software for the organization itself. I had already realized that the better tech jobs were in product companies where the work I do drives revenue, so I set out to look for one.

I found sites that pulled jobs from many sources, but critically, could take a search term and use it to email me job openings on a regular basis. I set up a dozen search terms based on my personal job statement. I got weekly emails, each with a few jobs to check. It took a year, but eventually, I found Atalasoft, which was perfect for me.

This way of searching had the two elements I mentioned

I had a specific intention
I expressed it to an agent that would do its best to notice opportunities for me

I had always thought that finding my next job was blind luck, but I don’t think it was. I think I went through these motions less consciously.

I left Atalasoft in 2013 to do consulting. In mid-2014, I had decided that my next career move had to have some sort of optionality associated with it (little cost, but unlimited upside), so probably a startup. But I was deep in a project and not looking at all.

It was a confluence of several events in a short time that led me to apply to FogCreek and ultimately get a job at Trello. I was not looking for a job, but I was advising my client on remote tech recruiting/working, so I happened to be doing a lot of research on existing companies and saw the FogCreek ad on StackOverflow.

In this case, the StackOverflow job recommender “AI” made this happen. My activity and searches were training it to send me opportunities like this. I keep calling these agents “AI”s, but they were really just glorified SQL statements. Still, even that can be effective if you have enough data.

StackOverflow would have a deep understanding of my skills and my job history (I filled out their Developer Story and connected it to LinkedIn). Even though I had set my status to “not interested in opportunities”, I was doing a lot of job searches, many of them from my client’s office in NYC and some from my home in Massachusetts.

Similarly, FogCreek could train the AI to target developers like me. I had a high reputation on the site in tags that they might be interested in. I was senior and interested in remote work, but had lots of ties to NYC (and spent a lot of time there).

So, I had an intention, and I did express it to an agent, even if I wasn’t fully aware of this until years later.

The Unreasonable Effectiveness of Mathematics in Programming

(with apologies to Eugene Wigner)

My college didn’t have a CS major, but they let me put together one under a general engineering program. To fill up the requirements, I had to take a lot of math, which has been more useful than I expected a programmer.

I didn’t seek out jobs that required a lot of math. I optimized my job search around small companies doing product development for B2B, and didn’t care much about the specific technology they used. But, I was comfortable with the math, so it made my life easier.

The first eight years of my career was in FinTech, and the software I wrote was a nice UI around a lot of math. The core concept was options pricing (probability and statistics) and the sensitivity of that price to its inputs (calculus and differential equations). To do risk analysis, you have to build up huge matrices (linear algebra) for various purposes. Our company employed mathematicians, so we didn’t do the research, but we had to understand it to work on those parts.

Later, I contributed to a patent related in spreadsheets where graph theory was important. I also implemented numerical differentiation and root-finding algorithms as a way to run expressions backwards (numerical analysis and calculus). That patent expired, so I am reimplementing it in Swift and Typescript.

In 2005, I did a consulting project to implement a distributed monte-cargo engine for a decision support system. I would not have won this bid if I did not understand the math behind the engine.

From 2006-2013, I worked at an image processing tools vendor. This job was the closest to pure CS that I have had, and there was a lot of math, specifically linear algebra, but also some numerical analysis.

Every front-end position I have had uses at least a little linear algebra (for affine transformation). It’s not like you are doing the matrix multiplication yourself, but you’ll understand the more complex compositions better if you understand them. For example, if you know that matrix multiplication is not communicative, you’ll get why the order of the transformations matters.

Nearly every programming job now requires you to understand the analytics data that the software generates and to do statistical analysis on it. Forming a hypothesis and getting evidence to support or reject it is essential. At a bigger company, you might have a data-science team to do the heavy lifting, but it really helps if you can do it yourself—you also want to be able to read and understand their reports.

If you really want to go deep into the type theory behind type-safe languages (like Swift or Typescript), you have to understand set theory and maybe even HoTT. You don’t need it to use these languages, but if you had interest in compiler theory or implementing a language like this, it would help. Understanding set theory also helps with understanding relational databases.

When I was trying to find a Swift implementation of numpy a few years ago, I ended up finding Surge and contributed Eigen decomposition to it. I had to relearn it, but I would not have even tried if I hadn’t touched linear algebra since college.

Games are essentially physics simulators, which are ultimately math engines. I only write simple games as a hobby, but even for pong, I had to write vector math functions.

And, although I think my career has used a somewhat typical amount of math, there are programming jobs that require a lot of math. A deep neural network’s guts are a calculus and linear algebra engine (see this video from 3blue1brown). As I mentioned, data science makes heavy use of probability and statistics. I learned in Quantum Country that the “programming language” of a quantum computer is based on matrix multiplication with complex number entries. And while writing a game is a reasonable amount of math, writing a game engine is much more than that—and as more things (the blockchain, games, machine learning) have used the GPU for computing, the way you think of implementing solutions in those domains is more mathematical.

To be clear, you can do a lot of programming without understanding any of the math behind it. But, I have found it more enjoyable to go a little deeper, and it makes it easier to develop intuition about the higher level concepts.

In (weak) Defense of Algorithmic Tech Interviews

Yesterday, I wrote about my preference for work simulation tech interviews. There was one place I worked where we did more algorithmic tech interviews. Here’s why

We were hiring almost exclusively people that had just graduated from a CS program. They were actually pretty good at these kinds of questions and didn’t really know much else we could ask them.
The company made an image processing toolkit. There was a lot of data-structure and algorithmic code. There were a lot of optimization tasks. You really did need to know big-O for your code because all images had millions of pixels.
All of our code was in C# and basically no one knew that already. So we hired people that could program in any language and needed questions that worked for anything.

So, the questions I asked were not too far removed from the kinds of problems we did need to solve, but they were technically algorithm/data-structure questions. At that job, with that codebase and with the strategy to hire new CS grads, I would do the same thing.