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!
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?
> 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:
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.