pinchcramp

I clearly didn’t read it.

I love the honesty. It’s really refreshing to see someone take accountability instead of becoming defensive.

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 would have written that comment if you hadn’t already done it.

I don’t know exactly why people think that we can “just” do whatever they ask for.

Maybe it has something to do with how invisible software is to the tech-illiterate person but I’m not convinced. I’m sure there are other professions that get similar treatment.

I do have Ctrl under ä (which would be the semicolon key on US layout, I think). Interestingly, on Mac (with Karabiner) it caused regular mistypes when typing fast, even after a year. On my 12 year old Thinkpad (Linux with keyd) however, I’ve never found the overloading to be an issue.

I’ll probably give the layout in the article a shot. It sounds interesting.

Maybe Elm? It was the result of Evan Czaplicki’s thesis.

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.

Different strokes for folks I guess 🤷‍♂️

That programming as a career means you’re going to spend writing nice, clean code 80% of the time.

It’s rather debugging code or tooling problems 50% of the time, talking to other people (whether necessary or not) about 35% of the time and the rest may be spent on actually spending time doing the thing you actually enjoy.

I may be exaggerating, but only a little.

For the jargon part: See this Github repo. It ain’t exhaustive, but it’s a start.

Other than that, all I have to add is that functional programming does not necessarily imply static typing. There is a whole world of Scheme-variants that are dynamically typed.

Am I understanding this correctly that dynamic programming == breaking a problem into smaller (reoccurring) sub-problems and using caching to improve performance?

… 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.

Your algorithm can be implemented with tail-call recursion AND your language supports the same.

Just to nitpick but the compiler/interpreter needs to support tail-call recursion, not just the language. For example, tail-call recursion is part of the language spec for JavaScript (ECMAScript 6), but only certain engines actually support it (https://compat-table.github.io/compat-table/es6/ Ctrl+F tail call).