6 ms·

100% agree. Someone (who?) had to take time and write the detailed requirements. In real jobs you rarely get good tickets with well defined expectations; it's o

100% agree. Someone (who?) had to take time and write the detailed requirements. In real jobs you rarely get good tickets with well defined expectations; it's one of most important developer's jobs to transform fuzzy requirement into a good ticket. (Side note: I find that many people skip this step, and go straight from fuzzy-requirement-only-discussed-on-zoom-with-Bob to code; open a pull request without much context or comments; and then a code reviewer is supposed to review it properly without really knowing what problem is actually being solved, and whether the code is solving a proper problem at all).

ohwellhere 5y ago
Is the next step in the evolution of programming having the programmer become the specifier? Fuzzy business requirements -> programmer specifies and writes tests -> AI codes
- buscoquadnary 5y ago
  That's all we've ever been since we invented software. First we specified the exact flow of the bits with punch cards. Then we got assembly and we specified the machine instructions. Then we got higher level languages and we specified how the memory was to be managed and what data to store where. Now we have object oriented languages that allow us to work with domain models, and functional languages that allow us to work data structures and algorithms. The next level may be writing business rules, and specifying how services talk to each other, who knows, but it will be no different than it is now just a higher level.
- chinabot 5y ago
  If its anything like my job while(1) { Fuzzy business requirements -> programmer specifies and writes tests -> AI codes }
machiaweliczny 5y ago
But it's easy to create AI conversation that will refine problem.
ctoth 5y ago
So what happens when OpenAI releases TicketFixer 0.8 which synthesizes everything from transcripts of your meetings to the comments to the JIRA ticket to the existing codebase and spits out better tickets to feed into the programming side?
- jakub_g 5y ago
  Take my money.
- solarmist 5y ago
  Yup, I hope that'll happen. Then engineers would just end up being done at a higher level of abstraction closer to what designers do with wireframes and mockups. Kind of the opposite of the way graphic design has evolved. Instead of getting more involved in the process and, in many cases, becoming front-end developers, it'll become more abstract where humans make the decisions and reason about what to include/exclude, how it'll flow, etc. Even TicketFixer wouldn't be able to do more than offer a handful of possible solutions to design-type issues.
  - bmhin 5y ago
    Yeah, we need our TicketFixer to also include the No_Bob 0.2 plugin that figures out that a decent percentage of the time whatever "Bob" is asking for in that meeting is not what "Bob" thinks he is asking for or should be asking for and can squash those tickets. Without that we're gonna somehow end up with spreadsheets in everything.
    - solarmist 5y ago
      Haha, yeah, there's that, but there are also things like "adding a dark mode." There are a dozen ways to accomplish that kind of thing, and every company's solution will diverge when you get down to the details.
jensensbutton 5y ago
Maybe the problem transformation will be both the beginning _and_ end of the developer's role.

ohwellhere 5y ago

Is the next step in the evolution of programming having the programmer become the specifier? Fuzzy business requirements -> programmer specifies and writes tests -> AI codes

buscoquadnary 5y ago
That's all we've ever been since we invented software. First we specified the exact flow of the bits with punch cards. Then we got assembly and we specified the machine instructions. Then we got higher level languages and we specified how the memory was to be managed and what data to store where. Now we have object oriented languages that allow us to work with domain models, and functional languages that allow us to work data structures and algorithms. The next level may be writing business rules, and specifying how services talk to each other, who knows, but it will be no different than it is now just a higher level.
chinabot 5y ago
If its anything like my job while(1) { Fuzzy business requirements -> programmer specifies and writes tests -> AI codes }

machiaweliczny 5y ago

But it's easy to create AI conversation that will refine problem.

ctoth 5y ago

So what happens when OpenAI releases TicketFixer 0.8 which synthesizes everything from transcripts of your meetings to the comments to the JIRA ticket to the existing codebase and spits out better tickets to feed into the programming side?

jakub_g 5y ago
Take my money.
solarmist 5y ago
Yup, I hope that'll happen. Then engineers would just end up being done at a higher level of abstraction closer to what designers do with wireframes and mockups. Kind of the opposite of the way graphic design has evolved. Instead of getting more involved in the process and, in many cases, becoming front-end developers, it'll become more abstract where humans make the decisions and reason about what to include/exclude, how it'll flow, etc. Even TicketFixer wouldn't be able to do more than offer a handful of possible solutions to design-type issues.
- bmhin 5y ago
  Yeah, we need our TicketFixer to also include the No_Bob 0.2 plugin that figures out that a decent percentage of the time whatever "Bob" is asking for in that meeting is not what "Bob" thinks he is asking for or should be asking for and can squash those tickets. Without that we're gonna somehow end up with spreadsheets in everything.
  - solarmist 5y ago
    Haha, yeah, there's that, but there are also things like "adding a dark mode." There are a dozen ways to accomplish that kind of thing, and every company's solution will diverge when you get down to the details.

jensensbutton 5y ago

Maybe the problem transformation will be both the beginning _and_ end of the developer's role.