Ask HN: How to find intellectually challenging work?

I only have a BSc in CS, and I’ve worked with algo-trading, compilers, defi, zero-knowledge crypto, firmware for EVs and drones. And I only relocated once.

I’ve also been unemployed longer than I wanted to twice and had to swallow my pride and work on someone’s legacy to pay the bills. Switching the rockstar mentality with more humility and a sense that I’ve been very lucky was important.

Sounds like you could find a Scala job or a Rust job in your capital. They’re less rare than Haskell jobs.

As for advice: get obsessed, get good at something, don’t wait for people to pay you to excel at the tools you eventually want to master. I toyed around with Haskell for 10 years in my spare time before using it in production.

> I only have a BSc in CS, and I’ve worked with algo-trading, compilers, defi, zero-knowledge crypto, firmware for EVs and drones. And I only relocated once.

Where did you find those jobs?

Cold call, a friend, a friend, a Rust meetup group

Language of choice has nothing to do with it (people responding to look for Haskell shops lol). You need to work at a place that has problems that are deep enough to warrant deep dives.

Speaking from experience, the much reviled FAANGs have ample depth and reward correct solutions.

It is not implied that using Haskell is the only way to find deep problems. The other way around is that shops using a language like Haskell are likely also invested to thinking deeply about problems. So the causality is the other way around.

The recommendation to look for Haskell shops is exactly a heuristic for the thing you recommend:

> "work at a place that has problems that are deep enough to warrant deep dives."

There are many ways to find such places. Filtering by tech stack is one possible way of many to search for signal.

> So the causality is the other way around.

Yes and I'm arguing there's exactly zero causal relationship.

> There are many ways to find such places. Filtering by tech stack is one possible way of many to search for signal.

You're just wrong. Deep problems come with scale and also cost money to solve. Small-medium shops have neither no matter the "tech stack".

I've seen small shops doing, for instance, deep tech work in physics. Their problem is big and their team is small.

Some questions for you:

Would you say every programming language is fungible? If so, then why are there so many? How many should there be?

> deep tech work in physics

And how long did they have funding for to continue doing this work? Is there some part of "it's expensive to do deep work" that you disagree with?

> Would you say every programming language is fungible? If so, then why are there so many? How many should there be?

This is a complete non-sequitur.

If I want to do numerical computing (to solve a problem that needs it), which languages should I consider? Which should I not? Is any language appropriate?

Which languages do you reach for most often (whatever the reason for doing so)?

I still have no clue what you're getting at but the answer is 100% determined by the community you're a part of - the same PDE can be solved by different communities using Fortran/C++/Matlab/Julia/Python.

You're conveniently not addressing the more salient, central point: deep work costs lots of money.

Edit: but no one is solving PDEs using Haskell lol.

My point actually is that different languages suit different purposes with no statement about the cost to fund anything. While there may be many different paths to achieving a result—in this case numerical computing with any of "Fortran/C++/Matlab/Julia/Python"—certain languages are more suited to certain problem domains than others. You, yourself, stated the most popular languages for numerical computing. Most of those would not be suitable for general web development.

Thus languages are neither fungible nor does it seem from the languages you just mentioned (which most would say the same) that there is "zero causal relationship" between a language and solving problems in the domain of interest. In this particular hypothetical, someone would notice a desire to solve deep problems with lots of funding that use numerical computing and could thus look for the languages you mentioned as an initial filter. Such a person would probably not be looking at a javascript role, for instance, given these aims.

Thank you.

> nor does it seem from the languages you just mentioned

Lololol what exactly are the unifying themes of

Fortran, C++, Matlab, Julia, Python

They're all pairwise as different as can be.

Man it's hilarious how delusional some people are to insist on their flawed point despite the loudest clearest contradictions.

You need to start looking for big problems to solve. It was once said by a guy named Bruce Williams who knew what he was talking about that the way to get rich is to solve a problem.

So what you need to do is start looking for big problems. Not big problems that are only seen by developers, but big problems that are seen by the general public. People will pay for solutions. You will be motivated by solutions, something that you need to research the hell out of. Something you need to make connections that no one else has made before to solve. That's it

Fp is not a ticket to interesting job in any ways.

You can’t imagine how abundant are boring projects and products made of scala :)

This is not about language or current hype.

Hard to say with confidence because of very scarce signals, but probably you want to find a job with 2 features: 1. Very early stage of a software 2. Very ambitious software itself (like a new db on a competitive market, new game engine)

Most of the “boring” jobs are not about developing the software per se, but rather about _using_ (wiring up, cobbling up, tuning, integrating) pieces of existing software to shove data around.

That what makes it boring in a nutshell - lack of the aha moment of creating something new.

I'm aware that I'm in a privileged position

Why? You're a 21st century plumber without union protection. Sort out your company's plumbing, then do wtf you want on your own time.

What I meant by that was complaining about boring work is privileged compared to those people who can't find any jobs at all (at least not ones that pay well).

Still, I feel like I should at least try.

Have you read "You don't need to work on hard problems"? I don’t entirely agree with it, and it's more targeted at early-career people, but it might be interesting to read.

https://www.benkuhn.net/hard/

This reminds me of Cameron Zwarich, who created Rosetta 2 and went on to work on something Math related.

Have you looked into shops that use Haskell? I know some trading firms use lispy languages and some game studios (Naughty Dog?) also use them. But I could be wrong.

> I know some trading firms use lispy languages and some game studios (Naughty Dog?) also use them.

Naughty Dog had somewhat famously written Crash Bandicoot and Jak and Daxter using Lisp although they don't appear to use it these days

https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

In the wiki it was mentioned that they started to pick it up again for Last of Us.

Damn I'd love to use it in Emacs. I never had to use Emacs and stopped dreaming about it or vim, but would love to learn it, and the best way to learn it is to be forced to use it for a few weeks.

It would also be interesting to read the code for debugger, linker and compiler.

I was going to recommend you look for a Haskell shop and the saw that user markus_zhang mentioned the same thing in this thread.

I'm actually just starting my own company using Haskell so I can think deeply about what I want while making the product how I want.

That might be a good idea, yeah. My worry is that I haven't really ever used Haskell commercially (I used it a bunch for things like Advent of Code, etc.), so I would have to learn a lot on the job - which I'm willing to do, but companies might look for somebody who's more proficient.

Then I would not recommend starting a company with Haskell as the language.

If you do want to eventually get a role using Haskell (which are rare), it is a good strategy to pick some commercial thing and implement it in Haskell. For instance, do a CRUD app using a postgresql app like Esqueleto/Persistent, Opaleye, etc. Or make a web app with Yesod (or even Scotty or Servant).

It's always said that you should worry about customer needs before even thinking about technology. How do you see that with your company?

In my case, I am already proficient in Haskell, so I do not have to learn it. Using the technology I already know means not blowing my "novelty budget".

As for benefits, I get the following:

- strong, static typing via the Hindley-Milner type system

That means any changes to my logic and type signatures have to be addressed immediately everywhere.

- type-safe, composable everything

I want as many issues as possible to be caught at compile time. Ideally, I would have no runtime errors. It is possible to get close to this ideal with Haskell.

- terse, expressive language

Less code to read per concept expressed plus a strong type system means that maintenance and refactoring is a breeze. In fact, I can fearlessly refactor. That means once I get everything up and running, the codebase is stable even when I change things. Thus, I can actually focus more on the product and customer needs.

Combining all of the above with other stable and maintainable technology choices makes the entire app architecture easy to maintain over time as well.

You always have to consider the technology so you can properly architect your application and its dependencies.

Feel free to reply and we can chat more as I've thought deeply about this topic. Here are some cliff notes though if you want a quick answer (say for calibration).

1. Dod labs and defense contractors are great places to dive into topics pending you are inexpensive. You will likely be paired with other people who can sit and thinking deeply with you. As you progress though, you will be pushed into management, forced to being in money, and pulled many ways preventing your deep thinking. This is when most good scientists leave.

2. Be confident in your job search about what you are looking for. Don't be afraid to say you want 85% deep technical work and 15% reporting to stakeholders. This will be polarizing to a lot of employers but those who want you will quickly scoop you up when u get connected to them.

3. The market is terrible for r and d right now across almost all sectors. Most r and d labs are looking 3-6 months out which means they want people qoth a specific background to build prototypes amd fail quickly. This will be existing scientists in the company but rarely any new hires. i interviewed at Amazon and found this to be the case as an example (I turned down the role).

4. Wait until the market improves but keep looking while doing item 2.

Good luck.

Thanks for the assessment, your point 2 is probably something I'll try to keep in mind.

Try some lean proofs

I already have a project in Lean where I'm developing some complex analysis proofs, but I doubt it'll land me a job (the few job that do seem to exist in that area mostly require a PhD).

Database gotta be it

Wouldn't recommend starting of with a <insert item of interest> standards committee. Do learn way more than ever thought possible / would want to know about <insert item of interest> that people feel are relevant to given standard committee is in charge of.

One approach: Pick something that was at the time 'state of the art' and envision what would constitute 'state of the art' today. 1800's good for steam punk approach. Describe what existed at the time of 'original state of the art' and how that changed to current state of the art aka standards, techniques (black smith to all digital chip/embedded laser scan). Learn quite a bit about how things came to be & underlying abstractions/standards that 'simpify'/'unify' things.

Keep open mind about Alexander Fleming approach to 'bugs' in an experiment. (did that old ME design bug faithfully get replicationed in the software, intentionally or unintentionally?)

###

   ** 1800's telegraph engineer solution to needing multiple telgraph wires vs. current version of usb

   1800's fax : https://www.damninteresting.com/curio/the-fax-machines-of-the-1800s/

###

   ** K&R C vs. Published C standards (iso or otherwise) always fun way to find intersting things to explore (applied to hardware or not hardware applied). 

   ** RFC's bit less 'wordy'.

###

   ** awk progam(s) to use/interpret BNF in real time to provide "modern" constructs for awk programming. (or impliment way to read/interpret lambda expressions in awk to extend awk)

   ** ( as a learning tool/approach a scaled/toy awk scripted version of dbos )

   dbos :  https://www.google.com/search?client=firefox-b-1-d&q=dbos

###

   ** Nipkow mechanical tv 1920's vs. python/pi implimentation! (or Philo Farnsworth's take)

   mechanical tv : https://www.youtube.com/watch?v=R-wbfP1pmVw

   Farnsworth : https://en.wikipedia.org/wiki/Philo_Farnsworth

###

   ** foucault's measurements vs. LIGO vs. Fizeau Apparatus
   
   https://en.wikipedia.org/wiki/Foucault%27s_measurements_of_the_speed_of_light

   measuring speed of light : https://www.youtube.com/watch?v=R-wbfP1pmVw

   LIGO : https://en.wikipedia.org/wiki/LIGO

   Fizeau Apparatus : https://www.youtube.com/watch?v=YMO9uUsjXaI

###

   ** MUMPS vs. current 'concurrent' databases (postgres).

   MUMPS : https://en.wikipedia.org/wiki/MUMPS

###

How to loop in a loopless language might be useful for going from "spinning disks" to 'trees' : https://www.youtube.com/watch?v=qzsxO79zxS8