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.
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.
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)
> 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.
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.
> "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).
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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++).
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.
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.
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 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.
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.
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.
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.
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.
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.
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
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’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.
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.
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 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.
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
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.
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.
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.
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.
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.
200 comments
[ 2.9 ms ] story [ 230 ms ] threadWith 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.
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.
"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.
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).
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.
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).
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.
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://en.wikipedia.org/wiki/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.
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 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.
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.
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
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.
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.
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.
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.
Is the goal to ship or play? If latter, no harm done, else that’s your resistance, nothing else.