• 1 Post
  • 28 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle

  • 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! 🤞





  • I think it heavily depends on the size and (management) culture of your employer. My most recent gig had me sit in way too many meetings that were way too long (1hr daily anyone?), dealing with a lot of tooling issues and touching legacy code as little as possible while still adding new features to our main product on a daily basis. Obviously “we don’t need a clean solution. We’re going to replace that codebase anyways, next year™”.

    The job before that had me actually code for about 80% of the time, but writing tests is annoying and slows you down and we don’t have time for that. Odd how there was always time for fixing the regressions later.






  • … an average hobbyist programmer …

    and

    … create an MVP?

    are at odds in my opinion. Are you looking for a hobby project or are you trying to build a product that you can sell/persuade investors with?

    If you are interested in building such a thing because you care about the idea, go for it! Even if you abandon the whole thing after a few months of consistent work, I’m pretty confident that you will gain something in the process (insights, learnings, an idea for an actual product etc.).

    However if your goal is to build something that’s commercially viable, I would do some market analysis (see what’s out there, what you want to do differently) and maybe talk to people who have already launched products or started companies before, instead of basing my decision on the responses from strangers on social media.



  • The thing is, it works like this in certain countries. At least in Switzerland and Germany it is possible to make an apprenticeship as a programmer. This means there is a structured path for the vocational education that must meet certain regulatory criteria. Normally this takes 3-4 years to finish and includes both, working at a company as well as visiting vocational school. College is often done after finishing one’s apprenticeship to broaden the understanding of more complex or advanced topics like security, architecture, project management, advanced math etc.

    I don’t understand why this system is not more common in other places. Programming (not CS) is very much like a craft and to large degrees can be taught as/similar to one.