5 ms·

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

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.
- dhosek 2y ago
  I always fight to get this stuff into JIRA (or whatever equivalent tool we’re using), and then make sure that all commits have the JIRA ID in them.
  - Izkata 2y ago
    Works great until you're not using it anymore. We're on our third system, all the cases from the first one and most from the second one are long since gone. Meanwhile the commit messages survive it all, even across cvs -> svn and svn -> git migrations.
mmcnl 2y ago
And how do you figure out what the requirements are? In my 10+ professional years, I have never gotten requirements by asking for them. Almost always I had to show my interpretation of what I think the requirements are, and use the feedback I got to define the actual requirements. The quickest way to get there is by iterating.
- spiderxxxx 2y ago
  You don't ask for the requirements. You ask what they're trying to do, or what problem they're trying to solve. Sometimes I have to ask "where is this data going" or "what do you expect the end result of this to be".
  - mmcnl 2y ago
    Not disagreeing here but whatever question you ask, you will only get the final answer _after_ you have implemented it, almost always after several iterations.
stevage 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. Calling requirements gathering "programming" is just misusing a term for no good reason. By all means, include it in "software development" but it clearly isn't "programming".

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.

dhosek 2y ago
I always fight to get this stuff into JIRA (or whatever equivalent tool we’re using), and then make sure that all commits have the JIRA ID in them.
- Izkata 2y ago
  Works great until you're not using it anymore. We're on our third system, all the cases from the first one and most from the second one are long since gone. Meanwhile the commit messages survive it all, even across cvs -> svn and svn -> git migrations.

mmcnl 2y ago

And how do you figure out what the requirements are? In my 10+ professional years, I have never gotten requirements by asking for them. Almost always I had to show my interpretation of what I think the requirements are, and use the feedback I got to define the actual requirements. The quickest way to get there is by iterating.

spiderxxxx 2y ago
You don't ask for the requirements. You ask what they're trying to do, or what problem they're trying to solve. Sometimes I have to ask "where is this data going" or "what do you expect the end result of this to be".
- mmcnl 2y ago
  Not disagreeing here but whatever question you ask, you will only get the final answer _after_ you have implemented it, almost always after several iterations.

stevage 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. Calling requirements gathering "programming" is just misusing a term for no good reason. By all means, include it in "software development" but it clearly isn't "programming".