Quite a few forum members work in the tech sector, and I was wondering if those of you who do feel that there is any relationship between your go and your work skills. Here are a few things I'm curious about:

Do good go players make good techies and vice versa?
Do you enjoy your work as much as you enjoy playing go?
What sort of similarities/differences are there between improving your tech skills and improving your go skills?

_________________
Patience, grasshopper.

I've been trying to spread Go around the office, but so far one guy out of about 6 seems to be learning well. Incidentally, he's the only one who seems to have sustained some interest. Coincidence?



I do, but for completely different reasons. I find my job is about 30% about tech and 70% about people. I love working with individuals, and sometimes I have wonderful conversations while I work away at the tech. It's the exception rather than the rule, but it's great when I can make it happen.



They're entirely different, I feel. Go is about applying certain techniques and concepts. Tech support isn't very deep. It's not programming, it's not building hardware, it's not about networks and security. Sure I keep learning more about our products and how to deal with different issues that arise, but it still works like a flowchart rather than deep analysis followed by implementing creative strategies.

Go is much better for the brain, I feel. Having great conversations while playing Go is the ultimate.

I work as an analyst and soon-to-be software engineer. In go there are two types of analysis: reading and judgement. When I'm analysing, I use reading skills to manipulate data. I use judgement to evaluate the data to give information to the people who make the decisions.

I also think go players need to be quite fanatical and competitive, but also artistic.

It plays on both sides of the brain.

_________________
12k: 2015.08.11; 11k: 2015.09.13; 10k: 2015.09.27; 9k: 2015.10.10; 8k: 2015.11.08; 7k: 2016.07.10 6k: 2016.07.24 5k: 2018.05.14 4k: 2018.09.03 3k: who knows?

I have a particularly varied background with technology. I have done front-line consumer support, front-line managed services support (consumer support = millions of consumer-level customers, managed services = one or a few corporate customers), product line maintenance and support (a combination of 3rd-level support and software patching work, among other varied tasks), and now feature design.

All of these require similar, but varied, skill sets. I suspect that my approach to go is coloured by a similar skill set as well.

A common theme in my various positions is patterns. From patterns of consumer use, to expected software functions, to design patterns, to algorithms. One skill that I've used and honed in my work is the ability to apply patterns to various situations and analyze the result. In tech support, recognizing a pattern of symptoms, either described by an end user or in lab testing, can lead towards a favorable path to resolution. Funny how that sounds a bit like learning some of the patterns in go, eh?

It's interesting to note that I see some of the same degree of variability in technical support that I do in go. In some cases you may have two different situations where the same pattern can help resolve things, and the key is to make the connection between them. In other cases, two situations may seem incredibly similar, but the underlying solution to each situation may be wildly different from each other.

Perhaps I simply treat tech support (and tech work in general) as a great problem solving game.

I suspect the strongest correlation is just that becoming good at either requires you to devote a lot of time to something very arcane and abstract. If you can get excited about cache misses you've probably got the potential to become excited about aji keshi. If you don't have an interest in one, though, you're probably not going to be very good.


No, but if I was playing go 8 hours a day and scraping together time to write nlp software, I'd feel the opposite.


In both cases it seems to be largely a matter of seeing something went wrong and reflecting on how this problem could have been avoided. In both cases I had to learned to think more and more up front before committing anything to the board or code. Most of my tech improvement these days is learning various arcane topics (how some arbitrary library works, say), while Go is mostly improving reading/positional awareness. That said, I'm a much stronger programmer than a go player, so maybe I'll feel similarly as a high dan Go player.

One thing I try to improve on is that both my task-estimating in a project at work and my score-estimating in a Go game tend to be off by a factor of 10.

One of my co-workers is a mid-level dan player. I'm always surprised when he seems to fail to see the bigger picture at work, focusing instead only on his team's local situation.

I would have thought his Go would have given him a little better perspective in his Tech life.

(or maybe I'm still missing something with my weaker Go skills)

The team feels like about the scope as the board. Company-wide thinking seems like something larger than exists in Go.

Alternatively, in some companies hyper-focusing on your team is actually a wider view than focusing on the company as a whole. That behavior is often one that's rewarded =).