Understand, eNumerate, Paper, Historical context, Advantages, Think -> UNPHAT. Ozan Onay‘s approach to deal with the fact, that for most cases you (or your client) are not Google, Amazon, Twitter or the likes and therefore some of their currently hyped solutions might not fit your problems.
While MVP as an approach may not solve all of the problems associated with product development (and project definition), in almost all cases some valuable insights can be derived from it. There only is one caveat to this: In order for the magic to work, all sides involved have a clear grasp of what the concept actually entails.
Fascinating interview with Gitlabs CEO Sid Sijbrandij about how create and keep in sync a fully distributed and remote company with 160 employees spanning the globe in just as many individual locations.
Having a profitable business doesn’t mean squeezing the lemon for every last bitter drop. It isn’t all or nothing. You can be profitable and generous. Profitable and fair. Profitable and kind. These aren’t opposite ends of some moral spectrum. Quite the contrary.
Jason Fried, of Basecamp fame, with an interesting take on running a company on one goal only: profit!
Kenneth Kalmer makes a pretty convincing point here. Compared to what counts as a standard development and production stack nowadays, the The JVM is not that heavy. A stack that for the web dev community once symbolized the clumsiness bulkiness of “classic” software dev, feels “light” in comparison to what we typically have to handle in our projects.
As I have recently upgraded my standard stack in a side-project, I could not agree more. Yes, package managers and task runners and pre-, post- and side-processors, linters, normalizers and minifiers make some tasks easier. But some others painstakingly hard. While progress is all nice and good, sometimes you think, back in the days, we made it work with a lot less fancy toolstuff.
There are few skills as crucial in regards to communication as the ability to hit the right level of abstraction. No matter if you write a status report, participate in a meeting or just call somebody, hitting the right level of abstraction will make all the difference between succeeding and failing at making yourself understood.
If you’re telling a programmer that a particular piece of source code simply “does not work”, then you should no longer consider yourself a programmer.
Bugs suck. Dealing with bugs sucks. But there is no need to make this harder than it already is. Great (and bold) plea by Nick Griffith plea for a sensible approach to reporting bugs and issues in other peoples code: Does Not Work.