104 karma · joined May 6, 2021
You might as always happens attack them for not doing Scrum right, and I'll tell you that's the age-old cry of the agile-folks: you're not doing it right, and nobody ever was.
Fuck scrum, it's not agile, never was and never will be.
Continuous integration => of course, for me, never worked at a place where it didn't happen and that was before agile was even a thing. If I hopped on a project where it didn't make sense though, I should be free to ditch it.
There is no one way to write software that works for every project and there is no one process that works for every project. Just let the experienced folks decide what to use instead of leaning on some bullshit fixed crap process.
You can declare only when someone else already has performed the imperative chore, i.e. written the source code, programmed.
Q.E.D.
1) cover their asses
2) change anything at will
If you never agreed to anything, then you can keep demanding whatever, and blame whoever as well. It's a really shitty management style. I left such an organisation not too long ago where I would say that the engineering department survived not because of, but rather despite of the head of that department. First few years nobody had a clue what he was doing most of the days and when he decided to get actively involved it was obvious he had no clue about anything. He still has no clue but he's made sure to surround himself with incompetent yes-sayers to cement his position.
A real political genius.
There can't really be a shortage for more support engineers if he likes that, but if he wants to do more core engineering then of course go for that. Most of the big enterprises should have room for him in many different departments and he might be comfortable and safe.
As for concrete advice: Just go looking for jobs and weigh pros and cons. You can do it on his behalf and bring a few to him for discussion.
Don't be pushy if he's not into the idea and just feels like complaining a bit. Sometimes all a person needs is a bit of acknowledgement and not a solution.
Unit tests serve multiple purposes. Number 1 is to have a way for you to play around with your design. Then it also can document requirements. I then lastly serves as a vehicle for you to prove something about your design, typically the fulfillment of a requirement, or the handling of some edge case, etc. This last part is what people unfortunately mostly refer to as a test.
TDD says that you should write your tests before you even have a design, one-by-one typically, adding in more functionality and design as you go. You will end up with crap code. If you do not throw the first iteration away then you will commit crappy code.
Most people naturally find that an iterative cycle of design and test code works the best and trying to sell TDD to them is a harmful activity, because it yields no benefits and might actually be a big step backwards.
1) You seem to include any kind of processing in "finding patterns". I wanted to both get your definition for "finding patterns" as well as the proof that this is how humans learn.
2) In the example of reading a book in class you fail to include the past history of experiences/learnings that takes place outside of class and which helps you to put the words in context. This might very well be a major differentiating factor compared to the first example.
To give a silly example: If I kick a wall and get a pain response through my toes which teaches me to not do that again, did I learn this by observing a pattern? Is that really a useful model for how the learning took place? Surely there was a pattern, perhaps even several ones, no denying that, but I highly question the accuracy and thus general usefulness of this model for learning.
Depending on definition, finding patterns could mean just about anything, thus meaning nothing.
Proof please.
A program manager for me, any kind, relates to the function of leading and coordinating multiple interrelated projects, towards a common goal.