>no more overly ambitious build pipe-lines.
What exactly are build pipe-lines ? is it javascript webpack kind of stuff?
How to never complete anything
181–190 of 220 posts
Re: How to never complete anything
#182I finished my side project a couple of years ago, released it, and then found I was able to quit my Python webdev job and go full time making video games. The key difference is that my project was a video game (this one: https://www.youtube.com/watch?v=YwXl8lDrxn8 ) and that takes a lot of temptation to do what the OP is writing about, rewriting stuff in Haskell for example. The interesting bit when it comes to side…
Well, it must be easy when you can make art _like that_ ! Kudos!
Hah, well, thank you. My academic training is all in Computer Science, but I've enjoyed drawing since I was a kid. Still feel like such a beginner in that whole realm, been teaching myself animation and design and 3D modelling in the last five years, I think it'll take another five years to really get anywhere!
Re: How to never complete anything
#183Two things have made a huge different in my ability to finish/ship: 1. External Deadlines. I'm a career teacher, mostly self-taught Python/Django developer, and am applying for dev jobs. The school year's over in June, and I want to be able to step into a new jr position in July/August. I'm planning to resign my position this spring, and cannot be out of work. My benefits and salary will stop in September. I'm f'ed i…
I came here to mention 'Deep work' (which I found a very effective way to do and talked about on HN previously [1]) AND another tactic which is giving me good results.
The trick I found to complete things is:
Do not switch ladders of abstractions. When working on a modern web application (with backend, frontend, css, testing etc) if you start with writing backend API calls, then just write all of them first. Starting with the API call for /user', /signup, /login, /compose, /rate, /play. Don't worry about it working. If you do TDD then fine, but if you don't tests before you write the code, then avoid writing tests until you're done writing the basic code for your API. Then you write tests for it and make sure that each endpoint at least works.
Then write E2E testing for it(for the backend). E2E tests are a great way to build your app with it's core functionality full working and validated. In other words, write unit tests which first call /signup, then /login, then /compose then /play (which is I presume one full flow of a user). This will help you figure out issues with your API and it kinda feels like writing a full app.
Once you're done with testing, then write the frontend, just simple HTML, don't worry about CSS. Don't try to grab React + ES6 + Redux boilerplate or things like that. Just go with the simplest thing. Even if after every action user has to refresh to page, so be it. Oh you heard about CycleJS and think that you should be using that instead? Well guess what, you purposefully chose a really terrible technology to build this app, so once you're done making your app in that crappy tech, then you can rewrite it in CycleJs or anything else you want.
This way, even if you abandon your CycleJS rewrite effort halfway, you'd still have a completed project(and trust me, you will never let your app be stuck at static HTML with no CSS). Chances are that you'd abandon it, when you've already written your app in CycleJS but made a new rewrite effort to write it in Vue.JS.
Basically idea is, you think in terms of one layer at a time, and you defer all desires to refactor things until you are done finishing that layer.
Re: How to never complete anything
#184Earlier quoted context omitted.
> Stop lying to yourself because it's not doing yourself any good. The only reason you're not releasing your side projects to the world is because you are afraid of criticism. I often set the bar so high there is no chance I could ever finish. The only projects that are attractive and shiny enough are those that are too big to finish. E.g. I could choose between writing, completing and shipping a small indie game. Or…
I find your OS example a little bit misplaced considering a quite complex OS can be completed by one person (obviously more complete than "hello world") but regardless of that, the commercial value of a new OS is quite low but the usefullness of learned (I'd say) is quite high.
Hell, even Terry A. David completed TempleOS, and he's mentally ill.
So yeah you sure could complete and release shit, you just don't want to for some reason or other.
Re: How to never complete anything
#185Earlier quoted context omitted.
They are afraid that they will get hurt if they try hard and no one still wants their thing. I'm in this kind of release, not because of fear, but because promoting project takes times (a full time job for some people) and I prefer to spend my time programming something else
Yeah, it takes a huge amount of time and effort to make your voice heard and your project promoted. I have a feeling that naturally extroverted people do not understand that it takes a real push from other to show your work to strangers. Same thing as the discussion about "demo days" earlier today. Those who are good in promoting are not necessarily those who are good in building projects. This applies to other aspec…
I have a feeling that naturally extroverted people do not understand that it takes a real push from other to show your work to strangers.
Re: How to never complete anything
#186Okay, I am going to share my secret for finishing. I discovered this late, but am glad I did. Are you ready for it? The secret is this: don't start something till you finish the last thing, no matter how poorly. This goes even at a "micro" level, so don't start distributing the load on servers till you finish the last thing (interface), no matter how poorly you finish the last thing. Now you have the secret. Go forth…
I beg to differ. Sometimes things need to settle down or you have to gain some distance. This can take months or even years.
If you don't have an external deadline, you can afford finishing things when you are actually ready for it.
Re: How to never complete anything
#187Earlier quoted context omitted.
I find your OS example a little bit misplaced considering a quite complex OS can be completed by one person (obviously more complete than "hello world") but regardless of that, the commercial value of a new OS is quite low but the usefullness of learned (I'd say) is quite high.
Hell, even Terry A. David completed TempleOS, and he's mentally ill. So yeah you sure could complete and release shit, you just don't want to for some reason or other.
[deleted]
Re: How to never complete anything
#188I can't imagine ever shipping a side project. That's not why I build them. If I ever got to the point in my life where I do want my own company, a side project is not the way I want to go about it. Companies take a lot of work, that work has to be understood, then delegated and shared. The technology aspect is really only 10% of it. Sure, it's the essential 0-to-1 kicker that gets you going, but once that's done you…
>That quickly assumes second-job status and can wreck your personal life.
Your what?
Re: How to never complete anything
#189Right on the money this one: https://neilonsoftware.com/2017/03/10/my-response-to-how-to-...
I have been developing professionally for 7 years now and had similar experiences. It's important to allow yourself to stand still, if vacations aren't possible, exercise and meditation might help you a lot too.
Re: How to never complete anything
#190Okay, I am going to share my secret for finishing. I discovered this late, but am glad I did. Are you ready for it? The secret is this: don't start something till you finish the last thing, no matter how poorly. This goes even at a "micro" level, so don't start distributing the load on servers till you finish the last thing (interface), no matter how poorly you finish the last thing. Now you have the secret. Go forth…
I beg to differ. Sometimes things need to settle down or you have to gain some distance. This can take months or even years. If you don't have an external deadline, you can afford finishing things when you are actually ready for it.
This is actually a good insight and I agree with it. However, I don't think it contradicts the essential statement. The wiggle room is in "however poorly."
So you might want to edit it, but finish the first draft. You might need to tweak it, but finish the first version that actually works.