One of the very wonderful things about the moment that we live in is how many mature platforms – both open source and closed, community-driven and commercial – we have at our disposal.

Consider the case of content management. There are many precedents of publications that maintain their own in-house content management systems (to name a few: New York Times, The Guardian, Vox). Even if your business is publishing, however, I would argue that to maintain an in-house CMS is likely a very inefficient allocation of resources that will most likely produce a far worse outcome (both in usability for content managers and in the velocity of product development) than to work atop an established one.

Unless your business is the platform itself (that is to say, selling or licensing a CMS) or you have extremely niche requirements (such as following government regulations that somehow cannot be met with an off-the-shelf platform), you simply will not be able to touch the usability and feature set of a mature platform.

To understand, in a deeper repsect, why, consider the immense investment that has and continues to be made into established platforms like WordPress or Ghost. WordPress core, with backing by Automattic plus a humongous base of open source contributors, has, at this point, literally millions of man-hours invested in it. Massive investment and adoption has the knock-on effect of creating large supporting ecosystems for these mature platforms – in the context of WordPress, for instance, this comes in the form of things like Plugins, managed hosting providers and support/consulting services.

Even for content-management needs within an otherwise custom application, there are today many excellent “headless” CMSes, both commercial and open-source, such as Contentful, Prismic or Directus. All of these expose content-management interfaces and workflows that, as with WordPress, have far more man-hours invested in them than many organizations would have the wherewithal or interest to invest, while still allowing you to integrate with your own application at the deepest level through client libraries.

This consideration of knowing not to build extends just as much to things like ops and infrastructure. Many organizations believe they need in-house ops solutions, an ops team and a permanent or interim CIO to manage them. I have seen in-house ops solutions balloon literally into the millions of dollars while providing _extremely_ poor usability compared to third-party platforms. There is certainly a case for in-housing ops, but I feel it is more narrow than many organizations tend to believe. If your application deployment requirements can fit within a PaaS solutions like Heroku, Cloud66, Hatchbox, Rancher or others, carefully consider the cost of choosing such a solution vs. the cost of matching the usability and power of such a platform with an in-house one.

This is ultimately the test for me. Building something custom is an investment, both in time upfront and time for ongoing maintenance. If a mature third-party platform has much more invested in it than you will ever be able to invest in your own alternative solution, and especially if the function that it fulfills isn’t the central competency of your organization, you will likely find significant leverage in not building in-house.

The post Leverage often comes in knowing what not to build appeared first on Hacker Notes.

1 month costs the same as 2 weeks

This was an observation my friend Steve made when we were in Asia last year and it’s proven reliably true for me. Typically to stay in a place for 1 month costs roughly the same as 2 weeks. This comes down to being able to pay month rates for things like accommodation (usually a 50% price break), transit passes or car/motorbike rentals, phone SIMs, and also cutting an additional day of travel (which is likely to cost several hundred dollars depending on where you’re going next).

Mobile internet has eliminated whole classes of tourist scams

I came to Europe after high school with a group of friends over a decade ago. We were subject to a handful of scams that are significantly harder to pull off now that you can get a local data plan for your phone in pretty much any country for ten bucks or less. Apps like Uber and its equivalents around the world have, I imagine, eliminated billions in dollars in taxi scam proceeds. Similarly, being able to spot-check exchange rates for a specific amount of currency makes it hard to get totally ripped off by a money changer (though you should only really use a money changer if you have no other option, like a proper ATM).

Making friends: easier and harder

It’s easier to strike up conversations in a place where simply hearing that someone is speaking your language is a pretext to break the ice. That said, when you’re living somewhere for just a few months, most friendships are transient. It’s mostly just the friends from travel-focused communities like Hacker Paradise that I’ve managed to reunite with reliably around the world.

Bummer though this can be, I also couldn’t help but notice how little I managed to see my friends even when I was back home in New York earlier this year. I find that when I’m in a fixed place for a long time, I tend to assume that I can always get together with friends “next week” and end up only seeing most of them very rarely as it is.

Some mundane things are an inordinate pain

Things like seeing dentists or certain medical specialists are doable, but usually a bigger pain than back in your home country (with the exception of a few places like Thailand, which has great dental and medical infrastructure that’s set up to a large extent specifically to accommodate English-speaking foreigners). Even simpler things like getting a good haircut can be a lot more challenging when you are on the road for a long time.

Similarly, setting up a new business bank account from abroad, at least for me as a US citizen, was impossible and I just had to wait to be back in the US (this is mostly thanks to the US Patriot Act and the rigorous “Know Your Customer” policies that often require an appearance at a local branch).

Thinking in timezones

Want to call your parents? Oh right, it’s 3 in the morning for them.

Want to have a conference call with a client? Better squeeze it into the 1 hour window where your work day overlaps with theirs (if you’re even so lucky to have that).

These sorts of things are never a problem when your work and most of your community are in the same city (or at least the same country) as you. It quickly becomes a central part of your thinking when you are 10 timezones away.

Overall is it worth it?

Overall I feel the tradeoffs are definitely worth it. Things like mobile internet, modern banking and Airbnb have made travel  so much more seamless and affordable than it’s been through all of history prior. I value a lot of the friendships I’ve made and experiences I’ve had, and feel that they always give me a unique and valuable perspective even when back home.

The post Some reflections on slow travel appeared first on Hacker Notes.

I say this is “baffling”, but there are reasons why the model persists. Having worked in several companies that pursued and (at least transiently) thrived under the model, the justifications I have observed are:

• It often *is* good for founders, in that if founders are able to do secondary sales in later financing rounds, they can get paid up front (by investors directly purchasing their shares) sums of money that it might take many years of slogging to pay themselves through distributions/bonuses if operating a non-VC backed company.
• If the company has a major liquidity event (big acquisition or IPO) founders and (occasionally and with caveats) early employees see significantly more money than they would have had they operated under a more traditional model. This is another way of saying that with the VC model (and with many caveats) you will “win bigger” if you win.
• Even though infrastructure/manpower costs might not justify selling a ton of equity for capital, there are certain domains where you really do need massive financial resources to win dominance or bust through bureaucracy (things like Uber are a good example of this, using VC both to subsidize rides sold at a loss and also to shoulder the legal expense of fighting regulation).
• You can pay yourself a salary (and even sometimes a very generous one) while being unprofitable.
• Salaries (at what I have seen in engineering) can be very high in VC backed companies. Employees aren’t subject to a natural accounting for their value since there is not an expectation of ongoing profitability.
• You get resources, guidance and a sheen of legitimacy/prestige by having the backing of established VC firms.
• You have someone in your court (your VC backers) with a financial interest in seeing you win very big (this is a double-edged sword).

The very unhealthy aspects of the model that I’ve observed are:

• VC backers actually have a financial disincentive for seeing you become sustainable and cease pursuing an exit. It might take 5-10+ years or longer for them to just break even on their investment through traditional profit distributions (or liquidation of their shareholding) if you cease to pursue IPO/acquisition. Breaking even on a company over 5-10 years is actually an outcome of objective failure for their limited partners (LPs) and in the scope of the fund.
• Founders end up owning less and less of their company through dilution over many rounds of financing. This can be justified as having a “smaller piece of a bigger pie” and coming out net ahead but it does do something to the soul of a company and does cause them to leave sooner in my experience (i.e. either being pushed out by the board or leaving after an earn-out/golden handcuffs at an acquiring company).
• Employees typically get shafted as far as the class and treatment of their shareholding (common stock with fewer entitlements and longer lockup than the preferred stock that VCs and founders will hold).
• Often the company’s objectives become misaligned with those of its customers/users. Think of the countless product shutdowns that have happened after acquisition and consolidation or the many user/community-hostile decisions companies have made because of the independence they have surrendered after extensive VC financing.

This line of thinking led me to consider what a more symbiotic model might look like. I have been thinking through a product that is a sort of marketplace. It has no value for customers without an actively engaged seller community. Providing a well-functioning, well-designed platform and ongoing support are obviously important, but similarly essential is the community. It seems to me reasonable to offer the community equity.

Existing precedents

One startup that I know of that granted equity to its users (in the form of restricted stock) is the New York-based car-sharing service Juno. Their particular case has actually been a bit of a disaster, but an instructive one.

Juno is a competitor to Uber/Lyft that was founded in New York in 2016 by Talmon Marco, the founder of the once very popular mobile VoIP company Viber. Juno granted restricted stock to its drivers in proportion to the work they did on the platform. Juno stated that 50% of the entire cap table should belong to their drivers by 2026. In 2017, Juno was acquired by competing ride-share company Gett in a merger that eliminated the driver equity program and that drivers claim substantially undervalued what shares they had earned. Drivers are now suing Juno in a class-action over the handling of their equity in the acquisition.

The accusation leveled against Juno is that the restricted stock program was a disingenuous ploy to lure drivers away from entrenched competitors (Uber, Lyft, etc.). I don’t disagree, but I do think that there are valuable lessons that can be taken away from the disappointing episode. One is that this concept of incentivizing user engagement with stock works. If you are in a relatively commoditized space with many competitors, it appears that it may be an effective way to distinguish your product among users. The other is that the model is possible from an implementation perspective, within existing legal frameworks (which I don’t think had previously been clear).

I hope that in the coming years more companies experiment with this model (and in a less dubious way than Juno appears to have). There are many domains where developing/delivering a product demands very modest (if any) startup capital, so I would love to see more companies give some of the equity that they would have sold to VC to their users instead. If a company will live or die by its users, it might be good business to make them owners.

The post Why not give users equity? appeared first on Hacker Notes.

The term has since been transposed to the online realm with brutalistwebsites.com, a site put together in 2016 by Pascal Deville (now Creative Director at the Freundliche Grüsse). I wanted to pay tribute to the tongue in cheek term by recognizing some of my own favorite Brutalist websites.

Disclaimer: Don’t take this terminology too seriously. What is “Brutalist” to one person’s eye might be Minimalist or Modernist to another. To me, Brutalist web design is distinguished by user agent styles (the sort of plain concrete of the web), system typography, etc. providing a bare bones interface to an ultimately highly-functional application. To others it may mean something different.

Pinboard

Pinboard’s primary bookmark UI (photo credit serafin.io)

Pinboard.in is probably the Brutalist interface that I have the most intimate relationship with. I’ve been happily using the bookmarking service since college and find it wonderfully smooth from a usability perspective, despite arguably having little superficial appeal. The author/maintainer of Pinboard, Maciej Ceglowski, has a lot of excellent writing on his personal blog, Idle Words.

Craigslist

Craigslist has got to be one of the most canonical examples of Brutalist web design in mass use. Begun by Craig Newmark as an email list in 1995 and launched as a website in 1996, Craigslist has retained its stripped down, functional UI. Despite its design, Craigslist is one of the most popular websites in the entire world with an Alexa rank that always hovers around 100. This is because the design is in fact perfectly efficient for achieving its role of connecting local buyers, sellers, renters, job-seekers, romancers, etc.

NearlyFreeSpeech.net

NearlyFreeSpeech.net is an old school shared host, and one of the best-regarded companies in this space. I still recommend NearlyFreeSpeech.net to friends with basic needs like WordPress hosting that might otherwise go with one of the EIG-owned megaliths like HostGator or BlueHost. For websites that have higher levels of traffic, it’s better to opt for a dedicated hosting plan.

NearlyFreeSpeech.net site configuration UI (photo credit: mopsled.com)

The NearlyFreeSpeech.net admin interface is unapologetically functional and plain. In my opinion it is actually the perfect fit for the type of customer that they try to serve: people who have a reasonably grasp of the LAMP-type hosting stack and just want simple access to the resources at a good price.

Tarsnap

Tarsnap is a cloud backup utility that is popular among highly security-minded people who still require the convenience of backing up to the cloud. It launched on Hacker News and found its initial audience among the technical professionals of that community. The core backup functionality of the tool is accessed through command line and desktop applications, with the website providing account management, marketing pages and documentation. The Brutalist design seems to be perfectly effective at communicating the benefits of the service to its potential customers, and providing the administrative tools necessary for them to manage their accounts.

Linode

Linode Manager (source: Linode forums)

The trusty old Linode Manager, relatively unchanged for at least half a decade, is still the primary administrative interface for customers of the US-based VPS provider Linode. Some might say it’s a stretch to call this design Brutalist, and I somewhat agree, but with its user agent styled buttons, system typography and general lack of frivolous aesthetic adornments, it fits my own definition well-enough.

I happen to still love the Linode Manager interface. It is quick and functional, letting you perform all the actions that you need with your VPSes and related services. I find the presentation of critical stats reliably clear, and I actually even like the old school RRDtool based charting. I’m a little disappointed to learn it seems to be getting a rewrite.

Conclusion

There is a common thread among the sites that I’ve profiled here: the job that they do is so essential that a basic, functional interface is enough to keep users engaged and pleased. They are function first, aesthetic second. In a way I think this is a good reminder to all of us, even if we do highly value aesthetics.

The recent Reddit redesign is a good example of what happens when you neglect the primacy of function in pursuit of shallow aesthetic improvement: it is less functional and seemingly unanimously despised by users, despite having been “modernized” aesthetically (I am certainly filled with dread now every time I click through a link to Reddit from Google, anticipating the clumsy experience).

There are some people who feel that great aesthetic design is a base requirement for any product to succeed today. In some cases, I think this can be true – there are certainly domains where aesthetic is a competitive advantage. However, an emphasis on UI fidelity/polish can also be an endless time suck that sets you back months and keeps you from realizing what function is truly the core of your product’s value proposition, and achieving or maintaining a market fit.

Do you have any favorite examples of Brutalist or Minimalist web design that I’ve overlooked? Let me know in the comments section.

The post A tribute to Brutalist web design appeared first on Hacker Notes.

Pre-requisites

I feel that often when a company rejects remote hiring, or revokes remote work policies (such as former Yahoo CEO Marissa Mayer famously did in 2013 while kicking off her tenure that ultimately ran the company into the ground) an implicit or explicit dimension of the decision is lack of trust. If you cannot trust your employees to do work when you are not watching, then indeed you should not have a remote team. I would caution that if you find yourself this circumstance it may be a signal of a much larger issue with your team makeup and probably demands urgent introspection.

Defaulting to non-disruptive communication

One of the most profound benefits of having a remote team is that generally team members will default to asynchronous and non-disruptive forms of communication. This can benefit workers in any role but it is particularly valuable for developers, who rely on having blocks of uninterrupted time to focus and think through complex problems.

Even synchronous meetings benefit as they are generally organized in a more deliberate manner and unfold with far greater focus and intention than in traditional office environments where it is more trivial to pull people into a room.

Asynchronous team communication often has the side-effect of generating good records/documentation of business activities and decisions over time, which can also be a tremendous overall benefit to a company.

Happiness

Remote team structures enhance team members’ happiness in many important ways. One very essential dimension in which remote team structures enhance morale is in eliminating commutes. Commutes are often demoralizing exercises that claim significant chunks of time in one’s day while offering no direct renumeration. For employees who would otherwise have significant commutes, the ability to work on a remote team can eliminate a substantial source of anxiety and wasted time. Perhaps even more important, for those on your team who have families or significant others, a remote team structure generally means more time spent with loved ones.

Cost-effectiveness and talent optimization

For companies that are based in areas with competitive hiring markets and/or high cost-of-living like New York and San Francisco, maintaining a remote team means tapping into a talent pool hundreds or thousands of times the size of that which is locally available. It also often means more affordable salaries aligned with national or regional markets rather than those of ultra competitive tech hubs. Even if you peg salaries to your local, competitive market, you generally get far better talent-per-dollar than hiring locally.

Extended business hours

For businesses that are customer-facing/client-service or have an on-call component (such as IT) having a remote, globally-distributed team often means getting extended business or on-call hours for free.

The future

A decade or so forward, I believe that in many domains remote workforces will be a default choice. The tools to facilitate effective remote workflows are relatively new. To name some of the most critical:

• Broadband internet
• Reliable videoconferencing (such as Google Hangouts)
• Collaborative office suites like Google Docs
• Team chat tools like Slack
• Workflow management tools like Trello and Jira

These tools have mostly emerged in the past decade and a few of them only truly reached maturity in the past few years. I believe that many overlook the significance of these collaborative tools. I think that because these tools are relatively new the practice of remote work seems unproven and risky, but over time maintaining largely remote teams will become as rational a business choice as sending an email rather than couriering a letter.

The post Remote workforce as a superpower appeared first on Hacker Notes.

Larry ascribed to the adage, “We don’t do things right, we do the right things.”

I was reminded of another aphorism I’d once heard – a bicycling metaphor:

It’s not how fast you pedal, it’s what gear you’re in.

I’ve seen time and again that one of the most destructive things to a software development team, be their product nascent or mature, is bad prioritization. Much of development work is ongoing. A complex feature or integration has a cost upfront and an ongoing cost to maintain. One of the most destructive things you can do – for velocity, for morale, and ultimately for a product’s prospects of ongoing success – is to fill the pipeline with things that don’t matter, are highly speculative, or whose costs (upfront and long-tail) far exceed the direct value they generate.

The mobile messaging application WhatsApp (upon which I rely heavily when traveling outside the US) famously had 55 employees (only 35 of them engineers) at the time of its $19B acquisition by Facebook. In a Wired profile of the company, WhatsApp engineer Jamshid Mahdavi described the company’s modus operandi as concerned development:

“It was a completely different way of building a high-scale infrastructure,” he said on Monday. “It was an eye-opener to see the minimalistic approach to solving … just the problems that needed to be solved.”

I can imagine a parallel world in which WhatsApp had taken what seems to be the default path among startups of putting itself on an unfocused treadmill of speculative feature development. Perhaps the product would have worked (maybe even reached the point of acquisition) but I would certainly bet the team would be a lot bigger, less happy and, and less productive and we users, most likely, would have ended up with a much worse WhatsApp experience as a consequence.

A well-honed skillset and maturity among engineers is certainly important for achieving true leverage with a product, but just as important, I believe, is recognizing what work is worth doing. It sounds almost tautological, but amidst the noise and distraction of fast-moving startups, it is astoundingly uncommon practice.

The post What gear are you in? appeared first on Hacker Notes.

• Going API first
• Building to accommodate horizontal scaling
• Building with the most modern tools
• Building with tools and frameworks that let us hire the best (or sometimes “Building with tools and frameworks that let us hire the cheapest”)

There is often a tension in these matters between practical and “correct”. It may be most correct, for example, to build up your styling and javascript components from scratch, such that you only introduce precisely the code you need to realize desired functionality. There may be something intuitively less correct about bringing in styles and components that you never actually end up utilizing, such as happens in some degree when you build atop, for example, a UI framework like Bootstrap.

Firsthand experience has repeatedly shown me, however, that the teams who favor the correct over the practical approach get burned in far greater degree than those who favor the practical over the correct. Perhaps at an extreme operating scale this ceases to be the case, but in my work with sub-100-person teams, it reliably and repeatedly is.

I believe that there are a few essential reasons that teams favoring the practical over the correct seem to have disproportionate success. Certainly one obvious reason is that mature frameworks like Bootstrap have comprehensive documentation and strong conventions. If a new developer is unsure how to adjust the color palette, she can find a resolute answer in documentation, and the code changes she makes will be the exact code changes that future developers expect to see (and if these future developers don’t understand what is going on, they, too, can find out by reading the mature and thorough documentation of the framework).

I also believe that there is a less obvious force at work. That is that the team that operates this way is more likely to be composed of mature developers. Mature developers have lived through hype cycles and are often much less interested in trying out cutting edge tools for the heck of it. They usually have deep experience with mature – if less exciting – stacks and are most interested in servicing the needs of the business over more academic ends (if the broader outcome is something worse-documented that is harder to develop against and maintain).

Other good, real-world examples of questions of practicality over correctness include:

• Microservices vs. Monolithic Architectures
• Declarative JavaScript (or CoffeeScript) “sprinkles” vs modularized ES5/6
• Server-rendering vs Single Page Application architectures
• Full-stack frameworks like Ruby on Rails vs additive microframeworks like Sinatra
• Single/dedicated vs Multi-Tier deployment schemes

Broadly, there are ultimately places for the “correct” path. Experience just repeatedly shows that favoring the correct path largely for the reason of correctness is a mistake.

The post Practical vs correct appeared first on Hacker Notes.

Every day I work with teammates in Germany, New York, California and British Columbia. “Presence” means something quite different today than it has for much of human history. It is a divided concept, and virtual presence often has equal or greater consequence than physical presence.

The virtual space is overwhelmingly where I work and even where I live. Cut my ties to my virtual gathering places and remote repositories of information and I literally cannot work. Cut my ties to my physical place and it barely makes a difference (it certainly presents no dramatic impediment to work nor even a total disruption of my social life).

Estonia’s E-Residency program allows qualified citizens of any nation to become legal “E-Residents” of Estonia and gain the right to bank and do business in the country. Even though the rights are somewhat limited today, I feel like it is a step toward a future in which notions of residence and governance better align with our technologically bound reality.

In the US it feels like we are often far less interested than we should be in rethinking government to appreciate the dramatic changes technology has brought to all areas of our lives. Even though the Estonian E-Residency program is limited today, I think it’s awesome that a government has been bold enough and flexible enough to conceive of and execute on a project like this.

The post Estonian E-Residency and refactoring government appeared first on Hacker Notes.

There is a trope that is ubiquitous in our community. New tools or frameworks hit the scene, people are enamored of the new tools, they convince their organizations to tear down some stable and mature but “crufty” application and rewrite it with the hot new thing, rather than look for simple, pragmatic, high-leverage/high-ROI optimizations in the existing app.

Some months later the sheen has worn off the hot new thing, or the team’s limited facility with the tool – or the tool’s own immature and shifting conventions – has led them to construct, at worst, a total mess, and at best something semi-broken which in every measurable dimension functions worse than the thing it replaced. The lesson is forgotten. A year later those tools of which the team was so enamored have fallen out of favor. Team members complain about “that crufty old app over there” and suggest a rewrite in the newer hot new thing. Rinse and repeat.

Serial non-finishing should be seen as a serious cause for attention and re-evaluation – it may be a strong sign that somebody does not have a place in your organization. A project is all cost unless finished. To me there are few things more irresponsible than investing man-months or man-years in a project that either never ships or ships in a completely broken and regressive state.

New tools are not the problem – we should evaluate, experiment with and integrate new tools when they yield a superior outcome. We should only do so, however, in a progressive manner, where projects are finished and ROI can be evaluated in full context. For that reason I say that however much a person is a historic non-finisher, you would be wise to temper their influence by that degree, or perhaps question their place in your organization altogether.

The post Finishing Is Credibility appeared first on Hacker Notes.

I have worked on many teams that actively embraced practice of this sort in the workplace. Such teams celebrate opportunities to stretch far beyond the limits of their core competencies, experimenting with novel frameworks, tooling, and infrastructure solutions on production projects. More teams than ever seem to be disposed to do this today, with fashions in the JavaScript world turning over rapidly, fervor around novel infrastructure solutions like docker and kubernetes, and the simple fact that in many markets demand for development talent is outstripping supply, often leading to more junior team makeup altogether.

In the spirit of the Fowler passage, though, I’ve found that the teams I truly want to work with are those where members are exercising skills honed sharp as those of a working musician in New York. The mechanics should be second nature, like Ahmad Jamal on the piano. You should all be making music together, not racking your brains over the fingering. That’s when the magic happens.

To be clear, I don’t think we should all be working in J2EE – frameworks and tools evolve, and we should keep pace. I do, however, believe that the majority of the team working on a project should already have a strong facility with its tools. When I began working with Rails it was a young stack, but I did not take on contracts or introduce it to teams until I’d had a substantial amount of practice with it.

If people find gratification in practicing on the job and have a team that tolerates it, power to them. To speak for myself – I don’t want to practice on the job, I want to make great music.

The post Practice appeared first on Hacker Notes.