In the past I have just restricted Jenkins access to our main static IP, and whitelisted GitHub's published Webhook IP ranges. Remote employees just need to login to the office VPN to access the UI & SSH.
Does the articles method provide further flexibility? It seems much more complex!
As a Developer who was brought into the industry through this process, and now leading development of an online platform after leaving my last company, I feel there are definitely approaches my first company could have taken which would have kept me on for a lot longer.
Speaking with a CTO of a small web company recently I got to understand the issue from both perspectives.
CTO’s thoughts when hiring junior devs:
- Can be great for company but only if it makes economical sense I.e the developer stays with the company long enough after training
- From experience, the best devs from training move on to other companies soon after training
- Junior devs ask for frequent pay rises that aren’t viable for the company, holding the companies investment in the dev against them
Thoughts of a junior when considering other roles:
- How respected & valued will they be old vs new
- How interesting is the work, and will there be continued opportunity to develop themselves and learn new skills old vs new
- Salary old vs new
- The potential for future career prospects old vs new
Good junior devs will naturally be very enthusiastic and eager to learn, and the company needs to support this through and beyond the training to keep them motivated and engaged. On top of this, juniors will want to see regular progressions through the training process in forms of clear recognition and increases in pay and responsibilities as they progress. If these are not given, it’s likely the junior will feel under appreciated / taken advantage of.
Progression through a training course like this is motivated by success, and rewards, not unlike video games.
In my opinion the best way a company can keep a junior happy is to follow this and apply some of the proven methods researched and applied all over the video games industry.
- Progressively difficult but achievable tasks (missions)
- A sense of accomplishment from these (contributing towards real projects)
- Regular checkpoints ( targets and 2-3monthly reviews to support these)
- Regular rewards (small but regular pay increases, matched with greater responsibility and clear recognition of progression in the company; mutual respect is important!)
The list goes on.
If an approach like this is followed, the dev is much more likely to come out of training with a great sense of achievement and an attachment to the company for the support and rewards that were received. I think this massively increases the chances of a dev staying on, Provided salary, job title and sense of respect are matched with other members of the team in similar roles. I feel this is something many companies don't put enough thought into considering the large investment they're putting into the dev.
I've been implementing a similar regime on my smart phone for the last few months. After cracking a previous phone and resorting to a brick phone, I remembered how much I'd enjoyed the time I used to have with out a screen, either to read or just think.
I was eventually swayed back onto a smart phone after moving to a new city (for google maps) and now use that almost solely along with music, and occasionally chrome for fact-finding.
Would definitely recommend giving it a couple of months trial!
Does the articles method provide further flexibility? It seems much more complex!