hackerm0nkey

I've installed it and I felt the same as what you mentioned :)

Then I saw Goyo Vim plugin

that's exactly what I said and it's sadly not a joke :(

I've always wondered, how did it come to this? isn't having a standup every day a 'process'?

ooh yeah, the industry is dogmatic about ill thought about so called agile principles. Nobody dare to question them it baffles me.

I've been consulting for over 10 years, how come I've never encountered a useful scrum master if they do exist

that's exactly my reluctance to question Agile processes, because people will think I am pushing it too far.

or do it from a plank position

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.

I get it wrong every damn time. 16 years and counting.

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:

given_someInput_someOtherInput_when_doX_then_thisThingHappen_thatThingHappen

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

beware of the difference between simple and too simple though!

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

statically compiled languages are a pain, let's use a dynamic one for this project!

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.

in short, grab a task. make it work, and never look back to make anything right.

I like the stability of Maven, despite XML and people complaining about it's complexity, I just find it stable enough and does the job quite well.

For one of my clients, we created lots of similar microservices, similar setup but slightly differ. What I did was creating a template using maven archetypes so spinning up a new microservice for a new piece of work or simply to try something out or an ad-hoc job is a matter of seconds, so setup time is stopped being a hindrance to start something new.

Also these days there are quite few tooling that supports project generators which can give you a bit of setup to start from.

Interested to see how you guys approached that for a Java B2B service. Thanks for the offer.

It's a template, GDPR is EU-specific and not everyone in the world has to worry about that, it's just too specific a subject to consider in a generic template.

If an EU-based (or storing EU data) team need to jump start from this, one can implement that section on top and not have to wait until the end as you say. The aim of the template is to give you a head start in the right direction.

I come more from a JVM world. But aren't there any DB migration/refactoring tools in Rails to allow for changes to propagate across tenants ?

E.g for the JVM, there's Liquibase and Flyway, and I agree with you, setting that up took a good part of a couple of weeks of dedicated effort.