Ask HN: How to find intellectually challenging work?
31 comments
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’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.
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.
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.
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".
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?
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.
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)?
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.
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.
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.
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
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.
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.
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.
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/
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.
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
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.
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.
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).
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.
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.
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?)
###
How to loop in a loopless language might be useful for going from "spinning disks" to 'trees' : https://www.youtube.com/watch?v=qzsxO79zxS8
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
After working (mostly) as a backend developer since 2013, I was recently burned (or bored?) out a bit, quit my job and went on a sabbatical for half a year. Now I need to start looking for a new job. However, I'm not sure how to find something that feels more meaningful and intellectually stimulating to me.
I enjoy programming and also maths, but I found most of the jobs I had before not intellectually challenging in the ways that mattered to me. I'm someone who really likes doing deep dives into a topic and thinking carefully about problems and to me it feels as if the industry isn't rewarding that most of the time - instead, you have to work with 20 different technologies, most of which you barely understand and you never get enough time to really become an expert in anything, and requirements are changing so often that designing an overall architecture of your system seems like an exercise in futility (and is often ridiculed, maybe rightfully so given the constraints).
The best job I had was when I worked on a mathematical problem solver for two years. It was something I have never done before or since, it was very challenging (and rewarding), given that it was something very few other people were doing, and I had a great team full of very smart people. Unfortunately, we were all let go in the end. I'm still not sure whether that was just a once in a lifetime opportunity or whether there is a change that I could find something similarly challenging (and off the beaten track).
When I quit, my boss told me that I would maybe be happier in an R&D type of job. I'm just not sure how to find such jobs, given that I don't have a PhD in anything (I merely have a BSc in mathematics and a MA in a totally unrelated field). Another idea of mine would be to look for a job in a typed FP language (like Haskell, Scala, etc.), as I feel that the engineering culture could be a better fit (and I do enjoy type systems and FP languages), but I guess these jobs are also few and far between (I'm also in Europe with no intention to relocate, which might affect the number of open positions significantly).
I'm aware that I'm in a privileged position as a developer, and of course, if push comes to shove I'll just take a "regular" dev job (and maybe work on an attitude adjustment?). But I feel as if I should at least try to see what's out there.
I'm looking for opinions of people who have felt similarly. What did you end up doing?