3 ms·

It takes me an hour to even ramp up with all the context for anything of value... color me impressed.

by tbrock 8y ago

beaconstudios 8y ago
I'm fairly new to this process myself but I'm finding the trick is to keep your designs extremely clean and easy to mentally model using types you can reason about. Then your software's features can emerge as interactions between "systems". That way (along with many other benefits) there's less to remember as you start coding. I find this post from the other day explains the principle better than I can: https://danshumway.com/blog/design-is-implementation/ https://danshumway.com/blog/design-is-implementation/ [edit] not that that is necessarily how Fogleman does it. It just helps me.
laumars 8y ago
As someone who also does side projects with 2 young kids, all I can say is you get used to optimising your free time. You might be working through a problem while you sterilise bottles or other chores so that once you're sat down in front of your code editor, you can hit the ground running. A few tricks I've found: * Don't commit stuff to memory. Write notes, eg use githubs issue tracker. So you spend less time retracing your steps * Get used to working without spending half an hour restoring your environment. Whether that means you just Dev in a simple environment or use an IDE which supports workspaces, or you just sleep / hybenate your PC each night. Essentially you want to maximize your device time. To that end it also helps to rationalise your codes directory and class structure. It's a bit like working on projects with larger teams, because you cannot guarantee how much you'll remember (nor even how awake and switched on) when you next get dev time you then have to treat each next session as if you're handing over a project That all said, be flexible too. I break the above rules as often as I follow them. Sometimes I curse myself for it but sometimes it's just not practical to follow a process (time constraints or whatever).

It takes me an hour to even ramp up with all the context for anything of value... color me impressed.

by tbrock 8y ago

It takes me an hour to even ramp up with all the context for anything of value... color me impressed.

I'm fairly new to this process myself but I'm finding the trick is to keep your designs extremely clean and easy to mentally model using types you can reason about. Then your software's features can emerge as interactions between "systems". That way (along with many other benefits) there's less to remember as you start coding. I find this post from the other day explains the principle better than I can: https://danshumway.com/blog/design-is-implementation/ https://danshumway.com/blog/design-is-implementation/ [edit] not that that is necessarily how Fogleman does it. It just helps me.

laumars 8y ago

As someone who also does side projects with 2 young kids, all I can say is you get used to optimising your free time. You might be working through a problem while you sterilise bottles or other chores so that once you're sat down in front of your code editor, you can hit the ground running. A few tricks I've found: * Don't commit stuff to memory. Write notes, eg use githubs issue tracker. So you spend less time retracing your steps * Get used to working without spending half an hour restoring your environment. Whether that means you just Dev in a simple environment or use an IDE which supports workspaces, or you just sleep / hybenate your PC each night. Essentially you want to maximize your device time. To that end it also helps to rationalise your codes directory and class structure. It's a bit like working on projects with larger teams, because you cannot guarantee how much you'll remember (nor even how awake and switched on) when you next get dev time you then have to treat each next session as if you're handing over a project That all said, be flexible too. I break the above rules as often as I follow them. Sometimes I curse myself for it but sometimes it's just not practical to follow a process (time constraints or whatever).