I took an internet-free vacation last spring, and it was lovely.

While planning the trip, I made sure my old TomTom's built-in maps seemed accurate to what I was seeing online; there wasn't a lot of road-building activity there in the last decade or two. Then I turned off my phone and locked it in the glovebox, there in case of emergency.

Then I took a deep breath, started the car, and headed north.

It was awesome just knowing there was no way a notification could ding, nobody could call me, no news headline could pop up and harsh my mellow. Even if those things didn't actually happen constantly, simply existing in a state where they could was stressful, apparently, and turning the damn thing off was remarkably cathartic.

(Congratulations on the launch, looks interesting!)

https://www.imdb.com/search/title/?title_type=feature&releas...

I feel seen

https://briarproject.org/

edit: How it works: https://briarproject.org/how-it-works/

It doesn't have points and badges like Street Complete, but you can easily add/update/fix amenities, update addresses, add info about buildings, and fill in the same data using the "micromapping mode". I started with Street Complete, but now use this for most things.

Interesting, I'm going to have to check this out. I've been using OpenAudible for this purpose (paid).

I used to do this, but ever since reading Lexi Lambda's "Parse, Don't Validate," [0] I've found validators to be much more error-prone than leveraging Go's built-in type checker.

For example, imagine you wanted to defend against the user picking an illegal username. Like you want to make sure the user can't ever specify a username with angle brackets in it.

With the Validator approach, you have to remember to call the validator on 100% of code paths where the username value comes from an untrusted source.

Instead of using a validator, you can do this:

    type Username struct {
      value string
    }

    func NewUsername(username string) (Username, error) {
      // Validate the username adheres to our schema.
      ...

      return Username{username}
    }

[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

1. Sales -> You can hire a lot of sales people if they're generating enough business to cover their own salaries

2. Customer Support -> Big enterprise contracts generally have support written into them. Thus, for every enterprise customer Docusign may need anywhere from 0.1 -> 3 (or more) FTEs. If you price this right it's always worth it to keep growing the org this way.

Docusign has a lot of opportunities to upsell customers on legal services they provide.

You should also consider the scaling cost of internal support. For every 10 FTEs, add a manager. Also add on HR, accounting, janitorial, etc. Easilly 20% of the company might be these sorts of internal support roles.

If you want to read it before buying (or borrowing) it, have a look at some of the articles on fastcompany.com that excerpt parts of the book, particularly the hiring/career articles: https://www.fastcompany.com/user/judith-humphrey

If you want a bit of an “audiobook” version of it, you can hear parts in https://on.soundcloud.com/bAzbHeMJCC8CNhNk7 which is a podcast featuring the author.

shameless advert: do you wish testify was implemented with generics and go-cmp, and had a more understandable surface area? Check out my small library, testy https://github.com/peterldowns/testy

shameless advert: do you want to write tests against your postgres database, but each new test adds seconds to your test suite? Check out pgtestdb, the marginal cost of each test is measured in tens of milliseconds, and each test gets a unique and isolated postgres instance — with all your migrations applied. https://github.com/peterldowns/pgtestdb

I think "self-serve" analytics is silly, the idea that you put all of the data in front of people and they'll derive "insights". That's not how normal people or data work. We just had a discussion on HN the other day about Facebook's Prophet, and its pitfalls. Meanwhile we expect Joe in sales to be able to identify useful trends on a chart he made. Every company needs to forecast, regardless of their sophistication. That stuff needs to be defined by the right people and given to the users.

Strong agree! I do this too: https://jefftk.com/money

Of note, we do run our own javascript client on the pages. Our users can opt into hitting our backend API instead of running JS code, but many just use our client directly.

We currently serve the ads on our own domain. We could implement the ability for our publishers to proxy the ad views to our domain (this is generally called "ad cloaking"), but it hasn't felt like the right thing to do.

We are also on the Acceptable Ads non-tracking list, so our domains are unblocked for people who choose that in their ad blocker. If we use a publishers domain, they will be unblocked for some period of time, but then their domain gets added to the ad blockers, and we lose this Acceptable Ads traffic.

What I didn’t need at all, after all, was anything that installed different things on different hosts or classes of hosts.

Luckily, every tool I want to configure has a config file option to include another file, so I have a working copy of my version controlled defaults here:

  ~/.config/defaults

  # begin defaults
  source ~/.config/defaults/tool.conf
  # end defaults
  
  local specific config here

As soon as I figured this out I had to pinch myself as to why it had taken so long to come up with this idea.

It's pretty much my only "impressive" job of my career, in terms of name dropping at parties. But in terms of technology and business it was a madhouse. I remember thinking "Nothing like a business was happening at Esty." when they fired me. (I was going to quit, but my girlfriend at the time convinced me not to, and then they fired me a week or two later anyway. Long story.)

I always figured someone would eventually show up and want to interview me about it, but that's never happened so far.

I've forgotten most of the wild stuff.

All the business logic was in stored procedures in the DB so as you can imagine it was always on fire. Upgrading didn't help because our growth rate was ridiculous.

The frontend PHP guy was a newbie to programming. He barely knew what he was doing but he could nail those beautiful UX designs pixel-perfect. The guy's probably a millionaire now.

The backend sysadmin, DBA dude was a total Master-Blaster. If he didn't like it he would literally throw a fit and scream at the CEO and shut things down until he got his way. He used to lie to the CEO all the time if he didn't want to implement something he'd just say "it's impossible".

They built a skateboard half-pipe in the office even though none of us skated.

It was pretty nuts.

I found out later on that they hired me because my resume was the first one on craigslist that had Python on it. Then during the interview they found out I used Devorak layout on my laptop and that's why they hired me.

The "middle layer" they had me write was pretty much useless. It basically passed requests from the webservers to the DB. Over 80% of the API was empty methods, literally just a docstring, with all the processing happening in a decorator.

I implemented a cache in there (early use of Memcache. Glyph hisself wrote a Twisted interface to it in front of mine eyes! They were like "We want to hire a networking consultant. What about this guy?" Me: "You want to hire Glyph and I get to hang out with him and learn from him!? Yes. Yes, please." So that was nice.)

The thing is they didn't turn on the cache. It just sat there. The investors pushed this Sid person onto us to try to get some semblance of adult supervision. ... I've told this story before, Sid wanted some information on long-running requests, and I had to switch it (the cache) on in prod myself to show them that the required logging was already there.

There there was the other Sid who wanted to rewrite everything in Java. (First Sid wanted to rewrite in C++.) "Project Phoenix" he called it, that didn't go over well.

(Recall that the problem wasn't the implementation language of the server code, it was that all of the business logic was in stored procedures in the DB so rewriting the server code was never going to help.)

That's all I got this morning.

I’ve seen the same sort of thing in the private sector. Once you zoom out enough to understand decisions from the perspective they are being taken from, they very often make perfect sense. That doesn’t mean those very same decisions aren’t a load of bollocks from a lot of perspectives, but they are rarely just “fake it till you make it” sort of deals.

I think this author suffers from childhood delusion in that the author still thinks adults are supposed to have the answers for everything, which isn’t true. There is a lot to be said about figuring things out a long the way, but it’s not like people don’t know what they are doing, because we learn, we adapt and we very often plan ahead. I mean, the author even sort of contradicts the title or the article in the discussion on whether to do more SEO, YouTube, and/or, networking because that is already knowing a lot, just not everything.

A more accurate way to view the world would be that most people don’t know exactly how they are going to execute their long term plans, but almost every successful adult I have ever met did have both a plan and a genuinely good idea on how to execute it. From everything to their careers to raising their children, and I think it’s very easy to see when someone actually doesn’t know, because often they are either drowning, looking for help or both, or, alternatively never even beginning on the thing they want.

I'm going to use this comment as a way to talk about remote hiring generally, rather than respond directly to your comments. I want to help others understand some of the challenges it has been being one of the larger (relatively) fully distributed companies.

I think there is a common misconception that the world is mostly flat and that our company can hire from anywhere. I am commonly criticized when tweeting job postings (almost always remote) when the countries we can hire from is limited to a select few. "Not real remote" "first world remote only" "remote != 8 countries" etc. are common criticisms.

Disclaimer for the remainder: I am not a lawyer and my exact details because of that may be wrong. Please consult your own legal team.

When hiring remote, there are a few things to keep in mind:

1.) You have to adhere to employment laws within the country you're hiring from. Employment laws vary widely between countries and getting them wrong can be very expensive. For example: vacation time will vary, holidays will vary, the ability to let someone go will vary, what you can/cannot expect from an employee varies. In one country, emailing an employee outside of work hours is legally considered harassment; when working with multiple timezones that's a challenge because "in work hours" for one country may be "out of work hours" for another country.

2.) To employ someone full time, many countries require you to have a legally entity within that country. Establishing a legal entity takes a lot of time and a lot of money.

In the past 12 months, we've had at least one member (more now) on our HR/finance teams establishing legal entities _full time_. I've had my signature on at least 8 incorporation documents in the past 6 months. By the way, most incorporation documents require a "wet" signature so if you're remote like we are, be prepared to be FedExing a lot of sensitive legal documents around.

Beyond just paperwork, there are often requirements to establish a legal entity: a real, physical, local address is one. In one country, we had to pay out of a local bank account in local currency (which has its own red tape), and this country also required we maintain a minimum balance to pay 3 months salary in the local account in local currency at all times. For a startup, that much cash "not working" can be problematic depending what stage you're at.

In one country we're establishing an entity in, the process just takes a LONG time. We've been responding to any inquiries and sending paperwork immediately and we're 8 months in and still probably 2 months away from completing the process. Meanwhile, we still can't legally hire there.

A lot of legal paperwork is understandable in the local language of where you're creating the entity. This means that you also have to pay lawyers fluent in that language to vet the paperwork. We employ full time lawyers, but primarily in English, so this requires us to go to expensive outside counsel.

Finally, this is all expensive. There are fees to creating entities but also recall that we have multiple full time employees that spend their entire day establishing legal entities. So we have our own full time salary costs plus filing costs plus legal costs.

3.) Hiring contractors DOES work around some issues, but has its own downsides. First, we can't offer options/stock to contractors and we'd like all our employees to benefit from this. Second, we often can extend the same full time benefits we want all our employees to share such as healthcare, 401K, etc. Put another way: we want all HashiCorp employees to be employees, we don't want to create second class citizens.

Legally, some countries have legal limits on the hours a contractor can work or length of time they can be contracted before they're considered an "employee" by default and regardless of what you SAY the relationship is, the country will consider it employment and points 1 and 2 above all take effect immediately.

So we certainly DO hire contractors but our point of view is that we intend to hire those people full time over time. We'll often hire contractors if we know that we'll have a legal entity established to hire them within X months, and we're up front with the new hire about this. We'll also pro-rate option/stock vesting for their contractor period when they are hired.

4.) We prioritize countries where we have the most interest. We get asked a lot "please hire in X" but if the number of times we've heard X is much lower than Y, then we'll prioritize Y first.

This creates somewhat of an imbalance, since more countries with a more established tech ecosystem generally have more qualified candidates and therefore get prioritized higher.

We WANT to hire from everywhere, but as a startup with constrained capital and timelines, we have to be pragmatic about choosing the locations where we'll probably be able to hire the most roles while we continue to expand our entities.

5.) We are also open to relocating employees into countries where we do have entities. We've done this multiple times, we pay a relocation fee, and its a great way to hire someone from a country where we can't [yet]. Also note they're "relocating" but are still working remote.

Of course, this is highly dependent on the individual and it is unfair of us to ask or force someone to do this if they have an established family, friend circle, and generally just a life in their existing country. So this only works some of the time!

6.) Despite building process around remote-first, we try to a keep a healthy timezone overlap in each of our teams (3 to 4 hours out of the working day is best). We find that teams that have a team member with a non-overlapping TZ struggle for multiple reasons. So, even though we can hire in many countries now, we'll restrict some job postings to certain countries so we can have that overlap.

EDIT, some additions:

7.) Each US state ALSO requires a legal entity in addition to adhering to state-local employment laws, taxes, and more. At this point HashiCorp has entities in ~30 US states.

Further, there is a tax consequence to the business outside of employment taxes. If you hire an employee in a state, you also now have to pay sales tax on revenue from there. You may argue for/against whether that makes sense, but for a startup this can be VERY expensive.

Our corporate tax obligation would be hundreds of thousands of dollars [less] if we didn't employ people in New York state. We've had to weigh this in cases because the tax obligation from hiring _one_ individual could suddenly be that you can't afford to hire _multiple_ other individuals.

Note we don't want to avoid taxes, that's not what we're doing. But startups are capital constrained and we have to determine long term how we continue to grow and hundreds of thousands of dollars can make a difference.

----------------------------------------------------

Finally, I want to note that we're 100% dedicated at HashiCorp to remaining fully remote. We WANT to hire from everywhere. We're establishing the entities and process to hire in new countries full time. 18 months ago we could only legally hire in 2 countries, today we can hire in 8. By the end of the year it should be at least 4 more. We'll continue from there.

I could write a LOT more about culture and process within the company. But this comment is already getting very long and I think I'll keep it to this. Maybe in the future I'll write more about "chat literacy", the importance of decision inclusion, things that definitely don't work, keeping people motivated/happy, managing people you can't physically see, the lack of body language for signaling, and a lot more.

I hope this helps someone!

If the domain knowledge is on the code, you can only refactor. If the domain knowledge is on the team, then rewrite tends to be faster.

Most rewrites fails because the team rewriting is not the team that did the initial development.

The nice thing about this is I get a breadth of methods for receiving comments/reactions across multiple platforms, including anything that directly supports webmention (such as https://micro.blog/, where my posts are also syndicated), without having to do any of the platform-specific wiring myself.

I'm biased, being a musician, but my experience and many of my colleagues is that musicians are often excellent coders, and I credit this to the fact that you need to master your attention to become a good musician. There is no other way than getting good at putting yourself alone in a room with no distractions and practicing in a focused manner. I remember when I hired a friend of mine (pro bass player) as a junior coder and it was so obvious watching him learn.

Personally my top tips for getting better at attention management would be:

- Take up an instrument or some other hobby involving regular, quiet, uninterrupted, solo deliberate practice. Do it daily. It becomes your rinse cycle.

- Adopt the pomorodoro or other similar technique of doing 20-30 minutes of completely focused, uninterrupted work at a time and then taking a real break for a few minutes. This is both how I work and practice.

- Read a lot, on paper.

- Run - IMHO way better than lifting for overall mental effects and mental focus

- Get enough sleep, religiously

my two cents Canadian. :-)