or subscribe with
Join 14,100+ readers for one email each week.
Digests » 355
Vettery is an online hiring marketplace that's changing the way people hire and get hired. Ready for a bold career move? Make a free profile, name your salary, and connect with hiring managers from top employers today.
this week's favorite
Every year companies spend $41B on enterprise resource planning software, commonly known as ERP. Today, almost every large business has some sort of ERP system implemented. But most smaller businesses generally don’t purchase any ERP system off the shelf, and most engineers probably haven’t seen them in the wild. So for those of us who haven’t used an ERP system ourselves… what’s the big deal?
It’s a good a problem to have, but information on how to take a web app from 0 to hundreds of thousands of users can be scarce. Usually solutions come from either massive fires popping up or by identifying bottlenecks (and often times both).
“Technical debt” is a metaphor for all software design choices that turn out to be suboptimal, no longer valid, or just plain wrong. They incur a cost on future development. The shortcuts taken today will later slow you down, until you “pay back” the debt by fixing the problems. And it’s not just code: artifacts like architecture, documentation, tests, and domain models, can all suffer from technical debt.
If you are a software developer, security is one of your primary concerns. If you ship code, and that code deals with any sort of sensitive or personal information, you need to ensure your code and the systems you build allow people to transact on your systems safely and securely, free from fear of compromise or consequence. Your user’s security is not Someone Else’s Problem.
We’re decent at building software when the consequences of failure are unimportant. The average piece of software is good enough that it’s expected to work. Yet most software is bad enough that bugs don’t surprise us. This is no accident. Many common practices in software engineering come from environments where failures can be retried and new features are lucrative. And failure truly is cheap.