beryilma

There are also other ways of ruining engineering organizations that I observed, especially if they are growing: increased bureaucracy and documents for everything; design by committee of engineering/software products; mid-level manager cliques; inability to make individual managerial decisions such as hiring, product decisions, etc.; extreme deference to management chain.

As much as I like Dijkstra and this particular article of his (it is an assigned reading in my "Software Engineering" class), developing any large scale software that we have today starting from formal methods is just a fantasy.

I understand the importance of learning formal methods (discrete math, logic, algorithms, etc.), but they are not nearly enough to help someone get started with a software project and succeed at it.

So, if not "software engineering", then what should we teach to a student who is going to be thrown into the software world as it exists in its current form?

> The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), published by the IEEE Computer Society (IEEE CS), represents the current state of generally accepted, consensus-based knowledge emanating from the interplay between software engineering theory and practice. Its objectives include the provision of guidance for learners, researchers, and practitioners to identify and share a common understanding of “generally accepted knowledge” in software engineering, defining the boundary between software engineering and related disciplines, and providing a foundation for certifications and educational curricula.

I had a similar meeting with documentation folks about "dataset" vs. "data set". With Google trend charts and all... I also wish I was kidding.

The fact that the term "evidence-based" science exists in medicine research is an indication of a big problem to start with.

I understand the premise of the idea and that more scientists in the field are trying to make their research more rigorous. But, this also indicates that the research that has been done until recently was NOT "evidence-based", hence not very credible and reproducible.

> Given that anyone that codes is at least probably lightly on the Autism spectrum

What?!

> It’s not insulting... but a lot of software development honestly just needs painters.

The entire Picasso vs house painter analogy is insulting.

> Picasso goes to a cabin in the woods for two weeks to architect something that handles every edge case and is absolutely elegant...

If this is a product owner's idea of how software development occurs, they must be either clueless, narcissistic, cruel, or all of the above.

> As soon as it works, no one calls it AI anymore.

So, what are good examples of some things that we used to call AI, which we don't call AI anymore because they work? All the examples that come to my mind (recommendation engines, etc.) do not have any real societal benefits.

Notion and Obsidian will be dead in couple years.

I see academics going crazy with Obsidian to organize and link their precious little ideas and research articles together. But, only to create an overwhelming mess that they will be afraid to look back to in couple years.

Anybody, remember MindMap? Same idea as Obsidian and it is all but dead at this point.

I have been doing this for more than 20 years and it has been working well for me. I have a Works folder and 26 subfolders under it, each subfolder therein starting with the same letter...

On a slight tangent, the type of transactions you can make through your banking app in a developing country like Turkey is insane compared to US.

Without exaggeration, you can make instant money transfers across banks; buy stocks, gold, insurance, bonds, foreign currency; pay taxes and other government fees; make international SWIFT transfers; open retirement accounts; buy private healthcare; instantly open as many checking, savings, CD accounts as you want; and many more.

And in the US, they try to sell Zelle as the biggest innovation in banking. It's just pathetic.

Why is it that the developers would go into useless directions and solve non-problems? Perhaps they were not given good directions and a well-defined problem in the first place?

It is this attitude toward developers that made stupid shit like Scrum possible. Processes will not solve communication problems if there is no mutual trust to start with.

Being an actual process and being slow and bad are not opposites of each other. Literally, every recent software engineering book has a section on the "Waterfall Process". Nobody claims waterfall is good, but it is a software development process.

> Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto?

Increasingly, I am also blaming the Agile Manifesto for causing the mess we are all in.

Given current business tendencies, the authors should have probably foreseen the future consequences of their wishy-washy manifesto declarations. I think "true Agile has never been implemented" should not absolve them from assuming some responsibility.

By all "software engineering" books' definition, Waterfall is a software/development process. Good or bad...

Extreme Programming used to be a thing. Pair programming and all that... Not so much anymore.

> ... if we don’t feel stupid it means we’re not really trying.

> Science involves confronting our 'absolute stupidity'.

I understand where the author is coming from, but these are just useless statements. Stupidity and knowing that you don't know stuff are not the same thing. The former involves an inability to understand or learn, whereas the latter involves an acknowledgment of our current state of ignorance and that we can do better.

I don't believe one can be successful in science by constantly feeling stupid and getting used to it. You have to be comfortable with not knowing stuff, but with the drive and self-confidence that you can discover new things and expand your knowledge, which is of course not easy either.

Next we will get subscription toothbrush features. Personally, I want my ultrasonic toothbrush to hum to the tune of Taylor Swift songs.

More seriously, at this point, any idiot who downloads such invasive apps deserves its consequences.

> Why is it that so many of the PhDs and MDs out there are unable to tell when someone's lying to them about their very own areas of expertise?

I'd wager that they can actually tell. They just choose to accept it, or, at least, not to do anything about it.

I see it in my own field (software engineering). Sometimes pushing against lies and stupidity is just too hard and tiring.

If Keith Jarrett can produce such a sublime music as his Köln Concert on a broken piano, perhaps the level of perfection mentioned in the article is just professional pedantry. After all, isn't an artist a better artist when they can use their medium to maximum effect no matter its imperfections.

https://en.wikipedia.org/wiki/The_K%C3%B6ln_Concert

In the past, I have used a Raspberry Pi 400 as my main home computer for more than two years without any problems.

I am currently using a Raspberry Pi Zero W as a wireless security camera. It has been running continuously for over a year without a single crash.

KiCad is the good stuff. Having your design rendered in the 3D Viewer is a fun experience.

If you want to learn about the mechanics of designing PCBs, install KiCad (https://www.kicad.org/) and go through these tutorials: https://docs.kicad.org/

> The hiring managers always claim to look for innovators,

I thought that they were looking for "rock stars". Not the same thing...

3. No meeting agenda, no meeting. It is OK to have weekly recurring meetings. But if you don't have an agenda emailed a day or so before the meeting, cancel the meeting.

4. Unless you have a somewhat detailed requirements document based on actual customer input, you will build the wrong thing. All stakeholders should be in agreement with what's on that document.

6. For the love of god, no Scrum or daily standup, unless you want your team hate you. Weekly iteration meetings for progress updates might work better. Your 1-on-1's is a better way to track team progress.

There is absolutely zero chance that either of them will go to prison on this matter. Billionaires don't go to prison for stuff like this. If anything, it will be settled for a sum of money.

This is the modern day equivalent of "every signal is an image" after the initial success of deep learning algorithms in image classification tasks. It is just the academia chasing the hype train...

Obligatory link from a sceptic: https://arxiv.org/pdf/2009.13807

> However, they wanted to develop a technique that avoids fine-tuning, a process in which engineers retrain a general-purpose LLM on a small amount of task-specific data to make it an expert at one task.

This method does not avoid fine tuning. It just offloads the task to somebody else (i.e., to the LLM).

I'll buy the promise of the approach when the authors can show that they can vastly outperform an AR time series model or the simple techniques mentioned in the linked article.

I think about naming of things all the time: how they make some things easier and other things absolutely awful. My two recent hang-ups: Agile with capital A. If we applied the principles of Agile without naming the process would software engineering be at a better place? I think there is a case to be made for not naming such things but just describe the principles of the process for a better, un-enshittified outcome.

The other is ROC (receiver operating characteristic) used in statistics and machine learning. The current usage is very divorced from its original meaning (related to radars as I understand) and it sounds very stupid when used in its current context. It is just a simple ratio of a few statistical measures. I think using such names actually makes things even less understandable.

On the other hand, definitions (ie, naming things) is very useful in math and other disciplines.

> Mostly hiring devs fresh from university so there was a ton of group think due to a lack of new ideas

This is a very interesting description of group think between less experienced developers. I've never thought of it this way, but it seems to have some truth in it.