Thank you for your advice. I understand where you're coming from, however, I respectfully disagree (plus, in my case, your advice is not much applicable, since my knowledge and experience with Python and .NET ecosystems are not that much different - I still will need to master quite a lot of topics and aspects). If I would be debating which UI styling to use, which relational database to use or even which front-end framework to use, I would agree that it does not matter that much and should be based on existing knowledge and skill set. However, I strongly believe that spending enough time to select the best/optimal technology stack for the target product is worthwhile and will provide a high return on investment. You don't want to skimp on architectural decisions, since fixing the wrong ones will cost much time, money, effort and, sometimes, will even be outright impossible. Hence my deliberation.
> Call around, talk to your network. I don’t just mean those ~300 people you’ve never met on LinkedIn, but your actual family, Facebook friends, etc. ... Figure out what the problems that they’re having are. Solve exactly the problems they express
This is, imo, the biggest hurdle for engineers who want to become entrepreneurs. I've seen so many HN posts about people trying to crowd source startup problems, trying to automate away this piece and just get down to coding. I too struggled with this for the longest time. I felt like a solution looking for a problem. Just give me a problem, any problem, and I'll build the best damn app and be on my way!
But that's not how it works. If you want to stop being an engineer, you need to stop acting like one. Engineers have their problems roughly scoped and entered in a JIRA board. Entrepreneurs have to go find problems to solve. You want to go be an entrepreneur? Go learn to talk to people. Go learn to listen to others, empathize, and to convince people to believe in you. You will be a company of one - so go build out your personal sales & marketing departments.
A key thing most developers wanting the become entrepreneurs miss (I certainly did) is that more often then not coding something is the slowest and/or most expensive way to solve someone’s problem. Many, many business ideas could probably just be a Wordpress site with a small plugin which you can farm off to Upwork for a pittance that doesn’t make for a very good “Show HN”.
But that's not fun to build. And I suspect this is where the dichotomy comes in. Engineers want to have something that's fun to build while also making money, which can be the problem.
As an engineer, what is fun about it? From your statement it would be "something fun to build." I wonder why building a business and building a piece of software are so different, and why one is fun while the other is not.
Fun about what exactly? If you mean farming to Upwork, not building is not fun for engineers. Building a business can be, but again, only if the product itself is fun to build. Who wants to work in a business where the core product is boring? I mean boring as in the fundamental product, not the industries, such as healthcare, construction, and so on, basically all but consumer tech.
> Fun about what exactly? If you mean farming to Upwork, not building is not fun for engineers.
Nope. Never said anything about "not building." Only you have stated that.
This circles back to my original question/statement; "I wonder why building a business and building a piece of software are so different"
> Building a business can be [fun]
Absolutely! Remove the words "a business" and restate that as:
"Building can be [fun]"
Now you can insert almost anything...
"Building a bike can be fun"
"Building a business can be fun"
"Building a product can be fun"
"Building software can be fun"
"Building a computer can be fun"
...
...
...
> Who wants to work in a business where the core product is boring
Remove the words "wants to" in that sentence and you could apply that statement to most of the Software Engineers who work for others. SE's typically work around this limitation by justifying it with the technology they are working on instead.
"I'm learning React!"
"I get to use Ruby on Rails everyday!"
"I get to learn more about using all the AWS services!"
...
...
...
None of that matters.
The only thing that matters is "building." Building is fun!
Why can't building a business be just as fun as building software? ...and we're right back to my original question :-)
Because business is mostly about sales and marketing and not so much about the product. Exceptions occur, of course, but generally a better marketed product is more successful than a better built product.
Engineers don't like sales and marketing generally. That's why they're engineers. And unlike as you state, building in general is not necessarily fun, only specific things being built are fun, those that align with the interests of the builder. If you told me to build a house, I wouldn't necessarily consider that fun, so your initial premise is flawed. A business in this case also falls into the "not fun" category, again, in general to engineers.
> Because business is mostly about sales and marketing and not so much about the product.
That's not been my direct experience.
Actually, very much the opposite for myself and many others I know who are software engineers building their own businesses.
> And unlike as you state, building in general is not necessarily fun
No. I said building in general IS fun. That's my premise ;-)
> If you told me to build a house, I wouldn't necessarily consider that fun, so your initial premise is flawed.
No, that's for you as an individual. Not everyone. Yes, there are many people who find building a house fun. Those statements of mine, they were examples. The point is being missed. Engineers like to build.
There is no flawed premise, only an individual looking for flaws.
> A business in this case also falls into the "not fun" category, again, in general to engineers
Again, that's not been my direct experience nor the experience of other Software Engineers that I know who are building businesses.
Most likely you think it's not fun for you. That doesn't mean it's not fun in general, to engineers. Maybe you've chatted about this, anecdotally, with other Software Engineers, maybe you've read some online threads and it's formed a cognitive bias. That's very typical. I can clearly see it in these very generic statements.
---
There is whole world out there for people who like to build (e.g. software engineers) and they can do it on their own terms, by better understanding what it is about building they like. Not what they "think" they like, but what actually drives them. That's harder to figure out. The biggest hurdle that I've experienced / seen is not the thousand and one reasons for why software engineers would hate building a business, but rather the biggest hurdle is their own cognitive bias towards it (force fed via generic, and widely accepted statements such as "business is mostly about sales and marketing and not so much about the product").
I'm sure you'll snap back with why I'm wrong. Maybe even sprinkle in some snark. Making sure to get the last word in. Please indulge yourself.
It's now time for me to get back to having fun building my business as a software engineer :-)
What was your actual point in this conversation? I took it as, "building is fun":
> No. I said building in general IS fun. That's my premise ;-)
Then I disagreed with that saying that building in itself is not necessarily fun, only building certain things is fun for certain people, which you seem to take issue with. I posed a counterfactual statement to your general rule, which means that your general rule cannot be true, as in propositional logic.
> Again, that's not been my direct experience nor the experience of other Software Engineers that I know who are building businesses.
> Most likely you think it's not fun for you. That doesn't mean it's not fun in general, to engineers. Maybe you've chatted about this, anecdotally, with other Software Engineers, maybe you've read some online threads and it's formed a cognitive bias. That's very typical. I can clearly see it in these very generic statements.
I said that in general, regardless of one's anecdotal experience, engineers tend towards building technology rather than business aspects like sales and marketing. Much as you disagree with me on anecdotal evidence, I also disagree with you. Whatever, seems to be a disagreement on principles, we can't convince each other.
But, regardless of our disagreements, please don't make statements like these:
> I'm sure you'll snap back with why I'm wrong. Maybe even sprinkle in some snark. Making sure to get the last word in. Please indulge yourself.
> It's now time for me to get back to having fun building my business as a software engineer :-)
When you engage in discourse, you are not above criticism or disagreement. Don't act holier than thou when someone disagrees with you. It harms the nature of argumentation, especially on fora like HN where it's expected more than other fora.
I believe this is very common with web devs as well who argue all day over wordpress vs static site vs whatever. What works best? Usually the solution that is quick and web dev for small brochure sites is more a marketing skill than a technical one.
Honest question, is this worth it? I've noticed the same thing. Most requirements are simple, and can be done via upwork freelancer etc. What you can provide is extra customer service or maintenance. But that seems like a race to the bottom.
Whenever I come across these, it's in the territory of not worth my free time. But for the more complex projects they want a whole team, and I've found it's difficult as a solo person to sale that.
I spent a lot of time going to angel rounds, vc meetups. Talking to a lot of people about their issues, what they needed. It was a great way to get exposed to a myriad of problems. Angel.co is also a good one for finding places where some one has an idea, but needs tech help.
The problem I had. Is that a majority of what I came across was mobile and web orientated. As a back-end dev, it's not something I can help with. Especially when for the pitch deck metrics/numbers and a pretty demo are the big selling points.
Buying put options are a great way to protect yourself against downturn risk. I think of it like an insurance policy. You pay a premium to protect yourself in bad times.
However, I'd recommend always having a put contract outstanding, not just when you predict things getting worse. You got lucky this time, but next time you may be too late.
That article doesn't apply to unvested RSUs: "put options are quite ineffective at reducing drawdowns versus the simple alternative of statically reducing exposure to the underlying asset. "
You can't statically reduce exposure to an unvested RSU.
Also, the article concedes that there is one case where puts are useful: "Put options may offer crash protection"
Most big companies that I know with equity-based compensation typically forbid any hedging of their stock, especially through puts. But assuming hypothetically this is not an issue, you could sell short your company's stock to reduce exposure to your RSUs vested in the future.
It seems OP is trying to hedge savings in the form of RSUs granted by his employer. Since they can't be sold yet cash isn't an option (pun unintended).
The OP probably can't cash out on the RSUs at this point, and options plays are like shooting fish in a barrel at the moment. Remember that the hard part of an options play is knowing when something is going to happen with a fair amount of accuracy, but there probably won't be a miraculous recovery of the market in the next 24-48 hours.
No, the hard part of trading anything is having edge over other people. Options are not priced assuming there will be a "miraculous recovery" in the next 24 hours. They're priced based on the world's expectation of future volatility, through a very competitive market mechanism. There is no reason to assume you have better insight than people who model this stuff full-time.
It's irresponsible to suggest that making money trading is akin to shooting fish in a barrel. Best case, it's a slightly negative EV gamble with high variance.
Your strategy is a great one to work - no matter the prevailing trend! The trend for 10 years has been to become lax on protecting the downside. Even large funds have stopped protecting downside with puts. Your strategy doesn't produce the highest ROI year over year, but DOES protect premium year over year. Which is perfect.
Not the OP, but what I have struggled with here is the feeling of being a "solution looking for a problem". It's a step before where you're at. It's not that I can't identify owners, it's that I can't identify _problems_.
I am lacking the domain experience to even have the first conversation, and it feels like paying people to ask "so tell me everything that is wrong with your business" is the wrong way to do it.
I know PG mentions "solve problems you have yourself", but I am not a business owner. I'm a software engineer.
That video you linked earlier - Designing the Ideal Bootstrapped Business - was incredible and feels like the right move once you have that idea. But what about finding that idea?
A good way to think of it is that you aren't looking for problems. You're looking for smells.
Most business owners tend to be experts in their specific domain, where they have already used their knowledge and expertise to great advantage. But running a business entails more than just handling the problem domain itself. There's an entire category of tasks and responsibilities under the "business administration" umbrella that the business owner will not be an expert in, and will probably despise dealing with because it takes them away from the fun stuff that is their expertise. That's a good area to focus your gaze on.
For instance, the accounting clerk may be spending 4+ hours every day manually typing invoices into two different systems, but to the business owner this is probably perceived as a normal and expected course of business. The accounting clerk is unlikely to complain about it themselves either, since they are getting paid to do it (remember that Sinclair quote). But to you as a software engineer, double data entry is very obviously a red flag, and if you care enough about it you can do a deep dive and see if it can be eliminated using automation, and present it as a cost-saving solution.
Generally speaking, nobody is going to hand you a written list of their problems on a silver platter, and even if they do, the problems they have identified will be so general and vague (e.g. "we have a lot of inefficiencies in our accounting department") that you won't be able to simply go home and start hacking away at them. So you need to use a methodology to start peeling off the layers of the onion, so to speak. And that always entails follow-up meetings and learning other software systems and familiarizing yourself with various business practices.
At some point, you will come to the realization that you no longer view yourself as a "software engineer". Rather, you are a problem solver, and writing code is simply one of the many skills you possess. That's when you'll know you're on the right track.
I was in Software for a couple of years and I only saw software/IT problems. But these problems usually had a variety of solutions and only some glue was required.
Now I've been in the natural stone industry for 4 years and I can't count the number of problems to which the solution is "add more people". So much data entry and data extraction from PDFs <-> ERP/CRM/Other software. 100s of man-hours spent on something that could be done with proper data formats and simple automation.
I personally believe that software engineers are SORELY lacking on all other industries besides software. We need more software engineers venturing out into other industries and identifying and solving problems.
> We need more software engineers venturing out into other industries and identifying and solving problems.
this seems to line up with my experience well. But I don't have a good line of sight for me to actually experience those businesses outside of taking a non-SWE job and going from a well-compensated expert to barely-paid newb. Spending years learning a specific industry in the hopes that I can turn my former skills into a viable business seems like the wrong approach in several axes. I know VC groups (sometimes) have entire departments whose purpose is to understand other industries... it seems counterproductive for individuals to try to and go this route. Thoughts?
Agreed, that's not a pragmatic path. But if starting a business is your goal, and finding a viable idea is your obstacle, I'd argue this is a sure-shot way of FINDING said idea.
Some potential paths can be:
1. SWE @ SW company -> "BA" @ non SW company or whatever term is used for generic-problem-solver in that industry.
2. Part-time hourly work in another industry. This is fairly easy through temp agencies.
3. Apprenticeship in another industry (perhaps in more hands-on industries).
Some are hard to get, others don't pay as well. But to find gold, I'd say some level of hardship is required, and this, in my view, is a bulletproof way of finding that gold.
Whether you're able to dig it out and then able to sell it at a profit, is totally another question.
Hey Gary, I'm solving them using 3rd party tools (docparser and evolution.ai) at the moment to offload these types of tasks.
I don't have a fully working solution, just started testing with specific documents (steamship lines notifications) to see if it's a fit.
I think it'll be slow road for each department I want to tackle - logistics, accounting, purchasing, etc. Every department has this issue, and I'm sure products could be built to serve those niches.
Plot the day - talk to a business owner and get a sense of the hours they spend doing different tasks. If there's something they spend X+ hours per day doing - find what they want to achieve and optimise from there.
What solutions would you pay for as a software engineer? What would your boss/team lead pay for? You can't really do it for someone elses domain, you need a motivated partner in that domain for that (my general experience, of course there are exceptions)
Been really enjoying workona as well. Have found myself recommending to folks on my team. I organize my tabs into their “workspaces” which map to the strategic and tactical projects I’m juggling. Helps me switch btwn contexts
I actually changed to Chrome only for this. I have been looking for months for something like Workona for Firefox but to no avail.
I used Firefox for years and I want to continue using it, but for my way of work (multiple tabs open in several spaces and changing computers often) Workona is just great, nothing comes close.
My goal would primarily be to avoid having to make sure there's an active python installation with all the right dependencies set up on a client's computer. That's been a huge problem for me in the past during deployment (esp. older windows OS's).
A nice side benefit I foresee would be easier coordination of state between a JS front end and a Python process running specialized computations. The current best approach I'm aware of now involves sending data back and forth as JSON and trying to mirror what's going in Python with JS state management. The system described in this article where JS and Python can reference the same objects (and somewhat the same typing?) sounds like it could be an improvement.
This is also the way Java is supposed to be deployed on client machines nowadays, apparently - using the jlink tool to create a bundle of the Java runtime for your application.
