Being Cellfish

OKR Mistake #9

noreply@blogger.com (cellfish) — Thu, 24 Jul 2025 13:24:00 +0000

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.

Mistake #9 - Don't cover the basics

In the previous article I mentioned that a good process is to have some generic high level goals that remain the same with some adjustments every year. And this is related to this mistake. Consider a situation where you want to increase sales and for the sake of this argument, let us assume you have a single KR; increase number of sold items by 100%. It is plausible that this could be achieved by dumping the price of the product. Maybe we can double the number of items by cutting the prize in half.

The problem here is that if the team have the freedom to make any decisions as long as they meet their KRs, dropping the prize could happen. As a result the actual profit might go down or we could even end up in a situation where every item is sold at a loss. Since this is probably not want we want, we need to fix this.

Naturally this could be fixed with various constraints in the organization, but since we're talking about OKRs the way to fix this is to add another KR to balance the scale and set some rules. We could for example add another KR: average profit per item sold should be at least $10.

I'll admit that in this simple example, putting a constraint on the profit doesn't feel like a KR at first glance, but there are actually two important things this KR allows the team to do: First, this allows the team to have tiered prizing. The more you buy the cheaper each item is. And the team can make these decisions themselves since they know the goal. Second, this allows the team to explore other options. Can they improve production to lower the cost to create the item and hence be able to lower the prize while maintaining the same profit.

In this simple example it might feel like an overkill and you could also argue that the team is not going to be malicious in order to meet the KRs set. While the latter is true, in a less obvious scenario a team might make an optimization for one KR that has an undesired side effect if the basics are not covered. And the team might not do this out of malice, but rather ignorance or just in dedication to succeed with the KRs set.

So in conclusion, since you tend to get what you measure, spend a few minutes thinking about how your KRs could be gamed and add a few more KRs to balance the scale and avoid KR gaming.

Mandatory manager training - Sabotage an organization

noreply@blogger.com (cellfish) — Thu, 15 May 2025 11:15:00 +0000

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.

The gem I'm talking about is the simple sabotage manual, and specifically the 11th section starting on page 28 covering how to sabotage organizations and production. Section 11b even talks specifically about things a manager can do and hence serves as great examples of what not to do.

Why not have users jump around in a form?

noreply@blogger.com (cellfish) — Thu, 30 Jan 2025 20:30:00 +0000

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

When you live in the US, but have assets (such as a bank account) in another country you need to fill in a form to declare how much money you have there. It used to be a paper form but now there is an online form to fill in.

This form has a great "feature"... When you fill in the form from top to bottom and you want to enter the state for your address, the drop down is empty... But there is a helpful comment letting you know that you first need to skip down two fields and select the country. Once the country is selected you can select the state. Note that the US of A that is selected for line/field 13 is there because I selected it before taking the screenshot. Initially no country is selected and hence no state can be selected...

I'm pretty sure the ordering is just whatever order the paper form (that is still available as a PDF version) have the fields in this order. And for some reason the electronic form was not changed to be logical but to mimic the paper form. A great example of how UI should not be a reflection of the implementation behind the scenes.

You never know what the users mean

noreply@blogger.com (cellfish) — Thu, 05 Sep 2024 15:05:00 +0000

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.

This is the tweet in question (screen shot to the right in case it get's deleted). It highlights a very common problem when it comes to both abuse prevention and streamlining content for users - you cannot be sure about why users take certain actions.

Let's look at a two examples from "my world". If a user deletes an email without reading it - what does that mean? Does it mean that the user don't want to see similar content? Or does it mean that they could triage the email based on the subject and decided they don't need to read this message (but is still interested in other messaged from the same sender)? Technically we cannot know...

What about somebody who is reporting an email as spam? Does that mean that they think all emails from that sender is spam? Or only that one email? Or are they using an email client with the options "junk" and "trash" where one means "delete" and the other "spam"? We can probably figure out if the last option is happening - but we still don't know if the action was intentional.

You might think that you can just ask the users for more information about their intentions. Sadly I think that rarely works with real users. I remember when I wanted to report a fake account on twitter and because I was not the victim directly affected it took me several attempts to reach a state where I could actually report the account. At that point I would have clicked anything just to proceed so the reasons I provided had less value. Generally I think users hate clicking through wizards so they probably just give up and your system do not get feedback on how it is performing.

At the end of the day, maybe it is acceptable to be mostly right. But even if you keep the majority happy, the user experience for the minority where your system do the wrong thing can be pretty bad. And if you don't recognize the fact that users will do unexpected things you'll likely end up making a lot of users disappointed.

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

noreply@blogger.com (cellfish) — Tue, 07 May 2024 04:22:00 +0000

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.

While the blog post on math/rand/v2 goes into interesting details around different pseudo random algorithms, exciting optimizations, and how to generally update a widely used library (like the standard library) with new versions are all interesting it is really three other things that make me even more excited.

One of the first things that I appreciate is the openness in recognizing that the original math/rand library has several bad design decisions in it. And this is a tone in the whole article. Very appreciated and directly related to the next two things I'm excited about.

It might seem like a small thing but the fact that the new library recognizes that different pseudo random algorithms needs to be seeded in different ways, just like different crypto algorithms need to be seeded (with a key and other parameters) in different ways.

But the final thing is really the best; the removal of the Read method from any math/rand/v2 types since this introduces a risk of accidently using the weaker randomness in math/rand vs the cryptographically secure crypto/rand package. In my opinion this shows and amazing attention to detail and is definitely in the spirit of Go - prevent developers from accidently making mistakes.

Go for C# developers: defer is not IDisposable

noreply@blogger.com (cellfish) — Thu, 11 May 2023 17:05:00 +0000

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.

In C# we expect the Dispose method to pretty much be called when the disposable object goes out of scope. Unless you use a using statement you technically don't have a guarantee, but there is always a chance that your object gets disposed pretty soon after it goes out of scope due to the garbage collector.

In Go however when you use the defer to mimic disposing of an object, the deferred method is not executed until the method returns. This is an important difference. You are actually guaranteed it will not be executed until the method returns.

I have seen this cause confusion and problems when people use defer inside a loop since all cleanup functionality is postponed until after the method where the loop resides returns. And the way to fix it is to create a new function that actually returns for each iteration in the loop. Here is an example showing both the "wrong" and "right" way to have a deferred method execute for each iteration in a loop.

Rant over a sloppy scammer

noreply@blogger.com (cellfish) — Thu, 27 Apr 2023 10:27:00 +0000

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.

This was one of the typical refund scams where they send you a receipt for something hoping that you'll call back for a refund. If you're interested in knowing what those calls sound like (and see somebody have some fun with the scammer) - here is one of many videos of that.

So the scam email I received was such a lazy attempt. First of all the sender was just a random gmail address (no attempt spoofing a realistic sender) and the subject was just the work "order" with a few random numbers. There was no message in the body and only an attached file that had a random characters and number for a name.

Let's take a look at that attachment. From the top note a few things:

The order number overflows to the edge of the page - Professional!
"Thurs" is definitely one way to abbreviate Thursday, but I would have expected just "Thu" given that the payment date is abbreviated "Fri". Maybe a small thing - but it caught my eye.
So the thing I "purchased" was $310.99 including tax - yet Paypal added tax. I guess that's another reason to call an demand a refund.
And the tax (12.58%) of $310.99 is not $38.99 - It's $39.12.
They definitely want me to make sure I know I can call them and cancel since they mention it three times!
Capitalization is wrong (using upper case i in the middle of a sentence and starting another with lower case c.
What does it even mean that the amount is done through Amazon but purchasing done through PayPal?
A cherry on the top I think is that what if I don't remember this but go check what this Norton 360 deluxe is? Maybe it's something I want. I guess I'll now definitely call for a refund since the actual prize is $109.99.

I guess there is no point in wasting time paying attention to details when scams like this still fool people. ¯\_(ツ)_/¯

Testing a periodic worker

noreply@blogger.com (cellfish) — Thu, 13 Apr 2023 10:13:00 +0000

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.

Interestingly enough they did know they could add more arguments to their main function to control the shorter period as well as using a function argument to capture the longer period worker. But two problems remained; they would rely on some (short) waiting in their tests and they also would prefer to know that some short period work always happened before the longer period work.

If you accept some really short waiting times (and ignore the second requirement), then you can get away with pretty short waiting times. The problem with short waiting times is that you might end up with too short waiting times and get occasional failures just because something took a little longer than usual due to load on your machine (for example lots of other tests running in parallel). But if you do go down this route you probably end up with something like this.

But I think you can do much better... I think there is an easy way to also test how the shorter and longer period work interacts without any waits in a predictable way. The trick is to not add more parameters to the existing function but rather break out the periodic worker and test that one separately. If you do that you end up with something like this.

Yes, that solution uses three different function arguments which might look scary, but since you get really fast and predictable testing I think it's worth it.

Using soft limits to prevent abuse with good user experience

noreply@blogger.com (cellfish) — Thu, 30 Mar 2023 09:30:00 +0000

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?

I have come across situations like this several times in my career and often the problem is solved short term by increasing the arbitrary limits. This however only works when clients are few and don't expect quick fixes and you can deploy a fix quickly. I have however found another way to deal with this problem.

Instead of completely blocking unexpectedly large request I have found it effective to process them differently than "normal" requests. The solution is to allow each client a small emergency quota. Any requests conforming to the limits expected do not need emergency quota. But when a request comes in that in some what exceeds the expected limits (typically on resources) I can check if that client have enough emergency quota to process the request. If not; I return an error informing the client they do not have quota to process the request since it exceeds some specified limit.

This way any users that only have an occasional extreme request will never notice what happened. But users that exceed limits a lot will only get a fraction of the requests processed but they will also (hopefully) get a clear error from their client. And whoever maintains the client can clearly see what the problem is.

But the biggest benefit is that I can protect my own service from extreme requests causing a denial of service since the quota check ensures I only process a small fraction of the dangerous requests. It is true I take a small risk this way that always needs to be weighted against the user experience. So this is not a pattern I use all the time, but rather a useful pattern in certain situations.

OKR mistakes and how to avoid them

noreply@blogger.com (cellfish) — Thu, 09 Mar 2023 13:00:00 +0000

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.

What is OKRs?

OKR stands for Objectives and Key Results. An objective is a higher level goal and does not necessarily need to be easily measurable. Each objective can then have a number for Key Results (KR) to measure progress towards that higher level goal.

Mistake #1 - Treating OKR as a single thing

The largest mistake I've seen is when OKRs are treated as a single thing (Objective Key Results AKA Key Performance Indicators (KPI)) when it's really a combination of two things with a clear hierarchy. When every single KR have their own objective, you also tend to make mistake #2 and/or #4 below.

Note that using KPIs instead of OKRs is not a bad if you know you are using KPIs. But if you are trying to use OKRs, using KPIs (without the objective) is a mistake.

Mistake #2 - Os and/or KRs are just tasks

This typically happens in an organization where individual OKRs are used. Everybody need their own KRs so the easiest way to accomplish this is to just take something that needs to happen and call it an OKR (ex: "Implement the Foo component").

Mistake #3 - Objectives change every quarter

If objectives change all the time it means priorities change all the time or the objective is too short term. And organization where this happens should look at if some of the objectives really are KRs and/or consider what is the longer term objective to achieve.

Mistake #4 - Os and/or KRs defines the how

Since Os and KRs typically span over a longer period of time, if they define how something is expected to be implemented (or released) the team will be bound by an early decision on how to achieve a goal rather than letting the team make that decision when needed. By defining early how to do something you risk exploring the wrong solution or will have to spend time on changing OKRs.

Mistake #5 - KRs cannot be measured

Not every detail of work needs to be measured but if you have a KR that cannot be measured (or can only be measured as a binary - either you are done or not done) it will be time consuming to follow up on the KR and see how it progresses. This can somewhat be mitigated by defining how a KR is measured upfront (ex: "If the KR is implement Foo, we call it 10% complete when design document is approved").

Mistake #6 - 70% success on each KR is the goal

There is a recommendation that every team should aim high and hence 70% success on KRs is considered success. For some KRs this could make sense when you set an aggressive target like increase performance by 20%. But there is a risk that you end up with all your KRs being 70% done rather than actually reaching a certain goal. And if all your goals are ambitious and you never reach them the team will likely over time feel dissatisfied since they can never reach any goal set. Actually meeting 70% of the KRs and care less about lower priority KRs is probably much better for the organization both long and short term.

Note that this mistake is particularly bad when combined with mistake #2 as nothing will be completed. The team just ends up with a lot of unfinished work.

Mistake #7 - every layer of the organization needs objectives

Not everybody needs objectives. They make sense for large organizations and most teams. But a smaller team or individual can just consider the higher level Os and make their own KRs instead of spending time of breaking down a big O into a smaller. That just tends to be reusing a higher level KR as a lower level O. For example if a sales organization has an objective of being the market leader with their product and the KR is to achieve 50% market share. Then a smaller sales team that want to contribute by making 10 sales do not need their own objective in my option. And if you really want them to have their own objective I would suggest using the 50% market share as the small team objective.

Mistake #8 - No stack ranking of Os and KRs

Just like any backlog your Os and KRs need to be stack ranked. This way teams and individuals can easily negotiate to help each other by looking at what KR their work contributes to. There is a mistake within the mistake to be made here. All KRs that belong to the most important O is not necessarily more important all KRs of the second most important O. The objective stack ranking serve as a guidance to the KR stack ranking since most KRs of a high priority O should be higher priority than most of the KRs of a lower priority objective.

Good OKR mind-set

The O should explain why something needs to happen and the KR defines what needs to happen. The how it is achieved should be left to the teams to figure out.

You should also have a mix of long and short term Os and KRs. The longer term Os and KRs guide the organization at a high level and you then use shorter term Os and KRs to guide where you want the organization to focus short term. By long term I mean 1+ years and by shorter term I mean 1-2 quarters.

You should also think of Os as being defined top-down while KRs are defined bottom-up. I.e. stakeholders define the desired outcome with Os and the teams figure out how to best measure success with KRs. Stakeholders and teams then agree on the KRs.

It is also OK to change Os or KRs at any time if needed based on new information, but I think you have a good set of Os and KRs if changing Os or KRs only happens if there is a significant and unexpected change in organization priorities. If you expect KRs to change often, you have the wrong set of KRs.

Good OKR process

I have come up with this process because I have seen it work well a couple of times.

First of all you want an objective that essentially never would change (ex: be the market leader in X). That objective also needs one or two KRs that represent yearly goals so it would be adjusted every year (ex: we have 40% market share in X). Both of these are defined top-down in the organization.

If needed you might also have one or two objectives for the year (ex: become market leader in Europe) that help guide the organization on where to focus. Finally for a quarter you can further guide the organization with an objective (ex: become market leader in Germany).

I would have each team lead figure out what good team specific KRs would look like for each OKR cycle (ex: make 10 sales in Berlin).

Finally with all these Os and KRs in place it is up to the team to suggest what activities would contribute to the goals already set. But those activities are not Os or KRs - it is just a backlog for the team on how they plan to achieve the given KRs.

The KRs should be picked in such a way that they are easy to objectively measure and hence become easy to put on a dashboard. That way you can continuously follow up on where you are compared to the goal of each KR.

Every team is different

The Os and KRs will likely look very different depending on what type of work the team is doing. And they are really just tools to guide the team (on a higher level) on what is important and how progress towards those goals look like.

Go for C# developers: LINQ

noreply@blogger.com (cellfish) — Thu, 08 Dec 2022 19:08:00 +0000

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.

But before looking at options, what does LINQ bring to the table? In my opinion LINQ brings two good things to the table.

First it makes it very concise to filter and manipulate collections of data. It can possibly be argued that this conciseness makes programs harder to understand and I agree. Just like any program can be written in an easy or hard way to understand, the usage of LINQ sometimes makes it easier to write hard to understand code. This can however be mitigated by splitting up the LINQ statement into multiple statements.

Second and the most important reason I used LINQ is that it defers enumeration until it is needed. This makes it very easy to abstract fetching data in batches etc, and still do complex computations on the data. This benefit is obviously lost of you sort, or want distinct elements, but a lot of the time this deferred enumeration made my code both efficient and easy to understand.

ahmetb/go-linq - using reflection

This is a package that predates generics in Go and correctly have identified that there is no easy way to implement LINQ using generics. The good news is that if you are looking for a package that let's you write LINQ just like in C# this is the package you are looking for. The bad news is performance. There is a lot of memory allocations and since it is using reflection you don't have compile time type safety.

ahmetb/go-linq pull request - adding generics

The main reason why adding generics to this package is hard is because the generic types can only be on functions types, not on receiver methods. Hence something like Select becomes a little cumbersome to implement. This pull request works around that limitation by introducing a new intermediary type that holds all the types that are needed and hence increases the length of your LINQ statement. That intermediary step also becomes confusing I think.

samber/lo - using generics

This package is really a bunch of small helpers and does not claim to be a replacement for LINQ. This package will not allow you to make any "method trains" as each function will take the collection as an argument (i.e. receiver methods not used). These helpers also do not defer enumeration as they operate directly on slices and channels which means performance is just as good as if you manually do your processing. Since these helpers don't do anything other than hide a few for statements from you, the usage seems questionable to me, and definitely not idiomatic to Go where explicit implementations is preferred.

szmcdull/glinq - copying IEnumerable

This is an interesting approach where similar to samber/lo the constraints with generics is circumvented by only using functions rather than receiver methods. It introduces a copy implementation of IEnumerable from C# to defer enumeration. I think this implementation could have been much more idiomatic reusing the Iterable concept used in the internals of ahmetb/go-linq.

Conclusions

Given the constraints in how generics are implemented in Go I don't expect to see anything like LINQ be used very much. And I have come to think that is a good thing. A long chain of function calls where each of them perform fairly simple tasks does not really make the code easier to understand. Even when using an approach where each part of the chain is independent (as in the last two examples above) the value of these generic methods is very limited compared to explicitly perform the desired actions.

Since LINQ really shines when it comes the the deferred enumeration of (partially) asynchronous steps, there already is a good solution for that in Go; channels. So the use of an interface like in the last example above is again not adding much value.

Another interesting observation is that maybe LINQ is a terribly idea in the first place. In all languages. It is certainly nice to create a chain of actions (i.e. a data processing pipeline) and reuse that on different pieces of data, regardless of if the data is available all at once or not. And it might be helpful to have this data pipeline hide that fact. However, I don't think that means it is the most maintainable solution to achieve the same result. At the end of the day, maybe LINQ is best suitable to allow people familiar with databases to easily convert their SQL skills into another programming language, but I am no longer convinced LINQ is a good tool if you know the language well and want to do data processing.

Final thoughts

Since this was not the outcome of my research into LINQ for Go and I'm sure this opinion is not the most popular (especially among C# programmers), I'd love to get examples (in Go and C#) where a LINQ statement is actually easier to understand than the alternative (explicit code). And remember shorter does not necessarily mean easier to understand!

Here is an example I created that is border line better as LINQ. The use of Distinct and Sort is very short and clear, but the Go version is not much longer and follows the usual patterns for achieving the same thing. And even in a simple example like this, the non-LINQ version has the benefit of doing Select and Distinct in one place rather than separating them.

Go for C# developers: Unicode strings

noreply@blogger.com (cellfish) — Thu, 24 Nov 2022 16:00:00 +0000

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

For example, if you loop over a string using range to get all characters, you will actually only loop over the starting index for each character. Similarly the built in len function will return the number of bytes used in the string and not the number of visible characters.

Here is an example showing how the index variable is "jumping" to each character in the string and how accessing each character in the string using that index is not working as expected.

Go for C# developers: Using keywords as identifiers

noreply@blogger.com (cellfish) — Thu, 08 Sep 2022 14:09:00 +0000

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.

It's a lesser known fact, but the number of reserved keywords in Go are actually not that many. Note how none of the built-in basic types or functions are actually reserved. Those are instead predeclared identifiers. The difference is that while reserved keywords can not be used as identifiers, all the predeclared identifiers can be used as identifiers. That is no different than when you declare a variable with a smaller scope when one is already used in the larger scope.

Reusing variable names in a smaller scope is mostly a bad idea since it is harder to spot bugs where you did not intend to actually use a smaller scope (example), it is very nifty when reusing a name, but having a newly scoped variable makes the code more clear.

Redefining predeclared identifiers in a smaller scope suffers from the same problem of potentially causing confusion, but especially the ability to use variable names as "new" and "copy" without having to worry about prefixing them can certainly make the code more clear.

That being said, there is almost always alternatives that are guaranteed to avoid confusion and I would recommend looking to those first. For example "n" is a pretty good replacement for "new" and "clone" is a pretty good replacement for "copy".

But...

If you're still looking to redefined the predeclared identifiers you can have a lot of fun and not only use them as variable names but also types and function names (these are all identifiers). If your code needs to handle string lights, this is some terrible inspiration on how to do that.

What if I like prefixing like in C#?

Well, the go specification does not let you prefix with "@", but just like in C# you can use unicode in your identifiers so if you really want to name a variable switch, I got some options for you.

Let me know what your colleagues think of your creative use of unicode and variable names!

What is the purpose of a test name?

noreply@blogger.com (cellfish) — Thu, 23 Jun 2022 18:03:00 +0000

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.

At first I started to think about where my passion for test names came from. I started being passionate about test names a long time ago when I was working on a project where most tests were run after code was checked in. And the continuous integration server did not have a nice integration into the code base. Hence it was very costly to open up the IDE and search for a test name to look at the test code figure out what was wrong. Instead well names tests with good failure messages made it possible to quickly understand where the problem was and ask the right person to fix the problem.

Today we have better tools. And this scenario is very different than the scenario described in the article I read which is more about understanding failures as you are writing code. Similar to that author I also tend to use placeholder names while writing tests until I know what the test should really look like. And the final step for me is to give the test a name that signals intent so that future developers (including myself) know what the intent of the test was.

So in digesting that article I have come to realize that I should probably be less passionate about the naming of the tests and just continue to be passionate about what is tested and how failures are reported. Those two things are more important to me as I still consider tests to be the ultimate documentation of what I want to code to do. And as such, the name serves little more value than a summary of intent.

In the end this article also served as a good reminder to myself that in software engineering you should never stop learning.

The social standup

noreply@blogger.com (cellfish) — Thu, 07 Apr 2022 13:04:00 +0000

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

The idea described in the Tech Radar is that when the whole team is remote they lose out on ad-hoc opportunities for discussions. So rather than having a short standup everyday, the team blocks off much more time (up to an hour) so that there is plenty of time blocked off for discussions after the standup is completed. It is also pointed out that it doesn't have to be work related discussions but socialization is important too.

That part reminded me of the remotes standups my team started to have in the beginning of the COVID pandemic when everybody had to work form home. I don't think it was the work related exchange that was the most important but rather that we made a habit of joining early, exchange some jokes or stories and then hang out after the standup when possible. And I think this social aspect of our standups brought the team closer together.

I also remember back in the days when I worked on Xbox and we had a fairly large team doing standups together despite the fact that most of us didn't actually have work that affected each other directly. Hence everybody would spend most time in the standup listening to things most of us didn't care much about. A question was raised if we should split the standup into smaller standups so that we wouldn't waste everybody's time so much. Much to my surprise the team decided to not split the standup since we felt that the minutes of jokes and socialization as we gathered for the standup was worth so much for the team morale compared to the perceived loss of efficiency when everybody had to attend a slightly longer standup (because of how many people we were).

So while the social component in a remote standup really resonates with me - I think we should not forget that it can have a lot of value also in-person.

How to annoy your users featuring Volvo

noreply@blogger.com (cellfish) — Thu, 24 Feb 2022 21:12:00 +0000

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.

Driver specific keys and seat adjustments

There are separate seat adjustments for myself and my wife. Basically I'm taller than my wife and I want zero lumbar support while my wife want plenty of lumbar support. Our personal settings are programmed into separate buttons in the car. We also have our own personal keys that are paired with our respective seat settings.

So every time my wife has used the car and I open the car with my key the seat adjusts to my settings, right? No, maybe half the time the seat adjusts position and the rest of the time I need to push my button in the car. Then the seat adjusts position but not the lumbar support! In order to adjust the lumbar support I need to keep my personalized setting button pressed until the lumbar support adjusts.

How is this a thing? The lumbar support position is obviously programmed into the system but for some reason it does not adjust that automatically the same way the seat position does.

Always turn on music

So if I listened to a podcast on my phone (connected to the car) in my last drive I probably wanna continue listening the next time I get into the car, right? But my phone is not connected when I open the door to the car so what does the car do? Obviously it turns on a random radio station.

So I figured, maybe I should turn off my podcast before turning off the car so it doe snot automatically turn on the radio. I've tried turning my podcasts off several minutes before stopping and turning off the car. Still no success - my car really wants me to listen to the radio.

Service required means replace a fuse

I recently, during cold weather, had some problems with the adjustable suspension on the car. And the next day there was a message from the car telling me I need to service the suspension of the car. Since the adjustable suspension was not working I got an appointment to get it fixed.

Turned out the fuse for the suspension needed to be replaced. I wish the car would tell me a fuse was broken (or indicate no power to the suspension system) rather than suggest I need to service the car.

A coding interview that never happened

noreply@blogger.com (cellfish) — Thu, 10 Feb 2022 09:10:00 +0000

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.

The strategy is simple - solve the problem and write the code the same way you would solve a problem outside an interview. What it means is; if the problem seems too large/complex and you don't know how to solve it, then you need to break the problem down in smaller parts. Similarly when you write your code you should not write a single large function with a solution but rather split the code up in a number of functions that make sense.

Let me use an example to show you what I mean. I have never solved the Tower of Hanoi in any way and when I started thinking about this problem, at first I had no idea to how I would solve the problem. So I started thinking about the simple cases:

If I only need to move one disk - I know how to do that.
If I only need to move two disks - I know how to do that since I can use the extra pin as temporary storage for the first disk until I get the second one in place.

So the second statement made me think that the essence of the algorithm to solve Tower of Hanoi is to move N-1 disks to temporary storage since that will allow me to move N disks do the desired location.

In other words the essence of the algorithm is (pseudo code):

move(n, from, to) {

if (n <= 0) {

return

}

move(n-1, from, temp)

move(1, from, to)

move(n-1, temp, to)

}

At this point I frankly have no idea if there is a corner case where this does not work, but trying the algorithm with three disks also works so let's give it a try...

In an interview setting I would now start implementing the main function and leave any helpers out. Those can be implemented if there is time as needed. When I sat down and actually implemented this I realized a stack would be good to have so I created one. A helper function to figure out the temporary pin would also be nice to have so I added one of those too. I was also very paranoid that my solution would violate the disk size rule so I added a check in my stack to make sure I never put a disk larger than the previous disk in any stack. I was honestly surprised when I could see my implementation working for any number of disks. I really expected there to be some corner case this simple algorithm would not handle. And the resulting code can be found here: https://go.dev/play/p/CLm-oPmyfi5

Bottom line; breaking down the problem into smaller manageable chunks and solve each of those tends to always work. And breaking down your implementation by using helper functions tends to let you keep moving without getting stuck on implementation details.

I realize this advice may seem generic and not helpful, but still I've seen so many candidates over the years that fail because they do not break the problem down and start simple. So this is still my best advice.

Fire and the US insurance system

noreply@blogger.com (cellfish) — Thu, 20 Jan 2022 15:01:00 +0000

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.

Compared to a lot of victims in the fire we were very lucky; we were never in any danger evacuating and since we recently moved into the house we still had a box of all valuables and important documents packed so we could quickly grab those and have not had to deal with replacing various documents.

I have also learned that people in this area are extremely willing to help people in need and I have learned quickly to accept any offers for help. Even small things like not having to cook a meal or a small gift card is helpful to everybody in a situation like this.

An alarming thing however is that there seems to be a disconnect between insurance companies and builders and the expectation is that the majority of home owners are under insured meaning insurance will not cover all the cost to rebuild homes. It will be interesting to see how this plays out and the effect on the community because of this.

So if you live in the US - call your insurance company and make sure you have coverage to rebuild a home - even with recent rapid increase in building costs!

Yet another tale from an interview - 13 years later

noreply@blogger.com (cellfish) — Thu, 30 Dec 2021 19:30:00 +0000

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?

noreply@blogger.com (cellfish) — Wed, 22 Dec 2021 19:22:00 +0000

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.

A new schedule

noreply@blogger.com (cellfish) — Thu, 22 Dec 2016 08:22:00 +0000

For a long time I've made sure that there was something happening here on a regular basis. I've decided regular is no longer going to be the case.

All in on async/await

noreply@blogger.com (cellfish) — Thu, 15 Dec 2016 11:12:00 +0000

While I haven't been coding in C# for about a year now I couldn't resist reading this recent article. A nice write-up where I only want to make two additions.

First I want to make certain you get what I think is the message in the article; if you are using async/await you should go all in as not doing so will have surprising result if you are not ready for them.

Second the author of the article mentions that the overhead of async/await is tiny. But if I remember correctly there are some compiler optimizations that make certain things having even less overhead such as returning completed tasks.

Go for C# developers: functions vs methods

noreply@blogger.com (cellfish) — Thu, 08 Dec 2016 16:12:00 +0000

I must admit that I often use the words function and method interchangeable. Probably because I was once taught that a method is a function that does not return anything. In the Go vocabulary however there is a clear difference and a nice method gotcha!

Another common mistake C# developers do is to talk about class methods in Go. Go people hate this and politely let you know there are no classes in Go. So to all C# developers out there; what "looks" like a class method, that is a function that is defined as being attached to a specific type is in Go called a method. Everything else is a function.

A really fun gotcha with methods in Go is that if you declare your receiver as being by-value then you can create setters that don't change the instance used to call the method. Here is a snippet to demonstrate that. Cut-n-pasting method receiver definitions can definitely lead to bugs if you do not consider your definitions carefully.

Relocation, relocation, relocation

noreply@blogger.com (cellfish) — Thu, 01 Dec 2016 09:12:00 +0000

Looking back at March 2009 there is not much stuff that I still find interesting.

To be honest the relocation stuff is the only stuff that still feels relevant because buying a car is still a pain, getting a driver's license is a joke and cell phone plans are still expensive compared to Sweden. Apart from that code stewardship is probably the only post still worth reading.

Scrum is like riding a bike with training wheels.

noreply@blogger.com (cellfish) — Thu, 24 Nov 2016 08:11:00 +0000

Over the years I've grown to dislike Scrum, mostly because I've seen it abused and misunderstood. And an approach that makes it easy to screw up is not a good approach in my opinion.

And before you put me in the Scrum-haters bucket let me be clear: I think Scrum is a great way to boot-strap a team that wants to be agile. But I do not believe it is the best method out there to get there. All approaches considered without any constraints.

The reason is that Scrum lets you focus on the practice of Scrum without having to think too much about why Scrum tells you to do certain things. This is awesome if you want to get from the dark ages of waterfall into the wonderland of agile, but if you don't get the fact that you need to learn and evolve, then you haven't achieved much I think.

It's like learning to ride a bicycle with training wheels. Every parent I know will tell you that you can have your kid ride around with training wheels for months (or years) without any real progress until you actually take the time and take those training wheels away, give your ~~team~~ kid proper help (coaching) and within hours they can ride the bike properly. Without training wheels.

Scrum is like riding a bike with training wheels. You wont hurt your self, you will definitely get to your destination, but it wont be pretty and it is definitely not riding a bicycle. You need to take those training wheels off and as you do so you need both the will to learn and proper help to get you there.

What triggered me to write this post was this Dark-Scrum post which is an excellent read. Because it helps you to see when those training wheels needs to come off...