I’ve been working at the same job for 15 months and on the 24th June I worked my last day there. My time there has had some extremely positive points, but has also had some frustrating moments like any tech job.
I’m moving to a more senior position where I’ll become the “Tech Lead” for the new company and hopefully be in a position to alleviate some of those frustrating things for new hires that we plan to make in the coming months.
I’ve been lucky over the past few years to work at companies that have had a really progressive attitude towards remote workers. This has seen me work primarily remotely for over 4 years now, and, to be honest, I don’t think I could go back to being in an office every single day as I find that I’m just way more productive when I’m at home. Nobody ever said “I’ve got so much to do, I’d better go into the office to make sure I get it done”. It’s always the opposite situation where people have lots of things to do so they take a step away from the office, if only briefly, to concentrate on those things.
During the past few weeks, I’ve been contemplating what an ideal environment to work in would be, whether that be in an office or remote, and I’ve come up with a few ideas that I think would make any tech position a lot of fun.
Encouraging Junior Developers
I’m a firm believer that without the Open Source community there wouldn’t be as many opportunities for developers. And I’m also a firm believer that nurturing and encouraging developers (and companies) to support open source is essential for long term success in tech. To marry these two together, I would always suggest that companies encourage junior developers to maintain low activity or neglected open source projects. Something not too distant from things that they would use in the workplace, but also not so close that it’s essential that bugs are fixed.
Giving developers the opportunity to contribute something back to the community should always be seen as a good thing. Most companies use open source software to build their tech stacks and not allowing contributions from their developers seems, to me, to be short sighted.
The benefits to allowing this should be obvious, but in addition to nurturing talent, it also gives the developers experience of working with different methods of contribution that can feed into their work life. The structure and communication needed for contributions to an open source project will reflect in the developer’s contributions to work projects - giving a greater clarity and focus to their work. A win for everyone.
As an added bonus, giving a developer time during their working day to do this would be ideal. Which leads to the next point…
Allowing Time For Learning
It’s vital for any forward-thinking tech company to allow developers to learn more skills. Being able to progress is (quite often) more attractive to developers than any other benefit provided by a company, and keeping them happy and fulfilled whilst employed means that they will be able to do better work.
Allowing devs some time - possibly a day per week, or fortnight - to work on their own projects, to learn new technologies, improve internal tools, automate frustrating repetitive tasks or something that doesn’t fall within the scope of their normal day to day activities will inevitably lead to discoveries and skills that can help in work related projects.
Google does this extremely well - GMail was one of those projects and is now one of their core offerings.
It’s not always easy for a company to give this time, especially when deadlines are looming or there is something that has to get done now, but the time given should be sacred. If the developer can count on that time always being there, they won’t be averse to putting in a little extra effort or time to get something out of the door for work. At least, I certainly wouldn’t.
Allow Further Learning
One of my most treasured benefits at previous jobs has been the ability to be able to go to conferences. Paid for by the company. As your tech team gets seen more and more, and they become more well known in the community, it’s increasingly easy for them to reach out.
This can take many forms: maybe they need some help with a bug in a framework, maybe they can’t get something to work properly that seems like it should. Sometimes just knowing the right people (many of whom hang out at conferences a lot) can make asking for help a lot easier.
But the effect is also true the other way around. Being active in the community allows your developers to give help too - and sometimes that’s even more beneficial than receiving it because it allows them to see pain points that others face, which, in turn, can impact on the usability of your own projects.
I’ve worked for companies that do all of the above, some that do some, and some that do none of the above, and I can honestly say that I’ve been the happiest at the ones that did them all. Sometimes it’s hard for management to justify the expense of training and allowance of time, but if no training is provided, and no time for exploration is granted, we end up in a situation where the end product isn’t as good as it could have been.
I hope that I’m afforded the luxury of being able to grant team members these benefits in my upcoming role. And, if so, I’m sure that the upcoming projects will be a success.
What are your thoughts?