Programming

Some tips:

• Unless the code is very small, or your feature is very big, try to put blinders on, and focus only on the code you absolutely need to to get your feature built. Use search tools to comb through the code to find the relevant methods while reading as little surrounding code as possible, tweak those methods to be different, and call that a first draft. If the maintainer wants the code refactored or differently arranged, they can help with that as part of the review process
• Being unable to build sucks, it really does. But if the software is released for your platform, it means someone out there is able to build it. And these days that someone is often an automated build tool that runs per release. See if you can figure out how this tool works. What build steps it uses, what environment it runs in, etc. If you can't figure that out, try contacting the person who releases the builds
• If the software is in apt (if you're on a Debian-based system), you can use apt build-dep, apt source, and debuild to try and recreate the native apt build process. These tools will give you the source that built the system package, and its dependencies, and allow you to build a deb yourself out of it. Test the build to make sure it's working as-is. If it is, and if the software's dependencies haven't changed too much, you can even use apt to fetch the old version that's in the repos, update the code to reflect the upstream release, and then test the build there to see if it still builds. If so, now you have something you can start working off.
• If you aren't on an apt system, but do have a package manager, I assume there's an equivalent to the workflow mentioned above
• If your change is subtle enough that you think it's pretty low-risk, you could just edit the code even though you can't build it. This might be sufficient for bug-fixes where you just need to check something is greater than zero, or features where you pass a true instead of a false in certain conditions or something. You should probably mention this in your PR / MR / Patch so the reviewer knows to test building it before merging.
• This one is a bit wild, but let's say you're on a Mac or Windows machine, and the build instructions only work for Linux. You can just run a virtual machine that's got Ubuntu or something running on it, and use it as your build environment. These days you can probably be in a simpler situation with Docker or something more lightweight, but as a worst-case scenario, a full virtual machine is there for you if you need it
• And finally, if the tool isn't a crazy popular or busy tool, it's possible the maintainer or other people in the community are more approachable than you think. If they are looking for contributions, then getting a willing contributor's build environment setup is a benefit to the project. Improving their build docs helps not just you, but potential future contributors as well. A project will usually be more helpful towards someone who says "I'm trying to build this feature, but I'm running into trouble" compared to someone saying "why doesn't your tool do X". You may need to be a bit patient, they're probably doing this on volunteer hours, but they might be happy to help you get your stuff sorted out

Good luck out there, and try not to be discouraged!

You’ve said everything actually.

1. Fork
2. Build (and if you can’t, stop because it will be too painful)
3. Learn the code, debug, and write at the same time
4. Write a merge request

That’s it. If you’re not a professional it will be longer but the steps are the same.

The only advice would be to learn your tools, learn the IDE, learn to debug. And if there is no documentation, write it.

Depends on the project (and the maintainers), but have you reached out to the developers for assistance?

Touching a foreign codebase is always difficult, even for professional coders. I have found that it usually is a very hard slog for a few weeks or so, and then it will start to click in place. I think the only real shortcut is to ask for help and see if an existing dev can guide you through it.

Most of what comes to mind has already been said by others, but I want to add one thing...

the overall code seems so convoluted to me that I don’t even know where to start to analyze a solution, even though if it’d probably take ten lines to implement.

One of the most important things to understand about software development is that (outside of small hobby projects) the vast majority of the work is not writing code. Most of the hours will be spent on a combination of other tasks, including:

• Understanding the desired behavior
• Understanding what has been tried before
• Understanding what has and hasn't worked well in past attempts
• Considering unexpected ways in which the software might legitimately be used
• Imagining needs that might emerge in the future
• Imagining problems/circumstances that might emerge in the future
• Devising a solution that you think will work well
• Predicting limitations of your design
• Communicating the reasons and goals behind your design choices
• Listening to feedback from others, and understanding it
• Collaborating with others to find common ground
• Conducting research to prove your assumptions or answer open questions
• Learning the ins and outs of surrounding code that is only tangentially related to yours
• Learning unfamiliar tools
• Learning unfamiliar languages
• Learning unfamiliar algorithms and data structures
• Revising your design
• Coming up with succinct and clear names for things
• Testing your implementation (making sure it works now)
• Devising and writing automated tests for your implementation (making sure it will keep working when someone else changes something)
• Composing comments to explain why non-obvious things are done a certain way
• Reformatting your code to fit the style of the project
• Writing documentation, and rewriting it
• Answering questions
• Waiting for others to get back to you

The time and effort required for all of this multiplies when modifying an existing codebase, and multiplies again when most of that code was written by other people. Shepherding a contribution from idea to final merge often requires not only technical skill, but also study, diplomacy, empathy, and immense patience.

But I have no reference for how long a feature should take to implement in someone else’s code for the average Joe who does this for a living.

It varies quite a lot. I have had dozen-line changes take months, and thousand-line changes take a day or two. Just know that if it's taking much longer than you expected, that is completely normal. :)

Looking back on my career, submitting your first merge/pull request can take anywhere from a few hours to several weeks (we're talking about 8+ hour work days). And that's at companies that have an onboarding process and coworkers you can ask for help and explanations about the code base, architecture etc.

Getting into someone else's code (this may include your past self) is almost never easy and often feels convoluted, because it's very difficult to see the context that existed at the time when the code was written. And by context I mean everything that influenced the decision to write lines the way they were written, including undocumented discussions, necessary but non-obvious workarounds, understanding of the problem and solution space by the dev, general state of mind of the person writing the code and more.

Don't beat yourself up because you couldn't contribute in just a few hours.

I would first reach out to the devs on IRC/Discord/Matrix and express interest to contribute and see how they react. You don't know if they would even accept your PR, so I wouldn't do too much work upfront.

Then, when they are open to work with you, find out if they are willing to help you ease into the code. What files should you study to implement the changes that you've discussed earlier, any considerations that are not obvious, is there legacy code that you shouldn't touch etc.

It's important to keep in mind that (collaborative) software development is more than just being able to write code. And a lot of the surrounding work is not very glamorous or fun.

I hope that helps and wish you good luck! 🤞

Honestly, I run and gun. I make the change I want, and submit a merge request. I then move on. It's then up to the maintainer to accept or reject it.

I'm not going to debate it. I'm not going to rework it over the course of months to make it perfect in the maintainer's eyes. I don't care enough about it. I've solved my problem. I'm just sharing it for others.

The things I submit are normally big fixes with the smallest possible code change, not refactorings to solve an underlying problem.

Can't code. Donate to Asahi Linux on Patreon.

I'm doing my part!

Fork it, improve it, get in they discord, cause general disarray, leave

Donations

Follow up question -- I'm not OP but I'm another not-really-new developer (5 years professional xp) that has 0 experience working with others:

I have trouble understanding where to go on the spectrum of "light touch" and "doing a really good job". (Tldr) How should a contributor gauge whether to make big changes to "do it right" or to do it a little hacky just to get the job done?

For example, I wanted to make a dark mode for a site i use, so i pulled the sites's repo down and got into it.

The CSS was a mess. I've done dark modes for a bunch of my own projects, and I basically just assign variables (--foreground-color, --background-color), and then swap their assignments by the presence or absence of a ".dark-mode" class in the body tag.

But the site had like 30 shades of every color, like, imperceptibly different shades of red or green. My guess was the person used a color picker and just eyeballed it.

If the site was mine, I would normalize them all but there was such a range -- some being more than 10-15% different from each other -- so i tried to strike a balance in my normalization. I felt unsure whether this was done by someone who just doesn't give a crap about color/CSS or if it was carefully considered color selection.

My PR wasn't accepted (though the devs had said in discord that i could/should submit a PR for it). I don't mind that it wasn't accepted, but i just don't know why. I don't want to accidentally step on toes or to violate dev culture norms.

To make it more accessible

1. create your own (small) projects
2. make small contributions where it's possible (skip compiling, or -> 3.)
3. try to work on a project, and quit early if it's not simple
4. pick technologies that are simple to set up or you are familiar with

Testing is also very useful. If you even just happen to find some bug, that you can reproduce, it's pretty useful.

I personally have quite a few open source projects (mostly gamedev related, some are multi-purpose enough for other things), all of which need a lot of testing, also I would use someone to develop Mac (and maybe FreeBSD) parts of my middleware.

When a library I'm using at work doesn't have a feature I want or has a subpar implementation for my use case, I often try to send my changes upstream. Sometimes they get accepted, sometimes they're too specific of a usecase.