Inspired by the many conversations I’ve had since joining the tech community, by questions I’d been asked over the last six months about my journey into a full time tech job and how I’ve navigated all the learning, content and jargon in the industry, I set out to create a platform for open communication to help others – like me – learn from our peers, boost our confidence and build our communities.
In April, I launched my Twitter Spaces series #TechTable. In this series I’m bringing some of my favourite people to the table to answer all those questions you’re too afraid to ask. Worried about technical interviews? No idea what caching is? Confused by APIs? Then #TechTable is the space for you.
I chose Twitter Spaces as I wanted my platform to be accessible and at the heart of my community. My Twitter connections have taught me so much over the last 12 months (as I mentioned here) and I was keen to platform my community so they could share their learning with (and learn from) all of you!
On 14th April, my first space, I invited Elle Townsend and Eddie Jaoude to talk about Open Source and Open Learning. We were joined by some amazing speakers many of you will be familiar with and had some great questions from developers at all stages of their career. Here’s some of my reflections:
Why you should get into open source and open learning regardless of technical background
- As with any piece of content you put out there, you can’t control how people will react to your code. Instead of worrying about others’ reactions, think about the factors you can control. 1) Is this code useful? 2) What is the purpose of this project/tutorial/post? 3) Are you happy with it? And, if you have an answer to all these questions and – importantly, number three – that’s all that matters
- Ignore the haters – you will never impress everyone and the bigger your profile, the more negative comments you will receive
- It helps with hiring if you learn in public. Whether it’s contributing to an open source project, sharing your #30DayChallenge, #60DaysOfCloud, #100DaysOfCode, blog posts, videos – employers look at your work from today and from 3-6 moths ago to show improvement and a commitment to learning
- If you’re getting comments on your open source projects, take time to respond and respond how you would like to be treated. Not only will employers look at the heated comments people receive and see how you handle these, it’s a good way to learn how to work well in a team remotely, how to boost your communication skills and understand the impact of your work
- It’s all about problem solving and showing your capabilities in this area. Problem solving is the key skill in most tech jobs. In each project, tutorial or course you do – focus on the learning you can get out of it. Open source is great resource for this as reading other people’s code gives makes you a better developer especially if you focus on why this problem needed to be solved over the how
How can senior developers get involved in open source and what they have to offer
- The senior part isn’t as important. The same benefits our speakers had contributing to open source at the beginning of their career continues today. The continuous learning and growing network is still beneficial now as before
- Github is also a social platform now. Helps you build a community and understand more about the tech world from the ground up
- In the same way you would hire junior people to help your company innovate, bring fresh ideas and eventually lead, someone can add value regardless of their experience in years. In tech we must continue to foster vertical and horizontal learning
How can I make my Github profile *pop* and attract more people to my network
- Don’t have code that lacks context! Many love writing code but hate reading code. Be clear with the intent. What did you set out to do and why. Take pictures of your project and post this alongside the code to help explain this to viewers
- So many people say they put code out but nobody is discovering it or getting involved – most of the time it’s because those projects don’t have anything other than code. Add code of conduct, license and a README. Use the issues sections in your own projects
- Don’t copy tutorial code. For example, if the tutorial is to create a job posting board then change it to something slightly different such as an online recipe book or housing site. Changing fields helps you learn and share better, making your project unique to you. Employers and many open source coders will notice project/tutorial code quickly so it helps boost your profile to show your uniqueness
- Go to coding meet-ups! You get free code reviews, build a community and find those who may have similar interests to you, want to collaborate or have something to teach you from their experience and learning. Code changes everyday so if you don’t evolve with the industry you’ll be left behind
How to get over nerves when posting my learning or code openly
- Many people online put themselves down and caveat projects saying: “my code is not great”, “I don’t know what I have to say”, “people won’t care about my voice or my code”. As I’ve shared many times, you’re not expected to be unless you tell people (or yourself) that you are. You don’t need to be the Michelangelo of coding to contribute to open source. It’s all about documenting your journey, your learning and building your community
- If someone offers to correct your code, give a new idea or perspective to your project – take it, learn from it and use it. It is not a sign that you’ve failed or even necessarily done something wrong. If they’re willing to spend the time to check your code – thank them
- If you don’t want to take their contribution – explain why. Got to the closed closed issues and pull requests on any projects you want to contribute to – see the ones that are not merged. If the project maintainer just closes requests without answering that’s not an inclusive project. This can be disheartening if you’re new to open source and should keep in mind it speaks more about them than about you
- If you comment on others’ work make sure to check styling guides (and provide them on your own projects!), oftentimes requests are denied because they simply don’t match or the context hasn’t been given by the reviewer either
- Coding and learning is hard. We all know this from school, university, courses, but the benefits out-way downsides. Treat this as a fun learning experience and not a test and it’ll help lessen your nerves
- Nerves and even anxiety is normal when sharing anything openly. Make sure to go at your own pace and avoid comparison with others. As long as you are being honest, open and committed to learning – you’re doing the right thing
How to balance contributing to other projects vs. maintaining your own, and how to balance time for open source projects and open learning content with other commitments
- Explore where you find the most value and fulfilment for yourself in your learning journey
- Only create collaborative projects if you’re fully committed to the outcome. Being a project maintainer is a lot of work and if people are willing to spend time to contribute to the project, you should be on hand (within reason) to help them
- Start by raising issues – with context – this helps you learn and everyone reading learns too
- Remember: writing the coolest thing isn’t necessarily the best thing. Tech is vast and not every aspect of tech will be interesting/beneficial to you. Start any project, course or learning with aims and intentions for that project
- Share your journey on platforms that work for you. This could be Twitter, Github, blogging, Community groups, YouTube videos. Use social media with intention to avoid over-saturation, pressure to post and even burnout. Share to boost yourself and support others
- Focus on building your community
Thank you to everyone who took part in #TechTable. The next session is on Wednesday 21st April at 7pm (BST) and we’re talking ✨ Taking the Leap: Career Switching ✨
Make sure to ⬇️ follow ⬇️ so you don’t miss out!
rkulidzan 