• 0 Posts
  • 36 Comments
Joined 1 year ago
cake
Cake day: August 2nd, 2023

help-circle









  • We solve that problem using naming conventions. Branch names must start with the issue key (we use Jira). You don’t do anything in that branch that’s not part of that issue. If you do, you must prefix the commit message with the issue key that it goes with. The commit itself identifies what changed. The Jira issue provides all the backstory and links to any supporting materials (design docs, support tickets, etc). I have to do a lot of git archeology in my role, and this scheme regularly allows me to figure out why a code change was made years ago without ever talking to anyone.



  • As someone in the US, 40 hours per week is the minimum. Recognition for “being a hard worker” has required 60+ hours at some places I’ve worked. This is for a fixed salary and no overtime pay, mind you. Then you’re usually on an on call rotation every few weeks where you may have to work off-hours if something comes up. That’s additional unpaid hours. My current company pays $80,000 USD for new college grad software developers.

    US holidays are 8-10 days, and junior devs usually start with 5-10 days of vacation. Health insurance costs at least several hundred a month (your employer also pays about 3x more than you towards your insurance premium as a benefit).



  • I’ll often cludge something together just to make it work but I don’t feel like I made any progress

    That’s a good first step! I’ve been programming for ~25 years and that’s still usually where I start. Get a little code that compiles and produces some kind of output or tracing. Then compare the output to your requirements and tweak the code to get it closer to the right behavior. Run it and repeat till it’s doing what you want. Do this cycle with small changes, like a handful of lines or a short function, not 20 mins of coding at a time.

    Test-driven development can also help with breaking down tasks. It takes a good amount of practice to learn the right patterns, but it’s an approach that forces you to work with small narrowly scoped tasks. Then you chain those testable tasks together to create more complex behaviors to create robust testable code.

    Experience takes time. Junior developers frequently ask me after I’ve helped them “but how did you just know how to do that? I’ve been trying to solve that for an hour and you did it in 10 seconds!!” The answer is because I’ve solved that exact problem before. More than a few times.





  • My cousin got a job working on FOSS for 5 years out of college. His secret? Work 40+ hours a week literally for free, crash on people’s couches, and get his girlfriend to feed him. He eventually got a real job because that’s obviously totally unsustainable.

    Unless you have a sugar daddy/momma or a trust fund, you need an actual job. Some companies make good use of FOSS and give back to the community. But I’d suggest settling for any job to get an income and experience while you figure out what companies you actually want to work for.