> Scrum is meant to protect the team from changing requirements mid-work
Do I need this protection? Why cannot I protect myself? Do I want this type of protection? Especially if it comes with all the negative downsides of Scrum.
Scrum is based on the imho often wrong assumption that a team needs "protection" of some sort. If your team consists of 16 year old youngsters only this might be true and this type of protection might be useful.
All this "protect the team from changing requirements mid-work" is nonsensical anyway, because no _really_ valuable work is done in 2 weeks. If the requirements _really_ changes you have to throw away the code for the old requirement. You can throw away 2 weeks of coding or 2 days. I'm pissed off more by 2 weeks of dead code. If the requirements adopts a bit its better to adopt early. And change in focus and priorities (which is _not_ a changing requirement): I'm happy to do so if I'm convinced it's for the good of the company and I'm happy to say "Sorry, this will have to wait until I'm done with what I'm currently doing. Please come back next Tuesday.".
Yes, you need the protection. You shouldn't be protecting yourself because it takes time from your work.
Or do you enjoy explaining how project priorities work at length for the fifth time in two weeks? Do you enjoy sales just "quickly popping by" your desk to request "a small tiny feature I promised the client we'll have done by end of week".
This is why in Agile we have the Scrum Master who fields all requests like that and tells Marketdrone A to fight Marketdrone B on whose task is more important, because team only has enough time to complete either task on the next sprint. Every time someone tries to interfere with the team's work they firmly direct the person to the SM. In a few actual cases the team's SM has physically removed the over-eager middle manager out of the team's space with their "few quick requests and improvements".
I'd really want to know what kind of tasks can't be completed in two weeks in your opinion.
The tasks in a sprint aren't "build a house from scratch" -level, you split them until they're in manageable chunks of time. In a single sprint you might have the task of clearing the plot from any trees and laying down the markers for the house's base.
Then the client comes in and approves the direction or asks you to make the bathroom a bit bigger or move the house 5 meters to the east - which is still easy because the "house" is just stakes in the ground with string connecting them.
And again you pick 2 weeks of work you know your team can finish and the client checks that everything looks good. etc etc.
It really isn't complicated. I think the majority of HN has only been subjected to cargo-cult Agile or some kind of Agile-ish system where you just use the terms, but none of the actual processes.
+1 in my experience most people that criticize scrum simply have a bad experience with a half baked implementation of scrum.
If it's implemented well it's fantastic. You get to focus on the important stuff during the sprint. Issues tend to get caught early on because experienced team members chime in during planning poker. The whole team takes responsibility for the sprint together. This leads to lots of knowledge sharing and collaboration within the team.
Once the team velocity is predictable it also becomes much easier to ask for x amount of time per week for refactoring work as the impact to project timelines can be easily quantified.
You lost me there. This is the fundamental problem with Scrum; this type of paternalism where "programmer" is a synonym for "idiotic code monkey", borderline autistic who isn't capable of dealing with demand from the outside. And all programmers are the same, all organisations are the same and all type of development work is the same. Everywhere. If only we would be doing "Agile" right.
The protection in Scrum is "opt out". By default the process says that you're protected.
If the team feels that they don't need it or want it, they can drop it and just hang an "extra work and ad-hoc requests welcome" sign on their team area :)
Most teams I've worked with want to focus on the agreed work just among the team for the assigned sprint length and not have to deal with ad-hoc requests.
> I am [...] quite experienced in Java and Js/Ts.
> I never jumped the Go bandwagon because of the lack of generics.
> Can I now try Go?
Probably no. You still would be very disappointed. Go's take at writing and maintaining software often is pretty repugnant to people with a strong Java or JavaScript mindset. If missing user defined parametric polymorphism ("generics") was a reason to not even _try_ it you will be offended by by other things Go does in its particular way. Be it error handling, pattern matching, concurrency, mutability, etc. Basically if you try to write Java (or JavaScript) programs in Go you will suffer and hate Go. Same for C++/Rust aficionados. Go's newly added "generics" still come without "library support".
I'm mostly a C# developer that uses a ton of generics and when I tried Go previously I was disappointed that it didn't have generics. But I continued on. And so I found a handful of other things that would irritate me or would be an inconvenience versus doing the same thing in C#. So generics alone is not the main problem here, it is going from a C#/Java mindset to a Go mindset. In some way we would probably get bored with Go because it is so simple/easy and not much to mess up, versus the super complex object empires in C#/Java land.
So the problem is not really a problem, go is just a different tool for a different kind of problem or if your brain works in a specific way - but I wouldn't call it a problem at all. In a way, go is what Buddhism is to other (more fully featured) religions. I think if you get proficient with you can probably have a very peaceful programming experience and not fight against the system (like in Java, half the battle is just battling the tooling).
Thanks for bringing this up, will give Go another look again, its been a while!
I personally don’t get bored when a tool is “too simple”, but when it forces me to do things by hand that the machine should be able to do. Like manually specializing a generic concept. I didn’t become a programmer out of love for repetitive tasks!
For some people building "complex" things is how they attach sense of accomplishment to programming. If it is not complex, it is just boring or just a toy, hence not worthy of their attention.
Golang is waaay simpler than other languages, as some were designed to be arcane from the start and other became that way over time. So Go's stewards have been doing a good job of enforcing their philosophy so that it doesn't become a bloated monster.
This feels like an unusual opinion. Lots of people from different backgrounds are happy with Go. And it's praised particularly for its concurrency model.
That said, generics are still new and won't have the strongest library support for a while, and it takes a bit for idioms to settle. It wouldn't be unreasonable to wait for ~a year.
Whenever I see that quote being used to spurn Go I'm amazed of the seemingly large number of language researchers of a calibre of Wirth, de Moura or Wadler and the few actual used languages on the other hand.
That wasn't the greatest example as Go doesn't really have any way to represent it. If it did it might be something like this.
type MyStruct struct {
Name string
}
var-not-nil myStruct = &MyStruct{"Hello"} // this is a "not-nil" pointer variable
myStruct = nil // compiler would catch this
The idea being to allow variables to hold and pass pointers to structs like now but ensure they are never nil.
Some people think Optional/Either/etc are the absolute cure to a certain sort of problems and -- I speak from experience -- it is impossible to convince them that it's not.
Well, of course, if your end users, the business users, are okay if you present them an "optional result" which might or might not be a result, then Optionals/Either _are_ the cure. Unfortunately most end users are pissed if you tell them that you optionally shipped their purchase or that the refund will either be credited to their CC or not.
It's about handling those error cases or failing the build, rather than getting a null pointer exception at runtime that moves execution to some higher part that has no context and little ability to correct the problem, or just crashes. You can still handle it wrong, but you are forced to handle it rather than just, in your example, charging the card and crashing the thread when updating the database that you charged them.
Programming in Go since 10 years and I do not have to worry about nil pointers. You seem to assume that the possibility of a pointer being nil is something that is complicated, a burden to the programmer and a source of runtime bugs. It's not. At least not in Go. At least not something you have to worry about in practice.
I'm glad you've had a good experience, but yes it is a source of runtime bugs.
One piece of code from a well established tech company would just crashloop if authentication failed. I've seen others just die if the RPC service couldn't make a connection.
So in practice, yes I do have to spend my time tracking down nil pointer runtime bugs both from colleagues and also from other organizations.
In my experience I've not had too many issues because of it (due to good testing) but it definitely requires more effort of me. If they didn't exist I'd be much more productive
This. Basically all public economists agree on Lindner's ideas and behaviour to be nonsensical. So he either is an idiot or a puppet.