I liked this, Paul Smith had some good stories. This episode and the following one about Github CLI got me thinking a lot how we choose architecture and languages and how it’s an iterative process. Rarely do companies/orgs get it right on the first try. Needs change, estimates are way off, and budgets run out.

Well, the point of the article is that Greenwald was trying to write about how an (ex)(vice)president was using his influence to enrich his family...

It would have been nice if the impeachments had focused on real crimes like that, rather than obvious BS.

Thank you so much for this. I have wanted something like this since getting off Facebook.

I use this for tools. From Harbor Freight to Dewalt if I use it. Anyways, in the author's context, I've been using Miro.com for all of my diagrams. I love it. If you ever want to upgrade from ASCII art, check it out!

For me the ability to do laundry alone is worth $$$. That is 90% of the reason I have maid service (family of 5).

perhaps people do gitflow incorrectly? I've been using it for several years and, on teams of about 10-15 people, have rarely had merge conflicts. Feature branches should be short-lived and therefore avoid conflicts. Hotfixes pose a risk to conflicts, but that's their nature. Say you have bug in production code and you fix it via a hotfix and some other developer stepped on that code on the develop branch, you should have a human reviewing the bug fix's merge with the new feature in development.

I really didn't understand this post. To me, it seemed like someone writing a critical perspective of a process they don't fully understand. I know it's not because of a lack of documentation, git flow has been blogged about ad nauseam.

I have friends who use different branching strategies who complain constantly about the same pain points the author brought up. The only thing I agreed with the author with is to find a strategy that works.

this is really good to know. I've been using Typora for the past year and, at this point, I can't live without it for making md files before committing. Thanks!

This is so crucial. I've had managers who were ex-developers and I've had managers who are managers first and not subject matter experts. The unifying quality among the good ones was that they aren't really leaders, they're facilitators.

- They get you what you need to do your job. - They shield you from product owners and stakeholders by meeting with them and giving you only the information you need (unless it's necessary you meet with them). - They advocate for you and your work. - They give constructive feedback and insight to help you improve. - They never try to stand between you and the advancement of your career.

Again, they facilitate. They facilitate the goals of the team and they facilitate your career development. I had one manager who said his sole mission was to get developers promoted out of his team. He wanted to make developers better. It can be very frustrating to find talent if you can't nurture it but I think great managers create an atmosphere where people thrive and become better in the company of their team.

> They shield you from product owners and stakeholders by meeting with them and giving you only the information you need

I've worked at a lot of places like this, and I'm continually surprised people enjoy it. For me, it always ends up having the telephone game problem. You spend a huge amount of time error-correcting.

How do folks scale it? Given the aforementioned error-correction process, the amount of time a manager spends facilitating that process caps with very few engineers.

We have gone another way and our engineering teams work with product managers and together they make decisions. The PM deals with gathering feedback from our analytics teams, end-users and clients, and summarizes that for the team.

We feel this gives a sense of ownership to individual engineers and allows them to make better decisions without a lot of back and forth communication funneled through a proxy. And it also means we don't need a dozen managers.

Good engineers are expensive and hard to find, and I'd say finding excellent managers is just as onerous.

It depends on how toxic the rest of the organization is.

I've worked at places with a healthy culture (very little shielding was necessary) and I had awesome, close interactions with end users and the business side of things.

I've also worked somewhere where the culture of the executive team was bad and my manager (who was awesome at shielding things from the team) left.

This lead to close interaction with people who will insist that 7 different things can be the #1 priority for a single person. Or executives who repeatedly make people work nights & weekends to hit an internal deadline only to find out the internal deadline is weeks earlier than the client's actual deadline.

In the latter org the more time went on the more I missed my shielded ignorance of the rest of business's demands.

> I've worked at a lot of places like this, and I'm continually surprised people enjoy it.

That's been my experience as well. When a manager says they try to "shield you from the bullshit" it's just a lack of transparency that leads me to making my own (often worse) assumptions.

Wall of text incoming; I was trying to explore why I agreed with you and the parent post wholeheartedly while still finding some value in the "shield from the bullshit" concept, if perhaps not how it's commonly applied.

So I'm in an interesting position to comment on this, as a dev trying to transition into management. I've ALWAYS been on the full-transparency side as a dev, but have often had to defend that position to other managers and bosses, with the justification that I might scare the devs or distract them or have them focusing on things that aren't their core goal.

There's definitely a kernel of truth in that, but I've found most of the "grey area" is less ambiguous in practice; (e.g. don't be a rumor mill, don't get people worked up, realize there may be a proper time and place) and more importantly, _devs usually know most of what I would tell them._ They're not idiots. They have people they talk to, and they overhear things, they usually know how the games are played at some level and have some intuition that "something is happening." And by trying to hide this, and not being a partner and helper in wading through it/building confidence, you erode trust. So in terms of the "what's going on in the team" bullshit I'm pretty open, even if it's a bunch of political infighting and misaligned incentives, at least so the dev can understand the landscape and make sense of it.

The bullshit that I DO however think you can shield a dev from is the "Symptoms" of the above. Help balance out individuals playing favorites, individuals being biased against a certain dev, help a dev see if turmoil is coming and how they might navigate it, help a dev understand where motivations are pointed so they can avoid socio-political pitfalls, or optimize the decisions they make to drive their career to be responsive to the ecosystem they're in.

I believe one can be transparent enough to let a dev know WHAT is going on, but still provide them an ally and shield against potential negative impacts of it.

Lack of transparency is just bad communication. I see "shield you from the bullshit" not as bad communication.

I look at it more like this: The customer has an emergency and needs something ASAP. A bad manager will pass this bullshit straight to his team, including the "Oh my god this thing is going to blow up if you can't get it done by Friday!!!!",

A great manager however, will first figure out if this is a real emergency or not, how much it will cost, etc. (S)he will take into account who is currently working on what, what the priorities are, etc. Then will present a realistic solution to the customer/management: "Look, this we can do, this we cannot do".

In this situation, as a team member, work comes in as usual, and you probably were allowed to put an estimate on it. No "Help the world is going to end if this isn't done, DROP EVERYTHING!!!".

I've worked for multiple managers that fall in either bucket, and I had cases where something needed to be finished by Friday, because the customer needed it on Monday. Asking a week later after deadline: "Did it work?" "The customer hasn't tested it or put in production yet".

Great managers however, have great communication skills. Maybe a better wording is that they are able to filter the bullshit from the rest.

And when something bad happens because of this rushed code, they'll tell you, "you have to do more testing", make sure quality is not compromised. "We can do automated tests, we can do them as long as it doesn't eat up developer time".

Makes me think that in a consultancy business, everything hinges on getting the customer to fund your development properly. Ask too much and you'll lose the contract to a competitor.

Any thoughts on this?

Is it possible you read this as thy give you only the information you need without context?

I always give the why along with the request, but spare the noise.

As a person managing projects and also contributing as an IC, having a manager stand between me and my team’s PM was absolutely counterproductive. I know where they were coming from - it would have been great had I not been managing individual projects and needing feedback from the PM in a cyclic way on my technical designs before they were split into work items for my team. It’s incredibly hard to do something requiring good communication if you’re playing telephone.

I liked it... but I'm also a pretentious, intellectual Reddit user like all you fine folk ;)