Marijke Luttekes
I wonder how many people realize that writing code is one of the last, and possibly least interesting, steps in programming?
Dec 16 at 3:57pmWeb
Show threadMarijke LuttekesDec 16

Addendum: Not to say that writing code itself is not interesting on its own, especially when you are a developer, but in the grand scheme of design it's not.

Ideally, when you start writing code, you should already have your functional and technical design and requirements at hand, and have done most of the thinking work you need to make it happen.

Like a recipe, or building instructions, or a manual (you do read the manual, do you?)

Show threadJames ScholesDec 16

@mahryekuh Personally I can't fully think that way.

Functional requirements, user flows, etc., all fine. I absolutely like to get those down beforehand.

But in terms of technical architecture, what modules/functions/classes I'm gonna need, and the like? Those only come to me personally once I start coding. Which means refactors are sometimes necessary as the "best" design becomes clear, but I think that applies even when an architecture has been planned out beforehand (mainly because of changing requirements).

I've tried writing out system architecture in prose, stubbing code blocks I think I'm gonna need, and other techniques (sadly drawing stuff on a board isn't feasible). If there is an approach that works for me, I'm yet to find it.

TL;DR: the act of writing the code helps me design the system architecture.

Show threadMarijke LuttekesDec 16

@jscholes Agreed with your points as well.

I am a big fan of stubbing and pseudocode, and I usually have refactored my code several times before merging.

But I try not to write code if I am unsure about the functional parts, and have a rudimentary list of technical To-Do items (e.g., "I need a model with these fields", "I need to be able to perform these actions", etc.).

I also consider it part of my job to tell people "we should not fix this with code" or "other people than me should fix this with code" ("and here is why").

Because sometimes the presented problem is not the real problem.

Show threadblturnerDec 16
@jscholes @mahryekuh I'm the same way, I'm more productive writing things out and seeing how it behaves instead of trying to imagine it before hand. I've always considered it to feel like sculpting.
Show threadJames ScholesDec 16
@ben Indeed. I am exactly the same with non-code output, e.g. documents. Where things should go becomes much clearer once the things actually exist in some form. @mahryekuh
Show threadBrett CoulstockDec 16
@mahryekuh In the 90s my 'C' programming lecturer said "every 10 minutes you spend on design you save an hour debugging". I always remember that.