Category: Uncategorized

I had a Matias Ergo Pro mac version for about 3 years, purchased in May 2016. It lasted until the end of 2019 when the USB C port that connects the keyboard to the computer died. I bought the keyboard after I started getting pains in my fingers during a gaming phase. Using this keyboard with a vertical mouse eliminated my hand pain. 

The Ergo Pro is pretty solidly built, the wrist pads are comfortable. I replaced the wrist pads after about 2 years when they started to come apart. The two halves of the keyboard can be positioned to match your natural hand tilt which is very nice. 

The most annoying issue I have had with this keyboard is that it collects dust and crumbs over time, (years), and that can have an effect on the keys. Your keys will start acting up in weird ways. The first option is to flip over the keyboard and shake it out, then if that doesn’t do it. Take the keys off and really clean it. I don’t remember if it came with a key removing tool, but  its pretty easy to get the keys out, harder to get them back in. 

Disassembling the case is straightforward, it has two sizes of screws and my ikea set was able to do all of them. 

I’m pretty annoyed that my keyboard broke I would have kept using it. 

I strongly recommend the Ergo Pro for mac users with a desktop style setup. I used mine with a laptop and external monitor. The best features of the keyboard are its ergonomics and its custom mac keys. I’m using a more standard windows style keyboard now and I miss having my command, fn and option keys positioned so conveniently. 

Here are some interesting links I’ve come across over the last few months. 

htop explained 

4 Types of Documentation 

Making a Language Server 

The typical agile process involves 5-10 people in a room. They go through one sentence descriptions of tasks, and each secretly comes up with their own estimate before every turns over their cards like in the final round of poker.

Then there will be a couple minutes spent discussing the estimates which will end with the average of the “votes”.

These meetings are usually confused by someone misunderstanding the breakout of one particular feature into one sentence descriptions, causing the group to backtrack and re-estimate several of the stories.

Most of the team will think about each task for a total of 2 minutes total. 

The intention is that the project manager will take all this data and gradually calibrate the estimates.

I have spent a great deal of time participating in these agile “estimation” sessions and I can assure you that the estimates I produce in this setting have almost always been far off the mark.

Projects commonly run over what they were estimated, and sometimes a project estimated to take a month actually takes a day if you get the right person to work on it.

After 3.5 years working in this environment the whole process seems pretty pointless. Everyone knows the estimates are wrong and plans for it. Why do we bother doing this process that is known to be unreliable at best?

In construction estimates are done off of detailed blueprints using well understood heuristics, equations and the price of materials. 

In software estimates are done off of one sentence descriptions of heterogeneous tasks and the gut feel of developers about how long something will take.

Agile Rapid Delivery means you deliver bugs to your customers everyday. 

Every once in a while I read an article about how software has become horrible over the last decade. Software has gotten slower, it uses too much memory, it has too many confusing features, why are developers producing worse software? 

Part of this is coincidence. We remember software being fast, but that was during a time when CPU speeds doubled every year. By the time you had used a program for a year, there was a processor out that could do it in half the time. Now Moore’s law ambles around at low double digit performance improvements. 

Another issue is feature complexity. “The old software just worked, why did they have to change it?” With the move to Software as a Service we can constantly add new features. 

Frequency matters if you deliver buggy code to your customers once a year on CD-ROMs. They are going to complain about buggy code once a year. If you deliver buggy code to your customers everyday, they will probably give up and accept their fate.