Software development topics I've changed my mind on

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.

> 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.

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.

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.

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.

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.

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.

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".

> 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".

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.