3 ms·

Two 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, an

Two 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 if I'm not working by then. The need to ship projects (if only into my portfolio) is high. 2. "Deep Work" for time management. Ideas from Cal Newport's book "Deep Work" have been foundational in my getting more done. It's hard to find the energy to build my side projects/portfolio after wrangling eight year olds all day, so I started getting up at 5 am solely to work on my projects. I make coffee and toast then get to my desk. I close all applications except Atom, Dash, and Firefox; turn on Do Not Disturb; look at my to-do list in my notebook; then get to work. Having 75 un-interrupted minutes before my wife gets up allows me to get a huge amount done, and it's become gratifying to watch the 6 am commits pile up on my github punch card. I've also found that exerting discipline in this facet of my life has had a positive knock-on effect in other areas.

rickdg 10y ago
So your recommendation is to sacrifice sleep time?
- lukewrites 10y ago
  I edited that bit out of my post above. I guess it's about prioritization. I had to make tradeoffs to maintain the schedule and not be worn out at work. I decided to start going to bed a bit earlier so I could get up earlier. To facilitate this, I changed my workout schedule (I'm doing HIIT for cardio rather than time-based workouts) and cut some other activities that didn't seem as important as my other goals. Worth it.
splintercell 10y ago
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. 1. https://news.ycombinator.com/item?id=13813173 https://news.ycombinator.com/item?id=13813173
- lukewrites 10y ago
  Mental Models sounds fascinating, thanks for the suggestion.

rickdg 10y ago

So your recommendation is to sacrifice sleep time?

lukewrites 10y ago
I edited that bit out of my post above. I guess it's about prioritization. I had to make tradeoffs to maintain the schedule and not be worn out at work. I decided to start going to bed a bit earlier so I could get up earlier. To facilitate this, I changed my workout schedule (I'm doing HIIT for cardio rather than time-based workouts) and cut some other activities that didn't seem as important as my other goals. Worth it.

splintercell 10y ago

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. 1. https://news.ycombinator.com/item?id=13813173 https://news.ycombinator.com/item?id=13813173

lukewrites 10y ago
Mental Models sounds fascinating, thanks for the suggestion.