adjkant

Slogan an old company of mine tried to socialize while trying to wrangle overbooked meeting issues: "No agenda, no attenda"

Yep fully agree! I wanted to highlight some areas that devs may immediately "get" but "developing the spec is half the work" really should be shouted from the mountaintops.

I've noticed that people can conflate "detailed spec" with "terribly meticulous process". Close collaboration with design/product doesn't mean that writing things down isn't useful, and can come in handy specifically:

1. When capturing complex logic areas, especially if related to any areas that are related to money or legal considerations

2. When onboarding new people on any side who need to learn about or get context on a product (product, design, eng)

3. When you revisit a V2 3 months later and forgotten what decisions you made or why you made them

Lots of detailed specs to me sounds like a fast velocity of products and totally compatible with startups. That said, you also added the word "lots" that OP didn't use. It could just mean two or three!

Okay, that's not what I said or what OP said though:

> How does that get to 4 hours a day

Maybe so, but it's varied across size and industry and matches with my friends experience in other broad areas. So I guess let's reframe: what is my meeting load estimate (the 4 hour a week high side) missing? How does that get to 4 hours a day, and if not there, what is the maximum?

To be clear, that's not to say that other meetings can't be used, but that they are not part of the "agile" process. I can easily imagine a dev ending up with 4 hours a day, but that's more related to company size and process. Things like design reviews, meeting with other teams, not being able to quickly find the right point of contact, using meetings to find out you have the wrong person, not defining clear agendas, inviting too many people to meetings, and so on. I'd bet some of these are affecting OP, but again, this has nothing to do with the style of development planning/process.

Disclaimer: Defining and using a narrow definition agile IMO is a useless rabbit hole.

And the big names in tech also purport to use agile and spend maybe an hour every Friday or Monday doing "agile" type meetings. Which are we talking about here?

If it helps, add to my above post that I'm using "agile" to mean the philosophy of defined sprints with stand ups, planning, and retrospectives to help execute a larger, changing roadmap. There are many many other rules people can choose to add, but my experience across many companies is that this is the shared core in practicality.

When people say agile, 95%+ of the time they don't mean whatever Pivotal Labs is using for a standard. I've practiced "agile development" at F10, big tech, and under 250 person startups, and no one has ever referenced a strict spec definition like that, not even the F10 which basically said "here's some detailed guidelines some use, take what works". So what's the relevance of this strict definition?

Commenting this on every post without explaining anything doesn't really do anything but confuse. And the more you do it, the more it appears that your definition of "agile" would be the outlier here. Though as many will tell you, the definition of the process is quite varied.

> My current company spends 4 out of 8 hours every day in meetings

This doesn't have anything to do with agile. You can run "agile" with as little as an hour of meetings a week if you want. Planning, retro, refinement in one weekly, async standup in Slack. You can bring standups in person, have them daily or less frequently, adjust the frequency, change your sprints from 1 to 2 weeks.

Even the heaviest weight version of this I can imagine (daily 30 min standups, 1 hour planning, 30 min retro, weekly sprints) adds up to 4 hours total for the week. So what you're describing is 80% something beyond that.

> taking 2 weeks and 4 meetings with 10 developers on each call just to deliver a simple list-filter feature fit in?

This sounds like you've moved from smaller company to bigger company and are noticing things move slower, though correct me if I'm wrong.

Either way, these are the questions: Why does the feature actually take two weeks to build? Are there more factors beyond the team? Larger scale? More testing / QA needed than pushing out to prod? Just plain worse developers? Bad PR practices that delay the feature? These factors again are nothing to do with "agile".

Another person asked this well, but really you've offered no notes on what your old team did differently that was not "agile". What's the alternative that people are missing?

Actually not sure of the law here myself but FWIW as a NYC resident I regularly encounter places that don't accept cash.

> I'm willing to bet investing in yourself early will outperform the compounding interest you make on income you have at the start of your career.

People present this often as a choose 1, but in reality there's a big gradient of options here. There's no reason you can't spend some money for experiences in your 20s and also save a good deal for compounding interest in the future.

While Google may beat that salary, Google interviewing and hiring practices are infamous for being over the top filtering, choosing many false negatives rather than having false positives. I'm not sure I'd bank on Google hiring any quicker...

This idea would be antithetical to decentralization of cryptocurrency, but I think that since this issue is a platform level problem (e.g. future contracts can also introduce this) what is needed is a set of mediators/arbitrators (we can call them "judges" that hear these cases and have a technical mechanism to correct them without a fork.

In order to select these judges, the community can elect them directly or elect a board or leaders to select them indirectly.

Of course these corrections would require gas, so they may need to add a small additional gas charge to transactions to fund this group and perhaps also their salaries. We can call this extra gas a "tax".

In summary: Stand up an entire government around ETH in order to ensure the benefit of judges and humans can override code. Once you do this though, you have a central ruling authority with an in-code constitution, but parts that take place in a human judgement realm.

I set this up partially in jest of blockchain currencies in general, but I do actually say this seriously. I think that purists of decentralized code only control will hold back any possible benefits that cryptocurrency could bring. The situation above still has benefits from a monetary fiat system run by a nation state, though I think severely less than what the cryptocurrency ideal is. Some include:

- There is no nation state attached to this centralized ruling body and itself can be decentralized and beholden to no nation

- All transactions and reasons of the body can still be public and on open API's for people to integrate and monitor with modern tech

- The loose "untraceable" or general "freedom" arguments that come with a blockchain would still hold so long as the community with these tenants maintains control of the board / judges / leaders.

They are in location X and it has been written into code that there is no way to ever remove them from X. The only difference between throwing this "money" into a black hole and this is that you can see what's in this black hole once it's in there, even if you cannot remove it.

The only way to ever fix this is to rewrite the history of the blockchain which means forking the entire ETH currency by getting all mining/record nodes to agree to it.

Long story short: Virtually unrecoverable without large coordination from the entire ETH community.

Many things have difficulties and complexity. I would phrase it not as "software isn't hard" but that "it is no harder than many other things". This specific questioning is not often employed for many other equally complicated and difficult fields, which I think is a bit unfair and often acts as a gatekeeping mechanism that has led to diversity problems in the field.

> It does a disservice to other software engineers.

How does that phrasing affect any other engineers?