ਸਟਾਰਟਅੱਪ ਵਿੱਚ ਤੁਹਾਡਾ ਪਹਿਲਾ ਮਹੀਨਾ ਇੱਕ ਡੂੰਘੀ ਛਾਪ ਛੱਡਦਾ ਹੈ। ਇੱਥੇ ਕੋਈ ਹੌਲੀ-ਹੌਲੀ ਸ਼ੁਰੂਆਤ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਨਾ ਹੀ IT ਵਿਭਾਗ ਵੱਲੋਂ ਲੈਪਟਾਪ ਪ੍ਰਦਾਨ ਕੀਤੇ ਜਾਣ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹੋਏ ਸਿਰਫ਼ ਓਰੀਐਂਟੇਸ਼ਨ ਵੀਡੀਓਜ਼ ਦੇਖਣ ਵਾਲਾ ਕੋਈ ਹਫ਼ਤਾ ਹੁੰਦਾ ਹੈ। ਪਹਿਲੇ ਦਿਨ ਹੀ, ਤੁਹਾਡੇ ਤੋਂ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਬਣਾਓ, ਤੋੜੋ ਅਤੇ ਠੀਕ ਕਰੋ ਜੋ ਅਸਲ ਲੋਕਾਂ ਦੁਆਰਾ ਵਰਤੀਆਂ ਜਾਣਗੀਆਂ। ਮੈਂ Treevah ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਹ ਗੱਲ ਜਲਦੀ ਸਿੱਖ ਲਈ, ਜੋ ਕਿ ਨੌਕਰੀ ਲੱਭਣ ਵਾਲਿਆਂ ਨੂੰ ਉਹਨਾਂ ਦੀਆਂ ਅਰਜ਼ੀਆਂ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਟੂਲ ਬਣਾ ਰਹੀ ਇੱਕ ਕੰਪਨੀ ਹੈ। ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਦੇ ਮਾਹੌਲ ਵਿੱਚ ਤਿੰਨส ਮਹੀਨਿਆਂ ਨੇ ਮੈਨੂੰ ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਮੈਂਟ ਬਾਰੇ ਉਹ ਸਭ ਕੁਝ ਸਿਖਾਇਆ ਜੋ ਕੋਈ ਕਲਾਸਰੂਮ ਜਾਂ ਮੁਕਾਬਲਾ ਕਦੇ ਨਹੀਂ ਸਿਖਾ ਸਕਦਾ ਸੀ।
ਰਿਦਮ ਬਹੁਤ ਤੇਜ਼ ਅਤੇ ਲਗਾਤਾਰ ਹੈ
Treevah ਵਿੱਚ, ਕੰਮ ਤੁਹਾਡੇ ਸੈੱਟਲ ਹੋਣ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਦਾ। ਟੀਮ ਉਤਪਾਦ (product) ਨੂੰ alpha ਤੋਂ beta ਅਤੇ ਅੰਤ ਵਿੱਚ production ਤੱਕ ਲੈ ਜਾਣ ਲਈ ਜਤਨਸ਼ੀਲ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ ਕੰਮ ਦੀ ਆਪਣੀ ਅਹਿਮੀਅਤ ਹੈ। ਇੱਥੇ ਫ਼ਰਜ਼ੀ ਕੰਮ ਕਰਨ ਜਾਂ ਅਜਿਹੇ ਅਸਾਈਨਮੈਂਟਸ ਲਈ ਕੋਈ ਜਗ੍ਹਾ ਨਹੀਂ ਹੈ ਜੋ ਕਿਸੇ ਪ੍ਰੋਫੈਸਰ ਦੇ ਇਨਬਾਕਸ ਵਿੱਚ ਪਏ ਰਹਿ ਜਾਣ। ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਫੀਚਰ ਲਾਂਚ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਸਿੱਧਾ ਉਹਨਾਂ ਯੂਜ਼ਰਜ਼ ਕੋਲ ਜਾਂਦਾ ਹੈ ਜੋ ਆਪਣੀ ਅਗਲੀ ਨੌਕਰੀ ਦੀ ਭਾਲ ਦੌਰਾਨ ਡੈੱਡਲਾਈਨਾਂ, ਇੰਟਰਵਿਊਆਂ ਅਤੇ ਫਾਲੋ-ਅੱਪਾਂ ਦਾ ਟਰੈਕ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ।
ਇਹ ਰਫ਼ਤਾਰ ਥਕਾ ਦੇਣ ਵਾਲੀ ਹੈ। ਤੁਸੀਂ ਹਰ ਰੋਜ਼ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋ, ਅਤੇ ਕੰਮ ਦਾ ਬੋਝ ਤੁਹਾਡੀ ਉਮੀਦ ਨਾਲੋਂ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦਾ ਹੈ। ਡੈੱਡਲਾਈਨਾਂ ਕੋਈ ਅਮੂਰਤ ਚੀਜ਼ ਨਹੀਂ ਹਨ; ਉਹ ਮੀਲਸਟੋਨਜ਼ ਨਾਲ ਜੁੜੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਕੰਪਨੀ ਹੋਰ ਨੌਕਰੀ ਲੱਭਣ ਵਾਲਿਆਂ ਦੀ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ ਜਾਂ ਮੌਜੂਦਾ ਅਨੁਭਵ ਵਿੱਚ ਕਮੀਆਂ ਨੂੰ ਦੂਰ ਕਰ ਸਕਦੀ ਹੈ। ਇਹ ਭਾਰੀਪਨ ਤੁਹਾਨੂੰ ਥਕਾ ਦਿੰਦਾ ਹੈ। ਪਰ ਇਹ ਇੱਕ ਅਜਿਹੀ ਸਪੱਸ਼ਟਤਾ ਵੀ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਲੱਭਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਮੈਂ ਕੋਈ ਕੰਮ ਖ਼ਤਮ ਕਰਦਾ ਹਾਂ, ਤਾਂ ਮੈਂ ਜੋ ਬਣਾਇਆ ਹੈ ਅਤੇ ਉਸ ਵਿਅਕਤੀ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਿੱਧੀ ਲਾਈਨ ਖਿੱਚ ਸਕਦਾ ਹਾਂ ਜਿਸ ਲਈ ਹੁਣ ਆਪਣੀ ਨੌਕਰੀ ਦੀ ਭਾਲ ਨੂੰ ਸੰਭਾਲਣਾ ਆਸਾਨ ਹੋ ਗਿਆ ਹੈ। ਮਾਲਕੀ ਦੀ ਇਹ ਭਾਵਨਾ ਦੁਰਲੱਭ ਹੈ, ਅਤੇ ਇਹ ਥਕਾਵਟ ਨੂੰ ਵੀ ਸਾਰਥਕ ਬਣਾ ਦਿੰਦੀ ਹੈ।
Production ਵਿੱਚ ਹੁਨਰ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੇ ਹਨ
ਇਸ ਗਰਮੀ ਦੀਆਂ ਛੁੱਟੀਆਂ ਤੋਂ ਪਹਿਲਾਂ, ਮੇਰੀ ਜ਼ਿਆਦਾਤਰ ਊਰਜਾ ਪਬਲਿਕ ਸਪੀਕਿੰਗ ਅਤੇ ਹੈਕਾਥੌਨਜ਼ (hackathons) ਵੱਲ ਜਾਂਦੀ ਸੀ। ਦੋਵਾਂ ਨੇ ਮੈਨੂੰ ਦਬਾਅ ਹੇਠ ਤੁਰੰਤ ਸੋਚਣ ਅਤੇ ਵਿਚਾਰਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਦਾ ਤਰੀਕਾ ਸਿਖਾਇਆ। ਹੈਕਾਥੌਨਜ਼ ਖਾਸ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਕੁਝ ਘੰਟਿਆਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਡੈਮੋ ਤਿਆਰ ਕਰਨ ਲਈ ਸਿਖਲਾਈ ਦਿੰਦੇ ਹਨ। ਪਰ ਇੱਕ ਵੀਕੈਂਡ ਪ੍ਰੋਜੈਕਟ ਜੋ ਜੱਜਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ production ਕੋਡ ਵਿੱਚ ਬਹੁਤ ਫਰਕ ਹੈ ਜਿਸ ਨੂੰ ਸੈਂਕੜੇ ਅਸਲ ਯੂਜ਼ਰਜ਼ ਦੇ ਸਾਹਮਣੇ ਟਿਕਣਾ ਪੈਂਦਾ ਹੈ।
Treevah ਵਿਖੇ ਵੈੱਬ ਡਿਵੈਲਪਮੈਂਟ 'ਤੇ ਇੱਕ ਮਹੀਨਾ ਕੇਂਦਰਿਤ ਰਹਿਣ ਨਾਲ ਉਹ ਫਰਕ ਖ਼ਤਮ ਹੋ ਗਿਆ। ਸਕੂਲ ਵਿੱਚ, ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਨਾਲ ਸੁਰੱਖਿਆ ਦੇ ਨਿਯਮ (guardrails) ਹੁੰਦੇ ਹਨ। ਸਕੋਪ ਨਿਸ਼ਚਿਤ ਹੁੰਦੀ ਹੈ, ਲੋੜਾਂ ਪਹਿਲਾਂ ਹੀ ਦੱਸੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਜੇਕਰ ਤੁਹਾਡਾ database schema ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪ੍ਰੈਜ਼ੈਂਟੇਸ਼ਨ ਸਲਾਈਡ ਵਿੱਚ ਇਸਦਾ ਬਹਾਨਾ ਬਣਾ ਸਕਦੇ ਹੋ। ਇੱਕ ਸਟਾਰਟਅੱਪ ਦੇ ਅੰਦਰ, ਤੁਹਾਡੇ schema ਨੂੰ ਮਜ਼ਬੂਤ ਰਹਿਣਾ ਪੈਂਦਾ ਹੈ ਕਿਉਂਕਿ ਅਸਲ ਨੌਕਰੀ ਲੱਭਣ ਵਾਲੇ ਇਸ ਵਿੱਚ ਆਪਣਾ ਅਸਲ ਡਾਟਾ ਸਟੋਰ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਫੀਡਬੈਕ ਲੂਪ ਤੁਰੰਤ ਅਤੇ ਬੇਰਹਿਮ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਪੇਜ ਹੌਲੀ ਲੋਡ ਹੁੰਦਾ ਹੈ ਜਾਂ ਕੋਈ ਫਾਰਮ ਸੇਵ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਕਿਸੇ ਨੂੰ ਤੁਹਾਡੇ ਗ੍ਰੇਡ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਹੁੰਦੀ; ਉਹਨਾਂ ਨੂੰ ਇਸ ਗੱਲ ਦੀ ਚਿੰਤਾ ਹੁੰਦੀ ਹੈ ਕਿ ਕੀ ਉਹਨਾਂ ਨੇ ਹੁਣੇ ਕੋਈ ਮੌਕਾ ਗੁਆ ਦਿੱਤਾ ਹੈ।
ਉਹ ਦਬਾਅ ਵਿਕਾਸ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਸਾਫ਼ ਕੋਡ ਲਿਖਣਾ ਸਿੱਖਦੇ ਹੋ ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਕੋਈ ਮਾਪਦੰਡ ਇਸਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਬਲਕਿ ਇਸ ਲਈ ਕਿਉਂਕਿ ਅੱਧੀ ਰਾਤ ਨੂੰ ਉਸ ਨੂੰ ਡਿਬੱਗ (debug) ਕਰਨ ਵਾਲੇ ਤੁਸੀਂ ਖੁਦ ਹੋਵੋਗੇ। ਤੁਸੀਂ ਕੋਡ ਰਿਵਿਊ ਦੌਰਾਨ ਵਧੇਰੇ ਸਪੱਸ਼ਟ ਸਵਾਲ ਪੁੱਛਣਾ ਸਿੱਖਦੇ ਹੋ ਕਿਉਂਕਿ ਇੱਕ ਖਰਾਬ ਬਿਲਡ ਨੂੰ ਡਿਪਲੋਏ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸਲ ਯੂਜ਼ਰਸ ਨੂੰ ਮੁਸ਼ਕਲ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਵੇਗਾ। ਇੱਥੇ ਮੌਕੇ ਸਕੂਲ ਦੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੇ ਹਨ। ਗਲਤੀਆਂ ਦੀ ਕੀਮਤ ਜ਼ਿਆਦਾ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਸਬਕ ਵੀ ਡੂੰਘੇ ਹੁੰਦੇ ਹਨ।
ਬੱਗਸ (Bugs) ਦੀ ਨਿਮਰਤਾ ਭਰਪੂਰ ਅਸਲੀਅਤ
ਜੇਕਰ ਕੋਈ ਇੱਕ ਭਰਮ ਹੈ ਜਿਸ ਨੂੰ ਮੈਂ ਖ਼ਤਮ ਕਰਨਾ ਚਾਹਾਂਗਾ, ਤਾਂ ਉਹ ਇਹ ਵਿਚਾਰ ਹੈ ਕਿ ਹਰ ਸਾਫਟਵੇਅਰ ਬੱਗ ਇੱਕ ਡਰਾਮੇਦਾਰ ਤਰਕਸ਼ੀਲ ਅਸਫਲਤਾ ਹੈ। ਕੁਝ ਅਜਿਹੇ ਹੁੰਦੇ ਹਨ, ਬੇਸ਼ੱਕ। ਪਰ Treevah ਵਿੱਚ ਮੈਨੂੰ ਮਿਲਣ ਵਾਲੇ ਬਹੁਤ ਸਾਰੇ ਬੱਗ ਪਾਗਲ ਕਰ ਦੇਣ ਵਾਲੇ ਛੋਟੇ ਸਨ। ਉਹ ਸਾਹਮਣੇ ਹੀ ਲੁਕੇ ਹੋਏ ਸਨ ਅਤੇ ਮੇਰੀ ਜ਼ਿੰਦਗੀ ਦੇ ਕਈ ਘੰਟੇ ਬਰਬਾਦ ਕਰ ਦਿੱਤੇ।
ਦੋ ਪੈਟਰਨ ਵਾਰ-ਵਾਰ ਸਾਹਮਣੇ ਆ ਰਹੇ ਸਨ। ਪਹਿਲਾ ਸੀ ਡੁਪਲੀਕੇਟ CSS ਨਿਯਮ। ਜਦੋਂ ਕਈ ਡਿਵੈਲਪਰ ਕਈ ਸਪ੍ਰਿੰਟਸ (sprints) ਦੌਰਾਨ ਇੱਕੋ ਕੰਪੋਨੈਂਟ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਸਟਾਈਲਸ਼ੀਟਾਂ ਵਧ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਵਿਅਕਤੀ margin utility class ਜੋੜਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦੂਜਾ ਕੰਪੋਨੈਂਟ ਫਾਈਲ ਵਿੱਚ ਇੱਕ ਵੈਲਯੂ ਹਾਰਡਕੋਡ ਕਰ ਦਿੰਦਾ ਹੈ। ਅਲੱਗ-ਅਲੱਗ ਦੇਖਣ 'ਤੇ ਕੋਈ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ। ਪਰ ਇਕੱਠੇ ਹੋ ਕੇ ਉਹ ਲੇਆਉਟ ਸ਼ਿਫਟਸ ਜਾਂ specificity wars ਪੈਦਾ ਕਰਦੇ ਹਨ ਜੋ ਇੱਕ ਬਟਨ ਨੂੰ Chrome 'ਤੇ ਠੀਕ ਅਤੇ Safari 'ਤੇ ਖਰਾਬ ਦਿਖਾਉਂਦੇ ਹਨ। ਇਸ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਡਿਵ ਟੂਲਜ਼ (dev tools) ਖੋਲ੍ਹਣੇ ਪੈਂਦੇ ਹਨ ਅਤੇ ਸੁੰਦਰ ਐਲਗੋਰਿਦਮਿਕ ਲੌਜਿਕ ਪੜ੍ਹਨ ਦੀ ਬਜਾਏ computed styles ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਦੇਖਣਾ ਪੈਂਦਾ ਹੈ।
ਦੂਜਾ ਸੀ ਐਲੀਮੈਂਟਸ ਨੂੰ ਉਹਨਾਂ ਦੇ parent divs ਤੋਂ ਬਾਹਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ। ਇੱਕ modal trigger ਜਾਂ dropdown DOM ਵਿੱਚ ਗਲਤ ਨੋਡ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ। ਸਕ੍ਰੀਨ ਲਗਭਗ ਸਹੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਮੰਨ ਲੈਂਦੇ ਹੋ ਕਿ ਸੰਰਚਨਾ ਸਹੀ ਹੈ। ਫਿਰ ਇੱਕ z-index ਟਕਰਾਅ ਪੈਦਾ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਇੱਕ click event ਗਲਤ ਹੈਂਡਲਰ ਵੱਲ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਅਚਾਨਕ ਇੱਕ ਯੂਜ਼ਰ ਉਸ ਪੌਪਅੱਪ ਨੂੰ ਹਟਾ ਨਹੀਂ ਸਕਦਾ ਜੋ ਉਹਨਾਂ ਦੇ ਅਰਜ਼ੀ ਫਾਰਮ ਨੂੰ ਢੱਕ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਕੰਪਿਊਟਰ ਸਾਇੰਸ ਦੀਆਂ ਪਹੇਲੀਆਂ ਨਹੀਂ ਹਨ। ਇਹ ਸਥਾਨਕ ਅਤੇ ਸੰਰਚਨਾਤਮਕ ਗਲਤੀਆਂ ਹਨ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਵਧਦੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਬੱਗਾਂ ਨੂੰ ਲੱਭਣ ਵਿੱਚ ਹਫ਼ਤੇ ਲੱਗ ਗਏ। ਮੈਂ ਕੋਡ ਨੂੰ ਘੂਰਦਾ ਰਹਿੰਦਾ ਸੀ, ਆਪਣੇ ਆਪ ਨੂੰ ਯਕੀਨ ਦਿਵਾਉਂਦਾ ਸੀ ਕਿ ਲੌਜਿਕ ਸਹੀ ਸੀ, ਅਤੇ ਅਜਿਹੇ ਅੰਧੇ ਰਾਹਾਂ 'ਤੇ ਭਟਕਦਾ ਰਹਿੰਦਾ ਸੀ ਜਿਨ੍ਹਾਂ ਦਾ ਕੋਈ ਨਤੀਜਾ ਨਹੀਂ ਨਿਕਲਦਾ ਸੀ। ਇਹ ਨਿਰਾਸ਼ਾ ਬਹੁਤ ਅਸਲੀ ਹੁੰਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੁਝ ਬਹੁਤ ਹੀ ਸਪੱਸ਼ਟ ਦੇਖਣ ਤੋਂ ਰਹਿ ਗਏ ਹੋ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਤੁਸੀਂ ਹੁੰਦੇ ਵੀ ਹੋ। ਪਰ ਅੰਤ ਵਿੱਚ ਇੱਕ ਡੁਪਲੀਕੇਟ ਰੂਲ ਜਾਂ ਗਲਤ ਜਗ੍ਹਾ ਲੱਗੇ ਹੋਏ ਕਲੋਜ਼ਿੰਗ ਟੈਗ ਨੂੰ ਲੱਭ ਲੈਣ ਦੀ ਸੰਤੁਸ਼ਟੀ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ