They’re really not. As much as I hate commercial licensing for any dev tools, if you want to talk about superior there’s nothing quite as good as Visual Studio (not code) on Windows.
It really depends on what kind of project you’re working on. For .NET projects that might be true, but for other languages such as anything involving C++ then Visual Studio lags way behind CLion, which is multiplatform to boot.
Your comment feels half-baked at best. You start to talk about “best editors” but you proceed to present your two best examples and neither has anything remotely related to editors.
CLion is undoubtedly the absolute best IDE for C++ projects, and it’s multiplatform on top of it. It’s not even a competition, specially if you’re using CMake. Using Git integration as your best and single example to refute this is extremely puzzling by how silly it is.
i interpreted the “trend” correctly, “devops” was bastardized away from its original meaning to now mean “sysadmin”, at least in most cases.
I don’t think I agree. The role of a sysadmin involved a lot of hand-holding and wrangling low-level details required to keep servers running. DevOps are something completely different. They handle specific infrastructure such as pipelines and deployment scripts, and are in the business of not getting in the way of developers.
And Gallup claims that 29% of Americans have been diagnosed with depression at one point:
That really doesn’t mean anything. The only requirement for succumbing to a depression is being alive, because all it takes is something bad happening in your life (loss lf friend, loved one, even pet, etc) to fall into a pit of despair.
Every job lately seems to have been infected by Meta/google “data driven” leadership. Its so painful and wasteful sometimes.
It’s cargo cult mentality. They look at FANGs and see them as success stories, and thus they try to be successful by mimicking visible aspects of FANG’s way of doing things, regardless of having the same context or even making sense.
I once interviewed for a big name non-FANG web-scale service provider whose recruiter bragged about their 7-round interview process. When I asked why on earth they need 7 rounds of interviews, the recruiter said they optimized the process down from the 12 rounds of interviews they did in the past, and they do it because that’s what FANGs do. Except FANGs do typically 4, with the last being an on-site.
But they did 7, because FANGs. Disregard “why”.
In the 2010s, the mindset at tech giants seemed to be that they had to hire the best developers and do everything they could to keep them.
Not really. The mindset was actually to hire skilled developers just to dry up the market, so that their competitors would not have skilled labour to develop their own competing products and services.
Then the economy started to take a turn for the worse, and these same companies noted that not only they could not afford blocking their competitors from hiring people but also neither did their competitors. Twice the reasons to shed headcount.
It was not a coincidence that we saw all FANGs shed people at around the same time.
A comment on the YouTube video makes a good point that we already have a better word for the concept of dealing with multiple things at once: multitasking.
I don’t think that’s a good comment at all. In fact, it ignores fundamental traits that separate both concepts. For example, the concept of multitasking is tied to single-threaded task switching whereas concurrency has a much broader meaning, which covers multi threaded and multiprocess execution of many tasks that may or may not yield or be assigned to different cores, processors, or even nodes.
Meaning, concurrency has a much broader meaning that goes well beyond “doing many things at once”. Such as parallelism and asynchronous programming.
Do we really need a video about this in 2024? Shouldn’t this be already a core part of our education as software engineers?
I’m not sure what point you tried to make.
Even if you believe some concept should be a core part of the education of every single software engineer who ever lived, I’m yet to meet a single engineer who had an encyclopedic knowledge of each and every single topic covered as a core part of their education. In fact, every single engineer I ever met only retained a small subset of their whole curriculum.
So exactly what is your expectation?
good: Add foo interface.
Another commit style is summarizing what a commit does. In this case it would be someting like:
Adds foo interface.
I think this style is more in line with auditing code.
Does anyone have any good sources or suggestions on how I could look to try and begin to improve documentation within my team?
Documentation in software projecte, more often than not, is a huge waste of time and resources.
If you expect your docs to go too much into detail, they will quickly become obsolete and dissociated from the actual project. You will need to waste a lot of work keeping them in sync with the project, with little to no benefit at all.
If you expect your docs to stick with high-level descriptions and overviews, they quickly lose relevance and become useless after you onboard to a project.
If you expect your docs to document usecases, you’re doing it wrong. That’s the job of automated test suites.
The hard truth is that the only people who think they benefit from documentation are junior devs just starting out their career. Their need for docs is a proxy for the challenges they face reading the source code and understanding how the technology is being used and how things work and are expected to work. Once they go through onboarding, documentation quickly vanishes from their concerns.
Nowadays software is self-documenting with combination of three tools: the software projects themselves, version control systems, and ticketing systems. A PR shows you what code changes were involved in implementing a feature/fixing a bug, the commit logs touching some component tells you how that component can and does change, and ticketing shows you the motivation and the context for some changes. Automated test suites track the conditions the software must meet and which the development team feels must be ensured in order for the software to work. The higher you are in the testing pyramid, the closer you are to document usecases.
If you care about improving your team’s ability to document their work, you focus on ticketing, commit etiquette, automated tests, and writing clean code.
That way we’ll just find maintainers went near extinct over time, just like COBOL developers that are as rare as they are expensive.
Care to take a shot at figuring out why COBOL is still used today?
I mean, feel free to waste your time arguing for rewrites in your flavor of the month. That’s how many failed projects start, too, so you can have your shot at proving them wrong.
But in the meantime you can try to think about the problem, because “rewrite it in Rust” is only reasonable for the types who are completely oblivious to the realities of professional software development.
You’d have had me ignore them all and keep using C for everything.
Please tell me which language other than C is widely adopted to develop firmware.
You’re talking about so many up-and-comers during all these decades. Name one language other than C that ever came close to become a standard in firmware and embedded development.
Right.
Yeah, because the new tools are never actually better, right?
Well, yes. How many fads have come and went? How many next best things already died off? How many times have we seen the next best thing being replaced by the next best thing?
And yet, most of the world still runs on the same five languages: C, Java, C++, C#, JavaScript.
How do you explain that, with so many new tools being so much better than everything?
Might it be because fanboys tend to inflate their own definition of “actually better”, while turning a blind eye to all the tradeoffs they need to pretend aren’t there?
If you had a grasp on the subject you’d understand that it takes more than mindlessly chanting “tools” to actually get tangible improvements, and even I’m that scenario often they come with critical tradeoff.
It takes more than peer pressure to make a case for a tool.
That seems like a poor attitude imo.
Why do you believe that forcing something onto everyone around you is justifiable? I mean, if what you’re pushing is half as good as what you’re claiming it to be, wouldn’t you be seeing people lining up to jump on the bandwagon?
It’s strange how people push tools not based on technical merits and technological traits, but on fads and peer pressure.
Clearly Rust is a conspiracy.
Anyone in software development who was not born yesterday is already well aware of the whole FOMO cycle:
They’re a member, because they find Rust useful. This is just them saying another time that they find Rust useful.
Fans of a programming language stating they like the programming language is hardly thought-provoking stuff. There are also apps written in brainfuck and that means nothing as well.
The whole idea to check the donations came from stumbling upon this post which discussed costs per user.
Things should be put into perspective. The cost per user is actually the fixed monthly cost of operating an instance divided by the average number of active users.
In the discussion you linked to, there’s a post on how Lemmy.ml costs $80/month + domain name to serve ~2.4k users. If we went through opex/users metric, needlessly expensive setups with low participation would be a justification to ask for more donations.
Regardless, this is a good reminder that anyone can self-host their own Lemmy instance. Some Lemmy self-host posts go as far as to claim a Lemmy instance can be run on a $5/month virtual private server from the likes of scaleway.
Is there something else I’m not seeing?
Possibly payment processing fees. Some banks/payment institutions charge you for a payment.
OP is right. For web development with JavaScript frameworks (React, Angular, etc) with Node and even Typescript, you either use vscode or you haven’t discovered vscode yet.