The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.
Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.
Go sacrifices too much for superficial simplicity; but I would like to see a language that’s nearly as easy to learn, but has a better type system and fewer footguns.
Unit testing is often overrated. It is not good for discovering or protecting against most bugs.
Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.
Not everyone can or even should learn programming.
SQL is the core language that everyone should be required to learn first and foremost.
Modern PHP is great and people judging it by PHP 5 (version that’s almost 20 years old) are idiots.
Most frameworks are garbage and most programmers that use them have no idea how they work and that makes them shitty programmers. I hate when people use frameworks without even knowing why they’re using them.
deleted by creator
deleted by creator
This isn’t limited to JS. Too many times have I seen someone ask a question of how to do XYZ in language ABC where most of the replies were some form of “Just use this library bro” while not actually answering the question. And usually the library that’s being suggested is some big monolith that implements a ton of shit that no one really uses.
deleted by creator
Yes…and, worse yet, the jQuery responses are almost never a good way to do things or they use things that are deprecated. It’s a hot mess out there.
For their credit basic javascript is a garbage language.
deleted by creator
Oh I agree that questions are two often badly answered! The exemple of “why don’t you use this instead” is the worst offender. I didn’t understand you were talking about this, and I’m still traumatised by javascript after 14 years.
Hey us programmers only listen to our engineers or architects. Blame them.
PHP aint all that bad
If you can’t find where you missed a closed parentheses, just add a bunch of them to the end of your project like this…
)))))))))… until your editor’s syntax helper tells you it’s good. I am very good at coding.
deleted by creator
My mantra has always been to bring solutions not problems. Applying that to code reviews makes for a far more productive experience.
Rather than just pointing out errors in code help the developer with prompts towards the solution.
Or, if you’re too lazy to explain why something shouldn’t be done then why should another developer have to act on your criticism?
Spaces look the same on every screen.
Doing this is a hot take, but “clean architecture” is a joke.
My company is obsessed with it.
Mandatory pull requests + approvals within a team are a waste of everyone’s time.
You must trust your team’s abilities more than I trust my own. How often does your team merge bugs into main? We use CI primarily for running the full test suite, including integration tests and e2e tests that would be very difficult to run locally due to them using specific credentials to access testing resources.
If your team consists of people you don’t trust, that’s the problem to fix first.
I trust my team. I don’t trust my or their ability to write and merge perfect code each time. I’m not sure how we’d fix that problem aside from becoming programming gods.
My point is, having PRs desn’t result in perfect code either. They might help sometimes, maybe 10% of the time if I’m being generous, but the rest of the time they are a hindrance. The problems people tend to try and solve with them, validation and indoctrination are better solved with a good CD pipeline, and pairing sessions.
Unless you have people that are known to delivery garbage code. Which is more common than you would imagine, lol.
depends on the company/team culture. are other people gonna have to fix or extend code you wrote? are you the sole engineer working on entire modules? do you hate feedback?
We’v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams
what data? just curios because there are so many ways to do PRs properly… like for everything, if it’s done badly better not do it. does not mean it is inherently bad
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
Omfg yes! Have nothing to add, but an upvote was not enough to express my hate for gitflow. So fucking stupid. And you’ll show stats from Jez Humble etc about trunk based, and my boss was still “eh not convinced”
Gitflow is far more complex and unnessaray for most places. You do not need a dev, main, and release branches. Github flow is far closer to trunk based dev - create a branch of master, PR back into master when done. If you keep your PRs small it gives you most of the benefits of trunk based dev with a CI check before you merge to the mainline.
Git Flow and GitHub Flow are entirely different branching strategies.
Gitflow is has the same issues
Git Flow is awful I absolutely agree. On the other hand I like GitHub Flow.
Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters.
Source?
Got asked about this twice so I’m cut/pasting my answer, but happy to discuss further
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
Depends how good you are at what you’re doing. I’d argue that humans err and it saves a bunch of time to catch bugs before debugging in the wild
deleted by creator
sounds like your company sucks. I’m sorry, must be lonely
Big hot take to me; especially in an organization with a large size and code high standard
I actually like C.
Here’s another: most code reviews on larger companies are BS, just for show and nitpicking.
Dynamically typed languages don’t scale. Large project bases become hard to maintain, read and refactor.
Basic type errors which should be found in compilation become runtime errors or unexpected behavior.
