chunkyfunky

I would have thought the tags on the question make it pretty clear it isn't dealing with languages like Rust.

>Heat it. Squirt it. Serve

Hey, that highly technical process is valuable Intellectual Property owned by the McDonald's corporation, careful they don't come after you!

Well I understood it perfectly as in I read it as "modularity, type-safety, and maintainability"...then again I am familiar with DDD and thus understand the ubiquitous language from the original comment...which is kind of one of the main points from DDD ;)

Yep, keeping ur kids in the fridge is a great way to keep them fresh for weeks :)

I can't say I disagree with many of the points made in the article, but I am getting just a little tired of what I perceive to be the current trend of generalised manager-bashing these days...I transitioned from dev to manager a few years back and whilst I'm definitely not the greatest leader ever, I am also definitely not anything like the tired stereotypes portrayed in the article (case in point: when a dev tells me "two weeks" I smile and say "I believe you meant SIX weeks, right?". And then it takes 4, but everyone's happy cos the stakeholders got it 2 weeks "early" and the dev can sleep at night knowing the code is rock solid. etc.

This "Us vs Them" thing is bollox - we're all on the same team as far as I am concerned!

And, even though I have a good 20+ years of development behind me, I can honestly say that the two BEST engineering managers I ever had were people that could not have written a line of code to save their lives...they were just brilliant leaders and motivators who focused on me as an individual and trusted me enough to have the technical chops to get the job done whilst they meat-shielded us against waves of shite from the C-suite.

Well anyway, what would I know, I'm just a dumb-ass manager :)

I think that is a fair point and anecdotally at least it gels with what I have observed. I've worked in quite a few food service settings when I was younger and the margins (in general of course; Soup du Jour is like 5/600% margin at least) are very thin. However I wonder if this isn't just a symptom of the bigger problem; in order to pay better wages, consumer prices have to be raised because it's the only way to make enough margin to pay the employees BUT the real reason margins are so thin is because you are paying exorbitant rent to some faceless landlord who actually owns the building you operate out of; and it only ever goes up, never down; and your suppliers constantly raise their prices (or lower their quality) because they are in the same boat; and thus all that money that is generated by the tip of the spear (the restaurant, the retail store, the pub) is mostly being pushed back up to....the people who already have all the money...which is why they own all the buildings and rent them out to make more money....and so on. Just a thought :)

+1 - super achievment!

Was very disappointed too, I fully expected her to pull off a mask at the end and it would be Tom Cruise underneath :(

I'm not normally one to nitpick but Robert Boyle was Anglo-Irish, not English :)

>This is precisely waterfall

I'm not sure I fully agree, unless we want to define waterfall as "anything where a bit of time is spent up-front to decide how a part of the system should work" :)

For me, waterfall is where every single aspect of the project is pre-defined, and cannot be changed during development without serious pain and lots of awful bureaucracy

But in the above workflow, there isn't anything stopping us from making a loop for example on a sprint by sprint basis, and using feedback from both the tests and changing requirements to improve the design, update the APIs, change the tests, etc.

I suppose we could argue that this is "mini-waterfall" but it works in my experience :)

That's a great point. And here is a real example that happened recently at work. One of my teams needs to create the ability for their low-level code to be able to respond to HTTP requests for command and control. So they have all immediately started trying to figure out how to do this. Except I happen to know that another of my teams already did this exact same thing in another project, packaged it up and published it...and the source code is already sitting there on github waiting to be re-used. There is zero overlap between the two teams (two totally different departments) except for me, so in this case I (as a lowly engineering manager whose coding days are long behind me) am able to solve a problem and save time/wasted effort Now, if we didn't do dailies, of course this would come up at some point but we'd have lost a week of productivity or more.

As someone who came from a fairly poor background (not half as as bad as the OP to be fair) and who has managed to "break out" I can say for sure that looking back I had a ton of lucky breaks - but, and this to me is crucial, only after I stopped worrying about what might go wrong and focus on what I could do right. If I had predicated my success on somehow getting lucky I don't think I would have made it.

So to me - and not wanting to speak for the OP of course - but the way I look at this is that the simple encouragement of "I made it and you can too" is more motivating than "I made it but then again looking back I had a ton of lucky coincidences that you probably won't have so, sure, try it, but don't expect success" :)

Scrutor looks great, I must take it for a spin! And that is a great point about DI - being able to extend code/behaviour by injecting a different implementation of a dependency