Ask HN: If you could build anything, what would you build?
What do you build? Do you hire a team, or are you building it to learn?
What do you build? Do you hire a team, or are you building it to learn?
- Full-remote
- 4 days/week instead of 5
- 2-3 months mandatory PTO
- Bootstrapped
This isn't lofty or anything, it's really what I aspire to do some day soon. To me there are few sane reasons to build a company predicated on the 40 hour work week in an era where work is intellectual and not based on quantifiable throughput (like working in an assembly line). Today, I would gladly take a 20% paycut to work 20% less per week (e.g. get Fridays off), and so I'd want to build a company in the same way.
I personally think the world is already headed in this direction (with remote work being the first big change).
I want to clarify that I don't think this will necessarily work for every company, especially high-growth, high-competition companies like Uber. Probably moreso for companies that acknowledge, due to market cap, that they will never be a billion dollar unicorn.
I think we need more companies like this. Although to get a job as you are describing, I'd probably need to lose the lions share of my salary.
Then I have to ask: Should I just contract in a cubicle job for 6 months, then take 12 months off for the same amount of money over 18 months as one of these 'nice' jobs?
Open a chain of small 100-bed hospitals throughout the US, give them doctors working normal hours and software to handle all the management stuff. Accept cash and credit only--no medicare, no insurance, no bullshit. Just cheap healthcare that people can rely on, payable on exit.
Start a scholarship for hackers at colleges--must have less than a 2.8 GPA to apply, and must have cool hacks submitted every semester. Hacks that aren't some stupid fucking sociomoboloco sharing economy coupon thing. Hacks that have teeth.
Oh, and two gigantic hands, two thousand feet tall, flipping the bird to NY and SV.
Here's the plan: You go into the doctor's office. You give a small blood sample to a machine. It finds the bacteria in it, and DNA sequences them. It then looks them up in a library of known antibiotics, and prescribes for you an antibiotic that will kill exactly what you have.
If it can't find an antibiotic that will do the job, it sends the DNA sequence to the US CDC. They hand it to a supercomputer, which solves the protein folding problem, and therefore can determine what the surface of that bacteria exposes. They then derive an antibiotic that will kill it, and add it to the library in all the doctors' offices.
Taking the blood sample is a solved problem. Scanning the DNA is close. The protein folding problem is harder, and deriving an antibiotic from the surface geometry is really hard. So those are the problems that need solved to do this.
I think it could be done in 30 years, but I can't guarantee it...
Distributed artificial general intelligence app, probably something like using deep learning with a virtually embodied agent.
A digital circuit IP or maybe separate USB dongle that does path tracing in hardware, maybe based on procedural generation from a built-in Forth.
Various business and government ideas built on Ethereum, promoted with the intention of displacing existing more centralized institutions with decentralized ones.
A backyard exchange website where people can rent out or share their backyards for tiny house 'parking' and/or high-tech gardening like aeroponics or aquaponics, or whatever they want besides being a big waste of space collecting dog crap.
A deep underwater research living facility for testing closed eco-systems for space/the moon/mars.
Mesh and optogenetic BCIs explicitly for human enhancement.
Robots based on mulitlayered-multibraided electroactive-polymer muscles with anatomical mimicry.
A unification of computer science, programming, and math. Or, a metalanguage and representation tying together classical programming and mathematical notation with interactive and/or visual programming, with the common part reused in all types of informations systems.
Simple, low-priced home aeroponics systems sold in grocery stores, with plastic supports enabling sweet potatoes to grow.
A new operating system for virtual reality.
A small, lightweight hot-rod electric skid-steer with heads-up-display using ultracapacitors and high friction to enable very high-speed cornering and acceleration.
A house, fully paid for, for every person or family I could afford.
Elaborate.
But unlike traditional ones I'd build or buy the physical infrastructure and then resell access to any party which wanted to buy it, from big to small. I'd then use all of the profits to expand, then resell, repeat.
Essentially I'd want to become an "invisible" company that sits behind public facing ones, and let's them take all the credit/blame, while I just continue to expand and resell. Kind of like "Level 3 Communications" but in the "last mile" segment (all the way to consumer's front doors/businesses).
Then if I grow big enough, I'd start buying up companies like AT&T, take their infrastructure into my pool, and then resell the consumer/business arm off to someone else (and have them rent back space on the network from us).
The eventual goal would be a complete monopoly over all US infrastructure assets, but a completely fair one, big and small companies would pay the same dollar price for raw access and could resell at profit margins they felt suited their business model.
The hardest part aside from the billions of dollars it might cost, is setting up a pricing scheme which is rational, but also encourages continued growth. Most of the ways companies currently split up a fixed bandwidth network is kind of clunky and doesn't scale very well.
[1] https://en.wikipedia.org/wiki/Non-rocket_spacelaunch [2] http://shitelonsays.com/transcript/elon-musk-lecture-at-the-...
Just kidding (not really).
A bit more realistically, I would build an open source car company. I mean, a car which is 100% documented and documentation publicly available. with all the diagnostic tools and information how to use them available publicly.
The things I want to build: Firefox with the 3.6 or older interface and uses libavcodec for video decoding; a clone of Windows Explorer for Linux; a perfect clone of Winamp; media library software that links together all the best features of existing programs.
ITT: things that will never happen.
That's the idea
I'd like to make modern GUI stuff work a bit more like that. I'm imagining a state synchronized pseudo filesystem. Instead of storing files, it stores hierarchical C data types. A folder, with an array of vertexes and faces, inside another folder that contains textures and metadata. They're not folders, just nodes, but hopefully you get the idea.
You can use your image editor to edit those textures, and the changes would show up in real time in your 3D scene editor. Small applications that do one thing well, because the "file types"(data structures) are standardized enough.
Programs subscribe to changes in a file, sometimes over a network, using a state synchronization protocol. Think rethinkDB, but optimized for very fast read/write, not querying data. If you wanted to query the data like that, you'd have a daemon watch the folder, and index the data. The point is to focus on speed above all else, so you can watch real movies or stream real content in it, and then build your indexing a layer above that.
Of course there are a whole lot of problems with that approach, and it's well beyond me. But I'd hire some C tutors, and the guys who make btrfs, and see what could happen.
In my heart of hearts, I know this is probably just because I want to live in a world with a real metaverse, and I think this will get us one step closer to the kind of collaboration you'd need to get real work done in a virtual environment. But I still think it's a pretty good approach.
I do find there's an advantage to hanging out and working with people in a real space, and I'd like to break that down a bit more.
See:
#Problems in unix design, the art of unix programming, Eric S Raymond
http://www.catb.org/esr/writings/taoup/html/ch20s03.html
>#A Unix File Is Just a Big Bag of Bytes
>A Unix file is just a big bag of bytes, with no other attributes. In particular, there is no capability to store information about the file type or a pointer to an associated application program outside the file's actual data.
>#File Systems Might Be Considered Harmful
>Was having a file system at all the wrong thing? Since the late 1970s there has been an intriguing history of research into persistent object stores and operating systems that don't have a shared global file system at all, but rather treat disk storage as a huge swap area and do everything through virtualized object pointers.
#The Verse 2 Protocol