ਤੁਹਾਡਾ ਕੰਮ ਸਿਰਫ਼ ਕੋਡ ਲਿਖਣਾ ਨਹੀਂ ਹੈ। ਇਹ ਫੈਸਲੇ ਲੈਣਾ ਹੈ। ਤੁਸੀਂ ਉਹਨਾਂ ਤੋਂ ਸਿੱਖਦੇ ਹੋ। ਸਮੇਂ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਘੱਟ ਗਲਤੀਆਂ ਕਰਦੇ ਹੋ। ਅੰਤ ਵਿੱਚ, ਤੁਸੀਂ ਦੂਜਿਆਂ ਨੂੰ ਉਸੇ ਧੁੰਦ (ਗੁੰਝਲਦਾਰ ਸਥਿਤੀ) ਵਿੱਚੋਂ ਮਾਰਗਦਰਸ਼ਨ ਦਿੰਦੇ ਹੋ। ਉਹ ਸਫ਼ਰ—ਲੌਜਿਕ ਲਿਖਣ ਤੋਂ ਲੈ ਕੇ ਨਤੀਜਿਆਂ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਣ ਤੱਕ—ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਇੱਕ ਸਿੰਟੈਕਸ ਟਾਈਪ ਕਰਨ ਵਾਲੇ ਵਿਅਕਤੀ ਨੂੰ ਸਿਸਟਮ ਬਣਾਉਣ ਵਾਲੇ ਵਿਅਕਤੀ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ।

ਤੁਸੀਂ ਹਰ ਰੋਜ਼ ਚੋਣਾਂ ਕਰਦੇ ਹੋ। ਕੁਝ ਮਾਮੂਲੀ ਲੱਗਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਬਟਨ ਦਾ ਰੰਗ ਚੁਣਨਾ। ਦੂਜੀਆਂ ਪੂਰੇ ਪ੍ਰੋਡਕਟ ਨੂੰ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਚਾਲ ਇਹ ਹੈ ਕਿ ਜਲਦੀ ਹੀ ਇਹ ਪਛਾਣ ਲਿਆ ਜਾਵੇ ਕਿ ਇਹ ਦੋਵੇਂ ਆਪਸ ਵਿੱਚ ਜੁੜੇ ਹੋਏ ਹਨ। ਲਾਪਰਵਾਹੀ ਨਾਲ ਲਿਆ ਗਿਆ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਫੈਸਲਾ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਵੱਡੀ ਰੁਕਾਵਟ ਬਣ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਲਿਆ ਗਿਆ ਇੱਕ ਔਖਾ ਫੈਸਲਾ ਅਕਸਰ ਪਿੱਛੇ ਮੁੜ ਕੇ ਦੇਖਣ 'ਤੇ ਬਹੁਤ ਸਿਆਣਪ ਵਾਲਾ ਲੱਗਦਾ ਹੈ।

ਸ਼ੁਰੂਆਤੀ ਚੋਣਾਂ ਦਾ ਪ੍ਰਭਾਵ ਖੇਤਰ (Blast Radius)

ਜਦੋਂ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ, ਤੁਹਾਡੀਆਂ ਗਲਤੀਆਂ ਇੱਕ ਛੋਟੇ ਕਮਰੇ ਵਿੱਚ ਗੂੰਜਦੀਆਂ ਹਨ। ਇੱਕ ਗਲਤ commit ਇੱਕ local build ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਗਲਤ function ਇੱਕ ਸਕ੍ਰੀਨ ਨੂੰ ਹੌਲੀ ਕਰ ਦਿੰਦਾ ਹੈ। ਪ੍ਰਭਾਵ ਦਾ ਖੇਤਰ ਸੀਮਤ ਰਹਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਬਹੁਤ ਘੱਟ ਲੋਕਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹੋ, ਅਤੇ ਸੁਧਾਰ ਕਰਨ ਦੀ ਲਾਗਤ ਵੀ ਘੱਟ ਹੁੰਦੀ ਹੈ।

ਪਰ ਜਿਵੇਂ-ਜਿਵੇਂ ਤੁਸੀਂ ਵਧਦੇ ਹੋ, ਚਾਹੇ ਇੱਕ ਇੰਜੀਨੀਅਰ ਵਜੋਂ ਜਾਂ ਇੱਕ ਕੰਪਨੀ ਵਜੋਂ, ਤੁਹਾਡੇ ਫੈਸਲੇ ਵਧੇਰੇ ਸਿਸਟਮਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਉਹੀ ਚੋਣ ਜੇਕਰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਕੀਤੀ ਜਾਵੇ ਤਾਂ ਹਫ਼ਤਿਆਂ ਦਾ ਸਮਾਂ ਖਰਾਬ ਕਰ ਸਕਦੀ ਹੈ। ਇਸੇ ਲਈ ਤੁਹਾਨੂੰ ਹੁਣੇ ਸੋਚ-ਸਮਝ ਕੇ ਫੈਸਲੇ ਲੈਣਾ ਸਿੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਇਸਦੀ ਕੀਮਤ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋ ਜਾਵੇ।

ਤਿੰਨ ਆਮ ਜਾਲਾਂ ਬਾਰੇ ਸੋਚੋ:

  • ਅਜਿਹੇ ਪਲੇਟਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜਿਸ ਨੂੰ ਤੁਹਾਡੀਆਂ dependencies ਸਪੋਰਟ ਨਹੀਂ ਕਰਦੀਆਂ, ਦਰਜਨਾਂ ਜਾਂ ਸੈਂਕੜੇ ਇੰਜੀਨੀਅਰਿੰਗ ਘੰਟੇ ਬਰਬਾਦ ਕਰ ਸਕਦੀ ਹੈ। ਉਹ ਘੰਟੇ ਸਿਰਫ਼ ਟਾਈਪਿੰਗ ਵਿੱਚ ਨਹੀਂ ਜਾਂਦੇ। ਉਹ ਅਜੀਬ compatibility ਮੁੱਦਿਆਂ ਨੂੰ debug ਕਰਨ, transitive libraries ਨੂੰ patch ਕਰਨ, ਅਤੇ stakeholders ਨੂੰ ਇਹ ਸਮਝਾਉਣ ਵਿੱਚ ਜਾਂਦੇ ਹਨ ਕਿ ਇੱਕ ਸਧਾਰਨ feature ਵਿੱਚ ਪੂਰੀ ਤਿਹਾੜੀ (quarter) ਕਿਉਂ ਲੱਗ ਗਈ।

  • ਪ੍ਰੋਡਕਟ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਵਿੱਚ session-based authentication ਤੋਂ JWTs 'ਤੇ ਜਾਣਾ ਬਾਅਦ ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਮਹਿੰਗੇ ਰੀ-ਰਾਈਟ (rewrite) ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਹਜ਼ਾਰਾਂ ਯੂਜ਼ਰਸ ਹੋਣ ਤਾਂ login logic ਨੂੰ refactor ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਲੱਖਾਂ ਯੂਜ਼ਰਸ ਹੋਣ ਅਤੇ downtime ਕਾਰਨ ਅਸਲ ਪੈਸੇ ਦਾ ਨੁਕਸਾਨ ਹੋ ਰਿਹਾ ਹੋਵੇ, ਉਦੋਂ ਇਹ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।

  • ਸਮੇਂ ਦਾ ਅੰਦਾਜ਼ਾ ਆਪਣੇ ਸਭ ਤੋਂ ਵਧੀਆ ਅੰਦਾਜ਼ੇ ਤੋਂ ਦੁੱਗਣਾ ਲਗਾਉਣਾ ਉਦੋਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਉਸ buffer ਦੀ ਵਰਤੋਂ ਕੁਆਲਿਟੀ ਨੂੰ ਬਚਾਉਣ ਲਈ ਕਰਦੇ ਹੋ। ਸ਼ਡਿਊਲ ਵਿੱਚ ਵਾਧੂ ਸਮਾਂ ਸਿਰਫ਼ ਸੋਸ਼ਲ ਮੀਡੀਆ ਚਲਾਉਣ ਲਈ ਰੱਖਣਾ ਬਰਬਾਦੀ ਹੈ। ਪਰ ਉਸ ਸਮੇਂ ਦੀ ਵਰਤੋਂ ਟੈਸਟ ਲਿਖਣ, edge cases ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਅਤੇ observability ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਕਰਨਾ ਇੱਕ ਨਿਵੇਸ਼ ਹੈ।

ਇੱਥੇ ਪੈਟਰਨ ਸਧਾਰਨ ਹੈ: technical debt ਵਧਦਾ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਮੂਲ ਰਕਮ (principal) ਛੋਟੀ ਹੋਵੇ, ਉਦੋਂ ਹੀ ਇਸਨੂੰ ਚੁਕਾ ਦਿਓ।

ਕੱਟ-ਆਫ ਤਾਰੀਖਾਂ ਅਤੇ ਕੰਟਰੋਲ ਦਾ ਭਰਮ

ਡੈੱਡਲਾਈਨਾਂ ਹਰ ਪਾਸੇ ਹਨ। ਰਿਲੀਜ਼ ਤਾਰੀਖਾਂ, ਡੈਮੋ ਤਾਰੀਖਾਂ, code freezes। ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਤਕਨੀਕੀ ਉਦੇਸ਼ ਨਾਲੋਂ ਵੱਧ ਮਨੋਵਿਗਿਆਨਕ ਉਦੇਸ਼ ਦੀ ਪੂਰਤੀ ਕਰਦੇ ਹਨ। ਇਹ ਗੁੰਝਲਦਾਰਤਾ 'ਤੇ ਕੰਟਰੋਲ ਦੀ ਇੱਕ ਅਜਿਹੀ ਭਾਵਨਾ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜਿਸ ਨੂੰ ਕੋਈ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਝਦਾ।

ਇਸਦਾ ਮਾੜਾ ਪ੍ਰਭਾਵ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਲੱਗ ਜਾਂਦਾ ਹੈ। ਜਿਵੇਂ-ਜਿਵੇਂ ਕੱਟ-ਆਫ ਨੇੜੇ ਆਉਂਦਾ ਹੈ, ਕੁਆਲਿਟੀ ਡਿੱਗ ਜਾਂਦੀ ਹੈ। ਟੀਮਾਂ ਟੈਸਟਾਂ ਨੂੰ ਹਟਾ ਦਿੰਦੀਆਂ ਹਨ, error handling ਨੂੰ comment out ਕਰ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਅਜਿਹਾ ਕੋਡ ship ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਜਿਸ ਨੂੰ ਕੋਈ ਵੀ ਬਰਕਰਾਰ (maintain) ਨਹੀਂ ਰੱਖਣਾ ਚਾਹੁੰਦਾ। ਡੈੱਡਲਾਈਨ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਕੈਲੰਡਰ ਸਾਫ਼ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਪਰ ਪ੍ਰੋਡਕਟ ਹੋਰ ਵੀ ਮਾੜਾ ਹੋ ਜਾਂਦਾ ਹੈ।

ਅਜਿਹਾ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਪਰਫੈਕਟ ਕੋਡ ਅਤੇ ਸ਼ਾਨਦਾਰ architecture ਪਸੰਦ ਹੁੰਦਾ ਹੈ। ਇਹ ਸਾਡੇ ਸੁਭਾਅ ਵਿੱਚ ਹੈ। ਪਰ ਇੱਕ ਪਰਫੈਕਟ ਜਵਾਬ ਹਮੇਸ਼ਾ ਮੌਜੂਦ ਨਹੀਂ ਹੁੰਦਾ। ਸਹੀ ਚੋਣ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦੇ ਅਨੁਕੂਲ ਹੋਵੇ। ਤਿੰਨ-ਵਿਅਕਤੀਆਂ ਵਾਲੇ startup ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਦੀਆਂ ਰਸਮਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਜਿਵੇਂ ਕਿ ਇੱਕ ਨਿਯਮਿਤ (regulated) ਹੈਲਥਕੇਅਰ ਪਲੇਟਫਾਰਮ ਨੂੰ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਉਸ ਲਈ ਬਣਾਉਂਦੇ ਹੋ ਜਿੱਥੇ ਤੁਸੀਂ ਅੱਜ ਹੋ, ਨਾ ਕਿ ਉਸ ਲਈ ਜਿੱਥੇ ਪੰਜ ਸਾਲ ਪਹਿ

ਉਹ ਬਫਰ ਹੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਸਿੱਖਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਹਰ ਘੰਟਾ ਸਿਰਫ਼ ਫੀਚਰ ਕੰਮ ਲਈ ਅਲਾਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕਿਸੇ ਕੋਲ ਬਿਲਡ ਪਾਈਪਲਾਈਨ ਨੂੰ ਸੁਧਾਰਨ, ਕੁਐਰੀ ਲੇਅਰ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰਨ, ਜਾਂ API ਕੰਟਰੈਕਟ ਨੂੰ ਡਾਕੂਮੈਂਟ ਕਰਨ ਲਈ ਸਮਾਂ ਨਹੀਂ ਬਚਦਾ। ਟੀਮ ਹਮੇਸ਼ਾ ਆਪਣੀ ਮੌਜੂਦਾ ਵੇਲੋਸਿਟੀ 'ਤੇ ਹੀ ਰੁਕੀ ਰਹੇਗੀ।

ਇੱਕ ਗਲਤੀ ਦੀ ਥਾਂ ਦੂਜੀ ਗਲਤੀ ਨੂੰ ਲਿਆਉਣਾ

ਅਸੀਂ ਇਸ ਸਮੇਂ ਇੱਕ ਅਜੀਬ ਸੌਦੇ ਵੱਲ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਹੇ ਹਾਂ। ਅਸੀਂ ਮਨੁੱਖੀ ਗਲਤੀਆਂ ਦੀ ਥਾਂ ਨਾਨ-ਡਿਟਰਮਿਨਿਸਟਿਕ ਸਾਫਟਵੇਅਰ ਗਲਤੀਆਂ ਲੈ ਰਹੇ ਹਾਂ। ਲਾਰਜ ਲੈਂਗੂਏਜ ਮਾਡਲਜ਼ ਕਿਸੇ ਵੀ ਜੂਨੀਅਰ ਇੰਜੀਨੀਅਰ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਬੁਆਇਲਰਪਲੇਟ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਨ, ਟੈਸਟਾਂ ਦੇ ਸੁਝਾਅ ਦੇ ਸਕਦੇ ਹਨ, ਅਤੇ ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਦਾ ਡਰਾਫਟ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਨ। ਪਰ ਉਹ ਇਹ ਕੰਮ ਪੂਰੇ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਨਾਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹ ਅਜਿਹੇ ਤਰੀਕਿਆਂ ਨਾਲ ਗਲਤੀ ਕਰਦੇ ਹਨ ਜੋ ਕਿ