ਸਿਰਫ਼ ਆਪਣੀ ਕੋਡਿੰਗ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਨਾਲ ਤੁਹਾਨੂੰ ਬਿਹਤਰ ਵਿਕਾਸਕਾਰ ਕਿਉਂ ਨਹੀਂ ਬਣਾਇਆ ਜਾਵੇਗਾ

Techlead Skyeng Kirill Rogovoy (ਫਲੈਸ਼ਹਹ) ਕਾਨਫਰੰਸਾਂ ਵਿੱਚ ਇੱਕ ਪੇਸ਼ਕਾਰੀ ਦਿੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਉਹ ਉਹਨਾਂ ਹੁਨਰਾਂ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ ਜੋ ਹਰੇਕ ਚੰਗੇ ਡਿਵੈਲਪਰ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਬਣਨ ਲਈ ਵਿਕਸਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਮੈਂ ਉਸ ਨੂੰ ਇਹ ਕਹਾਣੀ ਹਾਬਰਾ ਪਾਠਕਾਂ ਨਾਲ ਸਾਂਝੀ ਕਰਨ ਲਈ ਕਿਹਾ, ਮੈਂ ਕਿਰਲ ਨੂੰ ਮੰਜ਼ਿਲ ਦਿੰਦਾ ਹਾਂ।

ਇੱਕ ਚੰਗੇ ਡਿਵੈਲਪਰ ਬਾਰੇ ਮਿੱਥ ਇਹ ਹੈ ਕਿ ਉਹ:

1. ਸਾਫ਼ ਕੋਡ ਲਿਖਦਾ ਹੈ
2. ਬਹੁਤ ਸਾਰੀਆਂ ਤਕਨੀਕਾਂ ਨੂੰ ਜਾਣਦਾ ਹੈ
3. ਕੋਡਿੰਗ ਕਾਰਜ ਤੇਜ਼ੀ ਨਾਲ
4. ਐਲਗੋਰਿਦਮ ਅਤੇ ਡਿਜ਼ਾਈਨ ਪੈਟਰਨਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਜਾਣਦਾ ਹੈ
5. ਕਲੀਨ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਸੇ ਵੀ ਕੋਡ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰ ਸਕਦਾ ਹੈ
6. ਗੈਰ-ਪ੍ਰੋਗਰਾਮਿੰਗ ਕੰਮਾਂ 'ਤੇ ਸਮਾਂ ਬਰਬਾਦ ਨਹੀਂ ਕਰਦਾ
7. ਤੁਹਾਡੀ ਮਨਪਸੰਦ ਤਕਨਾਲੋਜੀ ਦਾ 100% ਮਾਸਟਰ

ਇਸ ਤਰ੍ਹਾਂ HR ਆਦਰਸ਼ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਵੇਖਦਾ ਹੈ, ਅਤੇ ਖਾਲੀ ਅਸਾਮੀਆਂ, ਇਸ ਅਨੁਸਾਰ, ਇਸ ਤਰ੍ਹਾਂ ਵੀ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।

ਪਰ ਮੇਰਾ ਅਨੁਭਵ ਕਹਿੰਦਾ ਹੈ ਕਿ ਇਹ ਬਹੁਤਾ ਸੱਚ ਨਹੀਂ ਹੈ।

ਪਹਿਲਾਂ, ਦੋ ਮਹੱਤਵਪੂਰਨ ਬੇਦਾਅਵਾ:
1) ਮੇਰਾ ਅਨੁਭਵ ਉਤਪਾਦ ਟੀਮਾਂ ਹੈ, ਜਿਵੇਂ ਕਿ ਆਪਣੇ ਉਤਪਾਦ ਵਾਲੀਆਂ ਕੰਪਨੀਆਂ, ਆਊਟਸੋਰਸਿੰਗ ਨਹੀਂ; ਆਊਟਸੋਰਸਿੰਗ ਵਿੱਚ ਹਰ ਚੀਜ਼ ਬਹੁਤ ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ;
2) ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਜੂਨੀਅਰ ਹੋ, ਤਾਂ ਸਾਰੀਆਂ ਸਲਾਹਾਂ ਲਾਗੂ ਨਹੀਂ ਹੋਣਗੀਆਂ, ਅਤੇ ਜੇਕਰ ਮੈਂ ਤੁਸੀਂ ਹੁੰਦੇ, ਤਾਂ ਮੈਂ ਹੁਣੇ ਲਈ ਪ੍ਰੋਗਰਾਮਿੰਗ 'ਤੇ ਧਿਆਨ ਦੇਵਾਂਗਾ।

ਚੰਗਾ ਵਿਕਾਸਕਾਰ: ਅਸਲੀਅਤ

1: ਔਸਤ ਕੋਡ ਨਾਲੋਂ ਵਧੀਆ

ਇੱਕ ਚੰਗਾ ਡਿਵੈਲਪਰ ਜਾਣਦਾ ਹੈ ਕਿ ਵਧੀਆ ਆਰਕੀਟੈਕਚਰ ਕਿਵੇਂ ਬਣਾਉਣਾ ਹੈ, ਠੰਡਾ ਕੋਡ ਕਿਵੇਂ ਲਿਖਣਾ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਬੱਗ ਨਹੀਂ ਬਣਾਉਣੇ ਹਨ; ਆਮ ਤੌਰ 'ਤੇ, ਉਹ ਔਸਤ ਨਾਲੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਉਹ ਮਾਹਿਰਾਂ ਦੇ ਸਿਖਰਲੇ 1% ਵਿੱਚ ਨਹੀਂ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਸਭ ਤੋਂ ਵਧੀਆ ਡਿਵੈਲਪਰ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਉਹ ਮਹਾਨ ਕੋਡਰ ਨਹੀਂ ਹਨ: ਉਹ ਜੋ ਵੀ ਕਰਦੇ ਹਨ ਉਸ ਵਿੱਚ ਉਹ ਬਹੁਤ ਵਧੀਆ ਹਨ, ਪਰ ਉਹ ਕੁਝ ਵੀ ਅਤਿ-ਅਸਾਧਾਰਨ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਨ।

2: ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਨ ਦੀ ਬਜਾਏ ਹੱਲ ਕਰਦਾ ਹੈ

ਆਓ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਸਾਨੂੰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਬਾਹਰੀ ਸੇਵਾ ਨੂੰ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ। ਅਸੀਂ ਤਕਨੀਕੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ, ਦਸਤਾਵੇਜ਼ਾਂ 'ਤੇ ਨਜ਼ਰ ਮਾਰਦੇ ਹਾਂ, ਦੇਖਦੇ ਹਾਂ ਕਿ ਉੱਥੇ ਕੁਝ ਪੁਰਾਣਾ ਹੈ, ਸਮਝੋ ਕਿ ਸਾਨੂੰ ਵਾਧੂ ਮਾਪਦੰਡਾਂ ਨੂੰ ਪਾਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਕੁਝ ਵਿਵਸਥਾਵਾਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਇਸ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਅਤੇ ਕੁਝ ਟੇਢੇ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਅੰਤ ਵਿੱਚ, ਇੱਕ ਜੋੜੇ ਤੋਂ ਬਾਅਦ ਅਸੀਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਇਸ ਤਰ੍ਹਾਂ ਜਾਰੀ ਨਹੀਂ ਰਹਿ ਸਕਦੇ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਇੱਕ ਡਿਵੈਲਪਰ ਦਾ ਮਿਆਰੀ ਵਿਵਹਾਰ ਵਪਾਰ ਵਿੱਚ ਵਾਪਸ ਆਉਣਾ ਹੈ ਅਤੇ ਕਹਿਣਾ ਹੈ: “ਮੈਂ ਇਹ ਕੀਤਾ ਅਤੇ ਉਹ, ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਉਹ ਬਿਲਕੁਲ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਆਪਣੇ ਆਪ ਇਸ ਦਾ ਪਤਾ ਲਗਾਓ। " ਇੱਕ ਕਾਰੋਬਾਰ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਹੈ: ਤੁਹਾਨੂੰ ਕੀ ਹੋਇਆ ਹੈ, ਕਿਸੇ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ, ਅਤੇ ਇਸਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਟੁੱਟਿਆ ਹੋਇਆ ਫ਼ੋਨ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: "ਤੁਸੀਂ ਉਸਨੂੰ ਦੱਸੋ, ਮੈਂ ਉਸਨੂੰ ਟੈਕਸਟ ਕਰਾਂਗਾ, ਦੇਖੋ ਉਹਨਾਂ ਨੇ ਕੀ ਜਵਾਬ ਦਿੱਤਾ."

ਇੱਕ ਚੰਗਾ ਡਿਵੈਲਪਰ, ਅਜਿਹੀ ਸਥਿਤੀ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ, ਆਪਣੇ ਆਪ ਸੰਪਰਕ ਲੱਭੇਗਾ, ਉਸ ਨਾਲ ਫ਼ੋਨ 'ਤੇ ਸੰਪਰਕ ਕਰੇਗਾ, ਸਮੱਸਿਆ ਬਾਰੇ ਚਰਚਾ ਕਰੇਗਾ, ਅਤੇ ਜੇ ਕੁਝ ਨਹੀਂ ਨਿਕਲਦਾ, ਤਾਂ ਉਹ ਸਹੀ ਲੋਕਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰੇਗਾ, ਸਭ ਕੁਝ ਸਮਝਾਏਗਾ ਅਤੇ ਵਿਕਲਪ ਪੇਸ਼ ਕਰੇਗਾ (ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਇੱਕ ਹੋਰ ਹੈ ਬਿਹਤਰ ਸਹਾਇਤਾ ਨਾਲ ਬਾਹਰੀ ਸੇਵਾ)। ਅਜਿਹਾ ਡਿਵੈਲਪਰ ਇੱਕ ਵਪਾਰਕ ਸਮੱਸਿਆ ਨੂੰ ਵੇਖਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ. ਉਸਦਾ ਕੰਮ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਹ ਕਿਸੇ ਕਾਰੋਬਾਰੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਜਦੋਂ ਉਹ ਕਿਸੇ ਚੀਜ਼ ਵਿੱਚ ਭੱਜਦਾ ਹੈ।

3: ਵੱਧ ਤੋਂ ਵੱਧ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਘੱਟੋ ਘੱਟ ਮਿਹਨਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਭਾਵੇਂ ਇਸਦਾ ਮਤਲਬ ਬੈਸਾਖੀਆਂ ਲਿਖਣਾ ਹੋਵੇ

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

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

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

4. ਇਸਦਾ ਆਪਣਾ ਕਾਰੋਬਾਰ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਕਿਸੇ ਵੀ ਜਟਿਲਤਾ ਦੇ ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਹੈ.

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

5. ਕਿਸੇ ਵੀ ਸ਼ਰਤਾਂ ਅਤੇ ਜਾਣ-ਪਛਾਣ ਦੇ ਸਵਾਲ ਅਤੇ ਸਪਸ਼ਟੀਕਰਨ

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

6. ਤੁਹਾਡੇ ਆਲੇ ਦੁਆਲੇ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ

ਸਾਡੇ ਆਲੇ ਦੁਆਲੇ ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਚੱਲ ਰਹੀਆਂ ਹਨ - ਰੋਜ਼ਾਨਾ ਮੀਟਿੰਗਾਂ, ਮੁਲਾਕਾਤਾਂ, ਸਕ੍ਰਾਮਸ, ਤਕਨੀਕੀ ਸਮੀਖਿਆਵਾਂ, ਕੋਡ ਸਮੀਖਿਆਵਾਂ, ਆਦਿ। ਇੱਕ ਚੰਗਾ ਡਿਵੈਲਪਰ ਖੜ੍ਹਾ ਹੋਵੇਗਾ ਅਤੇ ਕਹੇਗਾ: ਦੇਖੋ, ਅਸੀਂ ਇਕੱਠੇ ਹੁੰਦੇ ਹਾਂ ਅਤੇ ਹਰ ਹਫ਼ਤੇ ਇੱਕੋ ਗੱਲ 'ਤੇ ਚਰਚਾ ਕਰਦੇ ਹਾਂ, ਮੈਨੂੰ ਸਮਝ ਨਹੀਂ ਆਉਂਦੀ ਕਿਉਂ, ਅਸੀਂ ਇਸ ਘੰਟੇ ਨੂੰ ਕੰਟਰਾ 'ਤੇ ਵੀ ਬਿਤਾ ਸਕਦੇ ਹਾਂ। ਜਾਂ: ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਤੀਜੇ ਕੰਮ ਲਈ ਮੈਂ ਕੋਡ ਵਿੱਚ ਨਹੀਂ ਆ ਸਕਦਾ, ਕੁਝ ਵੀ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ, ਆਰਕੀਟੈਕਚਰ ਛੇਕ ਨਾਲ ਭਰਿਆ ਹੋਇਆ ਹੈ; ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਸਾਡਾ ਸਮੀਖਿਆ ਕੋਡ ਲੰਗੜਾ ਹੈ ਅਤੇ ਸਾਨੂੰ ਰੀਫੈਕਟਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਆਓ ਹਰ ਦੋ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਮੀਟਿੰਗ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰੀਏ। ਜਾਂ ਕੋਡ ਦੀ ਸਮੀਖਿਆ ਦੇ ਦੌਰਾਨ, ਇੱਕ ਵਿਅਕਤੀ ਇਹ ਦੇਖਦਾ ਹੈ ਕਿ ਉਸਦਾ ਇੱਕ ਸਹਿਕਰਮੀ ਇੱਕ ਖਾਸ ਟੂਲ ਨੂੰ ਕਾਫ਼ੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਨਹੀਂ ਵਰਤ ਰਿਹਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਆਉਣ ਅਤੇ ਕੁਝ ਸਲਾਹ ਦੇਣ ਦੀ ਲੋੜ ਹੈ। ਇੱਕ ਚੰਗੇ ਵਿਕਾਸਕਾਰ ਕੋਲ ਇਹ ਪ੍ਰਵਿਰਤੀ ਹੁੰਦੀ ਹੈ; ਉਹ ਅਜਿਹੇ ਕੰਮ ਆਪਣੇ ਆਪ ਕਰਦਾ ਹੈ।

7. ਦੂਜਿਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਵਿੱਚ ਸ਼ਾਨਦਾਰ, ਭਾਵੇਂ ਪ੍ਰਬੰਧਕ ਨਾ ਵੀ ਹੋਵੇ

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

8. ਆਪਣੇ ਗਿਆਨ ਨੂੰ ਹਠ ਸਮਝ ਕੇ ਨਹੀਂ ਸਮਝਦਾ, ਲਗਾਤਾਰ ਆਲੋਚਨਾ ਲਈ ਖੁੱਲ੍ਹਾ ਰਹਿੰਦਾ ਹੈ

ਹਰ ਕੋਈ ਪਿਛਲੀ ਨੌਕਰੀ ਦੇ ਇੱਕ ਸਾਥੀ ਨੂੰ ਯਾਦ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਆਪਣੀ ਤਕਨਾਲੋਜੀ ਨਾਲ ਸਮਝੌਤਾ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਹੈ ਅਤੇ ਚੀਕਦਾ ਹੈ ਕਿ ਹਰ ਕੋਈ ਕੁਝ ਗਲਤ ਪਰਿਵਰਤਨ ਲਈ ਨਰਕ ਵਿੱਚ ਸੜ ਜਾਵੇਗਾ। ਇੱਕ ਚੰਗਾ ਡਿਵੈਲਪਰ, ਜੇਕਰ ਉਹ ਉਦਯੋਗ ਵਿੱਚ 5, 10, 20 ਸਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਮਝਦਾ ਹੈ ਕਿ ਉਸਦਾ ਅੱਧਾ ਗਿਆਨ ਗੰਧਲਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਅੱਧੇ ਵਿੱਚ ਉਸਨੂੰ ਦਸ ਗੁਣਾ ਜ਼ਿਆਦਾ ਨਹੀਂ ਪਤਾ। ਅਤੇ ਹਰ ਵਾਰ ਜਦੋਂ ਕੋਈ ਉਸ ਨਾਲ ਅਸਹਿਮਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕੋਈ ਵਿਕਲਪ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਉਸਦੀ ਹਉਮੈ 'ਤੇ ਹਮਲਾ ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਕੁਝ ਸਿੱਖਣ ਦਾ ਮੌਕਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਉਸਨੂੰ ਉਸਦੇ ਆਲੇ ਦੁਆਲੇ ਦੇ ਲੋਕਾਂ ਨਾਲੋਂ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਵਧਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ.

ਆਉ ਇੱਕ ਆਦਰਸ਼ ਡਿਵੈਲਪਰ ਦੇ ਮੇਰੇ ਵਿਚਾਰ ਦੀ ਤੁਲਨਾ ਆਮ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰ ਕੀਤੇ ਗਏ ਨਾਲ ਕਰੀਏ:

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

ਵਿਸ਼ੇਸ਼ਤਾ, ਸਾਧਾਰਨਵਾਦ ਅਤੇ 80-20 ਨਿਯਮ

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

80-20 ਨਿਯਮ ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ 80% ਨਤੀਜਾ 20% ਕੋਸ਼ਿਸ਼ਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ। 80% ਮਾਲੀਆ 20% ਗਾਹਕਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ, 80% ਲਾਭ 20% ਕਰਮਚਾਰੀਆਂ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੀ। ਅਧਿਆਪਨ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ 80% ਗਿਆਨ ਅਸੀਂ ਬਿਤਾਏ ਸਮੇਂ ਦੇ ਪਹਿਲੇ 20% ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ।

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

ਕੁੱਲ: ਤੁਸੀਂ ਆਪਣਾ 100% ਸਮਾਂ ਸੀਮਾ ਤੱਕ ਕਿਸੇ ਹੁਨਰ ਦਾ ਅਧਿਐਨ ਕਰਨ ਵਿੱਚ ਬਿਤਾ ਸਕਦੇ ਹੋ, ਜਾਂ ਤੁਸੀਂ ਪੰਜ ਖੇਤਰਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਸਮਾਂ ਬਿਤਾ ਸਕਦੇ ਹੋ, ਹਰੇਕ ਵਿੱਚ 80% ਤੱਕ ਲੈਵਲਿੰਗ। ਇਸ ਭੋਲੇ-ਭਾਲੇ ਗਣਿਤ ਦਾ ਪਾਲਣ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਉਸੇ ਸਮੇਂ ਵਿੱਚ ਚਾਰ ਗੁਣਾ ਜ਼ਿਆਦਾ ਹੁਨਰ ਹਾਸਲ ਕਰ ਸਕਦੇ ਹਾਂ। ਇਹ ਇੱਕ ਅਤਿਕਥਨੀ ਹੈ, ਪਰ ਇਹ ਵਿਚਾਰ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ.

ਸੰਬੰਧਿਤ ਹੁਨਰਾਂ ਨੂੰ 80% ਦੁਆਰਾ ਨਹੀਂ, ਪਰ 30-50% ਦੁਆਰਾ ਸਿਖਲਾਈ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ। 10-20 ਘੰਟੇ ਬਿਤਾਉਣ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਸਬੰਧਤ ਖੇਤਰਾਂ ਵਿੱਚ ਧਿਆਨ ਨਾਲ ਸੁਧਾਰ ਕਰੋਗੇ, ਉਹਨਾਂ ਵਿੱਚ ਹੋਣ ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਬਹੁਤ ਸਾਰੀ ਸਮਝ ਪ੍ਰਾਪਤ ਕਰੋਗੇ ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਖੁਦਮੁਖਤਿਆਰੀ ਬਣ ਜਾਓਗੇ।

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

ਅਤੇ ਅੰਤ ਵਿੱਚ, ਸਿਖਲਾਈ ਇੱਕ ਨਿਵੇਸ਼ ਹੈ, ਅਤੇ ਨਿਵੇਸ਼ ਵਿੱਚ ਵਿਭਿੰਨਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਕੀ ਸਿਖਾਉਣਾ ਹੈ

ਤਾਂ ਕੀ ਸਿਖਾਉਣਾ ਹੈ ਅਤੇ ਕਿਵੇਂ? ਇੱਕ ਮਜ਼ਬੂਤ ​​ਕੰਪਨੀ ਵਿੱਚ ਇੱਕ ਆਮ ਡਿਵੈਲਪਰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਵਰਤਦਾ ਹੈ:

• ਸੰਚਾਰ
• ਸਵੈ-ਸੰਗਠਨ
• ਯੋਜਨਾਬੰਦੀ
• ਡਿਜ਼ਾਈਨ (ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ)
• ਅਤੇ ਕਈ ਵਾਰ ਪ੍ਰਬੰਧਨ, ਲੀਡਰਸ਼ਿਪ, ਡਾਟਾ ਵਿਸ਼ਲੇਸ਼ਣ, ਲਿਖਣਾ, ਭਰਤੀ, ਸਲਾਹਕਾਰ ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਹੁਨਰ

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

ਕਿਹੜੇ ਖੇਤਰਾਂ ਵਿੱਚ ਵਿਕਾਸ ਕਰਨ ਦੇ ਯੋਗ ਹਨ?

1. ਨਰਮ ਹੁਨਰ ਉਹ ਸਭ ਕੁਝ ਹੈ ਜੋ ਸੰਪਾਦਕ ਵਿੱਚ ਬਟਨ ਦਬਾਉਣ ਦੀ ਚਿੰਤਾ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਸੰਦੇਸ਼ ਲਿਖਦੇ ਹਾਂ, ਅਸੀਂ ਮੀਟਿੰਗਾਂ ਵਿੱਚ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਸਹਿਕਰਮੀਆਂ ਨਾਲ ਕਿਵੇਂ ਸੰਚਾਰ ਕਰਦੇ ਹਾਂ। ਇਹ ਸਭ ਸਪੱਸ਼ਟ ਚੀਜ਼ਾਂ ਜਾਪਦੀਆਂ ਹਨ, ਪਰ ਅਕਸਰ ਉਹਨਾਂ ਨੂੰ ਘੱਟ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ.

2. ਸਵੈ-ਸੰਗਠਨ ਸਿਸਟਮ. ਮੇਰੇ ਲਈ ਨਿੱਜੀ ਤੌਰ 'ਤੇ, ਇਹ ਪਿਛਲੇ ਸਾਲ ਵਿੱਚ ਇੱਕ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ਾ ਬਣ ਗਿਆ ਹੈ. ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਸਾਰੇ ਵਧੀਆ IT ਕਰਮਚਾਰੀਆਂ ਵਿੱਚੋਂ, ਇਹ ਸਭ ਤੋਂ ਵੱਧ ਵਿਕਸਤ ਹੁਨਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ: ਉਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੰਗਠਿਤ ਹਨ, ਉਹ ਹਮੇਸ਼ਾ ਉਹੀ ਕਰਦੇ ਹਨ ਜੋ ਉਹ ਕਹਿੰਦੇ ਹਨ, ਉਹ ਬਿਲਕੁਲ ਜਾਣਦੇ ਹਨ ਕਿ ਉਹ ਕੱਲ੍ਹ, ਇੱਕ ਹਫ਼ਤੇ ਵਿੱਚ, ਇੱਕ ਮਹੀਨੇ ਵਿੱਚ ਕੀ ਕਰਨਗੇ। ਆਪਣੇ ਆਲੇ ਦੁਆਲੇ ਇੱਕ ਪ੍ਰਣਾਲੀ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜਿਸ ਵਿੱਚ ਸਾਰੇ ਮਾਮਲੇ ਅਤੇ ਸਾਰੇ ਪ੍ਰਸ਼ਨ ਦਰਜ ਕੀਤੇ ਜਾਂਦੇ ਹਨ; ਇਹ ਕੰਮ ਨੂੰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਬਹੁਤ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਲੋਕਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਮਦਦ ਕਰਦਾ ਹੈ. ਮੈਂ ਮਹਿਸੂਸ ਕਰਦਾ ਹਾਂ ਕਿ ਪਿਛਲੇ ਸਾਲ ਵਿੱਚ, ਇਸ ਦਿਸ਼ਾ ਵਿੱਚ ਵਿਕਾਸ ਨੇ ਮੇਰੇ ਤਕਨੀਕੀ ਹੁਨਰ ਨੂੰ ਸੁਧਾਰਨ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੁਧਾਰ ਕੀਤਾ ਹੈ; ਮੈਂ ਸਮੇਂ ਦੀ ਪ੍ਰਤੀ ਯੂਨਿਟ ਵਿੱਚ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ ਹੈ।

3. ਕਿਰਿਆਸ਼ੀਲ, ਖੁੱਲੇ ਦਿਮਾਗ ਅਤੇ ਯੋਜਨਾਬੰਦੀ. ਵਿਸ਼ੇ ਬਹੁਤ ਆਮ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਆਈ.ਟੀ. ਲਈ ਵਿਲੱਖਣ ਨਹੀਂ ਹਨ, ਅਤੇ ਹਰ ਕਿਸੇ ਨੂੰ ਉਹਨਾਂ ਦਾ ਵਿਕਾਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਕਿਰਿਆਸ਼ੀਲਤਾ ਦਾ ਅਰਥ ਹੈ ਕਾਰਵਾਈ ਕਰਨ ਲਈ ਸਿਗਨਲ ਦੀ ਉਡੀਕ ਨਾ ਕਰਨਾ। ਤੁਸੀਂ ਘਟਨਾਵਾਂ ਦੇ ਸਰੋਤ ਹੋ, ਉਹਨਾਂ ਪ੍ਰਤੀ ਪ੍ਰਤੀਕਰਮ ਨਹੀਂ. ਖੁੱਲ੍ਹੀ ਸੋਚ ਕਿਸੇ ਵੀ ਨਵੀਂ ਜਾਣਕਾਰੀ ਦਾ ਉਦੇਸ਼ਪੂਰਣ ਢੰਗ ਨਾਲ ਇਲਾਜ ਕਰਨ ਦੀ ਯੋਗਤਾ ਹੈ, ਕਿਸੇ ਦੇ ਆਪਣੇ ਵਿਸ਼ਵ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਅਤੇ ਪੁਰਾਣੀਆਂ ਆਦਤਾਂ ਤੋਂ ਅਲੱਗ-ਥਲੱਗ ਸਥਿਤੀ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ। ਯੋਜਨਾਬੰਦੀ ਇੱਕ ਸਪਸ਼ਟ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਹੈ ਕਿ ਕਿਵੇਂ ਅੱਜ ਦਾ ਕੰਮ ਹਫ਼ਤੇ, ਮਹੀਨੇ, ਸਾਲ ਲਈ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਖਾਸ ਕੰਮ ਤੋਂ ਪਰੇ ਭਵਿੱਖ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਹੈ, ਅਤੇ ਸਮੇਂ ਦੇ ਬਾਅਦ ਇਹ ਮਹਿਸੂਸ ਕਰਨ ਤੋਂ ਡਰੋ ਕਿ ਇਹ ਬਰਬਾਦ ਹੋ ਗਿਆ ਸੀ. ਇਹ ਹੁਨਰ ਕੈਰੀਅਰ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਤੁਸੀਂ ਸਾਲਾਂ ਤੱਕ ਸਫਲਤਾਪੂਰਵਕ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਗਲਤ ਜਗ੍ਹਾ 'ਤੇ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਜਦੋਂ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਗਲਤ ਦਿਸ਼ਾ ਵਿੱਚ ਜਾ ਰਹੇ ਸੀ ਤਾਂ ਸਾਰਾ ਇਕੱਠਾ ਕੀਤਾ ਸਮਾਨ ਗੁਆ ​​ਸਕਦੇ ਹੋ।

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

ਕੀ ਪੜ੍ਹਨਾ ਹੈ

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

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

2. ਸਟੀਫਨ ਆਰ. ਕੋਵੇ "ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੋਕਾਂ ਦੀਆਂ 7 ਆਦਤਾਂ". ਵੱਖ-ਵੱਖ ਹੁਨਰਾਂ ਦਾ ਮਿਸ਼ਰਣ, ਕਿਰਿਆਸ਼ੀਲਤਾ ਤੋਂ ਲੈ ਕੇ ਨਰਮ ਹੁਨਰਾਂ ਤੱਕ, ਜਦੋਂ ਤੁਹਾਨੂੰ ਇੱਕ ਛੋਟੀ ਟੀਮ ਨੂੰ ਇੱਕ ਵੱਡੀ ਤਾਕਤ ਵਿੱਚ ਬਦਲਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਤਾਲਮੇਲ ਪ੍ਰਾਪਤ ਕਰਨ 'ਤੇ ਜ਼ੋਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਪੜ੍ਹਨਾ ਵੀ ਆਸਾਨ ਹੈ।

3. ਰੇ ਦਲਿਓ "ਸਿਧਾਂਤ". ਲੇਖਕ ਦੁਆਰਾ ਬਣਾਈ ਗਈ ਕੰਪਨੀ ਦੇ ਇਤਿਹਾਸ ਦੇ ਅਧਾਰ ਤੇ, ਖੁੱਲੇ ਦਿਮਾਗ ਅਤੇ ਕਿਰਿਆਸ਼ੀਲਤਾ ਦੇ ਥੀਮਾਂ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ, ਜਿਸਦਾ ਉਸਨੇ 40 ਸਾਲਾਂ ਤੱਕ ਪ੍ਰਬੰਧਨ ਕੀਤਾ। ਜ਼ਿੰਦਗੀ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਮੁਸ਼ਕਲਾਂ ਨਾਲ ਜਿੱਤੀਆਂ ਉਦਾਹਰਣਾਂ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ ਕੋਈ ਵਿਅਕਤੀ ਕਿੰਨਾ ਪੱਖਪਾਤੀ ਅਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਕਿਵੇਂ ਛੁਟਕਾਰਾ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

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

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

ਸਰੋਤ: www.habr.com