OKR Mistake #9

 A while back I went over 8 mistakes I've seen in organizations using OKRs. I realized I missed one important one so here it is.

Mandatory manager training - Sabotage an organization

It's been almost 10 years since I found this gem from the OSS (CIA predecessor). Recently when talking to some colleagues I realized that the sabotage field manual would make for an excellent manager training.

Why not have users jump around in a form?

Starting to collect documents to do my tax return this year I came across a terrible user experience.

You never know what the users mean

A couple of days ag Elon Musk tweeted (it's still called that, right?) about how their recommendation algorithm easily can get things wrong since they don't know why you are sharing content with friends. This is a great example of a problem I have to deal with on a regular basis.

Yet another reason to love Go: math/rand/v2

With the recent explanation of how math/rand evolved into math/rand/v2 I got reminded why I first fell in love with Go. Design decisions are not always made to match what every body else is doing, but rather what is the better decision. By some definition of better that I happen to agree with.

Go for C# developers: defer is not IDisposable

When using an IDisposable object in C# you have some pretty clear expectations on when that object is disposed. While the same thing is technically true with defer in Go, I've seen a lot of people misunderstand when exactly the deferred method is called.

Rant over a sloppy scammer

Occasionally I come across some really good scam attempts. But most of the time I'm surprised at how bad scams are presented. Let's look at a recent scam I received.

Testing a periodic worker

I came across somebody that was asking about how to test their code. They had a function that would do certain work at short intervals and then some other work after a longer period of time. They provided a simplified version of the code and it looked something like this. They had coverage for the short period work (I guess functions foo and/or bar in the simplified example had some side effect they could test for.

Using soft limits to prevent abuse with good user experience

When you develop a service you will probably run into a situation where you want to put in some arbitrary large limit on something to prevent bad behaving clients from using too much of your resources. This can be a max length of the URI, max length of each request header, max size of a request and so on. What we tend to do is often to return some kind of error when this happens and expect the client to fix their request if it is legitimate. But what if it is a legitimate request - just something you didn't expect to be valid? Or what if there is a bug in the client, but the user have no way of fixing the client but rely heavily on your service? Do you really want to completely break your users in these cases?

OKR mistakes and how to avoid them

Using OKRs is popular at a lot of companies and has become a golden standard for a lot of companies. But just like how companies start their agile transformation because they heard it was good but without understanding what it is really about. I've seen the same thing happen where OKRs are misunderstood.

Go for C# developers: LINQ

When I worked in C# I loved LINQ. I also probably used it more than I should have. I have recently looked into some options to bring LINQ to a Go project so let me share some observations.

TL;DR: I don't think we'll see much use of LINQ in idiomatic Go. Nor should we desire it.

Go for C# developers: Unicode strings

 There are a few gotchas with strings in Go if they contain unicode characters.

Go for C# developers: Using keywords as identifiers

It doesn't happen very often but sometimes there is a variable name that makes sense that happens to be a reserved word in the language. In C# when this happens you prefix it with "@" so you get @new as a variable name. Not quite as clean with the prefix, but clear what is going on. Go takes a different approach.

What is the purpose of a test name?

Since I'm certainly a person who has been passionate about how tests are named, this article first made me a little upset since it almost suggested Test123 to be a good name. But as I kept reading I started to question my own crusade regarding test names quite a bit.

The social standup

Reading about a new idea for remote standups in the Thoughtworks Tech Radar reminded me of a few similar experiences I've had.

How to annoy your users featuring Volvo

I've owned a Volvo since 2017 and I would have hoped would have been fixed by a software update at this time, but no. So here are two things that annoy me pretty much every time I use the car. And then a third recent WTF moment.

A coding interview that never happened

I've conducted hundreds of interviews that involve some kind of problem solving and most of them involved writing the solution in code. And most candidates make the same mistake so I figured it was time to share a simple strategy that seems to have worked for me over the years when I was the candidate.

Fire and the US insurance system

It has been a long time since there was something interesting to write about in regards to relocating to the US. And it is a weird coincidence that once I started blogging again - something happened that makes me pick up this topic again. Since I lost a home in the Marshall Fire I'm about to learn a lot about insurance companies in the US.

Yet another tale from an interview - 13 years later

A little over 13 years ago I wrote something short about my Microsoft interview experience (now only available in web archive). Back then the format was a shocker to a naive swede and now 13 years later and several interviews later I figured I'll write something about my experience going through the Google recruitment process.

Rather than me writing a long thing here you might as well read this which pretty much explains my experience in general.

If that blog post is too long here are the important things from my own experience.

• You don't get a yes or a no - you get a yes or not now. Failing a Google interview is not a big deal since there are several reasons a good candidate fails to prove them selves. Get your chin up and try again.
• Be humble - if you are asked to implement Fibonacci with your 10+ years of experience just write the best damn Fibonacci the interviewer has ever seen with a smile on your face.
• Prepare - the cracking the coding interview book is actually a pretty good prep tool. I coded on paper one hour every night for weeks. And don't be over confident if you are asked a question from the book because those problems have more depth than the solutions shown in the book. If you are too lazy for that there is a rule of thumb I realized preparing; if you can solve something with a hash table or graph - you probably should. A lot of problems can be reduced into hash table or graph problems so learn how to identify and solve those.
• Think differently - Google do things on a different scale than almost everybody else. This means that things that are important to other companies don't matter at Google. That is; if you can speed up things by preparing the data for a repeated operation - you probably should, even if it means using thousands of machines and/or huge amounts of memory.

And most important; have fun. Even if I would not have gotten an offer I had a blast interviewing and would have tried again.

Still there?

When I decided to not post regularly, it apparently resulted in never. Well, I've decided it's time to change that after five years of silence.