At this point in my life I've started to believe that whenever you talk to someone who is "passionate about technology X and clean architectures" or "wants to work on challenging technical problems" is ultimately doomed to fail when setting out to create a (for-profit, bootstrapped) business. This is a strong opinion and there is certainly a spectrum for this mindset, but at the most extreme your mindset should be more along the lines of "all technology ultimately sucks, let's figure out the most straightforward way and the least amount of effort and headaches so we can create value for our customers so they, and we, can get off that damn computer screen and enjoy the fruits of our labor".
If you're saying "I'm passionate about delivering great products to users" or even "I'm passionate about making money" (I respect that) then technology becomes the tool you unfortunately have to wield to arrive at that goal.
Note that this attitude only applies to people who want to take ownership and deliver a fully functional product. There's tons of great people who are in it for the sheer enjoyment of working with technology, they all will have a great time working on challenging problems at one of the many tech companies. And there's a few people who can both enjoy technical challenges but also switch to dumb and boring crunch mode when it's demanded by the task at hand.
> At this point in my life I've started to believe that whenever you talk to someone who is "passionate about technology X and clean architectures" or "wants to work on challenging technical problems" is ultimately doomed to fail when setting out to create a (for-profit, bootstrapped) business
A flight to the Virgin Isles was delayed overnight, so a strapping young man named Richard Branson chartered a plane to the Isles with money he didn't have. His next move was to create a sign that read "Virgin Airline, $29 a ticket", which he showed to his fellow passengers. They all paid up and all flew to the Virgin Isles that night. Was he motivated by a "passion to help people get to their destination"? Hell no, he had a girl waiting for him and more than likely he wanted to get laid.
That is the only attitude that works for an entrepreneur, the ability to identify problems, find solutions, and get people to pay for them. If you say you have a passion fr a technology or a clean architecture, or that you want to work on challenging problems, you belong in an established company, either as a lead, an architect, or in the R&D. Entrepreneurs understand that technology is but a means to an end, and focus more on solving problems than gold plating something or waxing philosophical about software. They use the tools at hand to solve a problem to the best of their ability. They're not motivated by some grand scheme, their passions are more personal.
That story seems apocryphal. Richard Branson's business empire started with Virgin Records (and in particular, signing Mike Oldfield before Tubular Bells became a huge hit), and the name came from him sitting around stoned at a party/orgy with a bunch of friends and saying, "Well, we're all virgins in business, so let's just call it Virgin Records." He's not a cofounder of Virgin Atlantic - the cofounders were Randolph Fields and Alan Hellary, and Randolph met RB at a party in which RB agreed to put up all the money in exchange for a large equity stake. He was already wealthy from the success of Virgin Records, which had been in business for a decade.
Sources: Losing My Virginity (Richard Branson's autobiography) and the Wikipedia page on Virgin Atlantic:
That story is not how Virgin Atlantic was formed, it's more about his first experience with making money in the airline industry, and would later lead to his decision to agree to a partership.
Beyond that, it's more a look into the mindset someone requires to be a successful entrepreneur. It's not about the technology, the architecture, or the language. It's about identifying a problem, and getting people to pay you for a solution. The technology is tertiary.
You're really just talking about the differences in skill sets and interests between people who, in a bigger organization, would be sorted into the engineering team and the executive team. The "passionate about technology" people will end up in engineering. To the executive team, finding and serving the customer is the focus, while technologies (and engineers for that matter) are very much a cost that has to be justified.
But yeah they're different skill sets. The only time it's a problem is when they both have to reside in the same person, for example the solo app developer. You're trying to serve as both the engineering staff and the executive/management team, plus wearing several other hats as well.
The problem is that an engineering team full of developers that only care about processes, clean code and learning new stuff is mis-aligned with the goals of the organisation.
It will take a constant uphill battle to take them to ship anything, something that generally isn't worth it I believe.
Of course technical debt needs to be paid and clean code is the essential foundation of every productive company.
But as a developer, you need a desire to SHIP as well.
A process worth caring about leads to shipped software, and production is the wisest teacher and the most thorough QA. Shipping is important, but then you have to keep resources committed to quality improvement, not move on to the next shiny new thing.
That’s one of the biggest misconception I’ve experienced with developers. No one cares about whether you ship or not, unless it brings values. Shipping just for the sake of shipping is a fundamental misunderstanding of how a business works.
Well, sure, but whether the software has business value is the concern of the PM. Developers are usually haggling over the balance between speed of delivery and quality, for a fixed set of requirements.
I have known people who would not move to the next chapter in a book unless they understood the one they are reading in its entirety. I have pointed out the inherent impossibility of such an endeavor. They do not listen. I think this obsession with tech stack or architecture is related to this.
I am extremely passionate about a lot of subjects. However, I am not passionate about "technology X or Y". Technologies and programming languages are just tools for me. I like some more than the others, but they are just tools. It is like saying that I have a great novel in my mind, but I cannot write it down unless I have the "Pen A" or "typewriter X". Also, I will not write the next page down unless I get the current page 100% right. Never gonna happen.
Heck, when I began learning C# a few years ago and people would question me "where do structs in C# live? on the stack or in the heap?" I would get mightily pissed off. How was I supposed to know the internals of a closed-source (erstwhile?) language\framework? What if they change the internals tomorrow? Would this "knowledge" be of any use?
I have ideas. I need tools. I need results. The universe is all about entropy. The internals are constantly changing. However, as a giant mechanism it is always working, always producing results.
> What if they change the internals tomorrow? Would this "knowledge" be of any use?
Sometimes. I think the best response in theme of the thread so far is "When it starts to matter, I'll spend the time looking into it. Until then, I try to know just enough to clue me into whether it might matter."
As a concrete example, I know why stack and heap matter for performance, and I know that maximizing computation in a hot loop in something like assembly requires a fair bit of knowledge of the architecture and what instructions utilize what resources in a CPU you you can plan out usage optimally, but beyond reading some interesting articles that have popped up here, that's all I've bothered to internalize. I haven't done almost anything in C or C++ since college well over a decade ago, and all my day-to-day work is done in Perl. At the point I'm in need of a customized very optimized solution for a computationally heavy workload, I have promising avenues of inquiry to start with. The way I see it, that the optimal strategy for my current goals, and it's been the optimal strategy for quite a while.
>> "When it starts to matter, I'll spend the time looking into it. Until then, I try to know just enough to clue me into whether it might matter."
Exactly.
Stack and heap are not important in the C# example I gave. What matters is whether the data structure is a "reference type" or a "value type". This impacts the way we pass arguments to functions, scope of a variable and related side-effects etc. However, where these types reside has very little meaning since the memory allocation and cleanup etc. are not in developers control at all (unlike C, C++).
You're right, but it's kind of sad. We value flashy POCs, not robust, safe software. And look at the state of the world right now - garbage software everywhere.
It doesn't have to be flashy but it has to make money and can scale. The focus should be how can I make money, then build the product around that.
Being able to build the full product in a day allows you to pivot.
A side project doesn't have to be a business and probably shouldn't to start with. Why not build a game or app get as many people playing. Once it reaches a level you can try to make it a business afterwords.
This is a great summary of the zeitgeist of today's Silicon Valley and also totally wrong. You can do great engineering and build a successful company from it with out settling for low hanging fruit but, it requires a longer than average attention span, not needing to make your investors happy by the end of the quarter and a marketing plan.
Yeah, but they aren't tech companies. Lot's of other roles are needed for a successful company, legal, marketing, personnel, management, etc. but the value of a tech company is created by engineering.
I wish I could upvote this 100x. If I had a nickel for every successful founder who hacked their first version together in PHP instead of trying the latest framework, or worse, starting with a technology they’re in love with and then looking for a business problem to solve with it...
plus the "hacked in php " version is far more likely to work 20 years later because php is boring and people don't care enough about it to mess it up every week.
I really love difficult technical problems but luckily I'm still a CS student and have time for that. One thing I've been realising more and more is that if I want to make a good living working for myself the real problem is selling products to people who don't care at all about the technical side of it. They want a product they enjoy using that solves a problem of theirs, that's it.
It depends on what you want to do. There is a lot of room for technical experts who want to build products for other people.
I’m a manager now, and have been for years, but leaving product building behind was one of the hardest things I ever did. I did it because I wanted to make decisions more than I wanted to build things, but that’s not for everyone and it’s not as glamorous as it sounds. I could just never help myself from getting involved in every decision, and then it’s frustrating not to have any real weight, and you won’t as “just an expert”, even when you’re right. A lot of people prefer to just build stuff, and in CS and engineering especially, those people aren’t easy to come by or easily replaceable, and thus they are valuable.
My free time is still spent doing silly CS stuff though, I recently discovered edX.org, and I’ve been fooling around with cryptography.
So you’ll certainly have time for that, even when you get older. The only time I didn’t have time was when my kids were 0-6.
Funnily enough, I've been working on my transition to a CS career while my kids are in that age bracket. I work full time in the military and study CS, as a single parent, while my kids are 5 and 3 (I started when they were 3 and 1). I'm a tired man.
My end goal is to work for myself, I want to own a company that builds products. This can be either products that we own or building for others. I love building things but I'm now trying to learn about the art of selling and finding a customer base.
So how can you make a technological decision if you do not have hands-on experience with the technology (at least a year of deep immersion)? It sounds like the most important decision (whats to build) are at the hand of the least knowledgeable person.
Because decisions are rarely down to just one field of expertise, and technical experts are often some of the least knowledgeable about fields that aren’t theirs.
Like if you build a new application for handling internal e-commerce. The programmer will know how to build it, the service designer will know how to create the ux, the lean consultant will know how to build the best work-flow, the financial expert will know what functionality is required, the project manager will know how to get things build in the right order and how to manage benefits, the hr-consultant and the lean consultant and the service designer will know how to get it implemented, the data scientists will know what kind of data model their like to do BI. And so on.
The right decision is to listen to all those inputs, and implement them in a way that’s both realistic, possible within the budget and making sure the final product actually fits in within the organisation.
That doesn’t mean you won’t delegate. I don’t really care if it’s build with graphql or not, as long as building it with graphql doesn’t increase production time by an unreasonable amount of time compared to other options and graphql is part of what our company in general uses.
Because the best flashy new tech is useless if only 1 out of your 100 programmers know it.
Right. So why do you decide and not the expert decide? So the expert can be smart enough to come with a solution but cannot "decide".
My point here is that once you become the manager, you should constrain yourself to the functionality (input/output spec), but you cannot decide on technical issues if you are not keeping up with the technology.
Because the technical truth is only part of the equation.
The right decision almost always boils down to a combination of experts, finances, end users, over all strategy, corporate culture and realism.
The variables variate in importance, but the one thing you can be consistently sure of, is that experts over value theirs.
On top of that, decision making is only a small part of management. The majority of it is spend on politics, motivation and issues/conflict resolution.
This seems really observant. If the true goal is "building beautiful tech" then shipping an actual product usually takes one (far) away from that goal. Those who appear to self-sabotage by pushing back launch dates may simply be revealing their real goals. I think it's critical to honestly evaluate motives before starting a project to avoid burnout.
This is something I really wrestle with. I intrinsically care about clean architecture and clean code so much that I spend far too much time procrastinating and gold-plating. I realise I'm "doing it again" every so often, but invariably tell my self "yeah, yeah, but it won't take much longer". 4 hours later, I'm still at it :/
I don't know if it's my enterprise upbringing (been working for a megacorp for ~20 years), my love of tech, or my language of choice (C#, which I love, BTW), but sometimes I wish I could just ship a working product.
You're complaining about 4 hours? If you can spend 4 hours to make your code easier to understand, that's very likely to save someone 4 hours down the road.
When it's 4 days or 4 months, then it becomes an issue.
You could do a very small side project where the requirements are:
1) simple, polished, functional UI
2) quick and dirty code
If the code is nice, then the requirements aren't met! You might even write this in large letters on a piece of paper or whiteboard next to your desk at home, keeping it visible while you work on it.
Environmental clues like that can sometimes be helpful for me. I view it as an attempt to collaborate with "future me". Sometimes the collaboration is a failure, other time it is a great success. I think one can get better at this as well.
Back on topic, one phrase I really like "Make it work, then make it nice". The definitions of "working" and "nice", of course, will depend on the context. But I find it to be a helpful maxim.
Set dates and work backwards. Even better, get people to pay you and the then a date. Desiring to meet the expectations of paying customers can motivate you to cut the fat.
I'd go as far as saying clean code as an anti thesis to starting a business. Clean code is a huge battle in itself but not the battle you need to win when starting a business. Clean UI though is a different story.
Thank $$d someone someone else thinks this. I would add that TDD is a joke if you're serious about getting a product out as quickly as you can. TDD stifles that essential, fast-paced creative process like nothing else. Tests are fine. It's just TDD I have a problem with. If you have plenty of VC money to burn sure, burn it on TDD but if you're on a tight budget it will kill your ability to ship.
I couldn’t disagree more. TDD makes it possible to ship a more reliable product without superfluous code. TDD also makes it possible to move more quickly without breaking things. That “fast-paced creative process” turns into an albatross when your new stuff is breaking the old. The VC types are the ones that can actually forgo TDD because you can simply hire a lot of QA. When you are trying to ship “fast,” TDD reduces QA time and also ensures that your developers aren’t breaking each other’s work. I have hired by plenty of test-optional companies and they struggle with adding features or wonder why their application slows to a crawl with even a few hundred users — yet without tests fixing those problems results in new development grinding to a halt.
In XP parlance, a spike is specifically to allow for rapid development of a feature idea, but your entire development process ought not be a spike or it will bite you in the ass much sooner than you think and at a point where you can least afford it: when you have some mild, but not strong traction and churning users from buggy code is a real problem.
Unless you have some viral-type product (like Facebook,) move fast and break things is a terrible strategy if you care about creating a sustainable business.
Make it work, make it scale, make it elegant is smart advice, but part of “make it work” means that it doesn’t break. I would argue that pure TDD isn’t necessary, but I would adamantly suggest that shipping code without tests is far more risky than just hoping you catch issues when clicking through the application. Whether you write tests first or code first, that isn’t the issue — as long as you have tests before you ship. If you fail enough times with building a business, that’s the first thing you’ll learn.
If you've failed multiple times trying to start a business, I'll guarantee is not because of my doing TDF but because of poor product market fit. You'd be surprised how much crap a user will put up with of your products fit their needs.
Total BS. That is the bill of goods sold by TDD. In TDD the tests become as critical as the code and they are an anchor that weighs you down and slows down time to delivery. It isn't that tests are bad. Build the code, write tests to support anything critical that is a risk, but for the sake of all that is good throw out writing tests first or any notion of 100% test coverage. It's a huge time suck that does not balance out in the end.
I hate on TDD as much as anyone, but there really are occasions for its use. Specifically when the results of working code can't be determined by the person running it. The simplest example I can think of is something like a math library -- if I have code that computes the cosecant of x, I don't really know if it's working or not.
On the other hand, I really don't need controller tests for my 1.0 version -- if they aren't working, it's immediately obvious. Circle back later and throw a test on it to nail it in place if need be, but TDD is absolutely not needed when development is obvious.
The problem often is many people take statements like mine “clean code is anti starting a business” much to literal. Your code needs to be somewhat clean, just clean enough to make it to the next round. You could do TDD on that one part that is super duper critical, just not on the part that is doing basic API stuff or something run of the mill. I guess assessing nuance is hard.
However, I would allow for refactoring that deletes large swaths of code. This keeps the codebase lean and maintenance low — so that you can keep up the fast pace.
The problem to me is that this is used too often as an excuse by sloppy developers to not care about the quality of the software. It is too easy to overlook the impact 6 months down the line of the lack of design/readability of some piece of software.
I have seen this too often. Technical debt is OK when it is managed. I.e. taking shortcut when we need to ship a product or reach an MVP in 3 months is fine, but having a sustainable software will require to pay back some of this at some point, or velocity/quality will suffer on the long term.
> If you're saying "I'm passionate about delivering great products to users" or even "I'm passionate about making money" (I respect that) then technology becomes the tool you unfortunately have to wield to arrive at that goal.
I've had crooters say to me things like "I don't get the feeling that you're really passionate about these technologies". At which point I begin wondering what universe the crooter is from.
What they're really saying is - "I don't understand the full tech stack, I'm interested in gaining that knowledge"
What you're saying is - once someone understands the full stack, they're much more likely to create something good, because they're spending their efforts creating a product, instead of fighting the technology and learning how to wield it.
Indeed, people who understand the tools have a better shot than those who don't.
The only thing is by not giving a smack about the tech is that you risk looking like one of those 'impostors' by the nerd-crew who think everything is about the tech.
Also ... there are intangible benefits from our hard-core nerd outs. Let's be real: 1/2 of the tech we used may not have been invented if it were not for some dude doing it 'just cause'.
Though I do agree to a great extent - I also think Linux was made (iterated, improved upon, invested in by so many) with pragmatism and 'customer' (i.e. users) satisfaction in mind - it just happens to be free. Meaning, a great deal of the same 'outcome orientation' without being so overtly commercial.
The reason that Linux took off was because it gave the FSF a working operating system kernel they could use to build their UNIX replacement. It was a rare case where someone's personal project matched perfectly with the needs of a group they were associated with. People wanted a replacement OS and Linus delivered just enough people could make that happen.
It's a shame no one is really talking about the elephant in the room. At the end of the day, most people are working on side projects... at the end of the day. If you really want to be effective working on something that isn't your primary thing, it absolutely can't be after a full days work, even if that work isn't very taxing. Your mind needs time to not be working, or at least, not be working on things similar to your day job. Worse, is many people working on side projects are also doing it at the expense of sleep, which is kind of like doubling down on a losing bet. Sure you might get lucky, but you've still got a negative expected value from your time. People get dumb when they're tired, and worse, is they often can't even tell how dumb they've gotten.
If you want to work on a side project, you probably don't want to work on it after work. And you probably don't want to work on it on your first of consecutive days off. Even writers who claim to be night owls tend to work on their writing first thing after a good sleep.
Also, if you really want to validate this wisdom, I suggest learning to play a competitive game with a ranking system (although you may never get around to your side project if you do...). I would bet dollars to donuts to that you will tend to gain ELO/rating early in the day, and you will tend to lose ELO/rating late in the day. That has held true for me for any game I play seriously. It can be even worse at night, in that as you lose game after game, you start to go on tilt, and try to keep playing until you get that win, or until you gain back the rating you started with. It's absolutely insane, but often not obviously insane until the next morning. Also, probably just take my word on it, and don't game competitively, you're life will be richer without it. Just understand that there is a mountain of evidence that talks about how bad people are at performing when tired, and that the very best artists tend to spend most of their time recovering from their creative endeavors, punctuated by very short, very intense periods of exceedingly high focus.
A good hack to this is to wake up earlier and work on your stuff first thing in the morning, allows you to spend that first energy on your real goals, and then you can move to other stuff. It's fucking hard for me to wake early, but I really need to get back to doing this.
Edit: another advantage of this method is that you can have guilt-free relaxation on the end of the day.
I used to wake up at 5am to work on my side project (blogged here[0]). It really is the best way to go if you are serious about a side project. That blog post was from 7 years ago. I again did the 5am stint recently and only lasted a couple weeks. Although my day job now is much more stressful than it was back then, so I think that is a big factor (along with being seven years more tired...)
I suspect most people here would be better off doing something orthogonal to their work. If you spend your day staring at a screen then perhaps your side business should involve working with your hands.
My inconsequential guess is that he only not launched it yet because (i) he thinks the technology he uses matters more than the product and (ii) he is building features that should not be included in the first version.
I was able to launch my side-project (the for-profit bootstrapping biz type), a web app, in 7 months even being a junior frontend developer.
I chose the tech with the sole criteria of how easy it would be for me to build it (I went with Ember, that I use on my day-job, and Rails).
And the whole time I was constantly thinking hard about a feature and then realizing "I don't need that for now...". I then would write the feature idea in a card on my backlog (a Github's project board) and move on to the next important feature.
What I guess is making so hard for him is not the diligence, commitment or motivation, but the product decisions he has to make (and I speculate he is making the wrong ones).
The absolute best advice on side projects (and full startups) I know of is that classic quote attributed to Reid Hoffman:
"If You're Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late"
These days I even apply it to my blog entries.
No one else cares about those details you are obsessing over.
What matters is that your product lets people do something that they couldn't do before - or in the case of blog entries that it teaches them something they didn't know already.
I agree mostly with this, but I would emphasize that your first release must be usable. I've seen a few promising products get released too early by people pushing to "ship early, ship often," etc, only to crash and burn because they quickly developed a reputation for being buggy pieces of crap. Once you have a slate of bad reviews on an app store, it's difficult to fix.
I agree. If users have a poor experience, they'll be less likely to try it again after you've polished it. I'm sure there's a balance between the two, but "if you're not embarrassed" is too strong of a statement (I suppose it's an exaggeration to send a message). Plus, embarrassment is subjective.
> Once you have a slate of bad reviews on an app store, it's difficult to fix.
Not really.
Take note of what the bad reviews say, fix the issues, release a new version and repeat.
Once you've got to the point that you've resolved the majority of the problems noted, release a version in the App Store which resets all your ratings.
If you keep going - from that point on - you should be getting better reviews and ratings which will make it a more popular app and these later reviews will eventually overwhelm the earlier lower ratings.
Also once the app is actually objectively good, use SKStoreReviewController.requestReview to prompt for reviews from users to encourage more and more good ratings.
It could be said that a poorly rated app is simply one which hasn't listened to feedback and focused on constant improvements.
If your reviews are that bad, and you've actually built something decent, you can just change the name, and get a clean slate (although depending on the app store, maybe just a new version number is good enough)
100% the best example of survivor bias. Together with the Facebook quote on perfect being the enemy of good. I’ll have the nice and polished version of a product over the rushed out and buggy one every day.
> What matters is that your product lets people do something that they couldn't do before - or in the case of blog entries that it teaches them something they didn't know already.
Hard if you don't really know who your audience really is, e.g. if you're selecting projects based on market opportunity vs. having a skin in the game yourself.
I have a very different take on why you're struggling. I read this in some book a long time ago when I too was struggling with a similar problem of procrastination and this advice helped me a lot (but YMMV).
What it says is (in my own words) you have three people living in you called the id, ego and the superego. The id or the kid is the child who wants to play, be happy all the time and wanta instant gratification, while the exact opposite is your superego that wants to impress others and wants to be perfect. The ego is the middleman trying to settle the two. So anyway long story short your superego or the perfectionist is what is making you obsess over the technology and you're doing the same work over and over again (if I'm correct you've rewritten it 4 times?) yet your id is not getting any reward and just more and more mundane work, so it revolts and creates resistance and starts giving you the excuses for not doing it anymore or calling the whole thing lame.
The best approach as others have pointed out is because you're being a perfectionist. As soon as you can stop doing that you will suddenly see that work even though mundane is getting done. Also you may need some play too as you've said you're feeling like a failure (search play it away), that book may have some invaluable advice for you on how to get back in the game.
IMHO tech is the easy part. The two hardest parts of side projects are:
1. Finding a solvable problem that hasn't already been done a million times.
2. Getting users and breaking even on user acquisition costs.
If you're re-writing your project 4 times, it means you're having fun or learning(nothing wrong with that).
But for those that are building a business, it is about delivering value to end customers.
this has become increasingly hard as we are short of options for monetization,as startups focus on being acquired since many years ago
> it means you're having fun or learning
I guess developers look at the huge salaries and decide that a job with the latest qualifications is a more profitable investment of their time in the medium term.
I take it you weren't around back when the only realistic method of finding customers was magazine advertising and a 1.5"x2" ad in a tech magazine was $500/month with no guarantee that anyone would even notice it?
look at the huge salaries
For a lot of us it's not about the money; it's about being to live by your own rules.
IMHO, only half of number one is a problem, because something that’s been done a million times has proven repeatedly that there’s a market there. It might be too competitive, but it might be easier to find a profitable niche than you’d think.
I especially enjoy it when I catch myself trying to reinvent that wheel the one millionth time.
Just today I was thinking to myself "All these music player apps (of which I tried five) are really convoluted, I should do my own."
So, I was brainstorming for a short while how I would do the layout and that I need this feature and that feature and yep, my idea would be essentially as convoluted as all the others. Maybe a tiny bit more refined for my specific use-case, but seriously not worth the effort.
I've found that the heart of the problem is... money.
With money comes time. If funds are sufficient, most of those whispers are diminished.
Let's say one is sitting on a pile of money:
> A year! Why haven’t you shipped yet?
I would not be bothered by this if I could continue to fund the project.
> This is boring. Just shelve this project and move on to something fun & exciting.
With money could come the possibility of hiring someone to do the boring stuff, or making the project look professional enough that it attracts contributors who think it has a future.
> This niche isn’t big enough. You should change the target to developers? Marketers? Sales?
If the project has enough money, course correction should be much less of a risk.
> No one will actually use this. / Will designers really find this useful? / What if you launch and no one finds it valuable?
Ok, this would be a worry no matter how much money one has. Although I suppose it's less of a risk if a project is small.
I recently set out to work on a side project with virtually no funding. I wouldn't call it a mistake as I've learned a lot about myself and the nature of doing a side project full-time, but money is a biggie no matter how much motivation one can muster. Maybe if I had spent less money on fancy lunches when I worked for a company, for example, I could have bought a lot more time to finish what I was working on. Now I'm at a point where I have to focus almost all my time on finding employment because the electricity doesn't pay itself.
Next time, I've gotta learn how to raise money for what I do instead of believing I can self-fund it. lol
It's not about money, it's about time, flow & motivation.
Time is the biggest obstacle, side project implies that there's another full time job. With a full time job and other obligations such as family or volunteer activities.
Without enough long stretch of time, it's difficult to get into a flow state.
Without enough flow while working on any project motivation wanes.
The secret becomes figuring out how to manage your small chunk of time, how to get into flow fast, suspend it and resume it across time and how to keep the motivation up if you miss out on flow.
No, in the end it's pretty much all about the money. And not just funding, but about making money. I mean imagine that you did finish your side project and did ship it, now what? Does it become sustainable the moment you ship it, does it pay your bills, does it maintain itself, pay for its own infrastructure? Of course not. You still need to make money just to keep it and yourself alive, and quite a bit of money.
end goal for all side projects is not money, end goal sometimes is scratching your own itch and using it, conquering a challenge you encountered, learning whatever you set out to do, etc. I have built 100+ side projects, most of them have NOTHING to do with money. People write poems, stories, music, paint, build all sorts of things for the fun of it, and guess what? many of us code for the joy of it too.
Keeping a side project going is pretty much $0-$5/month. if you already have a VPS, you can just run it on there, or you can run it at your own server or on a raspberry pi, you can even run it on many cloud servers for free. Using serverless for instance, you can run many side project on AWS for free.
I spend most of my time doing "side projects" except for 20% freelancing. And I think the factor that makes motivation the most difficult is working alone.
If I could hire a team to work for/with me, it would be a lot easier.
Reading this blog post, I see two skills in conflict:
1. Ship now, ship often
2. Strive for perfection
The first one is required for entrepreneurs. Your "work <--> reward" iteration cycle should be as short as possible, and should end with the customer handing you money.
The second one is a skill that rewards knowledge acquisition, and can be especially helpful for those looking to improve their skillset in order to move up the career ladder. It's also an iteration cycle, but the reward often doesn't end with directly delivering value to a customer.
Lastly, I think that startup media (Tech Crunch, YC, etc) has a lot to do with this. There are way fewer stories told about bootstrapping something long term, compared to stories about successful startups hitting home runs. The reality is that the bulk of the work will be after you launch, and will likely require continuing effort in the form of years rather than months.
Honestly I think ship now ship often deserves an asterisk by it. When you’re designing large and intricate back ends for a system that needs it, and you’re a PM who only sees things in terms of end-user features, it’s easy to set yourself up for failure trying to ship so fast that you accumulate technical debt faster than you can ever pay it down (because you underengineer the underlying platform but need to support it forever to meet SLA, and good luck arguing for a complete rewrite)
That is, no mantra above a certain level of abstraction should be adhered to too strictly. Sometimes it’s better to ship 3 months later if it means 3 years of way simpler support and scaling
There is some truth to that, but most people want to try out a product before they buy it. So if they run into bugs during that trial period, then your conversion rate will suffer.
For me it started off as a need to manage my reading as I was working on another project around cryptocurrencies and reading tons of PDFs and web content.
Got majorly side tracked but launched it and so far there are a few thousand active users.
Thanks for sharing, this looks neat and useful! The pagemarks are an interesting concept. It would be cool if the top progress bar above the document showed, not cumulative progress, but the progress as it maps to the areas marked on the document, which aren't necessarily contiguous. Kinda like the progress bar you have for a torrent as non-contiguous chunks are downloaded. This provides spatial information about what parts of the document have been read.
I have launched several side projects a couple of them financially successful.
They have had plenty of bugs in them and I got several angry emails about various things, but over the time I have fixed them as they come in. It's a great way of prioritizing what of that last 20% you should fix.
In other words. Ship as fast as possible, treat it as a project then over time improve. If you have something of value people will use it even when it's not optimal.
Really, you probably don’t want to hear this, but you need to ship. You have probably overbuilt already.
The reason I’ve basically embraced a lifestyle with a “second job” is that it’s enormously rewarding both intellectually and financially. Over 4 years the business has grown from a “hobby that made me a few bucks” to meaningfully changing my families financial outlook.
There is no way I could have sustained the investment without those two sources of reward.
I'm about halfway to launching a side project (I seem to be close than 50%, but there's always the 90-10 rule).
It's been fun. I've been writing the backend in rust, using squire for storage, and actix-web for the server framework. The front end is plain html without a lick of js. And my css is really just compiled scss.
I'm happy to report I've only engaged in a small bit of yak-shaving (writing a custom derive for defining APIs I need to hi from my backend for integration purposes) and only a small bit of framework churn (I switched web server frameworks because I wanted an abstraction that wasn't ergonomic/available in the initial one i had chosen).
And it's been fun. The best part is that even if it flops, my wife and I will still use it.
I have already cut features - I was going to launch with multiple integrations, but I decided to just do one. The difficulty is carving out time, and being painfully aware that anything I go to do could give me a grief and cost me lots of time trying to figure it out :)
I am mostly done with the bare minimum of what I need for it to be usable for myself. I have a little more work to do. Not much though, I've tested the most of the bits I still need to do. Now I just need take that learning and finish building it.
I think I'm only halfway because I need to get billing working (planning on integrating with Stripe - there goes my no JS goal...), fix the CSS so it doesn't look terrible (doesn't need to be fancy, just passable), and work on my error logging / reporting. So... mostly polish. But not feature polish, but "don't drive away potential users via stupid stuff" polish.
Edit: I do hope to launch by Jan. 1 since new years resolutions could be a great driving force for new user signups, but your assessment is a reasonable guess.
I've heard of quite a few products that launched without billing in place yet.
They gave users a 30 day trial period, so starting on launch day, they had precisely 30 days to get billing sorted out if they hoped to be able to charge anyone.
A free trial period may or may not be suitable for your product. But you can probably get by without it on launch day.
You could even launch in beta mode and give people access in exchange for feedback.
If you're targeting graphic designers, then go ahead and tweak that CSS. Otherwise, go ahead and get some real people using it. If they're using it to solve a pain point, they'll quickly tell you what's good and what's not. And if they don't use it at all...well, that's valuable feedback too.
Agree with this regarding billing. I just made the mistake of spending a ton of money on getting this working and mind you I don't have any customers. Stupid stupid stupid.
Thank you for the advice. I hadn't considered launching without billing. I don't think a free trial for my product could be very long (since it involves sending lots of SMS which would cost me quite a bit if I get a big user spike). But I think I can provide a sort of demo without that bit.
Right, that makes sense. It's not the right fit for every business idea.
If you could find yourself a 5-10 beta customers, perhaps launching to them before billing is ready might work? You could even perhaps set a cap on how many SMS messages they can send per day or week. That would keep your costs low while still getting you some feedback.
You should of course do whatever is best for your product. I've just learned from experience that launching as soon as you can is great, because you'll often find that many of your assumptions about how and why people will use your product don't match how they actually use it.
I agree. Getting billing to work isn't the most important part. Get users first. If you don't have anybody using your stuff, having a store won't do any good. Once users complain that they can't pay you, you know you're on the right track.
You can always invoice them manually as long as you keep track of whatever your billable items are. If its SMS's then keep track of how many they've sent and there you go. As long as they pay that is, otherwise you are out of pocket.
Integrating SMS (Twilio/Plivo) with Google Spreadsheets for Budgeting purposes. Basically allows people with custom budgets to get an easier form of transaction recording.
I had been using warp, but I wanted to write a custom middleware for some session / cookie management, but ran into trouble, so I moved to actix-web.
The google api crates also didn't seem to compile/work right for me, so that's why I wrote a custom derive. Basically, it allows you to define a struct that represents an endpoint, and you can just mark what get's included in the query, body, or in the url with some nice interpolation. And then I defined a endpoint processor that can take that and execute it, deserializing it. I implemented that for the reqwest client and for one of my custom structs, a google api token.
Here's an example of what a marked up struct looks like: https://gist.github.com/samsieber/d2efec774320c0af01ee72cb09... . It's a little rough around the edges, but I think by the time I'm done it'll have acquired enough polish to release it on crates.io - it's been super useful to eliminate a lot of the fiddliness I had been doing with making requests.
Don’t mean to be mean (i’ve been there) but this is the money line “Re-written the code base 4 times (Laravel, Vanilla JS, React, then back to Vanilla JS).”
Is the goal to ship or play? If latter, no harm done, else that’s your resistance, nothing else.
So true, I'm constantly plagued by those thoughts to stop whenever I work on anything, in case it's either not good enough for the public, boring, not gonna sell/find users, etc, and every minute I spend working on my projects is a battle between declaring I'll actually finish them this time around and a feeling of 'relax, you can take more time here'.
That said, they're not the only issues. In fact, I'd say what hurts me more than the nagging thoughts in the article is a deadly combination of OCD esque perfectionism and a tendency towards feature/scope creep that really needs a good project managing laying down limits.
This means endless reams of time is spent on 'nice to have' features that keep wasting more and more time, like a one person version of Duke Nukem Forever. And then even more time is spent procrastinating because I'm worried about said goals being too ambitious and the amount of work required to meet them being overly daunting.
Still, I guess it's not a unique issue, and I suspect this perfectionism is why (as some others commenting here mention) many successful entrepreneurs are the kind who can step back, stop trying to be 'artistic' and just get the damn thing done, tech be damned. Heck, sometimes I suspect someone like Homer Simpson/Peter Griffin would probably be the ideal entrepreneur/founder, since while they're not particularly bright, they've also got no inner filter whatsoever, are completely delusional about how good their work is and are willing to jump into new projects and ideas without a second thought. I'd rather be a delusional moron who gets things done than a normal person haunted by inner doubt and constantly worried about whether their work is good enough.
Either way, hopefully I'll just bite the bullet and get my current projects in the next year or so. Better to have something rather than nothing.
> Heck, sometimes I suspect someone like Homer Simpson/Peter Griffin would probably be the ideal entrepreneur/founder, since while they're not particularly bright, they've also got no inner filter whatsoever, are completely delusional about how good their work is and are willing to jump into new projects and ideas without a second thought. I'd rather be a delusional moron who gets things done than a normal person haunted by inner doubt and constantly worried about whether their work is good enough.
I know a guy like that. The problem with being a delusional moron is that his execution skills are poor (on account of being a moron), so even though he works hard on stuff, it likely won't amount to anything.
I'd be happy to look over your project and its features to let you know if something should be a v2 feature. Kick you to the finish line so to speak and keep you accountable.
In fact, this would make for a nice community. Anyone try to set one up like this?
My philosophy has always been "make it run, make it right, make it fast". If it runs and is functional it's good enough to ship and release. Making the codebase pretty and optimizations come afterwards
The trick is finding a problem you have a passion for. That way, no matter what or how long, it won't feel like work. Your side project is the sabbatical.
The downside to this approach is that it can kill the passion for the thing you were passionate about.
Also, I've noticed that real world solutions to problems tend to include lots of schleps that are excruciatingly boring, but necessary.
The longer I do this kind of work, the more strongly I believe that the people who are most likely to see a project through to completion are the ones who have the stone cold professionalism - or just plain stubbornness - to grind though the boring stuff instead of just faffing around on the bits of the problem that they're passionate about.
I think a side project that's just about indulging a passion is totally fine. But a side project that is also a product that makes money will almost require lots of pieces that definitely feel like work.
The problem is that whatever the problem you're trying to solve, the parts you have a passion for are only small parts of the overall solution.
It's the rest that gets you (e.g. you might like coding the backend algorithms but hate UI work). And even if you love all parts, you'll probably still hate the minutiae that goes into a finished product.
Side projects are hard when you are using "best practices" from Google and Facebook, choosing the best and "most right" js framework, even landing page looks like landing page of "best unicorn VC companies".
For me, it's easy to complicate things by saying "for this side project I'm going to learn new thing X" -- using 'learning something new' to help justify the time spent, but usually screwing up the project as a result.
I've found that setting a very hard deadline, ideally with some money on the line, is the best way to guarantee something gets done. It seems like this should be the authors next step. To get my last video out, I sent a friend $200 through Square Cash and said "Only send this back to me if I have X published by X hour on X date". It worked!
I definitely feel resistance in the last stages of side projects, but I don't necessarily buy Pressfields reasons for why it's there. Still valuable to know it will be there ahead of time though, regardless of what its origins are.
12 years ago I could code on a side project 8 hours straight. It was fun and exciting. 6 years ago I could do that, but with less frequency. Today its a rare thing that I can even sit down and get in 4 hours in. My computer is littered with barely started projects and a few projects sitting around 50%-90% completed.
The last side project I was able to hammer out was a thin API wrapper that I open sourced to github. It only took about 4 hours to code. It's a piece of a bigger project I am working on. Maybe thats a possible solution? Breaking your bigger project into smaller chunks?
> Maybe thats a possible solution? Breaking your bigger project into smaller chunks?
Definitely. Anything I cannot hammer out in a weekend I break into smaller chunks and treat each one as a separate project even though they are all contributing towards one larger one. This advice generally works great for any large type of problem or endeavour.
> "Re-written the code base 4 times (Laravel, Vanilla JS, React, then back to Vanilla JS)."
The path of least resistance is to research all available options, pick one, and see the project through, not to jump back and forth. It's a side project, but still, this isn't going to make it any easier.
That aside, the side project looks like it could see a good degree of success. I wouldn't use it because it seems like it's way too simple a feature to outsource, but then again, many companies also pay for simple customer / customer-service instant messaging services.
I fully agree with the premise but many times, it's just way too hard to actually predict the production problems you will have even with your most favourite tech.
Truth is that while working in a corp you can't see the big picture of seeing a project through from start to finish.
For example, I am helping on mostly good faith -- and at about 30% of what I'd normally charge -- a friend to bootstrap their website / platform and even though I use language and tech I very much like and I am the dictator of the backend, 95% of the work is extremely boring and it's just "make this controller, make this API endpoint, wire this object to that other object, integrate this payment provider" etc... Combine with the universally bad deployment experience of basically 99% of the languages out there and things aren't really that glorious even if the tech is much better than what you worked with your entire life beforehand.
What I am saying is -- even for every experienced programmers it's very hard to make an accurate prediction.
But if there's one metric I always use, it's this one: "does the tech stand in my way to productivity and waste my time with details I shouldn't care about?" -- if so, I try to ditch it (not possible with JS but still, there are transpiled languages and frameworks that make things better).
This is relatable. I have even begun to read "War of Art". Consistency is key to momentum.
My most recent project won an overall award at ETHDenver - which at the time became the world's largest cryptocurrency hackathon. My teammate and I created a cyberpunk-themed cryptocurrency trading game based on the classic Drugwars. My teammate is a great multimedia/graphic artist, and it was very well received. If interested, Beta is at https://www.cachethegame.com.
However, I would about 20% of the current total project (it's been 9 months) was completed in the 36 hours of the hackathon. We were on a roll.
After the hackathon - we ended up talking to investors, but decided to pass. This is a double-edged sword with downside.
"Side" projects are hard in the way self-guided learning is hard. You don't have people breathing down your neck periodically to keep you on track.
The further we got along to releasing a Beta the more the "Resistance" crept in. To the point of, as soon as the Beta was released - basically taking several weeks off altogether.
This is where some seed investment would have helped, besides the obvious ability to clear the calendar a bit. Forget big splashes of "raising a ton of money" or an ICO - it's practical to raise a bit money for reasons I mentioned.
I've found that if I can't just complete a certain feature, task or function on my product, and it keeps dragging on, then there is likely a reason for it being too difficult (more than just laziness on my part!)
A good approach when this happens is to redefine the feature. Either by reconsidering its importance, investigating different ways to achieve a similar outcome or mostly decomposing the feature into even simpler and more minimal deliverables and implementations.
Then deliver the extremely minimal implementation.
In a lot of cases you then come back and make it more rounded later on, or in many cases, the simpler deliverable is actually all that is required and you move onto something else entirely.
It's taking a disciplined and strict MVP approach to every task you have and focusing more on continual delivery as a north star. This tends to work because – as noted by the author – giving up on a side project is the biggest risk and one of the larger reasons for failure (you can't succeed if you don't show up).
By always delivering something/anything you get the satisfaction and reward of progress which is a lot of times all that is needed to keep going.
* No one will actually use this.
* Will designers really find this useful?
* What if you launch and no one finds it valuable?
Why not do some basic user research and get people to pay for it? This isn't some new ground, there are literally hundreds of internet gurus all saying that if you whip up a prototype, present it to people, and they pay for it, you'll have a higher chance of success.
Then you analyze feedback and redo your prototype with what your customers need?
The key thing is understand the underlying desire. Ford is famous for saying that if he asked people, they would tell him they wanted a faster horse. He understood they wanted a quicker means of transportation, so he built a car. That's what you do with the feedback of the prototype. Listen to responses, and adjust or abandon.
As for experience? Not directly, but seriously, this isn't hard. This is literally the standard way every successful businesses operate. They analyze market demand, built an answer, get feedback, and adjust. Only very rarely does an individual's personal itch ever become a successful product.
I was discussing this with a lawyer yesterday and she had something interesting to say about that.
At least in my jurisdiction both parties must act in good faith. This includes knowingly signing an invalid contract and blowing off some obligations in it on the premise that you didn't have to comply any way because it wasn't valid in the first place. In such cases it can be construed that you did act in good faith and a judgement made against you.
Bingo- has there actually been a recorded case of this happening to someone who’s working on an unrelated project? Obviously if you copy your employers product or do something very similar it’s suspect, but if you work for a defense contractor and build a social network for cats in your spare time, they’re not going to care
Are there recorded cases of this happening where the employee won? I've heard of those 'used a company laptop to work on the project so the employer is out for you' cases, but never read much in detail.
I don't know how to even begin figuring out whether something is enforceable or not. I read a news article that Canada isn't that protective of employees in this sense, but forget the details.
My breakthrough this year has been working on a side project that really really isn't just me. It's a collaboration with a small research group at a university.
I do my stuff mainly outside of work, and generally am improving the group's overall research bandwidth, rather than taking a full project on all by myself. Having some social obligation to keep the relationship going is enough to overcome a lot of the little hurdles, and having some excited feedback when I make some genuine progress is super helpful. It's also been a great chance to just meet lots of lovely people in the community, and having the communication has helped me make progress much faster than I would have on my own.
And best of all, I get to have the feeling of doing some real Science, in an important but generally underfunded problem space. It's been great.
I spent about a year or so reading and reimplementing interesting papers around machine learning on audio - probably six months was actually getting to know signal processing in a real way and learning tensorflow, and then some months doing seq2seq for ASR slightly more seriously. And now I've been doing things that you can find in the lifeclef or dcase competitions, with a group that focuses on one of the sub tasks.
Good luck. If you use your side project, it's worth it. If you learned new skills, the project taught you better than any textbook.
Marketing is hard. If you ask people what they want, they don't know what they didn't imagine. (Insert quote by Henry Ford about a faster horse, or the St Pancras train station champagne bar, etc). It's better to build something first, and if people like it, continue developing it.
I've made several Show HN, and occasionally even been offered jobs that way. I need a job now, and I've tried some more projects with that purpose, sadly without success. I think it shows motivation and initiative far better than a résumé, though, and attracts like-minded new friends.
Landing a job you deem [almost] perfect for you is, as many other things, a matter of luck beyond many other factors.
Very uncomfortable truth and something I had to gradually accept over being unemployed for 6 months (in fairness, I had enough money reserves to live very comfortably for 4 of them).
I am not gonna bore you with my story but the bottom line is -- keep trying. As you said, marketing is hard. But very, VERY essential, including in how do you present yourself in interviews. In the end what landed me the job was an injection of optimism I got from a really good massage by my wife and then 8 hours of tight sleep -- I used that optimism to send out several more job applications to leads I deemed highly unlikely to even get a response from. And lo and behold, 3 days later I successfully moved through all phases of the interview process of one of the companies, and I am starting in several days.
Don't let a bad period get to your head, no matter how long it may be. Persistence is basically your #1 advantage.
As a perfectionist myself, I continue to learn that you have to live with some "shit" in order to get your stuff out there. There's the tendency to rewrite/refactor, this makes side projects harder than it needs to be. It's self-defeating, really. There's plenty of time if you succeed, but no time if you don't.
The perfectionism also prevents shipping because you want to avoid the impending negative feedback of your current project, and so you bounce off to something else.
How to overcome? Experience (and failures) helps. You've spent so much perfection on something and it still didn't succeed the way you hoped. The next time you would care less about perfection and just ship.
I can't relate to this at all, I work on a side-project for a week or so and then launch it. Here's last week's, a community of maintainers that aims to maintain abandoned FOSS projects:
I too have a side project that is nearing completion but I'm nervous to launch it. It's nerve-racking not knowing if and when someone might sign up. As a a non-dev it's even harder since I had to pay a developer out of pocket. I'd this doesn't work I'm out of a lot of my personal money.
Hi Dave,
Kudos for sharing what you experienced. I actually completed a year working on https://shareseer.com on thanksgiving day. It is a side project. I have found shipping whenever a small milestone is hit to work for me. Another trick i use is to keep a backlog of items that need to be done, which brings me back to work on it. Thirdly I really care about the problem. Fourth an d finally I realized distribution is a vastly harder problem than product. Getting people to use what you build is the core of whether the product succeeds or not.
I think this is natural. The line between a hobby project, and unpaid venture can be quite thin. When your attention is split, it only becomes harder. Most rational people want to live life a little, and not work constantly.
I know I'm nitpicking here, but I find it annoying when people say things like: "If you’ve yet to read these x books, do yourself a favor and buy them today".
Did myself a "favor" a few times in the past and every single time I only read the first couple of pages and ended up giving them away. Or worse, I get FOMO so I keep those books around and it becomes clutter around my small apartment.
Its hard to focus and read the rest of what the author has to say if he makes blanket statements like that.
It's not a wholly terrible strategy to use peoples recommendations but it usually serves me fairly well to only take recommendations by people I hold in high regard.
Usually, after I build everything out, I debate whether I want to publish my work or not. I find that to be very hard. What motivates me is at least sending it out to my friends and getting validation that this is good and I should share it. So that pushes me to do the extra mile for polish.
My year long application update is finally nearing publication. The emotion and fear are very real. The psychosis resembles combat fatigue. It’s exhausting to think about, but I know people have waited on this and depend on my delivery.
Just started a side project and hit all of these ideas. For me they just aren't pronounced enough to be stopping points at this early stage. Hope this helps!
My friend developed first then Soviet software-controlled modem. He said they experienced more line cut-offs (hangups by telephone line operator) during testing next to the end of project (which was a success). He explained that their modem had crude analog adapter and caused a lot of noise and/or interference with the other phone company machinery. He said he also suspected KGB who they may thought that this is new voice scrambling device.
Basically, the Resistance is real, but can be explained by some real factors, just like in the novel above.
I am amused by how easy I find it to work on corporate drone work 8-12 hours a day + during my vacation, but have a hard time forcing myself to work even a couple of hours on my own stuff.
I think it's because in the end, it's hard to really believe it's not all for nothing.
I find it hard to do the bullshit company work(now it's more like startup, but corporate was hell too) while daydreaming I was spending my best hours and fuel on a number of things else that I'd rather do or work or build. But after 8-10 hours, since I only have the leftover fuel and small hours, then the incentives become more twisted.. e.g.: 5 hours left on the day, I've been thinking about working on my project all week, I need to rest a bit, I want to read, movies I'd like to watch, maybe I should skate or workout a bit to get a better mood, or get something to eat, will I get more stamina if I try to work at home or do I go to a coffee? Will it be worth it today to put 2 hours into my project, or will it just stress me out more? Maybe should I meet friends and have beer and hash because I'm already too stressed out?
So it becomes really hard. What I mean is that not having enough space/time to properly do your stuff really seems to matter to me. When I'm free for some days, I have no problem at all focusing on sorting through everything(treating myself, working on my projects, studying, doing physical activities, socializing), and I feel much more complete.
It's funny because what I consider to be for nothing is jobs, the biggest outcome possible out of a job is generally just another job in which you could have more of responsibility/flexibility/learning/money, but still just the same thing(I guess the payoff can be more promising in US or Europe, but I suspect this is an illusion for most). If you leave, they'll just find someone else to do the job, so really it doesn't matter.
It's the same for me. The answer has been to reduce my spending (incl. a decision to not have kids) and get well-paying fixed-time contract gigs. They require me to move from my (cheap) home town to a city (often in a foreign country) that's hellish for me (like London). I deliberately consider those period of my life as "working on an oil rig". I go to the rig, do the work for 6 or 12 months, am miserable there (from shitty work, no free time, no friends or family, usually substandard housing etc.) and come back with a nice bundle of money that can sustain me for a couple years. I have not managed to find a way to live a satisfactory life while holding a full-time job, and at this point I don't think I'll ever will.
This is pretty much the only reproducible solution. Investing in personal brand and networking can bring in remote contracts. Remote still consumes all your energy but it avoids a lot of the unpleasantness of being on contract.
I had some remote contracts as well. All in all, I prefer to move and work at the company's office. Remote software development is IMO much harder and less attractive that the in-person variant, so I prefer the hassle of a move.
I’m literally laughing out loud. I thought I recognized your username: you were one of the ones calling Boss as a Service a complete scam for losers who have psychological issues motivating themselves. And yet here you are, talking about how it’s easy to work on boring corporate stuff where you have a boss, but it’s nearly impossible to motivate yourself on your own stuff.
Which is exactly the issue that something like Boss as a Service is there to solve.
It’s so perfect that I’m pretty convinced this is a subtle troll on your part.
Hmm, saw this just before heading out. It's not a troll. It has nothing to do with having a boss, it has to do with knowing you are getting a guaranteed paycheck and knowing you need that to survive or maintain a certain lifestyle.
Not OP and I think too it's not about the boss. But marketing and sales as a service could be a help. I guess this is at least a part of the job that investors are doing for the startups. Maybe not marketing and sales but guidance to get a ROI.
The book invokes the pagan notion of a pantheon of gods, rather than the Judeo-Christian God. He describes a ritual where he propitiates the Muses (the gods of creativity) before sitting down to write. You might find it easier to swallow, because when people invoke the J-C God they often mean it completely literally, while the Muses are clearly allegorical.
But to get through the book, you have to suspend your rational empiricism quite a few times. Perhaps no more than to read The Odyssey or Macbeth, where internal human struggles are illustrated with supernatural imagery.
Many of the greatest human achievements in both art and science have had explicitly religious motivations. I'm an atheist myself but it seems like it might be worth exploring / understanding that if one wants to achieve something great. I've no idea if this book is helpful for that - I've never read it though I have seen it recommended several times - but it seems like an interesting topic to explore regardless of one's personal religious beliefs.
Despite my own lack of belief, to my taste religiously inspired art and architecture of the past seems to reach a level of greatness that seems missing from much of the modern God-free stuff.
I think we are going off-topic, but: 1) a lot of old art was commissioned with religious themes, regardless of artists' feelings, because that was the socially-acceptable thing to do; artists simply illustrated stories, giving it a personal spin. They are more akin to, say, illustrations for a modern movie production, than to a Warhol or a Duchamp. You might be responding to that. 2) if your parameters of greatness include "life-likeness", anything since the invention of photography will be disappointing, because artists stopped trying (they obviously couldn't compete); and 3) democracy freed artists from having to convey The Message, be it God, Nation, Progress or whatnot. Left free to choose topics, artists moved in other directions. Contemporary art is very cerebral and polemic, all the fun and sentiment is in pop.
I read this book this week. Its not well written, the „wisdom“ in it could be broken down to one page, and the religious explanation leaves a bad taste. Still there are some parts in it which are true imho and are often forgotten. For example that its necessary to be not cynical about your work, and treat it like something valuable which is not owned by you. To leave your ego out of the work and do the work for the work.
If you're saying "I'm passionate about delivering great products to users" or even "I'm passionate about making money" (I respect that) then technology becomes the tool you unfortunately have to wield to arrive at that goal.
Note that this attitude only applies to people who want to take ownership and deliver a fully functional product. There's tons of great people who are in it for the sheer enjoyment of working with technology, they all will have a great time working on challenging problems at one of the many tech companies. And there's a few people who can both enjoy technical challenges but also switch to dumb and boring crunch mode when it's demanded by the task at hand.