I’m curious about what do you mean by “cheapest options”. Do you remember how much you were paying then?

IIRC, StackOverflow Careers kind of established the price per posting around $300. After they came up every other job posting site was charging around that.

For CareerCupid, I want to make a single flat rate of $89/month and let companies make as many job listings as they want. I think that the value for a company should not be in charging per posted job, but to give them access to the whole database in a way that can help them make hiring decisions directly.

I get why they resorted to buying all this AI fuckery to try to more aggressively filter resumes.

I get it as well, but I think that this “send us your resume” and we will judge you based on it is such an outdated concept we could get rid of it entirely.

Imagine if we got something like Wikidata applied to the “professional social network” graph of the whole world. If “let’s set out to build a map of all the ~2 billion people who are economically active” was somewhat impossible to think about 20 years ago, today it’s the kind of project that can be easily managed on modest infrastructure.

I completely agree.

(I want to try something different here. Instead of a fully fleshed out post, I’d like to just start with a draft of some ideas and I hope that it is enough to generate a conversation. I’ll take the relevant responses and use them to keep improving this article)

But if you were so eager to give feedback, perhaps you could’ve started with something more productive than yet-another smutty comment that serves only to make you feel better than the plebs who use and get any value out of ChatGPT?

And if your first instinct is to comment on a joke, in the first paragraph to pass judgement…?

I work with Python. Usage of formatting tools (black, ruff) are widely adopted. Part of its Zen is “there should be one way to do it”, most of its idioms are widely adopted and if you ask anyone about an example of a PEP, they will respond with “8”.

That is to say, “how python code should look” is somewhat of a solved problem. Any occasional differences that might show up in a codebase are likely to be minor that are simply not worth arguing for.

I think that the interviewer was mostly looking for an answer where I could talk about how I deal with conflict. But to be honest if that was the case I would be either more straightforward about the question, or I would try a different scenario with something that might happen more frequently.

Great! When can I start?

I had to shorten the title, but some of the information you say is missing is actually covered on the question.

Anyway, I just thought of adding this question today because I actually was asked a variant of this in an interview (no mention about code style docs), and the interviewer was not happy with my answer which was something like “Whatever style decision is important should be covered in the style guide. If you don’t have a style guide, then I’d assume that this is not really important for the team, and I rather focus my review on things that really matter. Is the code testable? Is it maintainable? Is the code being introduced completely different from what we have before or are we consistent with our inconsistencies? All in all, I’d rather spend time working on new features and shipping than arguing over style preferences.”

Imagine if OSes in the 90s crashed as rarely as desktop OSes today. Imagine if desktop OSes today crashed as rarely as mobile OSes today. Imagine if mobile OSes crashed rarely enough that the average consumer never experienced it. Wouldn’t that be a better state of things overall?

Depends. What is the cost to get there? Will that sacrifice openness? Will that sacrifice portability? Will that require ossified structures that will make development of new applications more difficult?

Look, the article is talking from the perspective of someone who is developing web apps in Ruby. Performance is not a huge concern. Processes being crash-proof are not a concern. You know what is the concern? To be able to validate ideas and have something that bring customers willing to pay real money to solve their real problems.

For his scenario, forcing to define everything up front is a hindrance, not a benefit. And having GP screaming at it like this for having this opinion is beyond ridiculous.

I don’t really want to be talking past each other. The point I am refuting is that even if type-safety can help reduce the amount of bugs shipped, this is not the only metric that matters to measure the value of the software being developed.

bugs are really annoying

And being late or never delivering out of fear of shipping buggy code is even worse.

Some years ago, I worked on a crypto project that was financed via an ICO. This meant that whatever money the company was going to get was already in their hands, and their only job was to make sure they could prove they’ve done a best effort to deliver what was promised to investors.

Because of these incentives, the engineers were more concerned about covering their asses regarding bugs than to actually get the software out in the hands of users. The implementation was in python, and to the team it was easier to justify spending time on getting 100% mypy coverage than to get things in hands of users to see the value of what we promised to deliver.

In the end, by the time the team managed to deliver, the code was super well-tested, there were 0 mypy warnings and absolutely zero interest from other people in adopting our tool because other competitors have launched a whole year before them.

How many billion dollar companies were built on dynamically typed languages? Do you think that companies/bosses/investors care about the compiler warnings or whether you can deliver/iterate faster than the competition?

nobody likes plumbing, but we all know it’s necessary.

Is it, really? Are we all working on mission critical software? We are living in a world where people are launching usable applications with nothing but the prompt to an LLM, ffs, and you are there trying to convince yourself that pleasing the Hindley-Milner gods is fundamental requirement in order to deliver anything?

Good engineering is about understanding design constraints and knowing where to choose in a myriad of trade-offs. It’s frankly weird to think that such an absolute, reductionist view like yours got so much support here.

But the social network can be open. My current idea is precisely to build this like communick (replacing Mastodon with Takahe) and make it on top of the activitypub-enabled services that can interop with other networks, except that to get accounts at the instances people need to pay the monthly subscription.

Oh, wow, talk about timing.

Last week, I wrote a post asking for feedback for an idea to fund musicians. While the feedback was mostly positive, I realized that what I was proposing wasn’t necessarily restricted to musicians, and could be used as a model for all types of creative work. So I decided to take this whole thing and make a prototype for a “paid social media network where people and companies can contribute to anyone working in a creative project”

I’ve been doing for months already and have not been banned/shadowbanned.

PS: please stop with the stalking. You have been downvoting every comment and post of mine for the past days, even when not involved in the conversation. If you continue with this, you will be reported and perhaps you will understand that is not the Lemmy-linking that getting you banned from reddit, but just your obnoxious behavior.

You being shadowbanned and a site-wide censorship of links to Lemmy are two distinct things.

That is absolutely not the case. I have posted many links to lemmy there. The only thing I still do on Reddit is discussion related to Lemmy and fediverser, there is nothing being blocked and I afaict am not being blocked.

Organizations that feel that they desperately need to take that risk, are doing it because they disrespect their team’s time.

Or they are aware they are not in a position to block deployments for 60 hours every week? I’ve felt more discouraged working at companies that blocked Friday deployments because “it could wait until Monday”, and then when Monday came half of the team was blocked or waiting for some new data report that could have been running during the weekend.

It can be the smallest risk in the world, but it’s still a risk.

And it’s up to the Engineering manager (or at least the Release Manager in places where that role still exists) to evaluate what would be the trade-off. If you say that a bug coming from a Thursday deployment could’ve waited until Monday, why can’t a bug that has come from a Friday deployment?

I guess my issue is not in saying “Some things should not be deployed on a Friday”, but with the generalization. Of course there are things that should be okay to deploy on a Friday, or a Thursday night, or when the manager is on vacation… Being strict about it seems anything but “respect for the team”, but a general distrust of the people and the process.

Every change that isn’t already an active disaster recovery can wait for Monday.

I honestly fail to see the difference between “don’t deploy on Friday if this can wait until Monday” and “don’t deploy on the evening if it can wait until the next morning”.

The idea of CD is that changes are small and cheap. No one is saying “it’s okay to push huge PRs with huge database migrations on a Friday”, what is being said is “if your team is used to ship frequently and incrementally, it won’t matter when you ship and your risk will always be small.”

Again: if the changes are small enough and you have automated checks in place, they should not require manual intervention.

Plus, what happens if a deploy on Thursday has a bug which only is manifested on a Saturday?

How is that not easily reversible?

possible new ways

Name two, please.

The author ended up creating a strawman. Allen’s argument was pretty clear: if your deltas are small and your deploy system is fully automated, then no one should be afraid of the risk of deploying.

Given that, if I deploy on a Monday morning and there is a bug on the new release, you revert, reproduce the issue in staging and push only new code when it is fixed. Same thing if I were deploying on a Thursday afternoon or a Friday at 7PM.