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.
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.
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.
Here is how I passed 9 AWS certification tests in 14 months. Oddly the practice testing is not the most critical step. All of these steps are needed. Let me know if you try them out and how they work for you.
This blog series is an extended version of a talk I gave at Serverless Days NYC 2022. The goal is to share ways that a "friend of mine" has failed at serverless to help level up the community. Just as the transportation industry shares accident report analysis with the whole industry to improve safety, we in the software community need to do the same. This is my attempt to do that.
I work on mac OSX and linux command line environments. My tool kit is shaped by the needs I have. There may be similar tools for powershell or other, I'm just not aware of them.
I work on Mac OSX and Linux command line environments. My tool kit is shaped by the needs I have. This is my tool box of tools that work with almost any command and help me go from just using the command line to being an expert. Wow, your friends and colleagues. These tools make every other command at the command line more powerful.