In software value is produced by features running in production. Let’s assume a team delivers on average one feature per unit of time. We will call it team velocity. We can plot their feature delivery curve.

When building a startup I rarely have the time to build software in the way I think of as correct. In these situations I find particular pleasure when simple solutions can be "good enough". Best yet is when one of these solutions holds up to increasing numbers of users, employees and use cases. One pattern that manages all of these is using Slack as a searchable event stream DB.

In our journey as Node.js developers, we often deal with various external services such as Google Cloud or Firebase. These services require us to provide credentials that authenticate our application and grant it the necessary permissions to interact with the respective service. This post is about to handle large secrets or files that contain private keys. Google provides files like this. You will see them named a few different things: serviceAccount.json or sometimes serviceAccountCredentials.json. This file contains secret data and is used to authenticate against Google Cloud and/or Firebase.

Everyone fails at software they don't build​

There are three types of software systems that any company runs. First, high value software systems that drive customer value. Second, the systems necessary to deliver the product or service, but not sufficient as stand alone products on their own. Third, systems that support the business but are not related to the competitive advantage of the company. The fourth type of software system is one that doesn’t exist. Every company has software they chose not to build. This is "Unbuilt Software". To understand how much value organizations are missing out on, we must first better understand each type of software system and how software investment decisions are made.

As an engineer I like to talk about the features of a product. I talk about the product’s implementation and how it was built. I get excited about the internal workings. I have spent days of my life working on features that were never used. I operated under a mental framework that users came from outside and were external to the product. I was concerned with building the product. The users would be there when I was done. So I spent most of my time heads down writing code.

Chasing the wrong KPI is like chasing a mirage of water in the desert.

Check out our trailing twelve month site analytics above.

Our marketing and user acquisition was awesome in Feb, right? More of that?

by Ella Wheeler Wilcox

When I was a younger I went on several rock climbing and mountaineering expeditions. I was exposed to some instructors and practitioners that took staying safe in the mountains very seriously. One of them carried a book from The American Alpine Club on climbing accidents. The accidents were never the cause of a single bad choice. They were caused by a series of decisions, taken over time, that combined to create the conditions for the accident.

I've hired roughly 30 developers where the job would be their first professional position as a developer. I interviewed nearly 150 candidates. I reviewed resumes for about 300 candidates.

None of this is certainly going to get you hired, the goal is to just improve your odds. Also, each hiring manager is different. Sometimes the person doing the screening and first line interview may not have ever coded. This advice is much geared to increasing your odds with a hiring manager who is technical.