Post Published on July 27, 2024.
Last Updated on July 27, 2024 by davemackey.
Right now the job market for software developers / engineers is annoying / challenging / frustrating. There seem to be lots of open positions, but companies are turning down candidates like crazy and asking candidates to jump through ridiculous hoops. You can easily put out fifty applications and hear back from only 1 or 2. I’m lucky to have as much work as I can handle at the moment but I’ve been there in the past and know that I could be in the future.
Recently, when talking with job seekers I have had one main suggestion: contribute to open source projects. A recent conversation helped me realize that I needed to be more detailed in explaining the benefits of contributing to an open source project.
Work on a Team
I’d recommend choosing a project that has a decent number of developers already contributing. Look for projects that have some structure around how the team works – e.g., how are major decisions made? Do the developers pair program if one or another runs into a problem? Are senior members of the team approachable? How is leadership handled?
Lone-wolfing can be fun – but it also means we aren’t getting that teamwork experience. Developing the soft skills and demonstrating you are a team player are important in landing a new position. Many job descriptions I’ve seen specifically reference having teamwork experience.
Work with a Pipeline
When we work on a project solo we may not setup all the pipes that exist in a project managed by a team. For example, a team run open source project may:
- Have pre/post hooks setup for Git to ensure that code meets certain standards.
- Require a Pull Review (PR) process to ensure only high quality code gets merged into the main branch.
- Provide a container setup one can use to get started quickly and which is useful for understanding how containers work and interconnect.
- Use CI/CD pipelines to ensure that code runs correctly and/or is deployed continuously.
- Use various forms of tests (e.g., unit, e2e, visual regression) to ensure there aren’t regressions or bugs in the software.
- Have specific guidelines for formatting code and various tooling that supports these guidelines (e.g. linters).
Learning some DevOps can be hugely useful and while the company you eventually work for may not use the same pipes, they’ll likely have many of the same type of pipes (e.g., one might use CircleCI while the open source project you are using might use GitHub Actions).
Learn from Professionals
It isn’t always easy to get the ear of more senior software engineers. When one works on an open source project one can offer tangible value to senior engineers which encourages them (even more than they may naturally be inclined) to invest time in you – helping you figure out coding or environment challenges. They know that the cost of helping you will be worth it in the long-term benefits to the project.
Don’t necessarily expect this sort of investment off the bat. You might need to show yourself useful before you get much attention. Although, some projects, (e.g. Gatsby at least at one time) specifically offer some sort of pair / mentor / etc. relationship for devs who join a project.
Stay Fresh
Some of us have an easier time staying in the code than others when we have a break in employment. Working on an open source project encourages you to stay in the code which keeps your knowledge fresh (or develops new knowledge).
Build a Network
In my experience people want to help others. As you work on open source projects you’ll meet individuals who can become part of your network and through whom you might just secure that next position.
Stay Diverse
It can be tempting when working on our own code to use the tooling we are most comfortable with. This isn’t necessarily a bad thing but in the “real world” of software projects, there is usually give-and-take on what ends up being used in a project.
While you might like pipenv, the team may be using poetry and you’ll need to stretch yourself and learn new tech. Similarly, one might end up working with a different component library for React or Vue than one has previous experience with. The database might be relational instead of NoSQL or vice versa. The list goes on. Don’t paint yourself into a corner, be diverse.
Build a Reputation
As you contribute to open source projects you develop a reputation (hopefully good). You provide potential employers with the opportunity to see the quality of your work in the real world. My experience is that recruiters are actively searching GitHub for developers – seeing that you are regularly committing code and working with the technologies they are looking for is a good way to draw attention to yourself.
Pad Your Resume
If you are a relatively new developer you might not have previous job experience to list on your resume. Being able to point to open source projects you’ve made tangible contributions to is a great way to demonstrate experience. You can set yourself apart from all the other newbies simply by participating.
Conclusion
If you are currently looking for a coding job, I highly recommend jumping onto an open source project or two. Look at the tech stack you are using or want to use and then search for projects that are working with that tech stack.
Have I missed anything? Do you think one of my benefits is off base? Or do you disagree with my perspective on the importance of open source contributions? Leave a comment, I’d love to hear from you.
I think I disagree with your premise. Not because “working on open source” isn’t a great idea, I just believe that it’s a bad idea for the purposes of getting a job.
I love the idea of contributing to Open Source, but doing it as a side-quest on a journey to get a new job is the wrong approach. I think you’ve perfectly captured all of the outcomes that someone should focus on between jobs (Staying Fresh, Building a Network, Staying Diverse, Building a Reputation, etc), but I think your prescription (contributing to Open Source) is wrong for the patient.
My encouragement to someone looking to stay fresh and get a new job is to build complete projects by yourself. It can be a full-fledged Open Source project if you want, but I think the value in software development is not the act of writing code; instead knowing how to think like a programmer — architectures, data models, deployment, structure of a project, algorithms, etc.
Don’t Half-Ass It
The important part of my suggestion is the complete project and by yourself. Most software engineers incorrectly believe that their job is to take a business requirement and turn that into working lines of code. This is a terrible approach to our profession and is one of the biggest things I see holding people back from truly growing and becoming a valuable developer and advancing their profession. As professional engineers, we’re hired to create business value out of thin air to problems for your stakeholders. We write code, yes, but we do so much more.
You’re never paid to code. You’re paid to create value.
When I hire software engineers, I’m always looking for someone I can hire that won’t need to bog down anyone else on the team. I always want “full stack developers”, where I can say “build this feature” and they know how to gather requirements, ask interesting questions to the stakeholder, design the database tables, implement the business logic, and tie it all together in a useful well-designed front end. When I see people that specialize in something like “front-end” or “back-end” or some other made-up title, it looks to everyone else that they’re describing themselves as “half of a developer” and letting the world know they’re more trouble than they’re worth.
In my 25+ year career, I’ve built everything from fully immersive 3d simulations and games to web apps to automated robots and a ton of things in between. I am a programmer, and so I don’t care what the job is or the tech stack that’s required, I’m capable of getting a new job, learning the new technologies, and then focus on building things to improve the financial health of that employer. THAT should always be your mission on the job, and you should always act exactly the same way working on your own projects between opportunities.
Anyone that is capable of doing every discipline on an engineering team is always going to be an amazing asset to any company, because that individual makes the team stronger instead of decreasing team efficiency and becoming a communications and productivity bottleneck. The Mythical Man-Month by Fred Brooks goes into great detail about the challenges that come from larger teams and how the simple act of adding more people has a negative causal relationship to team performance.
This advice of “do-it-all” doesn’t mean that you have to be an expert at everything. There are many aspects of software product development that you’re always going to find tedious, but when you’re intentionally working on things to advance your career via your dedication to your own projects, that’s where all the growth occurs.
The goal of every company is to maximize revenues while decreasing expenses, and the best software engineers understand the relationship between product development and business success. If that company needs to downsize the team, they’re not going to start with the folks that add value to the bottom line.
That is the true definition of a 10x engineer. It’s not someone who is just a good coder, it’s someone that knows what to build and why, because of a deep understanding of the needs of the business, the customers, and the capabilities of technology.
So what do you do if not Open Source contributions? What is the secret to efficient career progression?
The secret is building. Building from passion. Building from curiosity. Building for yourself. Building for others. Building for the sake of Building. Then repeat and Keep Building.
But the catch is — you have to finish what you build.
As an example, Open Source is a great idea for most engineers trying to grow, but you should be writing and creating Open Source projects that you want to see in the world or that you’re passionate about. Don’t try to submit bug fixes to the React project, instead rethink Javascript framework fundamentals and build something uniquely yours. Release it as Open Source, but then treat that project as one that’s important and special. Build it until it’s done, document the heck out of it, and try to get other people excited to use it. Learn how to build and manage a community around your Open Source project and get people excited to get to work with you.
Or try building a small micro-SaaS company with a small product that does a couple of things really well and can bring in some revenue from a few passionate customers. Building the tool is just the first step, but you also need to branch out and do Customer Discovery and learn how to write compelling marketing copy for your landing pages. Learn how to organically talk to others online about your product and how your product is a simple solution to a problem you know they have.
Be passionate about whatever it is you choose to do. If you’re not going to put in your best work, you might as well just go back to the couch and watch another season of that show you like on Netflix. The important thing is that you build something you care about at the highest possible quality and you put your heart and soul into it. When you’ve done that and reach a point where you can honestly tell yourself that you’re “done”, you keep that project running, slap it on your portfolio page, and go build something different.
And then Keep Building.
I think professionals always look at their career this way. Every second you spend working on a passion project and getting it into amazing shape is time well spent. You’re investing in yourself, and hiring managers can spot that from a mile away. I’ve routinely hired people from non-traditional backgrounds completely via the strength of their portfolio and the obvious joy they take in building, learning, and designing products. Every time I’ve hired folks that didn’t have a bunch of active projects and things they were proud of building ended up in regret and eventual termination.
Open Source is awesome. I’ve built my entire career using, building, and contributing to Open Source, but “just contribute” is not a great pathway to a prosperous career. I think there are three times when “contribute to Open Source” is the correct answer:
.
When you create and maintain the Open Source project yourself on a topic you are passionate about. Build that kind of things whenever you want, but make sure you deliver a polished public product (no skimping on documentation and marketing).
When you need to fix a bug in a project you use frequently and don’t want to wait for someone else to fix it.
or When you love a project so much that contributing to it brings you personal satisfaction. You can code on whatever makes you happy if you’re doing it for the right reasons.
Great article, overall. Your opinion is extremely valid and I’ve heard it often over the past 10 years, but I’ve always felt that “just contribute to something” was the wrong approach and figured it was time I wrote out my thoughts on why I think it’s ineffective.
Focus on learning everything. Be wildly and madly “full-stack” or go all in to stop using terms like “full stack”, “front-end”, and “back-end” and just be a well-rounded professional Software Engineer.
And Keep Building.
Thanks Eric for taking the time to write such a detailed response. I appreciate a number of the points you make.
Don’t “Just Contribute”
I didn’t do a good job in my original article providing more specific ways in which to select a project. I think any contribution to an open source project is going to be a positive (especially to recruiters) BUT I think some contributions will prove more valuable to the coder than others:
Work on a passion project to give yourself an extra boost of motivation and perseverance.
Contribute to the same project so that you can develop relationships and this is oftentimes easier to accomplish on smaller projects where there aren’t a surplus of developers.
Work on a project in your area of interest so you are gaining experience in the specific architecture, processes, data, etc. you are hoping to specialize in during your career.
So I agree with not just contributing.
Bigger Teams Don’t Equal Better Work
I also agree with you (and Fred Brooks) that larger teams don’t necessarily build better software. The idea that more people will result in a better product is hard to combat because it does work in so many industries.
Add more people in a factory assembling The Widget and the number of widgets produced will increase (assuming one has the necessary supplies, equipment, space, etc.).
Having five people assembling walls goes faster than one or two people (usually).
But adding more people to a software project only helps to a point, then it actually becomes detrimental to overall productivity. We want right-sized teams, not the biggest possible teams.
Passion Projects Are an Investment
I also agree that working on side projects / passion projects are a valuable investment in one’s long-term career. We are learning the techniques, the concepts, the problems we will face in the future. We are developing muscle memory around specific patterns of coding.
Paid to Create Value, Not Code
I know, I’m getting a bit repetitive, but I agree with this as well. Being able to code is good but it is when we create quantifiable value for an organization that heads turn and we are able to further the mission of the company.
Importance of Finishing What You Start
100%
On the Other Hand
There are a number of points I disagree with. Let’s start with a few of the smaller issues and finish out by addressing the open source contribution vs. own projects.
Thinking Like a Programmer
I agree that this is super important and often the difference between a mediocre and good/great developer. I disagree that this is learned well by oneself.
When coding by oneself rather than with others (and when a relatively new developer) one is more likely to create spaghetti code than to learn architectures, data models, proper deployment processes, robust project structure, algorithms, or etc.
This is much better learned in the context of a team. More senior developers push back one’s spaghetti code with suggestions, “hey, take a look at x design pattern” or “have you thought about using y here?” And in the codebase you see these better patterns exemplified, abstract algorithms in operation.
Does a Programmer Need to Know the Tech Stack?
I think this can work for individuals who have an established reputation with significant years of experience. I don’t think this works well for most developers.
I wish that it worked this way. I agree that it’s more important that a programmer is capable of learning the tech and building out value than knowing specific technologies – but that isn’t the way most businesses are hiring.
Businesses are generally looking for individuals who are experienced in a specific tech stack (or at least most of it) and especially when the hiring process is screened through recruiters or HR the likelihood that someone who doesn’t have the desired tech stack will ever speak with a technical individual is very low.
I’m really glad that you hire in this way, but it hasn’t been my experience that companies are by and large hiring in this manner. The emphasis is on experience in the desired stack and oftentimes the ability to complete arbitrary tasks that demonstrate intimate knowledge of a language/framework but aren’t necessarily encountered in day-to-day coding.
Is The Goal to Maximize Revenues While Decreasing Expenses?
This is more of a side note. I agree that the majority of companies believe that maximizing revenues and decreasing costs is the goal of every company.
I hope that this notion is being dismantled and replaced by healthier, more balanced priorities.
In my opinion better balancing several priorities does result in more profitable, long-lasting companies.
What is a 10x Engineer?
I think a 10x engineer is what you suggest but just as importantly I believe a 10x engineer is someone who has robust soft skills / is a team player – and much of this only comes through experience. Until you’ve run into a bull-headed software engineer who is demanding things be done a specific archaic way or an unreasonable manager setting impossible deadlines you won’t fully develop those skills.
Learning how to communicate clearly yet not offensively when a PR just isn’t good enough. Negotiating with the designer about what aesthetic choices are worth implementing and so on. One doesn’t develop these skills flying solo.
This is one of the reasons I advocate working on an open source project that has at least a few team members and some established practices.
Do I Need to Be Full Stack?
I like to think of myself as a full stack developer. I understand your preference for full stack developers – and I think there is a huge place for developers who are dedicated to one or the other but not both.
I’ve been working on some front-end code recently and as a full stack developer I’m capable of doing it but I can often save hours (days?) of work by spending some time with someone who is a dedicated front-end developer.
I don’t think one needs to be full stack these days. Sure, learn as widely as you can, but you aren’t less than a full stack developer. You may just fit better on specific types of teams – e.g., ones with others who also specialize in specific areas (so you don’t have to know the other half).
I’d suggest that the reason you and I are full stack developers may have more to do with when we entered the field than the doability of full stack development for your average coder. What was CSS back in the day? Who cared if you used tables to do all of your pixel by pixel adjustments? Besides someone submitting SQL statements through forms to your database, how much were malicious actors trying to compromise your system?
As things changed and matured we were able to learn these things because we were being exposed incrementally and over time. We could build crap that wouldn’t pass muster because no one had established a muster to pass.
Should I Try To Do It All?
At one point you reference building a micro-SaaS and that the building is only the first step – then there is customer discovery, marketing copy, etc. I think this is asking too much. Spend some money to hire someone to handle these areas and focus on what you are best at. There is so much to learn about marketing, sales, customer service, and so on that will take away from time to actually build.
Do what you have to, but wherever you can, outsource it. I’m not saying don’t learn about it. I love learning from folks who specialize in different areas – it’s good to understand how they work so I can understand how to build solutions that actually meet their needs, but trying to do all of it yourself isn’t worth it.
On My Own Or On A Team?
Maybe we could meet halfway. If an individual has enough time they could work on a project they are building from scratch and contribute to an existing open source project. But if they have to choose between one or the other, I say open source all the way…and part of that is because I believe you can build something yourself while contributing to open source.
Maybe it’s that you build out a new password-less option for an existing open source project. Or you add SMS notifications. Or you improve the federation across a distributed networking site. You can pick a feature and build it. You can take advantage of the help of a team while still being primarily responsible for the result.
I think this will usually result in more impressive results than building a project on one’s own. “So how many people use the feature you built?” “Well, the user base for this open source project is 50,000 and 50% of users are using the functionality, so I’d say 25,000.”
Now you’ve demonstrated you can write secure, stable, performant code in a public forum without needing to do everything from scratch.
I’ve Been a Lone Wolf a Lot
I’ve done a lot of lone wolf development and I covet working on a team. The ability to pair program, to get feedback on my code, to brainstorm solutions, to have someone who can help me setup convoluted tool x when I run into problems is invaluable.