Ви коли-небудь хвилюєтесь, що вас більше хвилює те, як щось будується, а не те, що ви насправді будуєте?

Як програміст, мені притаманна роздратованість моїм інструментам, кодом інших народів, моєму коду, загалом світу. Я завжди хочу це вдосконалити. Тож я рефактор, я залишаюся на вершині новітніх методик. Я намагаюся і вивчаю шаблони, намагаюся використовувати рамки, щоб не винаходити колесо. Я можу написати технічну специфікацію, яка роздує твої шкарпетки з кількістю візерунків, в які я можу втиснутись.

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

Я відчуваю, що мені бракує набору навичок людських факторів, і я вважаю, що щоб бути успішним програмним інженером, потрібно більше, ніж знати найкрутіші рамки. Я думаю, що також потрібні деякі з наступних наборів навичок.

• Дизайн взаємодії
• Досвід користувача
• Маркетинг

У мене є трохи цього, про що я дізнався від людей, з якими працював, і чудових проектів, над якими працював, але не відчуваю, що я володію цими навичками.

Я правий? Чи варто намагатися розвивати ці навички і далі, чи їх слід залишити людям, які роблять це для кар’єри?

Як ви можете переконатися, що ви не занадто прив’язані до того, як щось робите, і переконайтеся, що "зробите своїх користувачів приголомшливими"?

Хтось знає про хороші ресурси для вивчення цих навичок з точки зору програмування?

Моя порада: якомога більше поговоріть зі своїми користувачами. Я не знаю, чи є ви у великій компанії та чи на іншому континенті, ніж у ваших користувачів, чи ви на посаді фрілансера, але якщо це взагалі можливо, просто поговоріть зі своїми користувачами.

Я знаю, що багато разів мені доводиться сидіти і пам’ятати, що це не моя робота - створити найбільший біт коду, який коли-небудь бачив світ, або створити функцію, яка використовує найменшу кількість циклів і займає найкоротший технологічний час, але щоб користувачі могли зробити свою роботу. І для цього я вважаю, що, крім чисто технічних можливостей, найкращими двома властивостями є хороші робочі знання про роботу користувачів та хороші робочі стосунки з ними.

Я працюю в невеликій компанії (близько 50 осіб), і мені подобається, що я можу підійти до будь-якого куба і поспілкуватися про останнє, що я зробив / зафіксував для них. Абсолютне найкраще почуття, яке я коли-небудь отримував від своєї роботи, - це коли я можу почути, як вони говорять про свою роботу, і запропонувати щось, що вирішить проблему, для якої ніколи не зрозуміли, що технічне рішення може існувати. Це було б неможливо, якби я не розумів їхню справу і не мав з ними випадкових розмов.

Я б сказав, що це залежить від того, де ви працюєте, і яких типів компаній ви бачите, що рухаєтесь у майбутньому - це насправді відкрита дискусія.

З меншими компаніями ви можете носити багато шапок (хоча я не впевнений, чому маркетинг є в цьому списку, якщо ви не маєте наміру продавати власний товар).

У більших компаніях вони, як правило, мають людей, які спеціально зосереджуються на цих речах.

Так що насправді, справа в тому, куди ви бачите себе, і потенційно відкриваєте більше дверей для себе.

Для кожного рядка коду, який ви пишете, ви представляєте шанс помилки.

Отже, найкращі конструкції мінімізують кількість введеного коду - можливо, за принципом DRY (не повторюйте себе). Однак стартапи віддають перевагу підходу YAGNI (вам це вже не потрібно), який значно швидше призводить до MVP (мінімально життєздатного продукту).

Якщо ваша мета - створити чистий, простий у використанні продукт, який виконує саме те, що хочуть ваші користувачі, то YAGNI - це ваша найкраща модель дизайну. Викиньте все, що не впливає безпосередньо на робочий код. Це включає пуристичні процеси побудови та нав’язливе використання шаблонів.

Деякі матеріали для читання

Ви можете прочитати " Не змушуйте мене думати ", що є чудовою книгою про дизайн інтерфейсу користувача. Крім того, будь-яка з книг Gitomer (зокрема Маленька зелена книга ) допоможе вам у ваших навичках продажів, мереж та маркетингу.

Я думаю, що певна кількість дизайну взаємодії та знання досвіду користувачів дуже корисна навіть у великій компанії з однієї причини: ви як розробник - це перша особа, яка фактично використовує інтерфейс, за тижні чи навіть місяці, перш ніж він перебуває у використанні для тестер для тестування.

На ранніх етапах може бути дуже корисно вказати на інтерфейс, який не настільки простий у використанні, як було заплановано, або на якийсь принцип дизайну, який, можливо, було не помічено. Ці речі іноді можуть бути важкими для того, щоб побачити, перш ніж у вас є щось конкретне, з чим завжди працювати, і ви завжди є першою людиною, з якою працювати щось конкретно.

Я можу написати технічну специфікацію, яка роздує твої шкарпетки з кількістю візерунків, в які я можу втиснутись.

Саме це твердження змушує мене вважати, що вам потрібно працювати над іншими аспектами розробки програмного забезпечення.

Хоча ви ніколи не можете нести відповідальність за кожен аспект програмного забезпечення вашої компанії, наявність широкого спектру знань з багатьох предметів може бути надзвичайно цінною. Якщо нічого іншого, це більше речей, які ви можете кинути на інтерв'ю, щоб ви могли продовжувати свою кар’єру вперед.

Якщо вам не вистачає труднощів у деяких сферах вашої роботи, почніть власний проект вдома, щоб зробити щось цікаве. Або брати участь у проекті з відкритим кодом.

Ні, я цього не роблю, це не моя робота турбуватися про те, що я будую, а скоріше будувати це відповідно до специфікацій, викладених моїм клієнтом / роботодавцем. Вони вже знають, чого хочуть, і на моїх належним чином це реалізувати, щоб воно було реальним. Я дам поради, коли з’явиться шанс, якщо можу сказати, що вони не зовсім впевнені в найкращому способі включення функції в програмне забезпечення

Можливо, в якийсь момент я захочу зробити власний проект і переживати про те, що я будую, але на деякий час думаю, коли починати кар’єру з розробки програмного забезпечення, важливо постійно прагнути навчитися правильному способу робити речі