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.

And for others it goes quite quickly! There is no doubt that programming can be helped with a natural aptitude and that it won't make sense to everyone no matter how smart they are, but that is true of many fields.

I'd also argue it's often a teaching problem. I'd highly recommend this essay that goes into the flaws in particular with introductory CS education:

https://felleisen.org/matthias/Thoughts/Developing_Developer...

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?

I think you've missed a step jumping straight to prison.

If you accept a lack of free will, the solution does not need to immediately jump there but rather to finding a way that is fair to all to prevent the bad behavior thing from affecting others negatively while not locking someone up in a cage. There are many lines in between and some penal systems have adapted, but the US is way far behind there.

The optimization is no longer about revenge / punishment but about altering the scenario of the world to make everyone work together better. Sometimes people need to be fully separated from society, but not often. I think we do have effective behavior altering treatments, but they just aren't drugs and take time. But it's not a straight line from "it takes time to help people and its unreliable" to "we're giving up on finding a way for society to work with the people who did not choose what they are".

Absolutely a UX failure here, one that it seems some doctors translate for patients while others are left in the dark on. From the way people are responding on here about the use of statistics in the article, it's clear that a big portion of the techo community I think is undervaluing that often UX is far more important than it is treated.

While the author may not be well versed or focusing on the stats side, you're missing the human side here I think.

> the tests are inaccurate, when in reality the tests are accurate

If the test make someone consider terminating a pregnancy or even considering it, that's a lot of pain. So for that human, the test is failing its purpose potentially, depending on the value calculation of terminating a viable pregnancy vs the severity of the issue if it comes to term.

For a human, accuracy as you defined it means little to nothing. Usefulness and helpfulness are far better metrics, and such a high false positive rate is clearly causing issues in respect to those, which is what the article is highlighting.

Because there is an upper bound for most candidates, and there most certainly is a lower bound if the company means to hire fairly to employees. But as others pointed out, most companies do not have an unlimited upper bound. Additionally, companies do not want all senior level superstars, they almost always want the balance of levels. So be honest with those listings!

> Especially with a well known company like YC, it seems like they would have a solid lower bound so there's no need to list it.

That sounds like a great way to exploit the subset of candidates that don't know the unspoken rules of the valley. And given the variance of companies in YC, I don't think there is a known lower bound for every company.

Then put that upper bound as unlimited and make a note that these are estimates. The theoretical candidate doesn't outweigh the value you provide to the vast majority of candidates if you do agree with the premise that it's good to provide the range.

If that's the case, why not post some general guides based on experience? It seems like this excuse doesn't hold up if the job posters actually cared about transparency.

Example:

Job: Software Engineer

Description: Lorem ipsum

Range of 125K-300K based on relevant experience level

New Grad / 1YOE: 125-150K

2-5 YOE: 150K-200K

5+ YOE: 200K-300K

You can of course be as specific or vague, but these guides help inform people on both ends while not closing you off to those two disparate candidates.

Those work for me on private browsing / it's set up to work for public viewing I think. What do you see when you try to click them?

Why not have them both and use Notion? It allows you to flip between both views of the same data :)

Zero affiliation just a very happy user. As an example, here's my TV show tracker in both forms:

Sheet Style: https://www.notion.so/b7da6a3929624f0c9d30e248111eff2a?v=df6...

Kanban Style: https://www.notion.so/b7da6a3929624f0c9d30e248111eff2a?v=fd9...

Ah, I misunderstood then.

I see that as a total misapplication then, as it actually assumes way worse - that 100% of the people would not like this work condition described, which is evidently false as OP has a company of people working in that. The question still remains though: what percentage of people would choose to stay / join this environment?

Curious why this is downvoted, it seems like a valid question here of how to handle a situation that may arise. I like a lot of these rules but could see myself hitting these. What if I "can't make" 25% of Mondays. What about half? What's the general force behind the policy? That's a big part of the design here.

Your points weighs heavily on a lot of implicit parts of the value equation you left out.

1. That 20% number. What if it's 40%? 50%?

2. How easy/quick is it to replace the people you will lose who don't prefer this work style?

3. What percentage of your current workforce likes the environment as described? Maybe hiring off the street is 20%, but you've already selected for 80% through other selection factors.

Basically, at what point does the value gained from the in person work / setup overtake the loss of potential workforce? You're making an argument for why some people won't want to work there, but so long as the environment is not discriminating on things like race/gender/ability, a partial in person setup may actually be the right call for some teams/companies, without any "luring" needed.

I say all this as someone who primarily prefers to work at home now, but goes into the office once a week or so without any requirement to do so. I agree with OP's initial points a lot, though I think I would lean less towards requirements and more towards guides.

There are solutions here that aren't predicated on that decision, such as shutting down the dangerous avenue to all data equally (though that would break the Facebook ad machine).

The point that a lie in this context can be societally dangerous is still very relevant. Next up is the frequency / commonality of these dangerous lies.

More context here, as I had to look it up and this one fits into the same pattern, but adds a layer of muddiness: https://variety.com/2021/digital/news/john-stossel-sues-face...

In Stossel's case, one of his video's is being very closely taken to their implications, and being marked accordingly as "misleading" and "missing context". In the case of the BMJ, the factcheck title is fully inaccurate and itself is misleading. The Stossel case highlights this nuance, but in the end appears to be a partisan test of the legal waters. Facebook itself has spoken on that one and has defended it.

Of note though is this passage:

> In a previous response posted by Climate Feedback to Stossel’s charges about the fact-check rating on the “Government Fueled Fires” video, the organization wrote, “Stossel complains that we should not have rated his post using a claim review of a quote that does not appear in his video. This is a misunderstanding of how fact-checking partners operate on Facebook. Given that many pieces of content posted on Facebook can separately make the same claim, it is not necessary to create a separate claim review article for each post we rate. It is, of course, necessary that the claim we reviewed is representative of the claim in each post we rate, which is true in this case.”

It seems like in an effort for efficiency, articles are grouped together. I wonder if some article citing BMJ made the inaccuracies, and then the source got grouped into the same article group. It seems like that is a corner that cannot be cut here. To the surprise of no one, fact checking is hard and trying to group things together will cause problems. It seems to me that the critics are right to point out that fact checking will simply not scale while maintaining accuracy.

While there may be some good life wisdom dispensed in this thread, honestly I think it will all amount to armchair psychology. I think some individual therapy may go much further here. Have you been to one to specifically talk about this? If not, start there.

This could be a mindset thing, or it also could be a specific to a diagnosis that may be helpful to have to better understand yourself. A qualified therapist will be able to help you figure that out.

I would similarly commend you for the awareness and bravery to step down, but I would offer two notes here:

> In no way am I a great CTO

> I am not a good manager

It sounds to me like one core thing you learned is that good developer != good manager != good CTO. With that said, all three skills are different, but improved in the same way. Practice and with focused attention. It sounds to me like you were still focused on development and never really gave yourself a chance to develop those management and CTO skills.

It may still be the right call to step down, but I would at least consider trying to shift your focus to the other skills instead of development, if a leadership role is of any interest to you long term. You could also step down to a manager role so you can focus on one of the two at a time. If the learning here is that you actually don't want to focus on those skills over development, then nevermind this for the most part :)