Hear, hear.
And of all the projects that users (well, okay, me, but I'm guessing I'm not alone) really really want the devs to have some objective data regarding the user experience, so they can make their amazing engine even easier to use, I think #freeCAD is probably top of the list.
Eeeeyyy, we can look at git tags in #VisualStudio now. (I didn't realise we couldn't before!)
Looks like VS is slowly getting better at git management.
#dotnet #softwareengineering #coding #tech #microsoft
https://devblogs.microsoft.com/visualstudio/view-and-manage-git-tags/
In software engineering, we are often encouraged to think about our contribution...
What did " I " do yesterday...? What am " I " doing today...?
The language we use, both inwardly and outwardly, sets the tone for how we work and interact with others…
Software engineering is a team game; our language should reflect that…
The obvious: What did "the team" do yesterday?
#developers #coding #softwaredevelopment #softwareengineering #wellbeing #mindset #mentalhealth
"Would you happily go on-call for a system of fully AI-generated services?"
#softwareengineering #developerexperience #vibecoding
https://serce.me/posts/2025-31-03-there-is-no-vibe-engineering
Listen at: https://archives.anonradio.net/202504020000_screwtape.mp3
This week we will talk about the Unix Philosophy and how it compares and contrasts with whatever one might call the “Emacs Philosophy.”
The impetus for the discussion is a series of blog posts by @ramin_hal9001 called “Emacs fulfills the UNIX Philosophy”:
…as well as a fascinating discussion that took place over this past week on ActivityPub on the topic of the Unix philosophy and history of Lisp on Unix in which some very knowledgeable people have contributed anecdotes and facts.
#technology #programming #SoftwareEngineering #RetroComputing #lisp #r7rs #SchemeLang #UnixPhilosophy
This weeks #ClimateCrisis #haiku by @kentpitman
within each of us
our loved ones, in tiny form,
caring's innate yield
company at a distance
legacy in case of lossJoined a new customer project today. The project started recently. Customer provides project director and business analysts. We provide architects/devs.
Watched a recap of a recent kickoff meeting to get familiar with the business domain and the project setup.
In this meeting I noticed that they presented a rough and very (very very) optimistic timeline.
Me: Were any technical people involved back then when you were setting the timeline?
Project Director: No. The dates are fixed. Why?
Me: 
I would like to introduce you to "Vibe Management". Give in to the vibes, and embrace exponentials. It's like management, but not really. You just see stuff, copy stuff, and paste stuff, and it mostly works!
Formation Architecture Modulaire et Pragmatique : Maîtrisez l'architecture des systèmes modernes
Vous êtes développeur expérimenté, team lead ou architecte ? Découvrez notre formation complète sur l'architecture logicielle moderne, animée par Cyrille Martraire.
Formation idéale pour monter en compétences sur l'architecture moderne et ses enjeux: https://buff.ly/42Y61lT
#Architecture #Formation #SoftwareEngineering #Microservices
Do you give pull requests and code reviews the time they deserve…?
They can be difficult to juggle when you’ve got your own work to do… Which can lead to them not getting the attention they deserve… Which can lead to poor code or, worse, poor communication…
Performing effective code reviews is an underrated skill…
It's not just about the code…
New intro now I am retired...
Looking to get into some #Indie #GameDev now I have time. Want to write the games I wanted to write all along: #Roguelike #Roguelite #ProceduralContent...
Also available to help other people with projects/personal development... Commercial or unpaid, drop me a message, the worst can happen is I don't know or am too busy.
Skills: #SoftwareEngineering #SoftwareDesign
#C++ #Teamwork, #C++, #Online
Development cycle time decays just like anything else in software. If not actively maintained, it gets worse over time.
I've worked on Clojure development cycles with tools.namespace and Component, but it's still hard: You have to intentionally design your code for interactive development and be careful not to break the feedback cycle.
Algorithm: The Ultimate Excuse
"It’s not magic… it’s just an algorithm!" Who else uses this to avoid long explanations?
https://techgeeksapparel.com/funny-algorithm-definition-t-shirt/
#DevJokes #JustAnAlgorithm #SoftwareEngineering
Explainable software engineering, slidedeck by Arie van Deursen, Delft University of Technology. About software engineering, AI, digitalization of government.
https://speakerdeck.com/avandeursen/explainable-software-engineering-in-the-public-sector
#AI #XAI #softwareengineering #TUDelft #AdrievanDeursen #AcICT #ICT #IT
DOGE Plans to Rebuild [US Social Security COBOL] Code Base in Months, Risking Benefits and System Collapse | WIRED
https://alecmuffett.com/article/113053
#SoftwareEngineering #cobol #doge #trump
Dev Containers are great way to try out the latest versions of .NET. Deploy to a dev container for some safe playground testing without changing your current environment!
https://devblogs.microsoft.com/dotnet/dotnet-in-dev-container/
Stratospheric - From Zero to Production with Spring Boot and AWS http://leanpub.com/courses/leanpub/stratospheric is the featured online course on the Leanpub homepage! https://leanpub.com #AmazonWebServices #Java #SoftwareArchitecture #SoftwareEngineering #CloudComputing
Data Munging With Perl [2ed]: Techniques for data recognition, parsing, transformation and filtering https://leanpub.com/datamungingwithperl by Dave Cross is the featured book on the Leanpub homepage! https://leanpub.com #Perl #DataStructures #SoftwareEngineering #books #ebooks
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.
_-/\-_ 
CET 
