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!
I would go further even and say that for any team that doesn't all do just one thing, developing the spec is half the work.
Once all the interconnections are figured out and the mechanical engineers know what needs to hold what shape at what temperature and pressure, and the metallurgists know what chemicals will be touching the metal, and the power connectors to sensors are all numbered so you know how many you need and where they'll go, and the communications lines with what format and inputs/outputs they'll talk to at what voltage... to me a spec is the document that tells everyone where their little part needs to fit.
You have to do that downstream and collect it back upstream for larger projects, since the person doing it never has enough expertise. And then the spec negotiation between teams that don't really necessarily know what constraints each other has which need to be resolved so that people know what to design.
It's frustrating but actually writing down a detailed spec really does enable a lot of other stuff to happen. I'm sometimes blocked as an individual because of a team that's in my path but which isn't really in my field. Say, they do optics and I design the optical sensor so I need to know the optical power to expect but they have to do simulations and get information from the chemists and semiconductor test engineers first. I need a spec for what they want -- I need to know how low the light level is, how much noise there is, and lots of other little details too.
I don't know if that qualifies as "terribly meticulous" but in my experience skipping the spec step often means wasting an incredible amount of time solving the wrong problem.
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.
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?
> 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.
Pivotal Labs, well known for "doing Agile right," spends the entire Friday doing no work every week.
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?
I agree that there's no use defining things so narrowly, but I think your experience about the meeting load involved in "doing agile" is atypically low for the industry in general.
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.
If your running strict scrum your stand-ups should be 15 minutes. In my current company as well as my last role that'd be a long stand. They were usually closer to 5.
Honestly, at my last company, in my first team we reserved the fridays afternoons for demo and short formations (the most complex, that also resonated the most with me, explained how and why the network architecture was made, while some were as basic as explaining how to make good PR).
It was way more productive than with my second team where we used one hour every two week for the retro. In big company, the time you actually spend on understanding how everything work is never really lost.
"The New York City Council has approved, by a vote of 43-3, a bill that would make it unlawful for most businesses to refuse to accept payments in cash, with limited exceptions."
It was supposed to go into effect November, 2020. I don't know if COVID concerns about handling cash meant that businesses were formally or tacitly allowed to require cards since they could be touchless (tap) or close to it (wipe down the hard plastic keys).
> 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.
>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.
Well in my scenario (and that of most of my peers/siblings) income is low and cost of living is a large % - you don't have a lot of discretionary funds to manage so it usually is one or the other.
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...
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.
Yup. One more freebie hardfork that reverses (okay not "reverses" techbically but forks away from a previous state) some mistake/hack and Ethereum would lose trust especially competition between chains (EVM or otherwise) is so high.
They would gain trust for returning all of the WETH accumulated in all of the contracts where it’s been idled due to PEBCAK, in concert with a code fork that refuses to accept such transactions. That would be a sign of maturity and intelligence to bankers, and influence their consideration of whether Ethereum might be a viable platform for their financial business someday.
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.
You jest, but “stand up a government” is a primary barrier to entry to being considered a “fiat currency”, which makes sense given the drawbacks of trying to qualify as a currency without one.
A banking-grade currency would have reversed the WETH transactions and prohibited new ones. Ethereum has refused so far to do so, even though it’s in their power to hard fork. Whether or not you view them as a currency, that’s not the sort of behavior that engenders a perception of financial trust and safety in their work.
So all that is needed is forcing a bunch of people to do something. Not much different than forcing a lot of people to do to war, so not impossible.
Lets imagine, hypothetically, that some mafia boss, big company, users would create a lobby, the "platform of people affected by Ethereum" that would lobby to force a fork for a fee. Lets say 50% percentage of your lost money if we are successful, that is still much better deal than having no money at all. And then would use some tool to convince/coerce/bully everybody to restore it or just would mess with the process to force it. Would be this possible or a probable outcome after enough amount of time has passed?
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:
Thanks for that link! That six-step design process appears to be a formalization of what I've learned to do subconsciously from years of experience. I've been struggling with mentoring junior colleagues wrt the software design process, and I'll be trying that six-step approach as part of my mentoring.
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?
