Live data from Hacker News

Work on interesting problems. Not interesting tech

ruky.me

1–10 of 97 posts

Re: Work on interesting problems. Not interesting tech

#2
I think many people are "interested" in novelty.

https://www.lehmiller.com/blog/2017/4/28/why-we-crave-sexual...

There is "interesting", "novel" and "not understood" which are related but not the same thing.

In projects I think one should budget novelty. If you understand the domain (understand the problem) then it is not so risky to use a framework, languages, etc. that you don't understand.

If you are unfamiliar with everything, however, you have a tough slope to climb. Sometimes you have to do it. To work with ISO Common Logic you almost certainly have to use Haskell. If you want to code for Arduino you're going to have to work with C or a similar low-level language. But if you can have a choice at all you don't want to use new tools for a new problem.

Re: Work on interesting problems. Not interesting tech

#4
That’s my thought every time someone creates yet-another HN reader. Sure, you were interested mostly in the stack you’re learning. But there are endless opportunities with similar scope where you might end up creating something actually useful.

For inspiration, Wikipedia is rich reservoir of repetitive tasks to fix minor issues that would be easier with a task-specific GUI for review.

Re: Work on interesting problems. Not interesting tech

#5
There are downsides to this. The early parts of my resume read like a list of major software project disasters of the 1990s. Among other things, I worked on Taligent OS and WorkplaceOS. (Never heard of them? That's my point.)

As a result of chasing interesting problems (and a stint as a university sysadmin), my salary history led me to be significantly underpaid for most of my career.

Re: Work on interesting problems. Not interesting tech

#6

... but if you can't work on an interesting problem (where you get a cut of the revenue to solve it) then please, make sure to work on the best possible tech stack, ie, the one the company you want to jump ship to already uses.

The author makes it sound as if "interesting" tech only exists for the sake of being interesting, but interesting tech becomes interesting because it (purports to be) a better way of solving problems than whatever the old way was. I'm old enough to have worked on Cobol at one point, and Cobol is "boring" but it's also bad, because it was designed around the constraints that existed at the time it was created (as was Java). If you're interested in something that doesn't seem like a step forward in usefulness, I wonder why you'd actually be interested in it to begin with.

Re: Work on interesting problems. Not interesting tech

#7
Want to work on interesting problems? Build software for doctors' offices and medical groups! Help lawyers crawl out of their low-tech hole! Work on software to revolutionize public classrooms! Why work on interesting tech when you could throw yourself at intractable problems that we never get any closer to solving?

Re: Work on interesting problems. Not interesting tech

#9

... but if you can't work on an interesting problem (where you get a cut of the revenue to solve it) then please, make sure to work on the best possible tech stack, ie, the one the company you want to jump ship to already uses.

The author makes it sound as if "interesting" tech only exists for the sake of being interesting, but interesting tech becomes interesting because it (purports to be) a better way of solving problems than whatever the old way was. I'm old enough to have worked on Cobol at one point, and Cobol is "boring" but it's also bad, because it was designed around the constraints that existed at the time it was created (as was…

> but interesting tech becomes interesting because it (purports to be) a better way of solving problems than whatever the old way was.

You would think so, but this is wrong for the same reason that "the most popular product is probably the best product" is wrong.

Quality doesn't determine who wins. It's a factor but not the factor. In the case of programming languages in particular, tribalism, new-and-shiny syndrome, and marketing are all probably more important.

Post reply on HN