Gaming
Entertainment
Music
Sports
Business
Technology
News
Design
Fitness
Science
Histoy
Travel
Animals
DIY
Fun
Style
Photography
Lifestyle
Food
2018-04-24T06:26:11.881Z
0
{"feed":"Signal-vs-Noise","feedTitle":"Signal vs. Noise","feedLink":"/feed/Signal-vs-Noise","catTitle":"Design","catLink":"/cat/design"}

It used to be a fundamental requirement that you learned an extensive amount of SQL before you were able to start working on database-backed applications. It was taken as self-evident that you needed to speak the native language of the database before you were qualified to use it. And better yet, you really ought to understand and care about your particular brand of database engine.

This is no longer so. That fact has snuck up upon us, but it’s none the less true — and that’s amazing.

Through advances in leaky abstractions, we’ve managed to compress the conceptual overhead of the database so much that it needn’t feature in the introduction material for making database-backed applications. In Rails, we call that abstraction Active Record, and it falls into the category of object-relational mappers (ORM).

The ORM was long derided by programmers as an unreliable, even harmful, aid of the lazy or the weak. Something Real Programmers shouldn’t expect to lean on, as it was likely to break down if not immediately, then certainly soon thereafter. And then you’d better know all your relational theory!

That’s the past.

Basecamp 3 has about 42,000 lines of code, and not a single fully formed SQL statement as part of application logic! It serves millions of people. It not only leans on the ORM abstraction, it hardly even thinks about it the vast majority of the time.

Do you know what else application programmers rarely need to think about any more either? Memory management and garbage collection. It used to be just...

We gave up on Likes and invented a totally new form of tiny communication.

If there’s one thing you can’t avoid on the Internet, it’s Likes. They’re in nearly every software platform where people post photos or write text messages.

Sometimes Likes are called Faves, Hearts, Reactions, Claps, or something else, but the basic idea is the same: they’re a small, quick way to express your feelings about something, usually accompanied by a count of other people who had that same feeling.

Until today, we had exactly this sort of feature in Basecamp 3. We called it Applause. If you liked a post, you’d clap for it. Everyone who clapped was shown in a row.

This was fine, of course—it worked just like all the other Likes.

But a couple months ago, we started thinking more deeply about this pattern, and we noticed it has a lot of insidious problems.

  1. Likes are vague, especially in a professional setting. Let’s say your boss liked someone else’s post, and not yours. You might start questioning what happened. Was she just busy and not paying full attention to everything? Or did she do that intentionally? What does it all mean!? There’s no way to know, because there’s not enough information — just a bunch of digital grunting.
  2. Likes are obligatory. How many times have you felt obligated to SMASH THE LIKE BUTTON because you didn’t want to seem like a jerk, or because everyone else was liking something? There’s a subtle peer pressure and herd mentality...
How to spend your time when there’s nothing left to do?

This morning something happened that reminded me of an important lesson re: time well spent.

Three of us are working on an illustration project for our forthcoming book, “It Doesn’t Have to be Crazy at Work”. In our previous books, we had an illustration per essay. This time we’re going in a different direction. Rather than an illustration per essay, we’re aiming for ~15 full page spreads spaced evenly throughout the book.

We’re going to be illustrating historical and contemporary figures with work methods that line up with our point of view on work. People who’ve done big important things without pulling all nighters, working crazy hours, or forgoing leisure for the eternal hustle.

Here’s an early example of a spread:

We like the direction, and so does our publisher. We’re going for it. So now we’re off to find interesting subjects to illustrate and feature. It’s research time. That means there’s going to be some design downtime — a gap in the project for the designers.

Now, back to what happened this morning… The designer leading the layout charge offered to continue to explore layout concepts while we look for more subjects to feature. He wanted to tweak the layout on the right, add some more details to fill out the space, etc. We’re happy with it, but could we be even happier with it? The tweak muscle yearns to be flexed!

That’s a perfectly natural reaction. Certainly there’s always room for improvement. And there is always more...

In 2014, Highrise was spun off as a separate (but wholly-owned) company from Basecamp. Last year it celebrated its tenth anniversary in business. And this year it’s moving back in with Basecamp.

In some ways, it’s like it never left. While Highrise operated as an independent company under Nathan Kontny as CEO, Basecamp’s technical operations team continued to run servers and systems. Our support team still has a lot of people who used to answer customers when Highrise was a direct part of our suite of products. And almost all the members of the original product team for Highrise are still with Basecamp.

In other ways, this is indeed a change. Nathan Kontny had built a team of seven to lead new development, and they made a lot of improvements over the years. We want to thank the team for all their work and wish them all the very best.

Spinning Highrise off into a separate company with a separate team and CEO was always a bit of an experiment. While that experiment had a bunch of highlights, we ultimate decided it was time to try something different on both the product and business side after a thorough review was conducted some time ago.

For customers of Highrise, we at Basecamp are committed to supporting the product until the end of the internet! Highrise is home to over 10,000 customers who’ve trusted their data and their business to us. We are grateful for the trust and will continue...

Find your ideal design process by sticking to a few simple principles instead of a rigid script.

You hear a ton of different advice on the right and wrong way to go about designing an app or website.

“You should be using Sketch.”
“Design Systems or GTFO.”
“Real Designers design 100% in code.”
“Wireframes are a waste of time.”
“If you’re not making prototypes, you’re not doing it right.”
“You need to start on paper.”

You’d think there’s no agreement whatsoever about the right way to design, but there’s one point that’s largely free of controversy — that your process should be linear.

The classic linear approach looks something like this:
research → sketch → wireframe → static comps → prototype → code

It’s kind of like those Rube Goldberg-esque manufacturing machines they use to make Doritos and Ding-Dongs. Drop an idea into the process machine, and after getting mashed and molded into shape as it winds through the steps a finished product pops out the other side! Predictable! Efficient!

Kind of.

Process machines work, but only when they work. They don’t adapt, and that makes them fragile. All it takes is one little Sabot to grind your process machine to a halt.

Hank, a.k.a. “the Sabot”

I’ve been watching Finding Dory with my kid lately, and part of the “making of” footage keeps jumping out at me.

In the movie, there’s this octopus named Hank:

Septopus, technically. His character model was so onerous to work with, they lopped off a tentacle to make animating him doable. Still, with 4,000 separate controls he was incredibly challenging to work with.

At this...

The ABC show Shark Tank is irresistible reality programming: Entrepreneurs pitch their businesses to a panel of famous investors and have the potential to make a life-changing deal. But as with any reality show, there’s much more to the Shark Tank experience than what gets shown on TV. In the new episode of the Rework podcast, we talk to three business owners about what it was really like to go on the program — and what happened afterward, when they had to get back to the very real work of building their companies.

This episode features:

Melissa Butler of The Lip Bar, a company that makes vegan and cruelty-free lipstick in vibrant shades that work on a broad range of skin tones. Watch a clip of their episode.

Chris Ruder of Spikeball, the maker of a game that’s a mix of volleyball and four square. Ruder played Spikeball as a child and later revived the brand after it had become obsolete.

Joe Moore of First Defense Nasal Screens, which patented an adhesive filter that sticks on top of the nostrils to prevent allergens from entering the body.

A friendly reminder that we are collecting your workplace communication questions for Jason Fried and David Heinemeier Hansson. If you’re seeking advice on how to talk to your boss, your employee, or a colleague, leave us a voicemail at (708) 628–7850 or email us at hello@rework.fm.


Life After Shark Tank was originally published...

This release is all about usability improvements. Download it for iPhone and iPad from the App Store now.Find tab improvements 🔍

The Find tab now lets you quickly jump to anything you recently viewed without having to type a word! When you open Find, you’ll see your most recently visited pages, making it super easy to quickly get back to something you were viewing. Or start typing to instantly search in place for anything in your Basecamp account. You can also use advanced filters to define even more specific search terms. Go forth and find!

New project and team pages ⚡️

The old project and team pages were… slow. We decided to speed them up, as well as feature your team’s latest activity more prominently with this new design. Instead of nearly identical cards for each tool, you’ll see a unique icon in a bright color, making them easier to recognize. Each icon also has a bit of data underneath, hinting at what’s in each tool so far. We’ve been testing these internally for quite a while and the increased speed has been such a relief. We hope you love it too.

Improved image viewing in Activity 📷

Image previews in the activity feed are now much larger and easier to interact with. If there are multiple images in an attachment, we’ll group them together in a nice grid, too! You can tap on any photo to view it in the media viewer right from the activity feed, or tap into the...

When we launched Basecamp 3, we introduced a new way for client services firms to work with their clients. We called it the Clientside. It was an entirely separate part of a Basecamp project where all client-facing communications lived. Essentially, it was a mini project within a project — a distinct space with separate tools and a different interface.

Conceptually it made sense, but practically it was inflexible and not collaborative enough. It worked well for some people, but it missed the mark for far more. We fell short of what we hoped we’d be able to create.

So we put our heads together and spent a couple months working on a complete revamp. Today we’re introducing something better.

Introducing Clients in Basecamp!

Starting today, not only can you send messages to clients, but now you can work with clients using all the same tools you already use with your team. That means you can assign clients to-dos, share files and folders, schedule events and meetings, chat around the Campfire, and even ask clients automatic check-in questions! If you can do it with your team, you can do it with your clients. And now it all happens in the same place as the rest of the project — no more separate Clientside. It’s everything you’ve been asking for.

You’re in 100% control of what clients see. Clarity and privacy is at the core of this new feature. That’s why everything in a project is now labeled as “private to our team” or “the client can see this”. Plus, to...

14 questions to ask an employee who’s struggling during your next one-on-one meeting so you can figure out how to best help.

Someone’s slipping. You see it. You feel it. You’re not on the same page. You desperately want to pull the person up, but you’re not sure exactly how. Do you encourage them? Switch them off the project? Change how you’re leading them?

You’re now facing one of the toughest tasks as a leader: How do you manage underperformance at work? And more specifically, how do you sit down and talk about their underperformance with them, during a one-on-one meeting with her or him?

It’s tempting to look outward first. To blame the person herself or extenuating circumstances. “They don’t pay attention to detail.” Or, “The client is being unreasonable with them.”

While those may very well be the case, you should also turn inward. As leaders, when an employee is underperforming, we must self-reflect. What are you doing that is stopping this person from doing their best work?

The hard part about managing an underperforming employee is choosing to look both inward and outward for the sources of underperformance at work: What are you doing to hold an underperforming employee back? And what is the underperforming employee doing to hold herself back?

Oftentimes, we think we know the answer to those questions. We have hunches about what’s causing the underperformance: “It’s their perfectionist tendency getting in the way, obviously…” or “It’s my lack of context I shared about the project, clearly…”

So, we just create a performance...

For years people have been asking us how. How do you design things? How do you code things? Why do you do it this way vs. that way? How do you think about writing? How do you think about what makes it into a product and what does? How do you decide which features to build and which ones not to? How do you stay up on everything that’s going on in your business?

We’ve written about these topics for years — and we’ll keep writing about them — but we want to bring some show to the tell. So we started a new YouTube Channel called Getting Real. To start, DHH and I will be posting occasional videos of actual day-to-day work. Down the road other people at Basecamp may join in.

So far we have a dozen videos up. More are coming. Check out what we have so far and subscribe to be notified when new ones are ready to watch.

We hope you dig it! And if you have any ideas for future episodes, please post a comment below.


Getting Real: A new YouTube channel from Basecamp was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why self-awareness at work just might be the most underrated, overlooked element of a successful leader.

A few months ago, I asked Ben Congleton, CEO of Olark, what he wished he’d learned earlier as a leader. No, he didn’t mention learning a new business development hack, nor did he talk about the importance of hiring well. Rather, what Ben wishes he’d learned earlier was how to improve his self-awareness as a leader.

Self-awareness, really? After considering it for a moment, I caught myself nodding vigorously at his answer. How true!

In my head, I recalled all the moments I’ve personally lacked self-awareness as a leader: When I micromanaged someone yet had no idea, when I argued against a new idea because of my own bias… The list goes on. Each time, I’d shot myself in the foot.

The more I thought about it, the more I realized: Self-awareness at work just might be the most underrated, overlooked element of a successful leader.

Here’s why…

Why self-awareness is crucial for leaders

Fundamentally, self-awareness is about understanding your own mental state. It’s knowing about yourself: When are you energized? When are you in a bad mood? Where are you strong in, and where are you weak? What are you tendencies, your biases, and your leanings toward? What might your blindspots be?

This self-knowledge is irreplaceable. Without self-awareness, you can’t make informed decisions. You don’t know if you’re getting in your own way — if a strong irrational personal bias or misguided mental model is shaping your view on things.

Self-awareness is...

“You know I try, but I don’t do too well with apologies,” Justin Bieber once sang. You’re not the only one with this problem, Justin! Businesses also struggle with saying sorry, and in this age of swift social media retribution, the process of screw-up ➡️ public shaming ➡️ bad apology ➡️ more outrage ➡️ slightly better apology seems to play out more frequently than ever. Why is it so hard to say sorry? Why do corporations and public figures default to enraging non-apologies, saying things like “We apologize if you were offended” or “We regret the incident” or “It was not my intention to offend” or other phrases that deflect responsibility? In this episode of Rework:

Susan McCarthy, co-creator of SorryWatch, looks at what’s changed and what hasn’t in public apology culture.

Basecamp’s David Heinemeier Hansson recounts a time in our company’s history when we had to say sorry.

The founders of SorryApp talk about their product, which helps tech companies apologize to their customers for downtime.

We’re collecting your questions for an upcoming mailbag episode with Jason Fried and DHH . We’re especially interested in questions about workplace communication — boss to employee, employee to boss, or colleague to colleague. Leave us a voicemail at (708) 628–7850. Thanks!


How to Say You’re Sorry was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

The evolution of “Everyone on Support”

At Basecamp, we’ve been running an initiative called Everyone on Support for nearly five years now. Each person in the company, whether a designer, developer or podcast producer, spends a day every eight weeks or so responding to customer emails. As Emily wrote a few months in, EOS quickly proved its worth: Direct contact with customers gave people a new perspective on our products, first-hand experience of the problems users were facing, and a reminder of what we were all working towards together. Lessons were learned, bugs fixed, and cross-team relationships were strengthened.

And then we got busy. With customer requests climbing, the support team lost some important people, and those that remained developed an unhealthy obsession with “inbox zero”. Our stress was infectious: Folk would turn up to their EOS shifts eager to help and leave deflated because they’d barely made a dent in the email queue. Each of them had a dedicated support team buddy to ask for help, but rather than “bug us” with questions, they’d spend hours down help-page rabbit holes. And on the rare occasions that things were quiet, they got bored because we weren’t leaving them with anything to do.

Something was very wrong, but the support team was too busy to notice. We didn’t have time to check in with each other, much less the people who were joining us for the day. We’d started Everyone on Support with the best intentions of not turning our...

In 2017 we made web accessibility a priority at Basecamp. It was long overdue.

Over the past year, I made it a personal mission to make Basecamp 3 more accessible for people with disabilities. It’s something we’d been meaning to focus on for a while. But as with so many unfamiliar and seemingly immense tasks, it was just too easy to put off! Which is exactly what we did, for years.

In the end, it took the mix of a personal search for meaning, the reward of learning something new, and a bit too much downtime to finally make some progress.

Excuses had been easy to find. “Why spend time improving something that only a seemingly small subset of our customers would benefit from?” After all, we’ve always found it important to say no to feature requests that could bloat the product or be useful to only a slice of our customers.

Making Basecamp accessible was different, though I didn’t realize it at first. Back in early 2017, I was about to hit my eight year anniversary with Basecamp and the itch for a new challenge was real. I needed to find something I could learn and grow around, and at that, a project which possessed some inherent meaning. Not to discount the Quality Assurance (QA) work that I’d been doing on Basecamp for the last five or so years — these efforts have a real impact on the quality of a tool lots of people use to run their projects. But there’s...

Whether you’re a first-time manager or are taking over a new team, here’s how to approach that first meeting with your team.

It happened: You’re a new manager now.

Perhaps, it’s the first time you’re leading a team. Or you’re taking over a new team as a manager. Either way, that first meeting as a new manager is a daunting event. What should the agenda for that first meeting with the new team be? How should you set expectations as a new manager? Should you make prepare some sort of “new manager introduction speech”?

First impressions are often lasting ones. And there’s no better time and place to solidify that impression than the first meeting with your entire team.

Whether you’re taking over a brand new team, or you’re a first-time manager, here’s how to approach that first meeting. I’ll walk through what you should be thinking about, some things you can say, and some questions you can ask…

Build trust, don’t chart a vision (yet).

The goal of this initial meeting with your new team is NOT to map out the vision for the next nine months or declare your mandate for change. You’ll have the space (and greater knowledge) to do both in the coming weeks. This first meeting is to establish trust and set the tone for the kind of team environment you wish to foster.

Specifically, as a new leader, you’ll want to internalize these goals for your first meeting:

  • Show you’re worthy of your team’s trust.
  • Show that you’re humble and ready to learn.
  • Show that you’re intention is...

A few months ago, I met a new friend at a Creative Mornings talk. She is going to take some time off at the beginning of 2018 to work through the AltMBA reading list before diving into job searching. I thought this was a great idea and it got me wondering about the kind of reading material Basecamp would suggest for people who want to build a business like ours. Of course, there’s our previous books and the upcoming Calm Company. But with minds like the ones we have, I guessed we can could up with a really fantastic set of material that SvN readers would eat up. With that in mind, I asked my colleagues:

Given your role at Basecamp, what one or two books/resources would you suggest to help someone prepare for the kind of work you do?

Before I share the list, I wanted to add some of my own thoughts here, as someone who can get a bit obsessed with collecting information and knowledge: Like a lot of people in today’s modern society, I often have a direct correlation between knowledge gathering and not applying that information to my actions in a meaningful way. Too often, the more I think I know, the less I’m actually doing. So yes, these materials are rich with good advice and ideas on how to start your business or manage people, but they’re no substitute...

No one sets out to become a bad boss. Yet, slowly but surely, it’s easy to become the bad manager we all dread.

Times are stressful. You’re trying to make things happen. You notice your team isn’t as engaged as they should be. You can feel your patience getting shorter and shorter. You feel stuck and exasperated about leading your team. The more you do, the worse it seems to get.

Then, a sinking feeling hits you: You might be becoming a bad manager.

I’ve had that sinking feeling in my own stomach before, too. Especially in the early days of running Know Your Company, I was plagued with self-doubt. “Am I doing this right?” I wondered. “Am I falling into the trap of doing things that I’ve hated in other bosses?”

Since then, I recognized the early signs of a bad manager — the kind of manager I dreaded working for. Now, I’d like to share these signs with you, so you can hopefully avoid these pitfalls and get back on track to being the good manager you want to be.

Sign #1: You think an employee “should already know that.”

When you’re a leader, you benefit from having all the information. Yet we forget that the rest of the team does not have that same information. Don’t fall into the trap of assuming that employees “should already know that.” Instead, consider why your team doesn’t have the information they need, and own that shortcoming yourself. Good leaders know it’s on themselves to make sure the team knows...

In the summer of 1962, the world-famous pianist Glenn Gould performed an all-Bach concert at the Stratford Shakespeare Festival in Ontario, Canada. The second half of the program was devoted to The Art of Fugue, and Gould did something radical before he started playing the piece—he asked the audience not to applaud.

This wasn’t the first time Gould publicly expressed his discomfort with audience applause. Earlier that year, he published an essay in Musical America called “Let’s Ban Applause!” He argued that the best way to consume art was to internalize it and reflect on it in a quiet, deliberate way, instead of making a flashy public response in the moment.

In the essay, he jokingly proposed something he called the Gould Plan for the Abolition of Applause and Demonstrations of All Kinds, or GPAADAK. Under GPAADAK, applause would be allowed only at weekday family concerts, where “the performers, naturally, would be strictly second-team.” For the no-applause concerts, Gould suggested that solo pianists be conveyed offstage on a giant lazy Susan while still seated at the instrument, to prevent any awkwardness over having to walk off the stage in silence.

For Gould, who ultimately retired from concert life in 1964, audience applause was distasteful for a number of reasons: It evoked a gladiatorial vibe that was at odds with the reverence he felt the music deserved, and it didn’t give him any real feedback. I see this today with standing ovations—I can’t remember a single classical concert I’ve attended...

I mean, in the widest possible sense, you are. Your mere existence is bound to change some of it somewhat. But that’s not what the unironic use of the phrase — WE ARE CHANGING THE WORLD — is meant to convey in Silicon Valley. They’re actually serious.

And look, some of them do end up changing the world. The world is different now that, say, Twitter is here, and the president of the United States can threaten nuclear war from the comfort of his golden shitcan. Seriously, that is different!

But let’s just say that most companies that actually end up changing the world rarely set out with that as the explicit mission. Twitter started as a way of telling your drinking buddies by SMS which dive bar you were hanging out at. Facebook started as a way for Zuckerberg to lure “dumb fucks” into giving him their private information. Modest beginnings!

The odds are that whatever you’re doing is never going to amount to any of the global significance that either Twitter or Facebook has bestowed upon the world. And thank god for that! If everyone in Silicon Valley who proclaimed to be on a mission to change the world actually did, our collective regret would be far deeper.

So ponder this example from HealthIQ’s career page from yesterday (since changed*):

I like to peek beneath the surface of such delusions of grandeur. What on earth would prompt someone hawking life insurance — LIFE INSURANCE! — to posture, and quite possibly believe, that they’re...

Stay in the loop when dates change

Last month, we added to-dos to the redesigned Schedule Card in Basecamp 3. This made it much easier to see what’s coming up on your projects.

But dates slip — due dates are shifted, events get moved—and Basecamp didn’t make it easy to see changes to your schedule. Starting today, whenever a to-do you’re assigned or an event you’re participating in is rescheduled, we’ll tell you about it.

Here’s how it works

Before, you’d only receive a notification when you were added to an event in Basecamp 3. Now, you’ll see a separate notification if that event gets rescheduled to a different date or time:

To-dos work a similar way. You’ll see notifications whenever due dates are added or shifted on your assignments:

Who will receive these notifications?

At Basecamp, we’re not huge fans of interruptions. To keep the noise down, we’ll only send these notifications to:

  • People assigned to the to-do
  • The person who made the assignment
  • Event participants

Other subscribers will not be notified of date changes. That means you can comment on an event or to-do without being inundated with notifications.

What if I reschedule something multiple times?

In another effort to avoid notification overload, we’ve grouped things together:

  • Hey! Menu: Hey! notifications are bundled for each item, so you won’t see 3 separate entries if your manager rescheduled that to-do or event 3 times in rapid succession.
  • Emails: For folks who prefer email, we’ll aggregate to-do due date changes into...