6 ms·

> Most programming should be done long before a single line of code is written Nah. I (16+ years developer) prefer to iteratively go between coding and design

> Most programming should be done long before a single line of code is written Nah. I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently. Quite often you also have eureka moments with better solutions that just would not have happened unless you had code in front of you, which again makes you approach the problem entirely differently.

gaptoothclan 2y ago
ok that sounds bad, you should have the option to go back to design, but depending on what point you find that issue, depends on how much time you have wasted?
- ZaoLahma 2y ago
  It's about defining and solving small problems all the way, and avoiding trying to solve big problems. If you manage to restrict yourself to only solving small problems (THIS is the true challenge with software engineering, in my humble opinion), then you won't ever have wasted too much time if (when) you need to reset.
gmm1990 2y ago
I assume there are people who are able to have those eureka moments before writing any code. I definitely write a lot of code before figuring out the final design but always think I should be designing more.
- bluGill 2y ago
  Always plan to throw one away. You will, so best to plan for it. (paraphrasing Fred Brooks)
VyseofArcadia 2y ago
Iterative work is THE way to work in large legacy codebases. The minute you wade into the code, all of your planning is moot. You don't know what's lurking below the surface. No one knows what's lurking under the surface. Except maybe Dave, because he vaguely remembers about 15 years back talking to some guy who wrote some code 30 years back about it. Greenfield, absolutely design up front you lucky devils, but iterative is the way otherwise.
- renewedrebecca 2y ago
  Every development shop has a Dave.
- bluGill 2y ago
  Greenfield lasts only for at best 2 years or the first public release. After that it is legacy. I'm am the "Dave" on my current code since I was one of the first engineers on the project and the others before me have long moved to management. There is a lot I don't know about how the code works. There are dark corners we just lifted completely from an earlier project where the guy who wrote it 30 years back is retired. This is normal. I'm fighting desperately to keep this code in shape as I don't want to go to management to ask for $$$ (billions) to rewrite it. I regret many choices. I'm making other choices in response that I fear someone will regret in 15 more years. I'm hoping to retire before then - better talk to me now because soon the people who have talked to the person who wrote the code 30 years ago will also be a memory. (the guy who write the code 30 years ago is still alive and someone has his phone number - they talk once a year about something weird to see if why is remembered)
  - arkh 2y ago
    > I'm making other choices in response that I fear someone will regret in 15 more years. Junior dev made to maintain some code base: "wtf, all this old code suck. People were really bad at their job". Same dev 5 years later: "wellll, this looks bad but there must be a reason.". Usually the reason is someone sold a new feature without asking the implementers or even checking what the impacts could be. So it has to be ready yesterday and you'll never get approval to refactor or clean-up anything, until it breaks.
Kichererbsen 2y ago
Most programming is actually figuring out what already exists and what (and more importantly: why) the requirements are. This is best done long before a single line of code is written. I think the author is taking a wider view of "programming" than the actual writing of code as the end product. Some of the most important work I've done is spend the time to argue that something doesn't need to be done at all.
- VyseofArcadia 2y ago
  > what (and more importantly: why) the requirements are Maybe in a startup? My experience as an IC in larger, more established companies is the requirements are dictated to you. Someone else has already thought carefully about the customer ask, your job is just to implement, maybe push back a little if the requirements they came up with are particularly unreasonable.
  - bluGill 2y ago
    If you dig deep you discover they have figured out some requirements in detail, but there is a lot missing. Is this new feature that last one in that line, or will there be more options in the future? Is this new feature really going to be used - many times we have put large effort into features only to discover no customer used them (as evidenced by the critical bug that made the feature unusable outside of the test lab that nobody complained about until 4 years had passed). These things drive how you engineer the thing in the first place.
- deleted 2y ago
  [deleted]
- polishdude20 2y ago
  This makes me think it would be really cool to tie code sections to slack conversations or emails. There's always commit messages yes, but most product decisions on why something was done lives in slack at least where I've worked. Even an AI tool that takes a slack thread and summarizes how that thread informed the code would be cool to try.
AnimalMuppet 2y ago
Always think bigger picture than what you're immediately working on. (I don't mean that you can't ever just focus on the problem you're trying to solve for, say, hours. I mean you can't focus like that for the entire time you're in that development phase.) Think about design and code (and functionality!) before you start coding. Think about design as well as code while you're coding. Think about design, code, and functionality while you're testing.
davidw 2y ago
Yeah, the other stuff seems sensible or at least "Ok, I can see that", but I definitely disagree with this one. You should spend time thinking about stuff beforehand, sure, but getting your hands dirty is also going to reveal things.
- pinoy420 2y ago
  Very surprised at this attitude. Or am I. The typical engineering savant omniscient to all future past and present engineering roadblocks fixed by “Just”(TM) thinking about it beforehand. I expect this from bay area mid level not someone with credentials. Strange because I agree with so much more of the article
  - davidw 2y ago
    TBH, I think it's more of a 'manager' attitude. A lot of actual "hacker" type people are very much in the "rough consensus and working code" category where you see what works by doing it.
mamcx 2y ago
What I think is a better way to say this is that you need a `design` phase before actually writing the first `real` implementation code. Something I do a lot, and even more with the LLMS, is that I make `scratch` projects where I sketch code over and over (and maybe make mockups in Keynote or similar, make some notes, etc), then write from scratch again in the real codebase.
nerdralph 2y ago
I agree coding should start early. The design might look good, but might not be easy to implement, so you need to change the design. The statement sounds like something out of a book on the waterfall method of software development.
knighthack 2y ago
'Programming as theory-building' is an approach that has grown on me in the past few years. Your first draft may be qualitatively an MVP, but it's still just a theory of a final product you want, which requires a lot of iterative building before you get to that. As such, there's no way to not shift between code and design, especially when business requirements are involved and which themselves may change over time.
- nradclif 2y ago
  > Programming as theory-building Sounds similar to https://en.m.wikipedia.org/wiki/Curry–Howard_correspondence https://en.m.wikipedia.org/wiki/Curry–Howard_correspondence.
- beryilma 2y ago
  Relevant HN discussion: https://news.ycombinator.com/item?id=42592543 https://news.ycombinator.com/item?id=42592543
recroad 2y ago
Developer for 20+ years. I can't even design anything without coding something.
- jillesvangurp 2y ago
  Exactly. I did a Ph.D. on software engineering and architecture before embarking on a career practicing what I preach. One thing that I realized early is that designs always lag implementations. They are aspirational at best. And people largely stopped using design tools completely when agile became a thing. Some still do. But you'll look in vain for UML diagrams on most software you ever heard off. I now have a few decades of experience doing technical work, running startups, teams, doing consultancy, etc. Coding is my way of getting hands on. It's quicker for me to just prototype something quickly in code than it is to do whatever on a whiteboard. I always run out of space on whiteboards and they don't have multi level undo, auto completion, etc. They really suck actually. I avoid using them. Of course, I sometimes chin stroke extensively before coding; or I restart what I'm doing several times. But once I have an idea of what I'm doing in my head, I stub out a solution and start iteratively refining. And if I'm stuck with the chin stroking, the best way to break through that is to just start coding. Usually, I then discover things I hadn't thought about and realize I don't need to over complicate things quite as much. This progressive insight is something you can only gain through doing the work. The finished code is also the finished design; they co-evolve and don't exist as separate artifacts. The engineering fallacy is believing that they are separate and that developers are just being lazy by not having designs. Here's a counter argument to that: we don't build bridges, rockets, expensive machines, etc. Our designs compile to executable code. Physical things have extensive post design project phases where stuff gets built/constructed/assembled. Changing the design at that stage is really expensive. For software, this phase is pretty much 100% automated in software. And continuous deployment means having working stuff from pretty much as soon as your builds start passing. Of course refactoring your design/code still is important. You risk making it hard to evolve your software otherwise. The process of designing a bridge is actually more similar to developing software than the process of constructing one. The difference is that when you are done with the bridge design, you still have to build it. But it's a lengthy/risky process with progressive insights about constraints, physics, legislation, requirements, etc. Like software, it's hard to plan the design. And actually modern day architects use a lot of software tools to try out their designs before they hand them over. Just some simple insights here. There is no blue print for the blue print for either bridges or software. Not a thing, generally.
jrochkind1 2y ago
The OP didn't say what it is they're talking about that should be done before writing any code. He might have meant design, and I'm not sure about that. But the other thing i think of is: Understanding the problem. It's hard to do too much of that before you start coding, and easy to do too little. It overlaps with design to some extent, because once you understand the problem better, some designs will naturally seem inappropriate or better -- without having to spend time allocated to "designing" necessarily, just when you design you're going to come up with things that work a lot better the better you understand the problem you are trying to solve. How the stakeholders see it, and what's really going on, and why it's a problem, and what would make an acceptable solution, and what the next steps down the road might be.
- x3n0ph3n3 2y ago
  Then the author should have said "Most software development should be done long before a single line of code is written" Programming is specifically about the authorship of code.
  - jrochkind1 2y ago
    Right, by your interpretation what they suggested is logically impossible (one can't possibly write any code, let alone most, before one writes a single line of code), so I understand you think they should have written differently, but its clear they meant something else, I would assume they meant programming as a synonym for software development, right.
dkarl 2y ago
> I (16+ years developer) prefer to iteratively go between coding and designing I have an extra ten years on you and couldn't agree more. There are two jokes: - A few months of programming can save weeks of design. - A few months of design can save weeks of programming. Inexperience is thinking that only one of these jokes is grounded in truth. Recognizing which kind of situation you're in is an imperfect art, and incremental work that interleaves design with implementation is a hedge against being wrong.
- spartanatreyu 2y ago
  I like to say: - One hour of planning saves ten hours or programming... - and one hour of research saves ten hours of planning. You can also invert it: - Ten hours of programming saves one hour of planning... - and ten hours of planning saves one hour of research.
  - baud147258 2y ago
    > - Ten hours of programming saves one hour of planning... If the planning is done with 5 or more people in a meeting, there still might be some time savings...
- jfengel 2y ago
  The difference between DRY and YAGNI is experience. Both are predicting the future, and you can only do that by having watched code evolve.
  - bena 2y ago
    What's that saying? "Once is a mistake, twice is a coincidence, three times is a pattern". Having to write something once, just write it. Having to write something twice with small differences, think about it. Having to write something three times? Consider refactoring.
mmcnl 2y ago
Yeah, validate your assumptions. Nothing ever works the first time. Quick iterations to get feedback is the way.
standardUser 2y ago
Absolutely, though sometimes it's more about reading code or 'playing' with code than writing/committing code. I try to always be hoping around my codebase during meetings.
stevage 2y ago
This kind of thing is incredibly context dependent. But it basically sounds like waterfall development, which is a reasonable approach in certain contexts. But this thinking doesn't really make sense for any of the projects I work on.
eyelidlessness 2y ago
Agree. Although I increasingly spend this iteration time on types/interfaces/documenting proposal of same. The actual implementation below that is often trivial once the boundaries are settled.

gaptoothclan 2y ago

ok that sounds bad, you should have the option to go back to design, but depending on what point you find that issue, depends on how much time you have wasted?

ZaoLahma 2y ago
It's about defining and solving small problems all the way, and avoiding trying to solve big problems. If you manage to restrict yourself to only solving small problems (THIS is the true challenge with software engineering, in my humble opinion), then you won't ever have wasted too much time if (when) you need to reset.

gmm1990 2y ago

I assume there are people who are able to have those eureka moments before writing any code. I definitely write a lot of code before figuring out the final design but always think I should be designing more.

bluGill 2y ago
Always plan to throw one away. You will, so best to plan for it. (paraphrasing Fred Brooks)

VyseofArcadia 2y ago

Iterative work is THE way to work in large legacy codebases. The minute you wade into the code, all of your planning is moot. You don't know what's lurking below the surface. No one knows what's lurking under the surface. Except maybe Dave, because he vaguely remembers about 15 years back talking to some guy who wrote some code 30 years back about it. Greenfield, absolutely design up front you lucky devils, but iterative is the way otherwise.

renewedrebecca 2y ago
Every development shop has a Dave.
bluGill 2y ago
Greenfield lasts only for at best 2 years or the first public release. After that it is legacy. I'm am the "Dave" on my current code since I was one of the first engineers on the project and the others before me have long moved to management. There is a lot I don't know about how the code works. There are dark corners we just lifted completely from an earlier project where the guy who wrote it 30 years back is retired. This is normal. I'm fighting desperately to keep this code in shape as I don't want to go to management to ask for $$$ (billions) to rewrite it. I regret many choices. I'm making other choices in response that I fear someone will regret in 15 more years. I'm hoping to retire before then - better talk to me now because soon the people who have talked to the person who wrote the code 30 years ago will also be a memory. (the guy who write the code 30 years ago is still alive and someone has his phone number - they talk once a year about something weird to see if why is remembered)
- arkh 2y ago
  > I'm making other choices in response that I fear someone will regret in 15 more years. Junior dev made to maintain some code base: "wtf, all this old code suck. People were really bad at their job". Same dev 5 years later: "wellll, this looks bad but there must be a reason.". Usually the reason is someone sold a new feature without asking the implementers or even checking what the impacts could be. So it has to be ready yesterday and you'll never get approval to refactor or clean-up anything, until it breaks.

Kichererbsen 2y ago

Most programming is actually figuring out what already exists and what (and more importantly: why) the requirements are. This is best done long before a single line of code is written. I think the author is taking a wider view of "programming" than the actual writing of code as the end product. Some of the most important work I've done is spend the time to argue that something doesn't need to be done at all.

VyseofArcadia 2y ago
> what (and more importantly: why) the requirements are Maybe in a startup? My experience as an IC in larger, more established companies is the requirements are dictated to you. Someone else has already thought carefully about the customer ask, your job is just to implement, maybe push back a little if the requirements they came up with are particularly unreasonable.
- bluGill 2y ago
  If you dig deep you discover they have figured out some requirements in detail, but there is a lot missing. Is this new feature that last one in that line, or will there be more options in the future? Is this new feature really going to be used - many times we have put large effort into features only to discover no customer used them (as evidenced by the critical bug that made the feature unusable outside of the test lab that nobody complained about until 4 years had passed). These things drive how you engineer the thing in the first place.
deleted 2y ago
[deleted]
polishdude20 2y ago
This makes me think it would be really cool to tie code sections to slack conversations or emails. There's always commit messages yes, but most product decisions on why something was done lives in slack at least where I've worked. Even an AI tool that takes a slack thread and summarizes how that thread informed the code would be cool to try.

AnimalMuppet 2y ago

Always think bigger picture than what you're immediately working on. (I don't mean that you can't ever just focus on the problem you're trying to solve for, say, hours. I mean you can't focus like that for the entire time you're in that development phase.) Think about design and code (and functionality!) before you start coding. Think about design as well as code while you're coding. Think about design, code, and functionality while you're testing.

davidw 2y ago

Yeah, the other stuff seems sensible or at least "Ok, I can see that", but I definitely disagree with this one. You should spend time thinking about stuff beforehand, sure, but getting your hands dirty is also going to reveal things.

pinoy420 2y ago
Very surprised at this attitude. Or am I. The typical engineering savant omniscient to all future past and present engineering roadblocks fixed by “Just”(TM) thinking about it beforehand. I expect this from bay area mid level not someone with credentials. Strange because I agree with so much more of the article
- davidw 2y ago
  TBH, I think it's more of a 'manager' attitude. A lot of actual "hacker" type people are very much in the "rough consensus and working code" category where you see what works by doing it.

mamcx 2y ago

What I think is a better way to say this is that you need a `design` phase before actually writing the first `real` implementation code. Something I do a lot, and even more with the LLMS, is that I make `scratch` projects where I sketch code over and over (and maybe make mockups in Keynote or similar, make some notes, etc), then write from scratch again in the real codebase.

nerdralph 2y ago

I agree coding should start early. The design might look good, but might not be easy to implement, so you need to change the design. The statement sounds like something out of a book on the waterfall method of software development.

knighthack 2y ago

'Programming as theory-building' is an approach that has grown on me in the past few years. Your first draft may be qualitatively an MVP, but it's still just a theory of a final product you want, which requires a lot of iterative building before you get to that. As such, there's no way to not shift between code and design, especially when business requirements are involved and which themselves may change over time.

nradclif 2y ago
> Programming as theory-building Sounds similar to https://en.m.wikipedia.org/wiki/Curry–Howard_correspondence https://en.m.wikipedia.org/wiki/Curry–Howard_correspondence.
beryilma 2y ago
Relevant HN discussion: https://news.ycombinator.com/item?id=42592543 https://news.ycombinator.com/item?id=42592543

recroad 2y ago

Developer for 20+ years. I can't even design anything without coding something.

jillesvangurp 2y ago
Exactly. I did a Ph.D. on software engineering and architecture before embarking on a career practicing what I preach. One thing that I realized early is that designs always lag implementations. They are aspirational at best. And people largely stopped using design tools completely when agile became a thing. Some still do. But you'll look in vain for UML diagrams on most software you ever heard off. I now have a few decades of experience doing technical work, running startups, teams, doing consultancy, etc. Coding is my way of getting hands on. It's quicker for me to just prototype something quickly in code than it is to do whatever on a whiteboard. I always run out of space on whiteboards and they don't have multi level undo, auto completion, etc. They really suck actually. I avoid using them. Of course, I sometimes chin stroke extensively before coding; or I restart what I'm doing several times. But once I have an idea of what I'm doing in my head, I stub out a solution and start iteratively refining. And if I'm stuck with the chin stroking, the best way to break through that is to just start coding. Usually, I then discover things I hadn't thought about and realize I don't need to over complicate things quite as much. This progressive insight is something you can only gain through doing the work. The finished code is also the finished design; they co-evolve and don't exist as separate artifacts. The engineering fallacy is believing that they are separate and that developers are just being lazy by not having designs. Here's a counter argument to that: we don't build bridges, rockets, expensive machines, etc. Our designs compile to executable code. Physical things have extensive post design project phases where stuff gets built/constructed/assembled. Changing the design at that stage is really expensive. For software, this phase is pretty much 100% automated in software. And continuous deployment means having working stuff from pretty much as soon as your builds start passing. Of course refactoring your design/code still is important. You risk making it hard to evolve your software otherwise. The process of designing a bridge is actually more similar to developing software than the process of constructing one. The difference is that when you are done with the bridge design, you still have to build it. But it's a lengthy/risky process with progressive insights about constraints, physics, legislation, requirements, etc. Like software, it's hard to plan the design. And actually modern day architects use a lot of software tools to try out their designs before they hand them over. Just some simple insights here. There is no blue print for the blue print for either bridges or software. Not a thing, generally.

jrochkind1 2y ago

The OP didn't say what it is they're talking about that should be done before writing any code. He might have meant design, and I'm not sure about that. But the other thing i think of is: Understanding the problem. It's hard to do too much of that before you start coding, and easy to do too little. It overlaps with design to some extent, because once you understand the problem better, some designs will naturally seem inappropriate or better -- without having to spend time allocated to "designing" necessarily, just when you design you're going to come up with things that work a lot better the better you understand the problem you are trying to solve. How the stakeholders see it, and what's really going on, and why it's a problem, and what would make an acceptable solution, and what the next steps down the road might be.

x3n0ph3n3 2y ago
Then the author should have said "Most software development should be done long before a single line of code is written" Programming is specifically about the authorship of code.
- jrochkind1 2y ago
  Right, by your interpretation what they suggested is logically impossible (one can't possibly write any code, let alone most, before one writes a single line of code), so I understand you think they should have written differently, but its clear they meant something else, I would assume they meant programming as a synonym for software development, right.

dkarl 2y ago

> I (16+ years developer) prefer to iteratively go between coding and designing I have an extra ten years on you and couldn't agree more. There are two jokes: - A few months of programming can save weeks of design. - A few months of design can save weeks of programming. Inexperience is thinking that only one of these jokes is grounded in truth. Recognizing which kind of situation you're in is an imperfect art, and incremental work that interleaves design with implementation is a hedge against being wrong.

spartanatreyu 2y ago
I like to say: - One hour of planning saves ten hours or programming... - and one hour of research saves ten hours of planning. You can also invert it: - Ten hours of programming saves one hour of planning... - and ten hours of planning saves one hour of research.
- baud147258 2y ago
  > - Ten hours of programming saves one hour of planning... If the planning is done with 5 or more people in a meeting, there still might be some time savings...
jfengel 2y ago
The difference between DRY and YAGNI is experience. Both are predicting the future, and you can only do that by having watched code evolve.
- bena 2y ago
  What's that saying? "Once is a mistake, twice is a coincidence, three times is a pattern". Having to write something once, just write it. Having to write something twice with small differences, think about it. Having to write something three times? Consider refactoring.

mmcnl 2y ago

Yeah, validate your assumptions. Nothing ever works the first time. Quick iterations to get feedback is the way.

standardUser 2y ago

Absolutely, though sometimes it's more about reading code or 'playing' with code than writing/committing code. I try to always be hoping around my codebase during meetings.

stevage 2y ago

This kind of thing is incredibly context dependent. But it basically sounds like waterfall development, which is a reasonable approach in certain contexts. But this thinking doesn't really make sense for any of the projects I work on.

eyelidlessness 2y ago

Agree. Although I increasingly spend this iteration time on types/interfaces/documenting proposal of same. The actual implementation below that is often trivial once the boundaries are settled.