This is a blog post about blitzscaling, difference between marines & soldiers & police officers, which of them are getting the shit done, why do the "code ninjas" & "programming rockstars" fail and how you can turn that all into your advantage.Few days ago I've started reading "Blitzscaling" by Reid Hoffman. I'm not done yet, book is OK, I do agree with a lot of things (but I still do not with some), however today I've found something really worth sharing. A classification of attitudes (mindsets?) of people that are the most desired/beneficial at various stages of modern…
All posts in engineering culture
In this blog post you'll read about ... where does the motivation come from, why direct pushing doesn't motivate us (for real), what is "the runway method", whether it's OK to stretch beyond 40h/week (50h? 60h?), why software development is like surgery and what's the difference between good & bad praise. Oceans of ink have been spent on all the articles on efficiency & productivity in the software development industry. As the technical aspects of gaining more velocity are not only tricky but also require a high level of expertise, many seek for more comprehensible & readily applicable…
By reading this article you'll learn that: not everything that appears as pep talk is a brainwash, you can be a Moses (& carve some stone tablets) for your team, why 10 commandments are better than "Chairman's Mao Little Red Book", where's the border between good & bad principles, where do the values come from (& whether they can be imposed) ... Utterly pragmatic creatures known as engineers are by definition allergic to any kind of activities they classify as "brainwash". This category is quite wide: all sorts of pep talks, motivational speeches, noble ideas/values behind…
TL;DR Poor (in terms of engineering culture standards) work environment doesn't just impact negatively the end products (quality, fit-for-purpose), development process (effectiveness, efficiency) & people morale - it can also deteriorate their skills, attititudes, long-term motivations. One with high standards is not likely to welcome happily the sudden, significant drop, but we fool ourselves by justifying short-term "compromises" that slowly (but cumulatively) lower our baselines, effectively turning us into much more inferior engineers over longer period of time. If you were to describe an archetypical engineer with just one adjective (that depicts the most desired/characteristic trait…
TL;DR Software development units are not really as simple (and linear) as the conveyor belts, so they should not be treated as such. But when in pit of despair, starting with some simple structure (that can be at last partially - in the most simple "areas" - governed automatically) may be a reasonable way to approach serious systemic problems. Tools (like JIRA) SHOULD NOT be running your team(s), but can provide them some kind of stable work framework to build some ritualization upon. It doesn't work beyond some level of sophistication, but it may be exactly…
TL;DR Many engineering organizations postpone their most ambitious plans due to cost constraints for so long that they start to believe that it's only money that limits their capabilities. When they eventually get funds, they learn (in a painful way) that scaling up in an efficient manner is not really a matter of funding (actually it's one of LESS meaningful factors) -> software engineering is a very fragile process w/o a simple formula to define Ability to Deliver (Execute) in a period of time. Instead, there are several important components with lower than linear positive impact (above…
TL;DR These days everyone knows that servers are supposed to be more like cattle than pets. But the same principle applies to the code - caressing it & endlessly tuning it according to completely subjective, quasi-aesthetic criteria is one of the most often committed sins of today's software engineers. Especially as we're speaking about very technical activity that frequently just gets away as it's totally non-transparent for business stakeholders & many managers. I'll start with a harsh statement: "refactoring" has recently become one of the most devalued terms in software engineering. It became a perfect excuse in…
TL;DR - educating a specialist takes time, money & effort - w/o a guarantee of final payoff. Maybe it's the time to get back to traditional apprenticeship model to secure educator's position & make job market more sane? On several occasions I've evangelized the advantages of sensible, organic growth over opportunistic, aggressive head-hunting. And I haven't changed my mind, but it'd be stupid to ignore risks & flaws of the model I recommend. Imagine the following scenario: You have a small software house. Your team puts a lot of time & energy in filtering out the most talented…