usica

Ну, вот я - добрый, отзывчивый, умный и средний. При этом искренне полагаю, что беру за свои услуги - недорого.
Но ни на минуту не готов поверить, что мы сойдемся по последнему пункту с человеком, который ищет раба на галеру (краткая выжимка из вопроса).

Вам в детстве мама говорила: все пойдут прыгать и ты пойдёшь?

Первая причина оптимизировать это если клиент в неадеквате и требует 100%.

Второе это желание наколоть алгоритмы этой проверки. На самом деле думайте головой над каждой рекомендацией. И что то делайте ну или игнорируйте

Вот тут (+ в комментариях) всё есть.

Но вообще эти мысли просто от большой тревожности, тут можно посоветовать походить к психологу или хотя бы посмотреть несколько роликов Лабковского - многим помогает.

В 99% случаев фрилансеру плевать с высокой колокольни на ваши гениальные идеи, исходники и что бы то ни было ещё. В 99% случаев фрилансер не имеет никакой мотивации поднасрать своему клиенту, если тот адекватен и вовремя и справедливо оплачивает труды.
Почему так категорично? Да потому, что в любом по-настоящему серьезном деле фрилансеры не участвуют. В Яндексе надо было вёрстку поправить и решили они обратиться на фриланс, ага. :)

Если у вас мега-секретный исходный код, значит он вам приносит неплохие деньги. Если у вас есть деньги и вы боитесь показывать код кому попало, наймите штатного программиста. Во у меня логика)

Или работайте через фриланс-биржи. Перед выбором исполнителя, посмотрите отзывы о нем.
Хм, вам нужно внести изменения в один файл, но вы подумайте о том, что сам по себе файл в большинстве случаев не работает, и тесно связан с другими файлами. И для того, чтобы внести изменения в один файл, может понадобиться доступ к другим файлам(ведь телепатию ещё не изобрели).

Если вам непонятна фраза "уметь читать и понимать техническую литературу на английском", то возможно у вас основная проблема не с английским, а с умением понимать.

class App extends Component {
  state = {
    input: '',
  };

  handleChange = (event) => {
    event.persist();
    this.setState({ input: event.target.value });
  }

  render() {
    const { input } = this.state;

    return(
      <div>
        <br /><br /><br /><br /><br /><br />
        <input type=''
          name='input'
          value={input}
          onChange={this.handleChange}
          placeholder='основной компонент'
        />
        <br />
        <Switch>
          <Route
            exact
            path="/"
            render={props => (
              <PageIndex {...props} input={input} onChange={this.handleChange} />
            )}
          />
        </Switch>
      </div>
    );
  }
}

const PageIndex = ({ input, onChange }) => {
  return (
    <div>
      <hr /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />
      <input
        name='input'
        value={input}
        onChange={onChange}
        placeholder='дочерний компонент'
      />
    </div>
  )
}

1. Без внятного тз - результат хз.
   
2. Результатом работы, в условиях жестких сроков, будет минимально рабочий вариант, об учете нюансов и речи быть не может.
   

Тут надо понимать, что взгляд программиста и непрограммиста на критичность ошибок несколько разнится.

Например, есть кнопка, по нажатию кнопки запускается хитрая-хитрая выборка из кучи источников с большими объемами данных + дополнительные расчеты. А еще при нажатии кнопка цвет должна менять.
И вот программист закопался в логику, сначала оттестил чтобы результаты были всегда корректны. Потом увидел, что долго грузится - стал увеличивать производительность. Все сделал, а перекрашивание кнопки сделать забыл.

Программист доволен собой, сделал сложный таск. А менеджер ему истерику закатывает, мол, почему кнопка не перекрашивается, это же самая очевидная ошибка, даже джун должен был справиться, как ее можно было пропустить. Понятное дело, что неправильную работу сложной логики менеджер мог запросто выявить только спустя несколько месяцев, а вот заметить, что кнопка цвет не меняет - это же так легко.

Программист в силу опыта зрит в корень, а менеджеры и клиенты, как правило, "встречают по одежке".
Зачастую при нехватке времени менеджеры заставляют программистов работать на показуху. Мол, если система цифры неправильно считает, клиент может и не заметить, потом исправим. А вот если шрифт, цвет не такой, или название заголовка в таблице неправильное - это косячище.

Поэтому вам не зря написали: чтобы маломальски объективно оценивать труд программиста, нужно самому быть программистом. Задумайтесь, не является ли ваш взгляд на проблему поверхностным. Может быть в проекте так много мелких ошибок потому, что все силы программисты бросили на решение ключевых вопросов?