I AM social, probably more than You are

I am an introverted software engineer and I love what I do and how I do it. People I physically meet usually think I'm asocial, tongue-tied or shy. The reasons I don't talk are usually because I don't have anything to say or you don't interest me (or worse). I spend most of my time in front of my computer doing things. Even lots of people from software engineering circles or usually subcircles [1], I meet physically do not interest me.

I have available techs like email, mailing lists, IRC and sites like github and stack exchange and even Google which directs me to many other sites where thoughts of people are available. You probably know only half of these and can use none of them effectively and you have no idea what this means if only thing you care about is facebook, instagram and minecraft [4].

With these techs I have available thousands of people at my fingertips, who I daily interact with [2] and a circle of people I interact with regularly. Often holding many conversation threads at the same time unless I'm currently immersed in part of the problem, that I need to figure out only myself.

That's my daily routine. What is Yours [3] ?

QED.

[1]Software engineering is broad discipline where people usually wield well only one or two of the subfields.
[2]Software engineering is not just about turning caffeine into software. It's a lot about what other people have thought and written and interacting with them to resolve issues and exchange ideas.
[3]By You I assume non-computer person who managed to keep their attention span long enough to read this short blog post.
[4]In which case you are nothing but a walking (and sadly, talking) bag of meat to me.

Why terminology matters

When arguing and correcting people on terminology, I often hear people say I'm quibbling and it doesn't really matter and it's always pissing me off.

In a sense they are right. What is important is the concept, the idea. The name is essentially an arbitrary symbolism and it can be anything we make up. But it is also important that both parties have in mind the same concept. The same idea. And this is where terminology comes in.

Terminology is important because it allows us to communicate with each other clearly and save time by naming very specific things or ideas by one or just a few words like resolver or directed acyclic graph.

If you don't have the terminology, sure, you can talk about the metalic boxes on wheels controlled by the steering wheel and pedals. But you can also talk simply about cars.

Let me tell you a story about Impedance Mismatch which happens when the parties think they are talking about the same thing but they really are not.

There was a bunch of developers teleconferencing with ops team about deployment of their application but due to lack of conference room even though the junior devs were not participating, they were exposed to the dialogue. At some point they started talking about some metalic boxes on wheels. It was getting lengthy and started turning into an argument.

The juniors did not really know what they are talking about but one of them recognized the metalic box they were talking about so even tough he was a new hire and junior dev at the time and wanted to stay out of it, he decided to step up and throw in just two words - "reverse proxy". The participating devs lashed out on him for meddling in their bussiness but it helped to move the discussion further as it quickly turned out that the ops were talking about load balancing where reverse proxying is just one of possible solutions which the devs were thinking of but the ops didn't. true-story.jpg

Right now I can think of another story where one is thinking trees while the other is thinking directed graphs with cycles. And I'm sure there are many, many more.

Sure, Impedance Mismatch can happen when you are using lot of terminology too but that's due to incorrect mental model of the term rather then difficult or unclear communication. Besides the obvious benefit of the common terminiology being easier to work with I find the incorrect models easier to recognize and correct when the terminology is in use.

You can also think of it as communication protocols. You wouldn't be talking SMTP to an IMAP server, would you?

On Window Managers

I've been happily using Xmonad window manager for a few years now. Before that I used pekwm for many years. I switched from pekwm to Xmonad because of tiling and later I found even better Multihead setup there. Nice thing was also that beside the tiling, I had the pekwm configured in what is basicly the default in Xmonad so the change was fundamental but subtle and there was no downside.

Here are my reasons for using Xmonad. Most of them apply genericaly to a tiling WM, though.

Keyboard oriented & Tiling

With tiling I don't have to fiddle with each window manually. I have few preset layouts, which I can switch between with a few taps. Zero mouse interaction needed to operate the WM.

∴ it's effective for typing work like writing (blogs, emails, …) or coding and et al (coding itself, sysadmining, debugging).

No bullshit decorations

The only decoration I have is ~ 10px high status panel (basic system stats, datetime, battery and systray) on top and 1px red border for the window with focus.

∴ I can work comfortably without useless distractions. Even on low screen sizes like 1366x768 (probably could even lower if I really needed but that's hard to find nowadays) and with the same WM and the same setup as on bigger screens like 2x 1920x1080. Consistency.

Minimal design

A.k.a less is more.

It looks like there are people spending lot of their time with migrating between bloated, never finished user interfaces with goals changing every major release instead of gaining insight and finding simpler composable concepts of operation. And then there is always some migration happening.

I always find it ridiculous when new version of Desktop Environment X is released and then half the people migrate to DE Y and then when Y releases new version, they migrate again.

Sticking with minimal systems means they are very clean, effective and almost never change.

Multihead setup

Xmonad is the only implementation I know that is dealing with multihead correctly for my kind of work. That is where you can control each head separately, meaning you can view workspace 1 on one head and workspace 2 on the other one and changing the workspace on one head does not affect the other.

Implementation & configuration in Haskell

At first I was reluctant about this (as my skill set was very different back then) so I first tried Awesome but it was doing too many things in default. The configuration via Lua was weird. And mainly I had some display issues with it which I was unable to resolve.

So I gave a shot to Xmonad and since then it just works perfectly without a single issue. Later I learned about the language and found it very readable and helpfull for writing correct programs once you grok the type system.

Page 1 / 3 »