Building Your Profile as a Developer
Most of the software that runs the world was built by software engineers you’ve never heard of: quiet achievers who toil away under fluorescent lights. Some of the best software engineers I’ve ever worked with have made incredible contributions to their teams and the projects they’ve worked on, but left no trace online. Their GitHub profiles were mostly empty, they didn’t have websites, they didn’t have side projects, and they didn’t speak at conferences. Having a public profile as a software engineer isn’t essential in being a great engineer, but it can help you in a number of different ways.
- It can help you get jobs.
- It can help you ask for and justify a higher salary.
- It can help you progress within your current company.
- It can help you launch a freelance career or business.
- It’s a great way to give back to the software engineering community.
Even though most engineers I’ve worked with haven’t had much of a profile outside of their current companies, almost all have wanted to build one. They’ve wanted to blog, give conference talks, publish open source projects, etc., but for one reason or another, it didn’t happen. In most cases, the constraint wasn’t a lack of time. One of the most prolific conference presenters I’ve ever met is also a devoted father of young boys. For most, it’s not because of a lack of time, talent, or things to contribute. They just don’t know how, or where, to start.
This post rests on a few central arguments:
- Most of the ways developers think about building up their profile, like blogging or giving talks, are easier than they seem.
- Your day-to-day work is fodder for a huge number of potential blog posts, conference talks, meetups, and open source projects.
- Regardless of what you do day-to-day — how easy, boring, or weirdly specific it may seem — there are thousands of other software engineers doing something very similar who could benefit from your help and experience.
Putting yourself out there becomes easier the more you do it. It can help to start small. Here are a few suggestions for simple ways to start building your profile as a software engineer.
Write and publish a blog post on Medium.
I recommend starting with Medium, as opposed to publishing on your own website, because it provides no opportunity for fiddling around with tech and never publishing anything. I suspect there are thousands of developer blogs and websites that have never seen the light of day because of this temptation. Even if you think Medium sucks and people should retain full ownership of their content, you can always take down your post and publish it on your own website later.
Photo by NeONBRAND on Unsplash.
I’ve written probably over 100 blog posts on dozens of websites. One thing I’ve noticed is that people carry a lot of assumptions about what publishing on the internet requires: it must be a certain length, be written in a certain way, be incredibly well-researched, or that you must understand every aspect of something before you can write about it. None of these things are true. When software engineers are interested in blogging but don’t know what to write about, I encourage them to write about one thing they learned that day or a problem they solved. Write the article you wish you’d found when looking for solutions to your problem.
Another thing that stops people from writing is a fear of making mistakes and looking foolish. I’ve made mistakes in articles that I’ve written, but generally all that happens is that someone leaves a comment with a correction, the article is updated, and everything works out okay. It isn’t as bad as you imagine.
Speak at a local meetup, the smaller the better, preferably to an audience of beginners.
Many software engineers would love to speak at a conference one day, but without much public speaking experience, the task seems daunting. The best way to build up confidence presenting on software engineering topics is to speak at local meetups. Many meetups have slots for several lightning talks, where people speak for a few minutes to an audience of a few dozen people. For many meetups, especially smaller meetups, it’s a struggle to fill all of the speaker slots. This often leads to the same people presenting again and again. Simply being a new face is often enough to generate some interest in your talk, and it’s hard to find a more forgiving audience than meetup attendees whose tummies are full of free food and drink.
I mention presenting to beginners because the idea of giving a talk to a small audience of peers or more senior engineers is still daunting for many. Some meetups hold “newbie nights” designed to attract less experienced engineers — these can be an excellent place to practice speaking in a setting where you’re sure to have more experience than the audience. My first talk was at a meetup for Ruby newbies, and it was the perfect audience for me at the time: even though I was a junior developer, the beginner audience enabled me to be the “expert” for that evening.
Photo by Kane Reinholdtsen on Unsplash.
Contribute to a tiny open source project.
Almost every software engineer aspires to publish or contribute to open source projects. Large, very active open source projects can, however, be really tough to get involved with. Any “low-hanging fruit” type fixes have already been made, leaving behind only difficult tasks that require extensive knowledge and project context. Highly active open source projects also often have lots of red tape and complex procedures for contributing. I’ve found that small open source projects (fewer than 10 contributors or 100 stars on GitHub) can be an excellent way to get involved with open source. These projects often have much less red tape around contributing, creators have more time to guide you through getting your first pull request merged, improvements are easier to identify, and contributions are simpler to make.
Contribute documentation to a really big open source project.
If you’ve set your sights on contributing to a big, famous open source project, there’s still lots of opportunity. One aspect of these projects that almost always has significant room for improvement is documentation. Documentation is usually not in-depth enough, out of date, or contains typos, spelling mistakes, and grammatical errors. Documentation improvements are also often easier for project maintainers to review than code changes and, as such, are more likely to be merged and reviewed quickly. I have been able to contribute to a number of big Ruby gems by helping with documentation. It’s worth noting that I will always tell potential employers that I “contributed documentation to” the project rather than “contributed to” the project. Even though the latter is technically true, it is potentially misleading. Besides, contributing documentation is just as awesome, and just as important, as contributing code.
Record a software engineering screencast and put it on YouTube.
Some people find writing difficult. Give them a whiteboard and the opportunity to speak and they can explain a concept clearly and beautifully in a matter of minutes, but a blog post on the same topic would take them hours to write. If this resonates with you, then screencasting may be a better way than writing for sharing your knowledge. Here are some ideas for a screencast:
- Talk through how you solved a particular problem and recreate your steps as you do so
- Demonstrate something you just learned about a programming language, framework, or tool
- Record yourself while you work on a side-project
- Show people how to recreate an aspect of your development environment that you really enjoy, such as your editor config
There are lots of free tools for screencasting, such as QuickTime for OS X, and VLC for Windows. Your laptop’s built-in microphone is probably adequate to start with. Once you’ve recorded your screencast, upload it to YouTube. Try to give your video a title that contains words and phrases that people might be searching for if they want to find a video like yours — for example, ‘How to eradicate Ruby nil values’ rather than ‘Some things I learned today’.
Photo by Simon Abrams on Unsplash.
Organize an event or meetup.
Websites like Eventbrite and Meetup.com have made it easier than ever before to create a new event or meetup. In fact, it’s possible to go from having an idea for an event to receiving several RSVPs within just a couple of hours. Here are some possible reasons to organize a new meetup or event:
- There isn’t a meetup in your area for the topics you’re interested in (Kubernetes, Tensorflow, Tech Leadership, 3D Printing, etc.).
- You have a different take on what a community around your interests could be like.
- You have an idea for a one-off event that doesn’t exist yet (for example, a friend and I organized a one-off “Women on Wikipedia” party to create Wikipedia pages for notable women in tech who didn’t have them).
- You’d like to create a place for you and likeminded people to receive support, whether it’s a junior developers’ meetup or a meetup for software engineers with disabilities.
Event organizers are forced to interact with many different people, not just your attendees but sponsors, caterers, employers, and venue staff. It’s a quick way to become known in your chosen community. Even better, tech events and meetups can generally be run for free. Check if your workplace will allow you to use your office as a venue, or if your workplace isn’t suitable, get in touch with other prominent tech companies or co-working spaces in your area. Most are happy for their space to be used for a meetup or event because it builds up their brand. Companies that tend to hire software engineers in your area of interest are also often happy to foot the bill for food and drinks in exchange for a small plug at your events.
Photo by Tegan Mierle on Unsplash.
Hold a workshop or brown-bag for your colleagues.
Book a large meeting room or conference room at your office — and tell your colleagues via Slack, meeting invite, or email — that you’re giving a talk/holding a workshop/or running a brown-bag. Somewhat counterintuitively, the best topics for these are not directly work-related. A “React Best Practices” talk can seem preachy when given to an audience of fellow skilled React developers. Instead, pick something technical but not part of your typical day-to-day. I saw this done successfully at a recent client’s event where one of the software engineers held a brown-bag on Elixir. Though Elixir was of interest to many of the engineers there (it was a Ruby shop), it wasn’t used day-to-day, so the session felt like a fun and interesting break from day-to-day development.
Though holding workshops and brown-bags doesn’t build your profile outside of your company, it helps build your profile within your company which is likely to be appreciated by future employers. It can be a great way to practice public speaking in an even more supportive environment than giving a talk at a local meetup.
Take a first step within the next 24 hours
Pick one of the items on this list and take a small step towards it within the next day or so.
- If you’ve decided to write a blog post, then create a Medium account and fill out your profile.
- If you’ve decided to speak at a local meetup, pick a meetup and find the organizer’s contact information.
- If you want to contribute to a small open source project, think about smaller, more specific tools and libraries you use with fewer than 100 stars on GitHub or fewer than 10 contributors. Alternatively, think about limitations in your favourite small tools or frameworks you believe you can fix.
- If you want to contribute to documentation for a big open source project, identify the project and the contribution you would like to make. If your spelling and grammar is good, then you can warm up by fixing a few typos and grammatical errors. There are always some to be found!
- If you want to record a screencast, spend 10 minutes coming up with ideas for topics you could make a screencast about.
- If you want to organize an event or meetup, spend 10 minutes coming up with ideas for your event.
- If you want to hold a workshop or brown-bag for your colleagues, talk to some of your colleagues to get ideas for potential topics they’d like to learn more about.
Building your profile as a software engineer isn’t as difficult as you’d think, and you can take some small steps today. We’d love it if you could share your progress in the comments section of this post. Good luck!