Work on interesting problems. Not interesting tech(ruky.me)
ruky.me
Work on interesting problems. Not interesting tech
https://ruky.me/2021/09/10/work-on-interesting-problems-not-interesting-technologies/
96 comments
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?
I was talking to my physio today (doing fine thanks for asking), and she was fed up about having to prove that a client had not paid her - manually matching payments into her bank account with appointments etc. It wasted an hour of her time or more.
Now the heart of that is 5 lines of python. It could be written by anyone after a days "starting from zero" coding experience.
But actually solving that in real world is a mess of just trying to access the data - it's her data and she only wants to see her bits. But the level of effort is ridiculous.
Anyway my point is that solving problems like software for doctor's offices is not the point - that's just building another silo. A doctor who has (secure) access to a industry wide common open data layer can do all the work to run their office themselves.
In short we are trying to solve the wrong problem - usually because proprietary code is not a profitable as proprietary data
Now the heart of that is 5 lines of python. It could be written by anyone after a days "starting from zero" coding experience.
But actually solving that in real world is a mess of just trying to access the data - it's her data and she only wants to see her bits. But the level of effort is ridiculous.
Anyway my point is that solving problems like software for doctor's offices is not the point - that's just building another silo. A doctor who has (secure) access to a industry wide common open data layer can do all the work to run their office themselves.
In short we are trying to solve the wrong problem - usually because proprietary code is not a profitable as proprietary data
Sounds like she just needs to sign up for something like Square where your customers set an appointment, order services and pay and invoice. They can even be asked to pay before hand.
Square is not the only player doing service appointment payments.
Square is not the only player doing service appointment payments.
That's very much not my point. What you are describing is the square development team taking their representation of a client, an invoice, a payment event and so on, and then they guess a feature like match up invoices and develop it and write a gui and hide it somewhere and...
But we (society) should have a standard representation of a calendar event, standard access to bank accounts and so on so that all she needs to go is write five lines
Once the data is free we won't need proprietary co e
But we (society) should have a standard representation of a calendar event, standard access to bank accounts and so on so that all she needs to go is write five lines
Once the data is free we won't need proprietary co e
The reason that people don't do the "obvious" thing is rarely that they're ignorant or stupid. Best not to assume that you know all the relevant context.
Why do you assume this is the obvious thing? Maybe you shouldn't assume till you know all the relevant context?
I have a brick and mortar small business that takes appointments, have monthly recurring services and did not use Square appointments. We did everything manually to handle calendar appointments, invoice, charging for payments. Found out after a few months the time is not worth the savings and rather just get a service like Square. I thought maybe his client was the same and was trying to help.
But hey maybe Square was very obvious for your brick and mortar service based business and I'm one of the few "ignorant and stupid one".
I have a brick and mortar small business that takes appointments, have monthly recurring services and did not use Square appointments. We did everything manually to handle calendar appointments, invoice, charging for payments. Found out after a few months the time is not worth the savings and rather just get a service like Square. I thought maybe his client was the same and was trying to help.
But hey maybe Square was very obvious for your brick and mortar service based business and I'm one of the few "ignorant and stupid one".
> usually because proprietary code is not a[s] profitable as proprietary data
Bingo. This is why Google et al. would never sell your data; they just keep it for themselves and merely sell to advertisers the ability to precisely target you (“pick a demographic down to the shampoo brand and we can target your ads to it”). But those advertisers (or anyone else) will never see a single iota of your data. It’s simply too valuable.
Bingo. This is why Google et al. would never sell your data; they just keep it for themselves and merely sell to advertisers the ability to precisely target you (“pick a demographic down to the shampoo brand and we can target your ads to it”). But those advertisers (or anyone else) will never see a single iota of your data. It’s simply too valuable.
In a weird kafkaesque way this makes me feel better about my data.
Now when you click an ad, the advertiser knows which shampoo brand you use.
Next, when you click an ad, the advertiser knows which medical problems you have (because that's where they targeted their ad at).
Google has a data leak, and nobody seems to care about it.
Next, when you click an ad, the advertiser knows which medical problems you have (because that's where they targeted their ad at).
Google has a data leak, and nobody seems to care about it.
Luckily I haven't clicked an ad in a decade!
Easy. Don’t click ads.
And beyond that, block them ruthlessly without a second thought
Man, I sure am glad Curtis and the Wright brothers didn't take this stance after Lord Kelvin claimed "Heavier-than-air flying machines are impossible" before they proved him wrong less than 20 years later.
Or NASA when Lee Deforest claimed flight to the moon was impossible "regardless of all future advances."
Or when Einstein claimed ""There is not the slightest indication that nuclear energy will ever be obtainable."
Etc. etc.
Or NASA when Lee Deforest claimed flight to the moon was impossible "regardless of all future advances."
Or when Einstein claimed ""There is not the slightest indication that nuclear energy will ever be obtainable."
Etc. etc.
> when Einstein claimed ""There is not the slightest indication that nuclear energy will ever be obtainable."
Not to be pedantic, but was Einstein incorrect at that time/in the future? Were there any actual indications that nuclear energy would be obtainable at that time?
Einstein didn't seem to say, "Obtaining nuclear energy is absolutely impossible, and can never be achieved." All he said was that there is not the _slightest indication_.
I am sorry if this comes off as being semantical, but I just want to make sure I am not misinterpreting you or what Einstein said.
As for the other points, yes. Those were great examples.
Not to be pedantic, but was Einstein incorrect at that time/in the future? Were there any actual indications that nuclear energy would be obtainable at that time?
Einstein didn't seem to say, "Obtaining nuclear energy is absolutely impossible, and can never be achieved." All he said was that there is not the _slightest indication_.
I am sorry if this comes off as being semantical, but I just want to make sure I am not misinterpreting you or what Einstein said.
As for the other points, yes. Those were great examples.
Ok, so libquote says this was stated at 1934, what is after the discovery of Uranium fission and that it emits neutrons that could start further fissions.
The quote is of course completely out of context, and looks a lot like something one throws at annoyingly overeagle people. Also, I imagine the context for saying it only existed because nuclear fission seemed perfectly plausible and just over the horizon. It was technically correct, nobody could imagine a Manhattan Project at that time, and it wasn't obvious that it was even possible, but there was a clear possibility.
The quote is of course completely out of context, and looks a lot like something one throws at annoyingly overeagle people. Also, I imagine the context for saying it only existed because nuclear fission seemed perfectly plausible and just over the horizon. It was technically correct, nobody could imagine a Manhattan Project at that time, and it wasn't obvious that it was even possible, but there was a clear possibility.
>nobody could imagine a Manhattan Project at that time, and it wasn't obvious that it was even possible, but there was a clear possibility.
That’s exactly the point. And yet the Manhattan project was less than a decade away.
Lord Kelvin said his quote in 1895. Deforest said his in 1926. In the myopic timeframe they were all technically correct.*
The GP stated that all those other problems were “obviously” intractable, but whose to say they won’t be solved under some ambitious effort in the next 20 years?
*Aside: All three examples come from the same place in terms of being plausible in the timeframe they were made yet wrong in hindsight. I wonder if people are more fiercely defending the Einstein quote because he’s more revered in popular culture. It’s interesting that his quote is the only one being defended.
That’s exactly the point. And yet the Manhattan project was less than a decade away.
Lord Kelvin said his quote in 1895. Deforest said his in 1926. In the myopic timeframe they were all technically correct.*
The GP stated that all those other problems were “obviously” intractable, but whose to say they won’t be solved under some ambitious effort in the next 20 years?
*Aside: All three examples come from the same place in terms of being plausible in the timeframe they were made yet wrong in hindsight. I wonder if people are more fiercely defending the Einstein quote because he’s more revered in popular culture. It’s interesting that his quote is the only one being defended.
Oh, your comment is spot on.
I guess my point is only that all those famous quotes probably just meant "shut-up and give me some space, journalist, I have some immediately pressing problems to solve", and probably nobody undesrtood them as anything else at the time too.
Anyway, my favorite of those is the Michelson's famous "physics is complete" one, that basically meant "let me do the experiment first, then we can talk about the results", but is excellent out of context.
I guess my point is only that all those famous quotes probably just meant "shut-up and give me some space, journalist, I have some immediately pressing problems to solve", and probably nobody undesrtood them as anything else at the time too.
Anyway, my favorite of those is the Michelson's famous "physics is complete" one, that basically meant "let me do the experiment first, then we can talk about the results", but is excellent out of context.
I assume this statement was made not long after Einstein discovered the equivalence between mass and energy, so it's understandable it may not have been obvious at the time that we could generate power that way.
I guess it's hard to tell without over-parsing his words, but you bring up an important distinction.
It may be fair to read it as a scientist essentially saying "we have no evidence it's possible." But as I read it, the addition of "ever" came across as saying he thought it was an unsolvable problem rather than one that had yet to come upon a solution.
It may be fair to read it as a scientist essentially saying "we have no evidence it's possible." But as I read it, the addition of "ever" came across as saying he thought it was an unsolvable problem rather than one that had yet to come upon a solution.
The Wright brothers didn't get off the ground by gluing wings to their arms, and Einstein didn't discover the theory of relativity in his study of alchemy. Entertaining silly or stupid ideas is risky, and for every Wright brother there's another 100 failed entrepreneurs who lost everything trying to make that dream a reality.
Case in point: Lilienthal, who wrote the aerodynamics book that inspired much of the wing building of the Wrights, died when he crashed with one of his gliders.
Amazing book by the way, there was a cheap reprint published a few years ago.
Amazing book by the way, there was a cheap reprint published a few years ago.
That comes across as straw manning. The point is that all kinds of problems are seen as intractable to the cynic, not that every optimist has the correct approach to solve the problem.
It’s easy and weak to just throw up ones hands and say it’s too hard but I don’t want to live in a society where 100% of people take that approach.
It’s easy and weak to just throw up ones hands and say it’s too hard but I don’t want to live in a society where 100% of people take that approach.
And many times, better solution is not to use software at all. People don't need to leave Excel or Wordpress at all. I don't even think using paper is a problem. They have pros and cons. "solution looking for problems" is actually accurate, ironically.
Most people in software seem to create interesting technology that sells ads, so your sarcastic examples sound a lot better to me.
I'm currently building a company that is replacing Excel at some of the biggest commercial real estate firms, which is "impossible" by your standards.
I'm currently building a company that is replacing Excel at some of the biggest commercial real estate firms, which is "impossible" by your standards.
Honestly curious, why is it better for them then Excel? What is the value proposition? Thanks.
Indeed, there's lots of great problems to solve in this space.
If anyone is interested I recorded a 90 minute podcast with a lead developer + ops engineer who created a custom electronic medical record system for an Ophthalmology clinic (eye care).
It's at: https://runninginproduction.com/podcast/99-a-custom-electron...
We talked all about using Rails to help consolidate 9 separate 3rd party solutions into a monolithic server rendered Rails app that the clinic uses internally to manage all of their patients. We also chatted about transitioning from Elastic Beanstalk to self managed EC2 instances to using Kubernetes with EKS.
If anyone is interested I recorded a 90 minute podcast with a lead developer + ops engineer who created a custom electronic medical record system for an Ophthalmology clinic (eye care).
It's at: https://runninginproduction.com/podcast/99-a-custom-electron...
We talked all about using Rails to help consolidate 9 separate 3rd party solutions into a monolithic server rendered Rails app that the clinic uses internally to manage all of their patients. We also chatted about transitioning from Elastic Beanstalk to self managed EC2 instances to using Kubernetes with EKS.
We're doing this kind of thing in banking right now. Would like to attack medical and insurance next.
I think with lawyers, the problem is basically GUIs. Because most computer users, even very high-skilled computer users like lawyers, are used to consuming software in the form of GUIs, you tend to get these kind of all-encompassing WYSIWYG programs like Word, with mysterious internals, and an endless labyrinth of useful tricks that lawyers tend to know, which are in one way amazing, but in another way essentially limited by the imaginations of the programmers, because they're monolithic and basically inflexible.
This is basically an education / culture problem. I'm sure in two hundred years, people will recognize that 'sort' or 'uniq' is really elemental functionality like a saw or a hammer, and baking it all into one giant saw-hammer-sanding machine that's really only good for making tables, and occasionally eats your cat, is just not the way to go. Until that point, I don't think that some plucky new startup is going to magic away all the problems. I mean, obviously there are some crazy low-hanging fruit out there, but the fundamental issue starts with how people are using computers in the first place.
This is basically an education / culture problem. I'm sure in two hundred years, people will recognize that 'sort' or 'uniq' is really elemental functionality like a saw or a hammer, and baking it all into one giant saw-hammer-sanding machine that's really only good for making tables, and occasionally eats your cat, is just not the way to go. Until that point, I don't think that some plucky new startup is going to magic away all the problems. I mean, obviously there are some crazy low-hanging fruit out there, but the fundamental issue starts with how people are using computers in the first place.
What a defeatist mindset lol
> Build software for doctors' offices and medical groups!
Please please please go into these areas with humility. Having worked for health tech companies in SF for a decade, I've seen so many people come from Google/Facebook/Mozilla/Ticketmaster/eBay to healthcare in order to "disrupt" and "fix" it. Their disruption or fixes are many times illegal, impractical, vaporware, or completely ignore industry standards and so can't speak the same language as all the other tools in the ecosystem. It generally doesn't end well if you don't deeply partner with stakeholders and domain experts.
Please please please go into these areas with humility. Having worked for health tech companies in SF for a decade, I've seen so many people come from Google/Facebook/Mozilla/Ticketmaster/eBay to healthcare in order to "disrupt" and "fix" it. Their disruption or fixes are many times illegal, impractical, vaporware, or completely ignore industry standards and so can't speak the same language as all the other tools in the ecosystem. It generally doesn't end well if you don't deeply partner with stakeholders and domain experts.
The above x100. Technology isn't a cheat code for a hard problem, it's just another tool. When we assume that tech fixes everything with no further research, everyone gets a lot worse off.
This is why I keep emphasising on "domain knowledge". As an engineer my domain knowledge is zero when I wade into a new problem space.
A good way to approach is to partner with a domain expert to understand the following aspects.
Also, at the end of the day automation is making someone (or part of someone) redundant. Make sure you identify that person and be subtle about your messaging to them.
All of this takes time so in olden days there used to be a role called "system analysts". Their job was to go deep into the problem domain, untangle all the above for you and help you define product. These analysts are typically ex-workers in the same domain so they have seen everything first hand. Given the nature of their job their role is not fungible in that you can't take one person and make them move around to be system analyst in different domains. Somewhere along the way system analyst role disappeared and they were replaced by fungible "product managers". These PMs have a generic set of product development skills such as UX, user retention optimisation etc., But they lack the domain knowledge. And they are expected to be fungible. If a PM changes job once every 3 years into a different domain they can at best do a superficial job.
Of the top of my head here are two examples.
There's this software called Docon (https://docon.co.in) used by small-setup medical doctors and physicians. The value add for doctors is very clear. It saves them time and all the hassle. What is good about Docon is it requires zero actions by the patient or any one else. So Doctors are happy to be using it. It is a nifty little tool to automate key parts of doctors' workflow.
Now let me talk about JIRA. It is mainly targeted towards management and execs. Because, let's face it, they have a genuine problem of not having clear view into project development state. They can't see how their quarterly projects are shaping up at different zoom levels. To that end I would say JIRA does a reasonably good job. Where JIRA fails spectacularly is it requires leaf level works to massively disrupt their workflow. Not only does it require them to use JIRA for daily updates and what not it also forces a way of agile development which comes with its own set of baggages.
A good way to approach is to partner with a domain expert to understand the following aspects.
1. Know about various stake holders that make up a business process. Understand each of their incentives. Some actors standout explicitly but some do not, such as regulators.
2. The value add by different player/stake holder in the chain.
3. Location of power centres. No one will explicitly call it out but you will be able to figure it out.
Also, at the end of the day automation is making someone (or part of someone) redundant. Make sure you identify that person and be subtle about your messaging to them.
All of this takes time so in olden days there used to be a role called "system analysts". Their job was to go deep into the problem domain, untangle all the above for you and help you define product. These analysts are typically ex-workers in the same domain so they have seen everything first hand. Given the nature of their job their role is not fungible in that you can't take one person and make them move around to be system analyst in different domains. Somewhere along the way system analyst role disappeared and they were replaced by fungible "product managers". These PMs have a generic set of product development skills such as UX, user retention optimisation etc., But they lack the domain knowledge. And they are expected to be fungible. If a PM changes job once every 3 years into a different domain they can at best do a superficial job.
Of the top of my head here are two examples.
There's this software called Docon (https://docon.co.in) used by small-setup medical doctors and physicians. The value add for doctors is very clear. It saves them time and all the hassle. What is good about Docon is it requires zero actions by the patient or any one else. So Doctors are happy to be using it. It is a nifty little tool to automate key parts of doctors' workflow.
Now let me talk about JIRA. It is mainly targeted towards management and execs. Because, let's face it, they have a genuine problem of not having clear view into project development state. They can't see how their quarterly projects are shaping up at different zoom levels. To that end I would say JIRA does a reasonably good job. Where JIRA fails spectacularly is it requires leaf level works to massively disrupt their workflow. Not only does it require them to use JIRA for daily updates and what not it also forces a way of agile development which comes with its own set of baggages.
Exactly this. I've seen it personally repeatedly.
Can you give some examples for illegal stuff?
Theranos, uBiome, and Practice Fusion all have well known scandals. I'm aware of other issues at some other health tech startups surrounding misrepresenting their impact on quality of care, building biased algorithms that have a discriminatory impact on care delivery, companies looking at questionable payment models that seem like they'd violate stark laws, straight up medicare fraud, etc. I'll just say that I'm skeptical of health tech companies that claim/suggest any impact on a medical condition, that claim to have a predictive algorithm related to a medical condition that's their core product, or that somehow give free things to providers.
To be fair I'd take that list and expand it to include the big pharmaceutical companies (see the new Alzheimers drug scandal at the FDA, billions spent on next generation statins that proved ineffective by confusing correlation and causation, etc), to include doctors and surgeons and various surgical practices or novel medical treatments (billions spent on full Meniscectomies that just lead to arthritis after years, pointless heart stints, etc).
True many startups in health are trying scammy payment models, but hospital bills often aren't much better unfortunately.
Personally my life has been positively improved by 23andme when they could still list health research, or by "zany" microbiome/probiotics startups years before the medical establishment caught up. Obviously these fields should be regulated, but properly so without just providing an excuse for regulatory capture for existing players.
0: https://www.nytimes.com/2021/07/19/health/alzheimers-drug-ad... 1: https://www.crossfit.com/health/the-great-statin-scam-time-t... 2: https://www.vox.com/the-big-idea/2017/12/28/16823266/medical... 3: https://www.theatlantic.com/health/archive/2017/02/when-evid...
True many startups in health are trying scammy payment models, but hospital bills often aren't much better unfortunately.
Personally my life has been positively improved by 23andme when they could still list health research, or by "zany" microbiome/probiotics startups years before the medical establishment caught up. Obviously these fields should be regulated, but properly so without just providing an excuse for regulatory capture for existing players.
0: https://www.nytimes.com/2021/07/19/health/alzheimers-drug-ad... 1: https://www.crossfit.com/health/the-great-statin-scam-time-t... 2: https://www.vox.com/the-big-idea/2017/12/28/16823266/medical... 3: https://www.theatlantic.com/health/archive/2017/02/when-evid...
Not following applicable standards like IEC 62304, 60601, etc.
https://en.m.wikipedia.org/wiki/IEC_62304
https://en.m.wikipedia.org/wiki/IEC_60601
https://en.m.wikipedia.org/wiki/IEC_62304
https://en.m.wikipedia.org/wiki/IEC_60601
Better bring a FAX machine..
This comment exemplifies my point.
Faxes are common in healthcare, and it's a common punch line from newcomers. But there's a series of standards that have been iterated on since the late 80s/early 90s that are finally getting to a place where they can eliminate faxes. There's standards for how to transmit data between EHRs, standards for how to store and represent data, and a standard API for 3rd parties to be able to write/read that data.
Regardless of these standards, you can already share data between hospitals using the same EHR -- so epic-to-epic (epic is the largest EHR vendor in the US) data sharing has been happening for a decade without any faxes. Unfortunately, there's a ton of different players in this game, so getting to a place where everyone has adopted the standards takes a long time, and the system still needs to keep running while this switch happens. To be clear, this is a common problem throughout tech: is it possible to run a native android app on iPhone? Do you think Google and Apple will ever make it possible to do that?
I can think of at least one medical company that builds their own technology and managed to paint themselves into a corner by not working from within the system. They just hire a bunch of engineers, who hear about how faxes run healthcare, so they say "cool, I can digitize the faxes" without bothering to consider or learn about other standards that are being developed. This leads to proprietary data models, with proprietary data representation, all transmitted using outdated technology. The engineers quit and go back to non-health tech, and tell their friends that health tech is so frustrating because it's so dated (make sure to bring your fax machine when you start your new job!).
But, really, the problem was never faxes. The problem is that healthcare is way more complicated, with way more stakeholders than consumer tech. You can't just launch a new product and iterate on the bugs later; people's lives are at stake, so the whole industry is heavily regulated. But if you enter with humility, recognizing that there is too much information for one person to know, but know that your skills are welcomed and needed. Take time to learn about things like HL7, FHIR, and clinical ontologies. And partner-- not just a quick knowledge sharing session-- actually partner with the domain experts, then there's a whole world of fascinating possibility out there.
Faxes are common in healthcare, and it's a common punch line from newcomers. But there's a series of standards that have been iterated on since the late 80s/early 90s that are finally getting to a place where they can eliminate faxes. There's standards for how to transmit data between EHRs, standards for how to store and represent data, and a standard API for 3rd parties to be able to write/read that data.
Regardless of these standards, you can already share data between hospitals using the same EHR -- so epic-to-epic (epic is the largest EHR vendor in the US) data sharing has been happening for a decade without any faxes. Unfortunately, there's a ton of different players in this game, so getting to a place where everyone has adopted the standards takes a long time, and the system still needs to keep running while this switch happens. To be clear, this is a common problem throughout tech: is it possible to run a native android app on iPhone? Do you think Google and Apple will ever make it possible to do that?
I can think of at least one medical company that builds their own technology and managed to paint themselves into a corner by not working from within the system. They just hire a bunch of engineers, who hear about how faxes run healthcare, so they say "cool, I can digitize the faxes" without bothering to consider or learn about other standards that are being developed. This leads to proprietary data models, with proprietary data representation, all transmitted using outdated technology. The engineers quit and go back to non-health tech, and tell their friends that health tech is so frustrating because it's so dated (make sure to bring your fax machine when you start your new job!).
But, really, the problem was never faxes. The problem is that healthcare is way more complicated, with way more stakeholders than consumer tech. You can't just launch a new product and iterate on the bugs later; people's lives are at stake, so the whole industry is heavily regulated. But if you enter with humility, recognizing that there is too much information for one person to know, but know that your skills are welcomed and needed. Take time to learn about things like HL7, FHIR, and clinical ontologies. And partner-- not just a quick knowledge sharing session-- actually partner with the domain experts, then there's a whole world of fascinating possibility out there.
I heard some woman with a fake deep voice is on trial now.
I haven't been following that situation, I'm too focused on getting my insurance company to pay to sequence my poop.
> insurance company to pay to sequence my poop.
What's that about?
What's that about?
uBiome— you’d send fecal samples to them and they’d sequence and tell you what bacteria you have. They claimed to have clinical value and started billing insurance, before eventually being raided and shut down for something along the lines of insurance fraud.
Aha, such odd behavior by them
The problem is that advertising or finance companies can outbid public classrooms and students 10000:1. It's the sad reality: in the current system finding ever more sophisticated ways to get people to buy more crap is very profitable, helping underprivileged students succeed is not.
If you seriously want to target classrooms (selling to the education sector is hard), target elite schools rather than poor public classrooms with underprivileged students. This way, at least potentially money could be made.
Hippa compliance...
Development is a nightmare
Development is a nightmare
HIPAA isn’t really that bad. If you’re following normal good security practices at your company you’re probably at the point where becoming complaint is more about implementing a bunch of small mostly meaningless changes to your infra and documenting stuff than some fundamental change to your architecture.
Thankfully we only have to worry about HIPAA.
Those are the types of problems which I describe as "solving the problem is half the problem". Anyone can easily write the fixes to these sorts of problems. They don't because the real complication isn't the surface level obstacle.
The parent comment does not actually define any specific problem.
"Build software for doctors' offices and medical groups!"
A problem that needs to be solved is _____________?
"Help lawyers crawl out of their low-tech holes!"
A problem that needs to be solved is _____________?
"Work on software to revolutionise public classrooms!"
A problem that needs to be solved is _____________?
Let us know when can provide even a single answer to any of these questions.
As other commenters point out, answering them means actually talking the people who will be using the software, or working in their shoes in these industries, before anyone starts programming anything.
"Build software for doctors' offices and medical groups!"
A problem that needs to be solved is _____________?
"Help lawyers crawl out of their low-tech holes!"
A problem that needs to be solved is _____________?
"Work on software to revolutionise public classrooms!"
A problem that needs to be solved is _____________?
Let us know when can provide even a single answer to any of these questions.
As other commenters point out, answering them means actually talking the people who will be using the software, or working in their shoes in these industries, before anyone starts programming anything.
Those are a set of questions with many answers - each answer might be a totally different business. If there was only one answer then all the software would be written already.
Why? Because I don’t give a damn I’m just here to write code and make piles of money and interesting tech makes it less dull.
Interesting definition of "interesting" you're using there.
I don't think he was necessarily saying that you should sacrifice yourself to your own idea of the pointless "greater noble good".
Build a stamp database, an app to record baseball cards, automatically conjugate latin verbs, make a recipe database that can give you a list of what can be made with a given set of ingredients, make a 3d anatomical viewer based on the BodyPart3D database, make a catalog of open source projects for a given combination of JavaScript technologies, make a periodic table that shows the 3D orbital structure of the atom involved, calculate and visualise knitting patterns, simulate an H-Bomb or global thermonuclear war...
Do it in Golang, write it in Rust or Haskell or PHP, or with a shell script if you have to...
Run it on baremetal, on a VM, in a unikernel, deploy it in a k8s cluster, or nomad, or docker-compose or host it on a microcontroller if that fits...
But for a change focus on the problem and not the tools.
I don't think he was necessarily saying that you should sacrifice yourself to your own idea of the pointless "greater noble good".
Build a stamp database, an app to record baseball cards, automatically conjugate latin verbs, make a recipe database that can give you a list of what can be made with a given set of ingredients, make a 3d anatomical viewer based on the BodyPart3D database, make a catalog of open source projects for a given combination of JavaScript technologies, make a periodic table that shows the 3D orbital structure of the atom involved, calculate and visualise knitting patterns, simulate an H-Bomb or global thermonuclear war...
Do it in Golang, write it in Rust or Haskell or PHP, or with a shell script if you have to...
Run it on baremetal, on a VM, in a unikernel, deploy it in a k8s cluster, or nomad, or docker-compose or host it on a microcontroller if that fits...
But for a change focus on the problem and not the tools.
Tools are also problems for some people, they don't exist magically. If nobody cared about tools we would be writing machine code.
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.
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.
I'm getting tired of this take. There's such as thing as programming for the joy of programming. You can love a clever algorithm with no "business value". Code can be beautiful and fun to write without being useful, or optimally-useful-per-unit-of-time-invested.
You’re pretty much in agreement with the article from my POV.
“Work on interesting ideas, or ideas that you are genuinely interested in” is the bolded message.
Spending time painstakingly beautifying your impl of a clever algorithm or, like the author, homegrowing the 8000th iteration of a PM tool with kanban functionality instead of working with k8s/cassandra/<tech> just to have worked with it.
Kinda feel like we all end up doing this naturally most of the time after a few years or so, and they’ve just decided to write it down tbh.
“Work on interesting ideas, or ideas that you are genuinely interested in” is the bolded message.
Spending time painstakingly beautifying your impl of a clever algorithm or, like the author, homegrowing the 8000th iteration of a PM tool with kanban functionality instead of working with k8s/cassandra/<tech> just to have worked with it.
Kinda feel like we all end up doing this naturally most of the time after a few years or so, and they’ve just decided to write it down tbh.
Work on iteresting¹ X, not interesting² Y!
─────
1. to me, not necessarily you.
2. to you, not me.
─────
1. to me, not necessarily you.
2. to you, not me.
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.
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.
For anyone else wondering https://en.wikipedia.org/wiki/Workplace_OS
> Workplace OS is IBM's ultimate operating system prototype of the 1990s. It is the product of an exploratory research program in 1991 which yielded a design called the Grand Unifying Theory of Systems (GUTS), proposing to unify the world's systems as generalized personalities cohabitating concurrently upon a universally sophisticated platform of object-oriented frameworks upon one microkernel.
> With protracted development spanning four years and $2 billion (or 0.6% of IBM's revenue for that period), the project suffered development hell characterized by empire building, feature creep, and the second-system effect.
> With protracted development spanning four years and $2 billion (or 0.6% of IBM's revenue for that period), the project suffered development hell characterized by empire building, feature creep, and the second-system effect.
>my salary history led me to be significantly underpaid for most of my career.
I feel like this misses the point of the article. The author claims its important to enjoy what you're working on. They make no claims that doing so is a way to maximize your salary.
I know tech gets paid well now but that wasn't always the case. Decades ago people went into medicine or law or finance if they wanted to optimize for pay and prestige. Only relatively recently has tech joined that list.
I feel like this misses the point of the article. The author claims its important to enjoy what you're working on. They make no claims that doing so is a way to maximize your salary.
I know tech gets paid well now but that wasn't always the case. Decades ago people went into medicine or law or finance if they wanted to optimize for pay and prestige. Only relatively recently has tech joined that list.
It's hard to enjoy what you are working on after you realize it's going from your fingers straight to the trash.
And then you find yourself junior to someone who was getting 6 figures straight out of programming bootcamp three years ago. (And good luck trying to convince them that their genius idea has never actually worked.)
And then you find yourself junior to someone who was getting 6 figures straight out of programming bootcamp three years ago. (And good luck trying to convince them that their genius idea has never actually worked.)
Those are both good, but I think distinct, points.
>It's hard to enjoy what you are working on after you realize it's going from your fingers straight to the trash.
I think this is more true of the two. Purposeful work is important to feeling fulfilled. Work that isn't appreciated isn't likely to leave one feeling like they have a purpose at work outside of generating a paycheck.
I think the other point is probably less wise. There will almost always be comparisons in which one falls short in terms of salary, even up to the billionaire class level. For me personally using that as a gauge is a recipe for constant unhappiness.
>It's hard to enjoy what you are working on after you realize it's going from your fingers straight to the trash.
I think this is more true of the two. Purposeful work is important to feeling fulfilled. Work that isn't appreciated isn't likely to leave one feeling like they have a purpose at work outside of generating a paycheck.
I think the other point is probably less wise. There will almost always be comparisons in which one falls short in terms of salary, even up to the billionaire class level. For me personally using that as a gauge is a recipe for constant unhappiness.
The only screenshot [0] I can find of TaligentOS looks remarkably like The BeOS. Did some TaligentOS guys move on to produce the BeOS?
[0] https://pbs.twimg.com/media/D7Gi8GgW0AAoguu.png
[0] https://pbs.twimg.com/media/D7Gi8GgW0AAoguu.png
Yes. https://en.wikipedia.org/wiki/Taligent
The whole convoluted story of Taligent and WorkplaceOS is something to behold.
It's a pity because the initial promise back in the early 90s was something I was genuinely excited about but alas, it was all promise and no shipping
The whole convoluted story of Taligent and WorkplaceOS is something to behold.
It's a pity because the initial promise back in the early 90s was something I was genuinely excited about but alas, it was all promise and no shipping
Quick anecdote: One of IBM's guys got back from Cupertino (Taligent was across the street from Apple) (I worked for IBM in Austin) and had his head in his hands. He kept repeating "they think mice only have one button".
As someone who has spent their entire career working on interesting problems using boring technology, and now work on an interesting problem using interesting technology, I can only recommend the latter.
Can you elaborate on how/why you came to that conclusion?
Even interesting jobs involve a fair amount of rote work, doing it using tech you enjoy working with makes that go a lot easier.
Counterpoint: http://boringtechnology.club/
These things are fairly orthogonal. There are interesting problems, there's interesting tech. Sometimes interesting problems require interesting tech to solve, but not usually. Often boring problems are best-solved with interesting tech, but they can optionally be solved with boring tech. In my experience, solving interesting problems with boring tech is far more frustrating and unfulfilling than solving boring problems with interesting tech. But again, they're pretty orthogonal.
There are a tremendous number of jobs using interesting tech to solve boring problems. This is really the bread-and-butter of most tech careers. You might be selling widgets or building another social network or something that is mind-numbingly boring and unfulfilling, but if you're into the tech, you might still enjoy your day-to-day. That's certainly been the bulk of my career. I've also worked on solving interesting problems using boring tech, and while it was nice to see the results at the end, the path leading there wasn't as fun.
If you're lucky enough to land both, that's great. I've worked on interesting problems with both interesting and boring tech (NASA projects), except it didn't pay well. I've worked on boring problems with interesting tech (fintech) and that both paid well and was actually more challenging and more fun. And I've worked on a whole lot of boring problems with boring tech (countless ecommerce web projects).
At the end of the day, if I can't have both, interesting tech is probably more important to me, because that's what I spend almost all my time dealing with, and I'm still a hacker at heart and appreciate the tech in itself. It does leave me feeling, most of the time, like my work has no meaning, but I can find meaning in other endeavors. There aren't enough interesting problems that also pay the bills to go 'round, so most of the time I just want my day-to-day to be engaging.
There are a tremendous number of jobs using interesting tech to solve boring problems. This is really the bread-and-butter of most tech careers. You might be selling widgets or building another social network or something that is mind-numbingly boring and unfulfilling, but if you're into the tech, you might still enjoy your day-to-day. That's certainly been the bulk of my career. I've also worked on solving interesting problems using boring tech, and while it was nice to see the results at the end, the path leading there wasn't as fun.
If you're lucky enough to land both, that's great. I've worked on interesting problems with both interesting and boring tech (NASA projects), except it didn't pay well. I've worked on boring problems with interesting tech (fintech) and that both paid well and was actually more challenging and more fun. And I've worked on a whole lot of boring problems with boring tech (countless ecommerce web projects).
At the end of the day, if I can't have both, interesting tech is probably more important to me, because that's what I spend almost all my time dealing with, and I'm still a hacker at heart and appreciate the tech in itself. It does leave me feeling, most of the time, like my work has no meaning, but I can find meaning in other endeavors. There aren't enough interesting problems that also pay the bills to go 'round, so most of the time I just want my day-to-day to be engaging.
... 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.
> 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.
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.
Well, "most popular" is an objective category, whereas "interesting" is not, so it's really up to the individual to determine what is and isn't interesting.
> so it's really up to the individual to determine what is and isn't interesting.
True. The claim I'm making is that what people think is "interesting" is usually (ofc not always) determined by the factors I mentioned, rather than being informed by deep experience with and knowledge of the relevant "prior art".
That is, the new framework or database seems "interesting" to you (the general you) because there are so many articles on HN about it, everyone is talking about, Facebook is using it, etc. Not because you are familiar with similar databases in this space, have specific complaints about them based on experience, and know that this new database has specific features purporting to address them, etc.
True. The claim I'm making is that what people think is "interesting" is usually (ofc not always) determined by the factors I mentioned, rather than being informed by deep experience with and knowledge of the relevant "prior art".
That is, the new framework or database seems "interesting" to you (the general you) because there are so many articles on HN about it, everyone is talking about, Facebook is using it, etc. Not because you are familiar with similar databases in this space, have specific complaints about them based on experience, and know that this new database has specific features purporting to address them, etc.
> I'm old enough to have worked on Cobol at one point
So, how much money would 'they' have to offer you to go back to working on Cobol.
they meaning a hypothetical company that says they can't find any Cobol programmers.
So, how much money would 'they' have to offer you to go back to working on Cobol.
they meaning a hypothetical company that says they can't find any Cobol programmers.
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.
For inspiration, Wikipedia is rich reservoir of repetitive tasks to fix minor issues that would be easier with a task-specific GUI for review.
As much as I agree that solving (technically) interesting problems is more fulfilling than selling ads using distributed clusters, I think that finding an interesting problem that helps business make money is a non-trivial problem by itself and usually requires a separate person doing it full time. If you have such a person in your team, you are in a great luck
Yes I totally agree with you. I did not write it in that POV where you work or do hobby coding.
I saw that some comments here has mentioned it as something of a hobby coding pov.
If you find working on selling ads interesting then that’s what you should do. Buy doing that you will create something innovative, and new.
And you might even be able to merge cool tech into it as a result of it.
But don’t learn cool tech just because it’s cool. Do it because you want to solve a problem.
I saw that some comments here has mentioned it as something of a hobby coding pov.
If you find working on selling ads interesting then that’s what you should do. Buy doing that you will create something innovative, and new.
And you might even be able to merge cool tech into it as a result of it.
But don’t learn cool tech just because it’s cool. Do it because you want to solve a problem.
I agree with you, Emphasis needs to be put on finding an interesting problem to solve in the first place, Finding problems is a hard skill.
I've been running a problem validation for 2 years[1], 1/10 new posts each day is actually a problem and rest are just ideas someone want to build(there's nothing wrong with it per se, But with problems as first class citizen they're not allowed).
And then not everyone who can identify a problem can also have an idea to solve them and that's fine too. It's just the distinction between problems and ideas need to be understood.
[1] https://needgap.com
I've been running a problem validation for 2 years[1], 1/10 new posts each day is actually a problem and rest are just ideas someone want to build(there's nothing wrong with it per se, But with problems as first class citizen they're not allowed).
And then not everyone who can identify a problem can also have an idea to solve them and that's fine too. It's just the distinction between problems and ideas need to be understood.
[1] https://needgap.com
"I picked up the project because I was genuinely interested in it, and because it was extremely challenging."
I pickied the OS as a project because Im generally interested in it. Its challenging. I had to learn Bourne shell and C, and a bit of assembly.
I am genuinely interested in the OS because I use it everyday to help solve problems.
I pickied the OS as a project because Im generally interested in it. Its challenging. I had to learn Bourne shell and C, and a bit of assembly.
I am genuinely interested in the OS because I use it everyday to help solve problems.
Naah. I'll work on interesting tech. Mostly because life is too short for things like php or windows, but also because sometimes (admittedly not very often) it gives me a significant advantage.
The author doesn't say who or how what about the project was interesting, just that it was interesting and that it made him endure Java. My experience is the opposite. I don't care so much what I'm making, as long as it's not something making the world a worse place. I care about what technology and methods I can use to do whatever. That is interesting to me from a craft point of view.
In my experience, it's fun to work on interesting problems and it's fun to work with interesting tech. But it quickly becomes overwhelming if you try to do both at the same time.
The thing is that interesting problems are never just tech problems. That's why they still exist. There's still a massive, complex human side to those problems.
[deleted]
I do both. Shall I be ostracized?
Shun! Shun!
Just kidding. We all want to know what you're working on.
Just kidding. We all want to know what you're working on.
Recommend striving for both.
Important note: the writer says they started on Java and had trouble grasping OOP concepts. No wonder, because Java is not an object-oriented language—it is a class-oriented language. This is especially apparent from the inheritance mechanisms.
JavaScript, on the other hand, is an object-oriented language down to its prototypal inheritance. There are no classes, only objects and primitives (which can get transparently promoted to objects).
JavaScript, on the other hand, is an object-oriented language down to its prototypal inheritance. There are no classes, only objects and primitives (which can get transparently promoted to objects).