jwdunne

reading royce made it apparent the agile movement was, in part, a response to a strawman

i have no doubt that places were practicing waterfall in the large. people running businesses, both vendor and client, want 'predictable' estimates up front, with a single timeframe, and single quote

but i suspect internally projects followed an iterative process, where designs were refined repeatedly and testing happened early. because you had to

unfortunately, those projects were still judged by a waterfall yardstick, with inflating timescales and bills, giving something for agile to attack

and on first blush, agile, the manifesto, sounds reasonable enough

but, after 30-40 years of practice to reflect upon, agile:

- has some good parts that were already well documented, i.e royce and brooks

- some radical parts of dubious general applicability and benefit

- just enough ambiguity that we have since been arguing what true agile really is

and this is what prevents it from ever really working or being the basis to solidify an engineering field around

it helped us get some of the way there but it won't help us get further and it's time to let it die

Makes sense really. The fat stores will go a longer way with less muscle. I imagine that would work brilliantly during the cold winter months living in a cave, where theres less reason to move much. Unfortunately, this is dysfunctional in the developed world.

We thought that at the SaaS I’m working at but AWS scheduled maintenance in our AZ and that led to significant downtime with nothing we could do about it, no compensation, nada. It was basically our fault because we didn’t use multi-AZ. I can’t remember if this was RDS or ECS but we figured if it could happen to one critical service in a single AZ, it could happen to another.

I think Proxy _is_ overkill and perhaps expensive for what it is. For a pg install, running pgBouncer isn’t difficult. But I guess that depends on whether you’re authenticating with IAMs, which doesn’t sound trivial with bouncer (it might be).

You’re right. Psalm has been a god send on the project I’m working on.

Unfortunately, it’s taking far too long for Laravel to catch up so parts of its API are a black hole for types.

Especially things like request input, which returns a union of string and array as opposed to using a conditional return type.

You end up with assertion soup every time you touch Laravel so over time the project uses less and less of it.

A well-typed framework and set of libraries would be very nice.

Hang on, let me cover B:

tHiS sHoUlDn’T bE oN hAcKeRnEws

Nexium, or esomeprazole, works well, or better than Zantac, and can be purchased OTC (at least here in the UK). It’s pricey but usually lasts a couple of days or more so it stretches further.

Northern English dialect too…

I noticed the difference too when moving to a town just outside of Snowdonia in Wales, UK. It’s truly wonderful - you just don’t see it growing up in a city like Manchester.

It’s Bortle 4 where I live and it drops down to 3 just 20 minutes down the road. One of the best perks of living here.

Time is ripe to invest in a good telescope, I think :)

Yes. I was thinking exactly this when coming into the comments.

Real world benchmarks take more time to prepare, we get that, but let’s be honest: a bold claim _needs_ bold evidence.

I have ADHD and this is what I would recommend. Dual screen is okay if you implement the rest as long as the task occupies both screens (e.g code in one and tests, type checking or a live demo on the other).

I’d go further and suggest turning off _all_ sounds and vibrations your phone period, including for calls.

If that’s a bit extreme, do it for work hours, but turning them off completely is life changing. With them on, it’s too easy for your phone to dominate your attention.

Your phone needs to be something you give attention to on your own terms, as a tool that you control.

You might wonder about urgent alerts, like waiting for an important call or on call notifications. Your habits simply change to give the appropriate amount of attention, like a quick glance every now and then at an interval of your choosing. And, more often than not, an urgent call can be called back.

I think a lot of the evangelism happened before Python and other languages both picked up steam and integrated some of the powerful ideas, e.g first class functions / closures or a powerful object system, so the chasm is now much narrower.

I’ve read a few pieces by prominent lispers who moved on to Python for similar reasons, along with wider adoption with a bigger ecosystem.

So you’re not wrong in thinking that. But I do believe there are a few things beyond macros that Lisp makes fantastically trivial that wouldn’t be so in other languages. It just doesn’t seem as magical anymore since we’ve raised the baseline for what is possible, for what to expect from a language. That is due in part to the influence of Lisp itself - lambda the ultimate own goal.

Yes, I find it harder to read code at lengths much longer than this. 120 is quite difficult. It also makes it even harder to read if you split the screen vertically, which I do all the time.

That said, I don’t think it should be a hard limit and it’s fine if a lines a bit over, +/- 10 like you said. Certainly not something that we should contort into multiple lines just to keep under a hard limit. Unfortunately, a few auto formatters only do hard limits - it’d be interesting to see how an acceptable interval around the limit would work.

Plus, I’ve noticed the limit makes more of a difference for comments than code so I try to keep comments under that. The written word appears more sensitive to line length.

I didn’t know this until I read it. Whenever I listened to Ghosts, I’ve hit a few tracks and thought “I’m sure this was on The Social Network”. And then some time later, I’ve done the same thing listening to TSN OST. Never clicked!

I really loved the soundtrack when watching this film. I was thinking this is some of the best New Age music I’ve ever heard. And, to my complete surprise, it was scored by Trent Reznor and Atticus Ross. NIN has been my all time favourite band since I was a kid. That made me chuckle.

Indeed, it’s hard to read about naughty Orcas and Postgres internals on a single feed, despite both being inherently interesting to me. It’s a refreshing change from the Reddit homepage, with topics I have to piece together myself.

Fact is, I can’t fully predict what I will find interesting so HN regularly offers me a good few dark horses that Reddit simply cannot.

Not long ago, there was a series on the history of bread. I’m sure there’s some kind of subreddit for this but I’d never have sought it out.

Let’s hope they don’t start eating tide pods.

I believe the chat backend was implemented in Erlang too. When I was much younger, the web based instant messaging seemed like magic to me so I looked into it and turned out they used Erlang.

Me too! I was, shamefully, in the middle of work so had a mini panic thinking my 5 min HN scroll was gonna become an hour long battle with my connection!

One of the quotes seems to mention to that, where he says he digests a lot of papers to add a small part to TAoCP, since his aim is to write books that cover a the breadth of computer science (which necessarily cannot be as deep as these papers go).

Interesting. The cheesecake here is nothing like ones found in the UK, which would be classified as toast!

This was my experience too :) Was a bit more promiscuous with where I helped out, including UN, Graal Kingdoms and Zone, but also spent a lot of time building my own playerworlds.

I owe my career to that game!

Wow lots of people here who played Graal. I spent 10 years of my life on that game and I can credit it with giving me my start in development. Learning to script for the game became my first step towards programming in general.

In fact, developing new content for the game became the fun itself.

Codein here btw (ignore the icky nickname - is what it is).

I’ve done this too. Quite the contrast to my disorganised life. I have two types: lined and square paper. Both hardback and book bound (find ring binds don’t play nice with me and I lose pages). Get the exact same ones each time, apart from a few old ones whilst I was in my discovery phase. The lined ones come in a stack of 5 so always have one ready to go.

Also use a single type of pen: a black staedtler fine liner. They in a box of 10.

Can echo this. A colleague’s node container was maxing out CPU and just removing PM2 and running node directly solved the problem. That was easier than debugging why PM2 was having such a hard time.

To be fair, it was a straight up conversion of an old VM in vagrant and Docker was looked at as a one to one replacement before learning otherwise.

I came to realise this too.

Using Homebrew and multiple users is excruciating and an eye opener on how system-level software should really be installed.

Homebrew insists on avoiding root privileges whilst also installing packages system-wide. That works fine and is invisible with one user but falls down hard otherwise.

Their documentation is incorrect too, saying that this is all fine because “we install in /usr/local/bin”. It’s not easy to change this.

The solution was to embrace MacPorts which correctly requires root privileges to install system-wide packages.

I haven’t looked back since. I haven’t missed brew or any software that’s available on brew alone.

Aye, I noticed this too and I’ve never written a line of production C# in my life.

On the projects I’ve worked on recently, the backend often ended up far more complex than the frontend, taking up more time to build and maintain.

This is natural. The backends were responsible for interfacing with other systems, like databases, 3rd party APIs and message queues, for example.

The frontends, on the other hand, generally interfaced with only one system: the backend.

Am I arguing that the frontend is never more complex and time consuming than the backend? Not at all.

But I don’t think you can blame the backend stack and tooling for the resultant imbalance of complexity between the two systems.

This is my feeling too.

I’ve written plenty of bash scripts to automate common tasks. Colleagues won’t open them up and extend or maintain them (some developers won’t touch bash). But if they have an easy to use, well documented interface, they will happily use them to be productive.

The problem with Python is as you describe. It’s not always guaranteed and if you want everyone’s environment on the same page, you then have to start faffing with virtual envs and/or version managers.

This is totally fine on projects written in Python as a whole. But, otherwise, adding complexity to the tool chain is a tough sell to the team.

If things get hairy in bash, it’s probably better to extract those parts in the project language and call them from bash. Your build will already be half way there to accommodate this vs introducing a scripting language.

Not only that, maintaining those programs involves less context switching. Although mainstream languages blur with enough experience, there is still overhead between juggling idioms, syntax and what not in, say, Python and Go. I’m not perfect: if I’ve been working all day in one language, writing another is like a smack in the face. Sometimes I’ll forget semicolons, or include them. Sometimes I’ll use camel case when really the style in that language is snake case. Not a big deal but it is jarring.

There is still context switching with bash but if you use a terminal-based workflow, that does have less of an impact.

Interesting how close our timelines match up, minus the 11 years. Smoked from 14 to just before my 30th birthday, which was 6 months ago.

If I smell it in passing, it smells pretty disgusting. But if I spend the weekend at my parents (both heavy smokers), I quickly fall in love with the smell again and yearn for “one last cig”.

A big problem for me is that tobacco smoke very much smells like home - it’s what home smelled like growing up. And nothing takes you back like a strong, familiar scent.

Yeah, I prefer an actual module system over PHP namespaces plus autoloader. It feels like a hacked on module system tbf. BUT I do get lots of real work done using namespaces and a PSR autoloader so it works.

I do wish they would extend auto loading for standalone functions and constants though.

This is roughly PHP’s approach. In this case, Illuminate is the vendor prefix and Mail is the package name. This often but not always corresponds to the rules around the composer package name, which would be illuminate/mail in this case.

This is similar to NPM’s organisation prefix (@foo/bar).

But yeah, I’m not defending the hacky way namespaces are resolved through autoloading. I do prefer actual language support for a module system (but Ruby suffers from this problem too).