The Resistance Is Real – Why Side Projects Are So Hard
davemart.in
davemart.in
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.
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.
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.
If someone cares about solving a problem, that's what he/she will do.
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.
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.
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.
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.
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.
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'.
In the backend make it work. Later make it perfect, scalable, etc when new features demand it.
I think we're all part of this on some level.
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.
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.
I would call that marketing.
serving the customer happens after they are found, to adapt your solution to the actual problem the customer has.
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.
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.
When it's 4 days or 4 months, then it becomes an issue.
I would dig myself into a well so deep it might take a month to crawl out of before my code is useable again, but it would be a huge waste to stop.
If you’ve only invested 4 hours it doesn’t seem that bad.
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.
Sources: Losing My Virginity (Richard Branson's autobiography) and the Wikipedia page on Virgin Atlantic:
https://www.businessinsider.com/richard-branson-entrepreneur...
https://jamesclear.com/successful-people-start-before-they-f...
https://en.wikipedia.org/wiki/Richard_Branson#1981%E2%80%931...
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.
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.
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.
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.
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.
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.
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++).
I bet no one at Facebook can say that
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.
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.
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.
Edit: another advantage of this method is that you can have guilt-free relaxation on the end of the day.
[0] https://www.mattgreer.org/articles/waking-up-at-5am-to-code/
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).
"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.
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.
And in the case of side projects: "Best practices are the enemy of fun"
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.
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.
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.
And yet it seems like everyone has a dozen different ideas for this killer app.
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.
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
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.
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.
If I could hire a team to work for/with me, it would be a lot easier.
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.
1. Ship now
2. Ship often, and strive for (eventual) perfection
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
.. but it's sort of become full time.
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.
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.
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.
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.
Edit: I've only been at it for a couple months
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.
I have no idea what you’re working on but I bet you don’t launch till March at least.
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.
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.
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.
Is the goal to ship or play? If latter, no harm done, else that’s your resistance, nothing else.
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.
In fact, this would make for a nice community. Anyone try to set one up like this?
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 think keeping the scope as small and simple as possible might be even more important than passion.
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.
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.
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.
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?
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.
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.
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).
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.
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.
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.
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.
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'd love to be a part of something like that... but definitely don't have the network for it.
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.
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.
Good luck to you!
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.
Why rewrite stuff? Just see if people want what you're building first and then figure out whether it's well-written or needs a rewrite.
What do you have to lose at this point? The money's already spent.
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.
I think it's key to realize:
* you have to be really into solving the problem
* you probably aren't going to make much money from it
* a side project is a great way to experiment with different tech
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.
Source: self.
I think it's because in the end, it's hard to really believe it's not all for nothing.
For myself, at least, I feel that drone work is obviously for naught, which makes side project failures that much more demoralizing.
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.
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.
I think I found a problem with your approach.
When God entered the picture, I lost all interest.
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.
The author believes in God and isn’t afraid of letting you know about it.
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 only read it to the end because it had been recommended so often and I hoped there was some pearl of wisdom waiting for me. There wasn't.
At least have a good read of the preview pages before you buy this one – it is 100% not my style, and I won’t be touching it.
Edit: turns out it’s easy to get a refund on a Kindle item. Nice.