fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

10K
active users

#SoftwareEngineering

62 posts57 participants7 posts today

Nachdem ich gerade in der Bäckerei den ständigen Kampf gegen das Kassensystem beobachten konnte der Aufruf and alle #uidesign und #softwareengineering Kollegen: Nehmt euch Zeit mit euren Benutzern! Bevor ich in die interne Entwicklung gewechs bin hat sich mein Team mindestens einmal im Jahr ins Lager gestellt und die Kollegen im Lager begleitet. Man lernt so viel darüber wie das system benutzt wird, validiert die eigenen Annahmen und kriegt viele kleine Probleme mit.

🚀 Wow, groundbreaking revelation: #AI still requires human intervention! 🤯 Who knew that a social platform isn't built by waving a magic wand and expecting code to write itself? 🧙‍♂️💻 Verdi's wife learns that software engineering might just require some, you know, engineering. 🙄
verdikapuku.com/posts/the-deat #HumanCollaboration #SoftwareEngineering #TechRevelation #SocialPlatform #HackerNews #ngated

verdikapuku.comThe Death of the Software Engineer by a Thousand PromptsThis is Verdi's personal website. He writes about interesting ideas or projects.
Replied in thread

@veer66

Claims like "X language is for beginners" or "Y language isn't suitable for real problems" are just dressed-up versions of "X language sucks". They are pseudo-religious arguments, not technical ones. They are not useful in choosing technology to use.

A "real programmer" chooses languages, libraries, and other technical things based on utility, not holy wars (like "vi vs. Emacs", or "tabs vs. spaces").

e.g. For different problems and situations, you might choose a language because it is technically suited to a particular problem class. Or you might choose it because the group to work on the problem has deep experience with it, even though another language is slightly better suited to the problem. Or you might pick one based on a dozen other factors - and usually you will actually use more than one in making the choice.

Hollow assessments like "Python is for beginners" aren't useful. The people who make such statements are generally not particularly well-versed in the thing they are criticizing, and possibly not with programming/engineering in general.

If you want real assessments of the strengths and weaknesses of a language or other part of a tech stack, they're out there - but they will be articles and essays, not sentences.

Unlock Your Engineering Confidence - Interview With Maria Glazunova

I've said it a million times and I'll say it a million more: Communication is a critical skill for software engineers. And if you don't want to listen to me, listen to Maria Glazunova who I had the pleasure of interviewing in this video!

Maria coaches many software engineers and tech professionals on how to improve their communication skills. Many of these people have English as their second (or third) language -- but the fundamentals of what we discuss regarding communication apply to EVERYONE.

Thanks for the awesome chat, Maria!

Watch it here:
podcasters.spotify.com/pod/sho

Which programming language should you choose?
It doesn't matter. Pick any. As long as you’re gluing libraries, worshipping frameworks, and elegantly concealing incompetence behind layers of "magic", you’re doing just fine.
After all, it's all just ancient text rituals running on toasters if you want to.

#Programming #CodeLife #TechHumor #DeveloperLife #FrameworkHell
#CodeMagic #SoftwareEngineering #ToasterDrivenDevelopment #DevSatire
#ChooseYourWeapon #CodingTruths #AncientCodeRituals #GluingCodeTogether #coding

One of my favorite memories from working in AAA video games:

I was at work late one night, like 11PM, during crunch. The lights were out at the office. I was sitting in my cubicle, with my headphones on, watching a Monty Python's Quest for the Holy Grail DVD on the TV hooked up to my Xbox devkit.

Suddenly, I hear a voice behind me. I turn to find my boss's boss's boss, a key producer on the project, behind me.

1/3

Hilariously low sample size, but I’m glad I’m not the only one with this problem. I’m more strict in code reviews than the vast majority of people I’ve worked with, but I still regularly find myself working with other people’s code and saying “this is terrible, who approved this? Oh wait I did.”

It’s really hard to fully understand code and its tradeoffs by looking at it statically. A really thorough sense of how it hangs together really seems to depend on working with it, making changes and considering alternatives.

This is why I don’t believe people who say that LLM-generated code is fine as long as you review it thoroughly. In my experience code review misses major problems *all the time*.

#programming #coding #SoftwareEngineering #LLMs #copilot #GenAI
social.treehouse.systems/@jnkr

Treehouse Mastodonjnkrtech (@jnkrtech@treehouse.systems)How often do you miss issues in PR-based code review? Not only bugs; I’m including cases where you approve someone else’s code, but find design or maintainability problems when you later work with the code yourself. This probably varies from team to team or job to job; please answer based on cases of working with junior and mid-level engineers if it varies. (1/2) #programming #software #SoftwareEngineering #SoftwareDevelopment #coding [ ] Most of the time [ ] Frequently [ ] About half the time [ ] Rarely [ ] Almost never [ ] I don’t do PRs/code reviews [ ] See results