This right here is really the spirit of the post. Yes there's many impractical applications. Much like there are many impractical applications for RDBMSs, but the tech has such a stank on it, it's important to remember it's just a tool that can be useful despite the hype cycle.
Yeah you're not wrong, that would be more efficient. Again a blockchain is not an efficient way to do it. But it would be effective.
In practice audit logs are used by and for auditors. Non-technicals that need evidence that would hold up to argument. Yes you could send your logs to a third party. Now you have to prove that third parties trustworthiness twice a year to the standards of each legal entity you operate in. And lawyers are more expensive than blockchain devs haha :p
Having a private blockchain that you can share with several changing parties that can subscribe to it. Without having to update anything about your infrastructure is a benefit.
Even though I've lived through several iso 27001 certifications, I'm still walking on thin ice when I say that it would probably easier to explain the blockchain in practice than any other proof of completeness method. Because the public is more aware of it. On the other hand the public is also more skeptical of crypto so it could also backfire :p
I use milkman
I totally understand. It sounds like you've been put in a frightening spot. These transitions really hard enough to do for established managers that have worked at a company for a while, let alone for a fresh hire. It sounds to me like you are doing all the right things: putting tasks into systems and managing expectations.
A growing organization is used to moving fast and when you reach a certain size, you start spinning wheels. Very rarely do companies stay ahead of the curve and setup systems before they hit that wall. You are in the unfortunate position of having to slam the breaks.
Often a company needs an outsider influence to be able to do that. The old guard is used to going fast and haven't developed the tools to go far yet. To me, it sounds like you are doing exactly that. Accept that there will be friction. The new company will work for different personalities. The people that take you from 5-50 are going to be completely different that take you from 50-500. You will lose people in this transition and all you can do is keep a steady course and communicate realistic expectations to stakeholders.
Something that helped me a ton during a turbulent time was implementing patrols. Now, I was lucky to be granted a lot of freedom to implement process changes. But it did really help us to minimize all the small tasks and distractions that kept coming up. Regardless of what tools you use, those little in-betweeners are by far the cause of most overhead. They never really take less than an hour to complete and they are constantly taking an engineer out of the working memory for a complicated task. Also, people love doing them, because you get a small accomplishment every few hours. It's much more difficult to sit with a long project for weeks without much progress, but it's easy to pickup low-hanging fruit. You're doing well to eliminate those.
When it comes to a billion client requests, a bit of requirement engineering goes a long way. Go through the requests and try to understand the root of the problem they are trying to solve. Propose a projects around solving that problem and eliminate all the chatter while your team can focus. If the requirements for that project change too much, then that means the chatter is even more wasteful and needs to be eliminated. A smart business will recognize this.
As for expectations. Yeah, it sounds like it's up to you te set expectations for you and your team. Stakeholders don't have preset expectations and often look at you to set the standard. You want to bring clarity to the table. You want to have the difficult conversation about responsibility and accountability. Again, none of that has much to do with databases and virtual machines.
Come over to the wonderful world of !csharp@programming.dev. Us dotnet nerds really take this kind of stuff for granted...
Lattice sounds awful. We use 7pace to track time spent on work and prioritise on that data. We don't impose time limitations, just measure reality.
If you can convince your org to let you keep your documentation and processes in git and maybe a static webiste you won't need anything more than markdown and mermaid.
If you really want to make a game then gamedev is for you.
There really isn't any way to start and be good. Your taste will exceed your skills at first. This is a painful period where you will find out if you enjoy the process or the idea of the finished product.
If you can't code or do art, maybe Godot or Unity might be a bit too much. Start out with something like löve some indie classics have been made in it and it's a great way to start learning to code and create simple assets.
Start out recreating simple arcade games. These are so full of teachable moments it's like a cheat code for getting good.
If you can make something with a start screen, a game loop and a game over screen, you've got a game. You're a game dev. Everything else, if you haven't lost your mind yet, will go well.
PS. Please, for the love of god, if you are still in school, pay attention to geometry. If there is anything I could go back in time and do pay attention in math class.
Dotnet had really been the ecosystem i keep coming back to. It's been so frictionless. It could be experience, but I really never feel like I'm fighting with it. Running plain C might be the only other ecosystem that I would hold as a less frictionless experience. I genuinely don't hold any frustrations with it. I don't have any ideological problems around Microsoft's involvement. The tool lets me solve problems effectively.
The only thing Im missing is a good llvm target for the clr something like what the kotlin native guys enjoy so i can take the ecosystems to new places.
Sure EFcore can be tiresome and LINQ is inefficiënt. But I'm going to be honest here. If you're trying to squeeze performance out of an ORM and you're running up against performance limits of LINQ, maybe not use a time-saving tool as a power tool?
Maybe I'm simping a bit over it, but I'm not seeing alot of positive content about a tool that has only been very productive in my experience. Maybe because all of the dotnet users are too busy solving actual problems for people haha 😂
Oh and newtonsoft... And maybe xUnit and nUnit could make up and figure out a way to be ergonomic AND work well multi-threaded.
I agree that credential management can be tricky. But genuinely after working from framework to core for over 15 years, publishing an consuming packages has been the best experience for me out of all other ecosystems. Maybe node is easier, but I've been burned too many times by supplychain issues to feel safe with it.
There was a period between 2016-2019 where due to error codes and no error messages it was a bit trickier to resolve the 'yellow triangle of doom'.
But honestly compared to pip and cargo and Gradle Nuget has been a damn godsend.
I think you might be out of luck. Even C# projects use a different semantic with dotnet6.
I spent a good long while reimporting resource references and rewriting code.
It was totally worth it tho!
Article is a bit dated and hard to read. The gist of the author is relatable though 15 years later: redundancies have been hella annoying, especially if they are unknown. Bad abstractions, however, create dilemmas, dead-locks and chicken-and-egg situations. And it's impossible to create good abstractions unless you have no colleagues and no customers.
I would take some frustration over grinding to a halt any time.
Sorry, I didn't mean to be dismissive. I wholeheartedly agree with you. What I meant was that it's a shame I, as an engineer in the year 2023, would have a hard time pitching a blockchain solution to a non-crypto problem to paying customers no matter how fitting the solution might be. I don't think that's very disputable. Now this attitude is entirely driven by the last decade of unsubstantiated crypto hype and associated bad faith actors. It has nothing to do with the technology as it is.