I can't agree with this strongly enough also with the parent comment.
I think it's the constant conflict between the 'maker schedule' and the 'manager schedule'
I firmly believe that I can be way more productive when having no standups and when I control my time rather than satisfy an ill thought about ritual, but more often than not you can't change much about it. When I can, I always do.
interesting to see this becoming part of the tools.
In 2012, I was on project were we used a physical board, and we would make a black circle for everyday on the board and once we started exceeding the initial estimate (it was done in days as opposed to complexity for some reason) we make that in red, then we started discussing the reds
it absolutely makes no difference to me to have standups, yet still we participate in them...
- To see who's working on what, I just look at the board.
- To seek help when I get blocked, I send a message on Slack (or whatever) at the point that I need that help, not only at 9:30 AM
- To know who's blocked on what, just tune to Slack
Given the above and if you have the team discipline to make sure that tickets reflect the state of work. Why do we need standups then?
That time can be more targeted towards a meaningful discussion, but the industry seem to be blindly just doing that without giving it much deeper thought. It baffles me.
The anti-pattern in play here is that “the decision is in the hand of the least-informed”
I believe technical decisions should be delegated by the “aware” manager to the team to make or to the most-informed. But then if the manager in question is not the aware or if ego is at play then we start getting the type of decisions that are useless at best.
Not really referring to these type of decisions, but things like "should we extract this into a service, instead of having it to live in the monolith?", "should we use this type of tech to X" type of decisions that in most organisation is left in the hands of the multi-layer above hands-off manager that don't see the code, don't deal with it yet unable to see the disastrous implications of not addressing things.
IMHO, organisations are better off leaving tech decisions to the people who _actively_ deal with that tech or at least give a higher weight to their take on the matter
Yes, surely it's possible. But the resultant test is highly tightly coupled to the implementation of the SUT which gives the test more than one reason to change.
We should strive generally to have tests that only change if the business requirements change. But if I want to refactor my unit (whatever that might be) then the test should not change, or at least should not change __much__
I love this. I started with trying to have simple, short and descriptive names for the test methods but then it doesn't work quite well with more complicated test cases. So I grew to like something along these lines:
which has the advantage to be optimised for reading. When I want to skim over the test class quickly I can simply look at the method names to get an idea on what the test is doing and if I want more details I can look further at it's implementation
Well to me that sounds more of a process matters than a choice of technology.
I use git day to day and before that used svn for a number of years. Now on the odd codebase, I tend to find svn is still in use, and I don't mind that, I just work with it.
From what you've mentioned, it does not seem that introducing git in your organization was solving a problem per-se, you "could" have the exact same flow you had with svn in git, have a single branch and call it whatever you like, e.g. "master", "develop", whatever...
What I think is happening is that someone didn't like the process you had and tried to solve/replace that with a more modern way, e.g. having feature branch, release branches, master, etc... and that it easier to technically achieve with git than with svn. Imagine doing what you doing now with svn, that'd be a nightmare, wouldn't?
On the other hand, your "new" workflow might be solving problems that you didn't realize you had. I.e. code review and approvals have the great benefit of having a 2nd pair of eyes reviewing your changes as well as spreading the knowledge throughout the team as to what's been changing, more like keeping a pulse... so that is not necessarily a bad thing.
despite being old, I think the value lies in the "principle", you don't have to generate your code out of your markup but at least if you document your thoughts and reflect upon them and what and why certain decisions were made, etc... That invaluable on it's own IMO
I do this day to day, nice to see that there's a name for it :)
Start every piece of work in a markdown with vim. and proceed to dump my thoughts, what I have tried, what did work and what didn't. Also any useful links that I've found useful.
And as they say "You only learn once you reflect", this proved invaluable for me going forward when faced with "ah. I've done that before but don't quite recall the details"
I move feel this to be like literate/log driven development
awesome indeed. Any plans to support more Vim navigations, something like 'gg' and 'G' would be useful IMO. As well as the ability to use a custom 'ESC' mapping to leave the scroll mode.
Then I saw Goyo Vim plugin