Isn’t that the opposite of what he’s saying? He’s saying it could become that powerful, and given that possibility it’s incredibly important that we do whatever we can to gain more control of that scenario
16 karma · joined March 23, 2015
Isn’t that the opposite of what he’s saying? He’s saying it could become that powerful, and given that possibility it’s incredibly important that we do whatever we can to gain more control of that scenario
I tried https://web.archive.org/web/20250506064408/https://www.natio... but I still hit the paywall.
Wholeheartedly agree with this.
I think code review will evolve from "Review this code" to "Review this prompt that was used to generate some code"
He mentions: > an engineer on a project should never go more than a week without showing something, and usually it should be more like a day
But in my experience by pairing you can shorten this feedback loop to seconds.
A few other people have commented about pairing: It's clear people have different preferences and that it's wise to use pairing at the right moments, but it still seems a glaring omission from the article to me.
To explain our process: We have a single designer, and when designs are reviewed it's usually by one of the devs
In the past we've done wireframes (Sketch) and interactive prototypes (InVision) We were frustrated that: 1. Lots of issues didn't surface until we started coding, when a raft of problems/edgecases would appear. 2. It was too easy to ignore existing UI components/css, so that each design featured new component styles and css.
For approx the last month our designer branches from `master` and hacks on top of that to create designs. He then creates a PR for design-review, alongside a spec with some screenshots in Dropbox Paper. Some advantages of this: 1. We get visual diffs from Percy, so we can see what's changed easily 2. We get versioning more easily built into designs (via git)
Then just before development we'll break a story down into tasks / subtasks and log those into JIRA for development. We have trouble with: 1. Letting the designer make changes once the subtasks are created and development has started (devs sometimes chasing a 'moving-target' spec) 2. Design not knowing the current state of development