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.
Yeah, the quality on Lemmy is nowhere (…)
Go ahead and contribute things that you find interesting instead of wasting your time whining about what others might like.
So far, all you’re contributing is whiny shitposting. You can find plenty of that in Reddit too.
It’s from 2015, so its probably what you are doing anyway
No, you are probably not using this at all. The problem with JSON is that this details are all handled in an implementation-defined way, and most implementation just fail/round silently.
Just give it a try and send down the wire a JSON with, say, a huge integer, and see if that triggers a parsing error. For starters, in .NET both Newtonsoft and System.Text.Json set a limit of 64 bits.
https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonserializeroptions.maxdepth
Why restrict to 54-bit signed integers?
Because number is a double, and IEEE754 specifies the mantissa of double-precision numbers as 53bits+sign.
Meaning, it’s the highest integer precision that a double-precision object can express.
I suppose that makes sense for maximum compatibility, but feels gross if we’re already identifying value types.
It’s not about compatibility. It’s because JSON only has a number type which covers both floating point and integers, and number is implemented as a double-precision value. If you have to express integers with a double-precision type, when you go beyond 53bits you will start to experience loss of precision, which goes completely against the notion of an integer.
Ok.
It’s very hard for “Safe C++” to exist when integer overflow is UB.
You could simply state you did not read the article and decided to comment out of ignorance.
If you spent one minute skimming through the article, you would have stumbled upon the section on undefined behavior. Instead, you opted to post ignorant drivel.
I think I could have states my opinion better. I think LLMs total value remains to be seen. They allow totally incompetent developers to occasionally pass as below average developers.
This is a baseless assertion from your end, and a purely personal one.
My anecdotal evidence is that the best software engineers I know use these tools extensively to get rid of churn and drudge work, and they apply it anywhere and everywhere they can.
the first thing I saw is 150 lines of C# reimplementing functions available in the .NET standard lib.
Once again: https://en.wikipedia.org/wiki/Dunning–Kruger_effect
They existed before LLMs were spitting code like today, and this will undoubtedly lower the bar for bad developers to enter.
If LLMs allow bad programmers to deliver work with good enough quality to pass themselves off as good programmers, this means LLMs are fantastic value for money.
Also worth noting: programmers do learn by analysing the output of LLMs, just as the programmers of old learned by reading someone else’s code.
Claude is laughable hypersensitive and self-censoring to certain words independently of contexts (…)
That’s not a problem, nor Claude’s main problem.
Claude’s main problem is that it is frequently down, unreliable, and extremely buggy. Overall I think it might be better than ChatGPT and Copilot, but it’s simply so unstable it becomes unusable.
I agree. Those who make bold claims like “AI is making programmers worse” neither has any first-hand experience with AI tools nor has any contact with how programmers are using them in their day-to-day business.
Let’s think about this for a second: one feature of GitHub Copilot is the /explain command, which is used to put together a synthetic description of what a codebase does. Please someone tell me how a programmer gets worse at their job by having a tool that helps him understand any codebase anywhere.
I feel like this will have zero protection against
Zero protections against what? Against the programmer telling the program to do something it shouldn’t? Not programming language does that. If you resort to this sort of convoluted reasoning, the same hypothetical programmer can also swallow all exceptions.
The main problem you’re creating for yourself is that you’ve been given an open-ended problem but instead prefer to not look for solutions.
Have you ever worked at large old corporation?
I’m not sure you understand that it’s way more than “large old corporations” that use it. Everyone uses it, from large multinationals to small one-taxi shops, and even guys like you and me in personal projects. This has been going on for years. I really don’t know what led you to talk about large old corporations, seriously.
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.