Doing too much work on one's own before looping in others

A few things;

1. Merging often and early might be viable, but it might also expose your colleagues and the codebase to your exploratory process, which might or might not be desired/possible. If you're making semi-permanent changes like API modifications or database table updates, going this route will mean a lot of extra work.

2. Too many chefs. If you open up for too many questions at the start, you will get a gazillion conflicting opinions thrown at you. You'll need to limit the audience somehow, or bring forward a clear idea or opinion. This leads to developers working a bit on the side. I don't mind this, I think it's good to give autonomy to working groups and let them make mistakes, as long as there is coaching or feedback in place in the long run.

3. If you go the route of designing a bit on the side first, to save time compared to 1), you might suddenly find yourself in the situation that the major parts feel quite done. Adding polish is now just a minor addition to what you're already accomplished, so you might do that before putting up the PR. This means that a complete solution showing up as a PR doesn't necessarily mean that it was over-engineered or overly polished on the side.

4. Not "syncing" too often saves time; less context switching, distracting information, and time to reflect on decisions and design.

And then let's have daily progress meetings to report on the status of each chunk of the investigation! Please update Jira at least once a day!

This is a great example of the perverse incentives built into the "everything should be done in one day chunks that you report on daily". The team is incentivized to ignore highly important but challenging / hidden work, and instead only focus on things that are highly visible to management.

I think criminal defense is a great service to humanity. It's hard to estimate how many are wrongfully accused, but surely there are many. Further, things like the plea bargain system or parole regularly lead innocent people to proclaim their guilt. It's very messed up and must be a terrible trauma for some. Lastly, I think even guilty people deserve humane treatment and perhaps forgiveness.

It's usually a mistake to build a large scale solution without consulting with others in your organization or team. Other engineers often have good feedback that will make your solution better and you are likely missing some core premise or context.

It's also a mistake to seek too much approval from others before proceeding. In any group of X people, Y% won't agree with you, and of those, Z% will be uncivil. By uncivil, I mean harsh criticism or otherwise toxic behavior that is not constructive.

If the organization is healthy that Z% is small and troublemakers will be handled by management if they do act up. If not that Z% will basically become like bridge trolls and you will be opposed by a confederacy of dunces every time you try to do something of consequence.

I've experienced both of these scenarios, and striking the right balance is an art and a science that boils down to reading the politics of the place and getting buy in from some key people so that your project at least has a fair shot. Sometimes the place has gone toxic and it simply can't be helped.

If you're in a situation where there is a high percentage of Z, you should ask yourself if the work you are doing is worth playing the politics necessary in order to get the job done. If yes, get smart, read books like the The Prince and Art of War and figure out how to play the game. If not, get outta there as expeditiously as possible, and put your time and effort to something more worthwhile. If you want to be kind, let management know in a professional way exactly why you are leaving so that they can have an opportunity to try to make life better for your colleagues.

It's about career growth. Most programmers (hope to) peak there.

You know those folks who peaked in high school? You look at them and feel sorry because that was as good as it got for them but tinged with a hefty dose of jealousy because you never had it that good then.

This is like that but in software terms. An individual contributor mostly works up to the point where they take on more than they can handle alone and are sometimes heroic. And some people, some really good ones, peak there.

The crazy debugging live on production servers in the middle of the night that saved millions of dollars or the championship-winning touchdown. Same same. We love to tell those stories.