On my dev blog, I shared some tips for working with Production databases. Especially helpful if you haven't had your morning coffee yet. You don't want to accidentally delete Production data that early in the morning.
Do you work with databases too? If so, I'm curious to hear your tips on how to avoid messing up Production databases while working with them.
Interesting read on “the Spotify model”, why Spotify themselves don’t use it and neither should you.
While Spotify gave teams control over their way of working, many people did not have a basic understanding of Agile practices. This resulted in teams iterating through process tweaks in blind hope of finding the combination that would help them improve their delivery. People lacked a common language to effectively discuss the process problems, the education to solve them, and the experience to evaluate performance. It was not really agile. It was just not-waterfall.
Huh, this seems awfully familiar.
When Agile Scrum introduced new meanings to a bunch of words like burn-down and sprint, it did so because it introduced new concepts that needed names. Spotify introduced the vocabulary of missions, tribes, squads, guilds, and chapter leads for describing its way of working. It gave the illusion it had created something worthy of needing to learn unusual word choices. However, if we remove the unnecessary synonyms from the ideas, the Spotify model is revealed as a collection of cross-functional teams with too much autonomy and a poor management structure.
When I first learned about “the Spotify model”, I loved the idea of getting to work in a tribe, squad or guild. I thought it sounded pretty cool. I bet it appealed to most developers who've played MMOs before.
Link: Failed #SquadGoals
The most important software development principle that everyone should be following is “If it ain't broke, don't fix it.” I know, I know, it's not really a principle coming from the realm of computer science or software development, but it should be. Adhering to this sage life advice is just as beneficial when writing code, as it is in everyday life. Forget about trying to master the five SOLID design principles if you can't even follow this one.
If you're constantly trying to fix stuff that wasn't broken to begin with, you're in for a lot of headaches in your software development career. Not to mention, headaches for other developers in your team. If you find a piece of code that is working, that is not causing bugs, that is not causing performance issues, you best leave that piece of code alone.
Found an index for the most popular programming languages as of today, it is called the TIOBE Index. If you have an interest in software development, you might want to check it out. If you want to get into software development, then this index can tell you what programming languages to learn right now.
This is a great resource for anyone who wants to get started with the fundamentals of C# and .NET Core.
Harder than it needs to be. Or maybe I was just so used to how easy it was to use with .NET Standard apps/projects. Either way I got it to work using this code.
I was going to copy the code over to here but it turns out I do not have the time to figure out how to write code on write.as. So you get a picture instead.