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!
The managers dilemma: Good, cheap, fast, you only get to pick two.
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.
How to deal with the dangers of hype, keeping teams motivated and at the cutting edge while retaining a solid technological foundation. Inspired a great deal, by Hype Driven Development by Marek Kirejczyk, of daftcode.pl.
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.
But, it’s urgent! We are late! We need to hurry – our client expects this. There it is, a stakeholder calls to put “a bit of pressure” on the team, to “go the extra mile” or “work double as fast”. All in order to meet a milestone, deadline or sprint goal. And as you crack your whip and shout “Faster!” your team miraculously pulls through – another crisis averted, another deadline meet.
Or not. Because this scenario rarely plays out like that. And even if it does, managing through urgency comes at both a high risk and price. Let’s take a closer look and evaluate if there is an alternative.
Zack Bloom from Eager with a beautiful in depth write-up on The Languages Which Almost Became CSS.