Stop believing the blogs, podcasts, and articles in the ecosystem that talk about how some new technology or technique will improve everything. It probably won’t.
The tech community has mastered the art of giving terrible advice.
It is everywhere. Not a day goes by where I don’t run into a blog article espousing a new framework or library, encounter some massively upvoted Hacker News post on yet another data management technique for the current flavor-of-the-month javascript framework, or a meet-up talk about a brand new technique implemented at some company that saved them tons of time or money.
It seems as if the entire tech ecosystem is yelling in unified consensus about the latest and shiniest new thing.
Sometimes, it makes me feel like an idiot because I’m just not using it. …
The tech industry is suffering from terrible technical interviews that lead to false negatives and hurt candidates. We can do better — here’s how.
I jut recently completed a month-long job search in which I went through 75 interviews, resulting in 7 offers. The technical interviews I went through could be classified as good or terrible.
The good ones were great. They were engaging, fun, and left room to interact with people and go through the thought process and tradeoff discussions together. They felt like conversations and collaborative problem solving.
The terrible ones were truly terrible. Some asked me to invest five hours into take-home projects, despite the fact I had a job as well as an extensive portfolio of open-source side projects. Others ask me to spend hours to complete technical assessments that ended up not assessing anything related to the role. …
Learn how to create a dynamic heatmap of the United States by yourself, without having to buy a license from a company that sells charts.
A strangely large number of companies I’ve worked with somehow inevitably get to the point where they want to build or integrate a heatmap of some kind.
In the past, I would reach for the nearest charting library like HighCharts. Why reinvent the wheel, and besides, their charting is cool!
Over time, as I felt the itch to incorporate heatmaps into my weekend projects, I kept bumping it off due to the price. I kept asking myself “is this too expensive for a personal project?”
I don’t know about you, but for me the answer is yes. Some charting libraries charge a licensing fee of $500 per developer. This prices out almost every individual looking to use it for any “for-fun” usage. I lose far too much money buying SPY puts in the stock market to be able to afford spending $500 for a weekend project. …
Dive into how I resolved a platform’s scaling, stability, and performance issues through caching, jobification, queue separation, and more.
Processing over $20,000,000 in a single day
A previous company built payments systems and giving day software intended for massive giving days where we would receive tens of thousands of donations for a single campaign.
One of my responsibilities at that company was to scale the system and ensure it didn’t topple over. At its worst, it would crash on just 3–5 requests per second.
Due to a inefficient architectures, questionable technology choices, and rushed development, it had many constraints and was a patchwork of band-aids and gaping performance gaps. A combination of magical spells and incantations would keep the server running throughout the day.
By the time I was done with the platform, it had the potential to manage several thousand requests per second and run thousands of campaigns simultaneously, all for roughly the same operational cost. …
Take an in-depth look at how I designed, developed, and migrated a legacy system to a new feature flag system
A previous company had a problem: our deploys were thousands of lines in size, took nearly an hour, and were massively risky. Engineers hated deploying, which led to a backed-up queue of dozens of pull requests awaiting deployment. Product managers reasonably wanted to wait to release things until it was all done, which meant our releases could contain thousands of lines of code, any one of which could cause a catastrophic crash. The result? Incomplete work was piling up, value wasting away without delivery.
Something had to change.
Releasing Deploys
To help resolve these issues, one of the things I implemented was technology improvements that allowed us to separate the concept of a deploy from the concept of a release. …
Walk through the components of a minimal rules engine and understand some of the thought processes behind approaching its design.
Imagine this scenario
You’re a busy engineer working in a company with too much to build and too few resources to do it. Departments constantly ask for changes only an engineer can make. Marketing continuously asks for email on-boarding changes. Operations wants more and more batch tooling. Sales wants to test new pricing structures every other week. You and your team are overwhelmed with requests.
What are your options?
Stop progress on planned work to make these requested changes? …
Avoid the all-to-common developer mistake of leaking sensitive information in an API.
A problem I’ve seen a lot is the back-end controller accidentally serializing and returning confidential data to the front-end.
Sensitive things like password hashes, API access credentials, etc. may accidentally be serialized by magic framework defaults.
Promiscuous serialization
It’s quite easy to accidentally do, especially on a large team with multiple projects. A lot of frameworks put convenience over security, serializing all fields by default in the absence of a whitelist.
As a result, common developer errors may contribute to hidden security vulnerabilities.
In Ruby on Rails, for example, not specifying a serializer when returning an object from a controller will simply return all of the attributes for that object. …
A story of a dev-ops adoption and an organization’s transformation from waterfall to agile to lean
The Beginning of the End?
It was the end of 2018 and engineers were leaving by the droves. We lost seven engineers in months due to a single project. Our turnover had hit a high of a 38%.
It was the beginning of an exodus and an organizational collapse was on the horizon.
What was going on?
We were supposed to be on a solid path. Product ran two-week sprints and performed all of the scrum ceremonies to the T. We had 1:1s with all of the engineers. By any organizational standard, we should have been doing well.
Our problem was that, while on paper we were agile, in spirit we were far from it. We had highly centralized, top-down command-and-control, driven by product management that told the developers exactly what to do and when to do it. …
How you treat failure will determine how much initiative your team will demonstrate.
Initiative.
It’s a bias for action. It’s a mindset that always boils down to a “just do the thing” moment. It cuts through analysis paralysis, and ensures forward movement on ideas.
It’s so important that it is one of the Marine Corps key leadership traits. It’s Amazon’s 8th principle. It’s what many leaders want, but few get.
How do you create a culture of initiative on a team? In this post I’ll talk about the importance of accepting failure in creating a culture of Initiative.
Encourage failure.
Most leaders unintentionally nip initiative right in the bud, killing it before it even has a chance to exist. In their quest to create excellent teams, they cause teams to have less initiative through a very common behavior: punishing failures. …
In many startups I’ve worked with, image uploading was a part of their web application’s workflow. From user avatars to uploadable inventory pictures, it was a common-enough feature to be present in almost every system.
Rather unsurprisingly, many of those startups’ solutions to their uploading suffered from the same issues. Logic to handle image uploads was ad-hoc. File processing happened at the same time as the request, causing the application server’s request queue to back up.
In short, it wasn’t so much a system as a bunch of disparate workflows cobbled together (typical of most startups). The result? …
