Shrinking the stack, working as a team & shaping new products

Welcome to the eighth edition of Growing the Stack!

This week we have a conference talk by about commoditization, a Twitter thread about building software as a team, and a post by about HEY’s inception.

Enjoy!

🙅‍♂️ You might not need _blank_

Konstantin Kydryashov (@everzet) talks about choosing tools at Full Stack Europe 2019.

If we are too busy following the rules of the past, we don’t have time to implement a better future.

Technology keeps on moving forward. We need to constantly evaluate what becomes commodotized, and take advantage of it.

I didn’t build the newsletter software that sends this email. There are more than enough off-the-shelf solutions to get that done. My core business isn’t sending emails, it’s curating content. I should manage as little as possible myself.

You can not possibly make effective end-to-end decision if it requires knowledge of thousand bespoke cogs.

A full stack developer manages the stack by keeping it small. Don’t just be a full stack developer. Compress the stack. Be a lesser stack developer.

As full-stack developers, we should strive to compress the stack. Growing knowledge is only effective to a certain extent. We can only keep track of so many cogs in the machine at the same time.

www.youtube.com

🐌 Go slow individually, so together we can go fast

I came across this idea on Twitter. The original tweet is by @ag_dubs, and the concept was explained beautifully by @tinydroptest2.

A team should be a group of people with diverse interests & skills, using constant communication to reach common understanding of a problem, and shared work towards a solution. This results in the fact that some people need to wait for, and help others to understand first.

“Waiting and helping” is seen as wasted time […] “If I had taken on this task on my own, I would’ve finished already” Yes, but nobody else would know about it, you might ‘ve missed something, somebody else might’ve thought of a better solution.

👋 The evolution of HEY: from humble beginnings to a multi-platform email service

I’m sorry if you’re HEYed out from all the commotion on Twitter the past weeks. I promise, this post isn’t another product review or Apple rant!

Jonas Downey from the Basecamp team wrote about how they explored a new problem space and ended up building HEY. Surprise: HEY wasn’t even supposed to be an email app.

At first, we were considering making a successor to our older CRM product, Highrise. Highrise was our first take on the external communications world, but it doesn’t do nearly enough to cover all the scenarios we wanted to solve.

And thus, HEY started its life as a prototype for a possible Highrise 2. It was originally focused around work problems—not personal email problems.

I really enjoyed reading this. It’s just a glimpse of the two year product development journey they made. What didn’t get shipped is just as interesting to examine as what did.

m.signalvnoise.com