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.
Stackshare did some (big) data crunching. Analyzing over 40 000 technology stacks and plenty of other data they identified the most used developer tools in 2016. The Top Developer Tools 2016 is a great read. Not only in order to get an idea what happened last year and what will be happening this year. But also in order to stumble upon a new tool or two.