Template for mastering the obvious

Title:What we learned from Google/Facebook/Twitter/<insert other big name that gives you a boner>”: state something obvious.

Overview: Describe in at least 100 words anything everybody knows. Don’t forget to combine here a mentoring attitude with clever hints on a tremendous importance of this obvious thing. Pretend that you are an elite knowledge worker, who earned this privilege of really understanding this obvious thing in multiple elegant brain-storming sessions with the same high quality bright intelligent people, or in a stressful, but extremely rewarding agile environment with a multi-million client.

How is works: Describe in at least 200 words what everybody knows about how this obvious thing works. Don’t spare any well known detail. Insert a “clean” looking diagram, because nothing complements an obvious thing better than a useless trivial diagram that pictures the obvious.

Describe how this obvious thing saves lots of time and money. Provide some useless numbers you pulled out of your ass to prove it.

Describe how this obvious thing promotes the openness. Again, about 200 words will do. Don’t lose your focus: state that this is obvious that openness is awesome, but you are writing about a different obvious thing.

Describe how this obvious thing is good for teams. Everybody knows that anything obvious that is useful is done by teams, and only sore losers do obvious things on their own. That is why Microsoft Office and Linux kernel rule, and Git sucks.

Add something about how this obvious thing is good for something that has a word “social” in it. It will look smart and modern (only smart and modern people understand what “social” things are). Any social reference will do, except the “national-socialist” one. Also avoid references to U.S.S.R. (Union of Soviet Socialist Republics) because there is still plenty of people around who used live in that shit.

In conclusion: make something up about how this obvious thing shapes our “culture” in a positive manner and at the same time our “culture” shapes that obvious thing. Less sense you make is better because nobody is going to read that far.

Examples:

What we learned from Google: code reviews aren’t just for catching bugs

 

Change

After a few hours of searching for a new software for this web site I’ve decided to stick with this software and update its design: self hosted WordPress and WordPress 2016 theme.

I want to keep it self hosted, with some anti-spam protection and a decent set of plugins.

While I still do software for living I don’t really have time to write this software on my own: I seriously considered coding it from scratch, well, maybe with some open source libraries.

No Wired

After many years being a subscriber I’m cancelling my “Wired” magazine subscription.

I don’t want to pay for articles for people who never grow up and live in a bubble with Silicon Valley as a centre of the Universe.

Also it’s annoying to browse ads for cigarettes and $5K watch – both items represent a life style that doesn’t attract me since I graduated from high school.

WordPress and Jetpack

Yes, WordPress seems to start following the global trend: “shove to your users throat whatever the executive dickheads decided”.

I’m talking about that bloated junk Jetpack.

The reason I choose self-hosting is precisely for that: to avoid this kind of modern social-media socialist style user management.

No, I won’t install it, never.

Sloppy vs Right

Every time I join an existing project I have to do one of the most frustrating things in my profession: reading and making sense of other developer’s code.

This is where I always see a reflection of one of the oldest false dichotomies: sloppy coding vs. “right” one.

It goes like this: one cannot write “right” code fast enough for a given time frame, that’s why it is sloppy: bad design, too generic (or misleading) names for abstractions, “spaghetti” style of routines etc.

Why this dichotomy is false?

Because it justifies unprofessionalism.

In our profession, despite its seemly overwhelming complexity, there is a limited set of corner-stone principals and skills (definition of this set is out of scope of this post).

One who does not possess, use and master (to some viable extend) this set is easily recognizable by someone who does.

Reading somebody’s code is one of the ways to recognize it. Unfortunately it means that sloppy code made it into production, and people behind it (developers and managers alike) made reading it one of the most frustrating things in my profession.

Scrum Rant

Well, not a rant, just an observation.

I do not understand why lots of companies these days are so obsessed with Scrum software project management development.

It is just one of many agile software development techniques, not better or worse than the others. For me personally it is actually worse, because I don’t like daily status meetings (in Scrum they call them “stand-ups”). I don’t like them for two reasons: I don’t feel comfortable standing up when there are sits available and don’t see a point of talking about my day over and over again.

As it looks to me, we have a substantial set of traditional, agile and lean development methods and principles, and selecting a right subset for a specific project and team is a matter of professionalism, experience and personal preferences.

I have always thought about agile software development as a rebellion for freedom. Freedom to choose and to use what fits and what works. When it becomes mainstream and takes a form of mandatory rules to follow, it defeats its purpose.