jacobyoder

You're welcome. Much of the speed bump in 7 came from reworking internal memory usage and allocation. A pointer for an array entry used to be 128 bytes - each array entry had a 128 byte overhead. It was reworked and refactored down to... 42? or 44? You can probably imagine the impact that might have on memory allocation.

"But you can't really know what it will be like if you just change an env in one area - what if you miss something? Or what it someone changes some code later that doesn't respect the env var?"

"well... that's what tests are for, right? We'll write more tests to ensure usages of these timezone/date/time specific areas are covered".

"Someone will miss something. I missed something years ago and it was bad. We can't rely on that. We have to change the actual server instance clock to ensure we can verify this behaviour works correctly".

When I pointed out that what we were testing was a scenario that wouldn't ever really exist in real life - mobile clients not using 'real' time (they're almost all synced to satellites and time servers you typically can't override) hitting a server that also may be set to a vastly different time (not synced to a timeserver with a few ms drift).... I was dismissed as "not understanding the problem".

There's a need to say "how might this perform in 8 months, when DST changes". But... you'd set both client and server to the same future (or past) time. This was setting up a server to be days/weeks in future, then testing 'now' clients against it, which "worked" somehow, but imo was just giving weird false assurances that a hypothetical scenario worked that wasn't ever going to happen in real life. Basically couldn't happen in real life under normal conditions.

Potentially, some, yes. However, when goals have already been decided, and 'missing' those goals is a 'bad thing', there's only so much you can do. We'd gone from collaborative to 'command and control'. And... FWIW, we got a lot more done under 'collaborative', but it was mostly just 'me' on the dev side and one other person on the product side.

At some point though, many of the original assumptions about problems are understood to have been fundamentally wrong/misaligned, and need some revisiting. You need to touch old code, whether to delete it, or to have it align with new standards or new ... whatever. Touching anything that didn't relate to an explicit 'agreed on' jira ticket was seen as wrong/bad. I ended up bundling in 'fixes' of unrelated stuff when working on 'new' stuff because... it had to get done, but was ignored or rejected during any sort of planning.

I've heard it said that "to go fast, do it alone. to go far, you need a team". I can get on board with that, but you need a team in agreement and competent. I have a colleague working on a small team and... they're mostly just completely inexperience and bad, but there's no self-awareness. Taking direction from the guy who was in high school last year, while ignoring the person who's lead multiple teams and has delivered high value software for 20 years... that's a bizarre imbalance that can't be fixed with 'sprints' or process alone.

7 brought a huge speed boost. (typically 100% or more without any code change required).

Not specific to 7, but 2 things I think have helped a lot are:

* PSR standards * composer packaging

Initial PSR work helped define some package interop standards. I'm not sure how useful ongoing PSR work today is (no doubt there's some incremental benefits?).

Composer is a great package manager, and helped usher in a lot more sharing/reusability of common components.

Laravel bundles a number of Symfony components, for example (many frameworks do).

The speed alone in 7 was big, and we've seen some more incremental improvments in 8 and 8.1 and 8.2. It's hard to find current benchmarking tools that compare the 5 series with 7 and 8. I found one showing 5->7 on a mandelbrot run.

* PHP 5.0 was 251s

* PHP 5.1 was 87s

* PHP 5.6 was 29s

* PHP 7.0 was 15s

* PHP 7.1 was 9s

The 'experimental JIT' work (at that time) yielded 4s.

That benchmark was from 2016, so... way out of date now, but other numbers I've seen were 7.1->7.4 was another ... 10% improvement on average, and depending on workload, you might see another 10-20% improvement from 7.4->8.0.

Kinsta has some interesting useful benchmarks on 'real world' apps

https://kinsta.com/blog/php-benchmarks

Been using PHP since 1996, and ecosystem, community, performance all continuously improve year over year.

> sprints give more discretion to the teams

when they do. i was part of an 'agile' team in 2019 (6 mo contract). I wasn't there long enough to have strong views on work items or priorities, but did watch the interactions between others. It was a decently organized team inside a (fast) growing org - lots of challenges there. But overall, there was a decent balance.

Worked on another smaller team longer - 2 years. As the company grew, it got far more process heavy. The 'sprint' stuff was "as tech lead, you get 5 points to use however you want per sprint!" (yay?). that got taken over by the CTO getting involved and using those '5 points' for constant infrastructure stuff. I was reviewing code I delivered, and it was full of cut corners to continually hit deadlines. I begged on a few occasions for more 'cleanup' time. It was always denied (except for 3 days over xmas, because... literally no one else was working, so they couldn't say no).

The project transformed in to "here's our strategic goals for 2022" with every quarter mapped and filled to the brim with work. 0 time for anything but bare minimum MVP. The thinking was "well... you've been able to work at that pace before, and we added someone new, so we can increase that". In 2019, it was MVP - test the idea. Speed to market makes some sense. In 2022, millions of dollars and hundreds of lives affected each month... we need to take a bit more time to clean up existing code, retire legacy code, adopt a slower pace to focus on clarity, testability, even performance concerns etc. This seemed to fall on deaf ears.

"discretion to the teams" tends to ring hollow to me based on recent experiences, and ideally I'll work with another group in the future with a healthier balance.

FWIW, I'm in your camp mostly too.

That expert may not know what to do either, or... will contradict earlier folks and say "you need to redo all of this pile..." and you'll be stuck.

I've no doubt there are some workloads that really do require a level of complexity that various cloud systems offer. Much of what I've seen doesn't require it, but once someone starts down that road, they're 'justified' in learning more and tying more stuff to the cloud provider's way of doing things.

I cut my teeth setting up servers back in the 90s, and that you can spin up 'full' servers (thinking various shades of VPS) in a few seconds is crazy great. But we're somehow now 'past' that... and we have mountains more complexity to consider.

Potentially, maybe? I didn't follow it closely enough, but the crux was a group trying to test out various time-related calls, and they'd set the base time of the containers to different times forward and behind 'now'. There were hundreds/thousands of minutes 'billed', going over the account threshhold, stopping all builds. But... I don't remember hearing if there was some diff between 'negative' charges and 'positive' charges.

https://www.sesostrisshrine.org/ looks like Nebraska area? Perhaps someone at that group might have some idea who he is.

Just finding out who made the scary tie-pin might be enough to identify this person!

Yet another pitfall: Changing the system clock on runners can throw off billing and calculation of used minutes. Colleague of mine told me about that one last year.

Having almost any alcohol will give me great heartburn in the middle of the night. I can't say quite when it started, but certainly by late 30s I noticed it, and by 40s... it became a thing to avoid.

wow... didn't know that. thanks!

I noticed... Limes grown in ... Peru or Uruguay, packed in ... Europe (might have been Italy, but maybe Poland)... then shipped to someplace in the US, then driven to me. This was on a bottle of lime juice. That is all of ... $1? Yet... I'd need to buy dozens of limes just to squeeze enough juice to get half that small bottle.

> What if we want to interally tag each cell in our bodies with nano?

There will need to be multiple addresses for all the nano-services running inside each of those nanobots. Solution: install a k8s cluster with each nano...

I recently went through an interview/exam with a takehome portion. The company indicated "this shouldn't take more than 2-3 hours". For me, it was 2.5 hours. And... I wouldn't want to do dozens of these, but doing one or two every couple of years isn't too much of a burden, imo. But I know everyone's tolerance is a bit different.

FWIW, i never did faceID with glasses, but it does recognize me, and in the last 6 months or so I've noticed that it works even with sunglasses on (and masks sometimes too).

Was on the fence last year between a 12 mini and the latest SE (which this article is about, I think).

I somewhat regret the 12 mini, not because of the size (or even battery - it's fine for my daily use), but the face ID. As others have said, it's just too interruptive. (well, they didn't say that word exactly, but it's what I think).

Rumors I'd read last year would be that a 13 or 14 would have a 'button' underneath the glass screen, so we'd effectively have a 'home' button without the need for a physical button. Not in the 13, and I've not heard about it in the 14 (yet?) but would welcome that. The touch-id flow I had grown used to was so ... useful and fluid. Part of the reason I don't think I recognized it as much was 2020/2021 - so much of my regular life was thrown out of whack (travel/meetings/etc) that the impact of moving to face ID wasn't all that noticeable. As we're 'returning to normal' more and more, and I'm 'out' more, the day to day impact is more noticeable.

> In nearly 20 years of doing this I’ve have never had one of these dreaded fake developers make it through the resume screen, initial phone call, and a conversation with an engineer....And if I did, we’d just fire them as soon as it was clear they lied about their ability.

I've spent most of the last 25 years working independently. A large number of the 'fakers' (or just... currently-low-skilled) don't apply to large companies with screening processes. They build custom one-off software/websites/etc for small businesses. Those small business people have no ability to judge skills or quality. Some of the tech folks doing that may, at some point, try to apply 'up' in to larger companies, moving away from independent/freelance, and some of those may get weeded out.

Had to deal with some automated scan tool telling a client "you have log4j - you're vulnerable!" when... we didn't. A project was including a dependency on SLF4J and that project pulled in slf4j-log4j (IIRC). But it was not configured, wasn't compiled in to the final jar, and ... even it was, it was very old log4j (1.1 or 1.2 IIRC?). The vulnerability didn't affect that older version.

We had to spend a week back and forth with

"no, we're not vulnerable".

"But we see log4j is right there in the a file in the directory".

"No, it's not vulnerable and it's not being used and we can't reasonably fork the entire dependency just to remove that one sub-dependency from our project's dependency"

"But we see log4j is right there in the a file in the directory".

Also, there was no budget to do any sort of rewrite/refactor/etc anyway.

I'm not saying every interaction has gone this way, but it's happened more than a couple times (over the course of... 15+ years).

The last interaction I had like this was a few years ago - someone had done lots of mockups in... figma (but it wasn't figma - I can't remember the tool, but it was relatively well-known). I had 100+ "screens" with example text/input/labels on every screen.

These were done by an agency, then handed off, and... there were multiple people who had worked on it. Screens/slides 1-40 had some font label in 12px, slides 41-95 were at 13px, and the rest were at 14px.

I pointed this out, and kept getting told "stop deviating - we've already approved these - we've spent weeks going over all of these - stop thinking you know better than an award-winning design agency!"

Making screen 41 and 40 look the same was "deviating" because someone reviewing "41" against the mockup was 'wrong'. So... I made each screen with same fonts as the mockups.

Two weeks later, in some review, someone 'complained' because jumping through all the screens, the font sizes kept changing. I pointed out this was exactly the same behaviour as jumping through all the mockups, sequentially. It was obvious, but ... it was only getting reviewed holistically weeks after everything was 'approved'.

Probably the worse 'designer-led' experience I've had, but a couple others have come close (just not as stretched out). But it reinforced that the 'design' portion really needs to be involved and iterative (and... they need to be open to feedback just as much as I have to be).

UI/UX has to be treated as an iterative process. Collaboration between multiple parties (eng/dev/design/pm/etc) is almost orthogonal to the root problem I've seen: "design" gets treated as "this is it" and the moment you start being 2-3 pixels off, or a shade of red isn't what was in figma/ps/etc, "you're deviating".

"These were already signed off/approved/whatever".

"But... you ONLY did a wireframe of 3 screens, for iPhone 13 only, in portrait, and ... we already have to support desktop/tablet/mobile."

"Stop deviating - we already interviewed customers!"

"But... you don't actually show what should happen in various hover/transition states. You haven't accounted for multiple lines of text in these screens. You haven't accounted for different font sizes... etc"

"Stop deviating".

I've had a couple of good experiences working with a couple design folks in the last year, but EVEN in those cases, "design" was sort of treated like "one and done".

Once the product is in the hands of real users, feedback - implicit and explicit - comes in, and there should be processes in place to make rapid adjustments - possibly multiple iterations - to deal with the feedback.

That's one of the biggest hurdles I've seen, even when there's decent collaboration and respect.

Not always, but if you only do some of those incantations a few times per year, and what you remember is that you tended to get them wrong... it's a bit of a pain. This is partially why I switched to GUI clients for day to day. Tower (and maybe others) have an 'undo' which gives me a bit more confidence to try/test out things, because I know if it's wrong I can hit 'cmd-z' and be back where I was (at least until I push!).

Git switch and git restore were introduced in Git v2.23, way back in August 2019. So... they're not brand new in the last few months, but... like you (and another poster) I'm not aware of them, as I had ... 8-10 years of muscle memory before without them around. I'm actually trying to think back to when I first used git... I don't think I learned about it at all until around 2007 - company I was at had a lot of SVN and a couple of the folks on the team were exploring other options. And... IIRC, around mid-to-late 2008, someone at a local Ruby group demonstrated github. But... I'm not sure I actually started using git 'for real' until 2010 or so.

So... there was 9+ years of learning certain commands/styles and... switch/restore weren't part of that.

And I've mostly switched to GUIs for day to day stuff - the Tower Mac client and sometimes the JetBrains git tools. They might even now be using 'switch' and 'restore' for some basic operations behind the scenes.

> your code is not fast, efficient, reliable, convenient or secure because you say so.

I often would be in meetings where tech folks would introduce their code (to non-technical audiences sometimes) as 'tight' or 'super fast' or... similar. It was cringey every time, and... often wrong. Yay - you got a query down from 8 seconds to 2 seconds. That's not really 'super fast' though - with a bit more work (or experience) that would be 300ms or less (which I eventually did with about 30 more min of rewrite and indexes).

Tooling and an active ecosystem around a language are generally more important for most projects. Lang-feature-X, on its own, is almost never the reason a project succeeds or fails. An active community fostering discussion about the best ways to address particular problems, with an ecosystem of libraries and examples that show one or more ways to deal with those problems - that is useful. As the language develops, the ecosystem will incorporate those newer features to build on the previous approach.

Good IDE will usually highlight style and basic issues as you're typing them, and you can get a better idea of what 'canonical' foo-lang is. I'm not a ruby expert, but using RubyMine I'm reminded of some things while I'm coding, and (some) errors (or just style issues) are spotted before I run.

i got stuck with 'vi' at a place a few years back because "that's good enough - they're pretty much the same". I don't mean as main development tool, but on server builds, 'vi' was 'good enough' and also "it's smaller - we need to keep this small". So any time anyone had to do anything on those remote servers... years of muscle memory gone because... oh yeah, it's 'vi' not 'vim'. it was jarring to be reminded of how different they are.

> ("4 hours" sure except the other candidate put in 12 hours and lied about it, so...)

Recently went through this. Got an email at 2pm saying "please run through this exercise". Looked at the doc, then decided to hit it. I submitted everything back before 6pm. It was around 2.5 hours, and I took a short break in the middle. I screen-captured my whole session (not sent in) but to have a little souvenir of the exercise. There's really not much way I could have 'cheated' on the time because there was only 4 hrs tops between sending the email and submitted my results.

Their estimate was 'we expect this to take 2-3 hours', and they weren't all that wrong. I could see someone less experienced taking more than 2 hours just on one of the bad queries - unless you've seen the pattern(s) before it's hard to recognize and refactor quickly.

> I hadn't understood how the people on the team thought about web development and it wasn't a better fit for them. They didn't feel like there was a problem, so a solution didn't make sense.

There's got to be a limit to this line of justification though. Lots of people have just plain wrong ideas about 'web development', so catering to their ideas doesn't serve anyone well (except, perhaps, those people, who in the short term don't have to learn anything correctly).

A colleague shares stories of his team who don't grasp the difference between GET and POST, don't understand the term idempotency, believe that 'web dev' testing only means 1 thing, etc. There's... 5 of 6 of them, and only one of him, so... much stuff ends up staying 'wrong', and the 'wrongness' in each section of the code ends up compounding 'wrongness' in other systems/features as they're being added. This matches how this team thinks about web/software development. But it's not in any way beneficial.

> you also benefit because people aren't just changing stuff willy-nilly. E.g. your project you've been working on wont suddenly stop working in production out of the blue because Clive decided to totally change the database table schemas at 4am on Wednesday morning and nobody told you about it

It can. I worked at a 2400 person company. 'Dev/tech' side was... ~150 or so, so not thousands of devs, but not just '3 folks in a basement' sort of place. Lots of 'process', but only for some people (like me). Other people - people who were dating management, for example, could make whatever changes they wanted.

I would need to have a formal meeting with 2-3 "sr" folks to request a database index, then have to do a presentation about why it was needed, then wait for 'review' ("this might break something else"). But then other folks would literally just go on the database (because they had direct access) and fuck with whatever they felt like.

And... I'd be dinged because my deliverable was late because... "well... you should have planned your project better" (when... I had no hand in planning or setting deadlines). Not in my wildest dreams did I think requesting 2 indexes on a couple tables that only our application used would require 2.5 calendar weeks and multiple meetings, so... unsure how I should have raised a flag earlier that we might hit some roadblocks.

But yeah... hey, if you already had access to prod dbs, you could just go in and make live changes without testing or documentation ("it's OK, Steve used to be on the database team - he knows what he's doing").

Process/overhead isn't necessarily bad, but applied unequally, you wind up with hypocrisy and resentment (and people like me leaving in less than a year).

Lots of advice of "just grin and bear it", and "get along"... etc.

IMO, it depends on the friction. If this is just your own expectations not being met... you can adjust those.

If, however, you have other people on your team or people you answer to expecting things to be faster, but other parts of the system are working against you... that seems to be a recipe for constant pain/friction, unless/until others leave/change (which you generally have no control over).

Things that should take 2 hrs taking 2 weeks are annoying/frustrating on their own. If you have other people setting deadlines for you which don't align with the processes you're tied to - that's a whole other level of pain, and it might be worth trying to find someplace a bit less internally conflicted.