jacobyoder

I saw this scenario happen. Startup, one person wrote an insanely complex engine that did a lot of stuff; allowed them to scale up, get funding, etc. But... it became a complexity nightmare. The answer was... hire a new single expert, and let them rebuild a bunch of stuff, and... there were now 2 insanely complex layers, one of which sort of knew how to interact with the other one. The first person had gone, and the second person ... just didn't come in the office much (2-3x/month), and... was 'above' all the 'day to day' needs.

First phase was about 4 years. Second phase started, and I was there in year 2 of that. 6 month contract on my part. Took me months just to figure everything out.

Background - the core engine was PHP. The 'rewrite' was also PHP.

I left, and got some updates from a few folks later. They hired some python and JS people ("we can't find/hire any PHP people!"). And... they gave the python and JS people greenfield "rebuild chunks of this system". And months later, this was all spun as "PHP sucks, node rocks". Because.. well... look what was getting done. They couldn't hire many PHP folks because... they weren't paying terribly well compared to the level of skill required to deal with the core engine.

This was far less about tech as it was management. Giving a team of JS people who are all colocated, have a working system to inspect and emulate, can choose their own tools, and are given a long time frame... it's not all that surprising they had some success compared to "let one guy go off on his own and don't talk to him for weeks at a time".

Looking back, the second guy was trying to recreate much of the flexibility of the first system, but in a 'modern' way, which was very much not a great idea (the complexity and flexibility were the core problems, from what I could tell). The node and python teams avoided implementing much of the flexibility, and they could get away with it a bit more because by that time the business was more established, and had a better understanding of what they needed and what was not.

Part of how I viewed it was "it took 12 people 8 months to recreate 20% of what one person did in PHP in a couple of years". But that's certainly putting an overly pro-PHP spin on it. ;). By all means, though, having just one person be the sole person who knows 90% of the system, with no time given to train others... huge red flag. Took me a few months to suss out just how precarious that was, and I understand the business need to spread out the risk. Was just very annoyed that the "rebuild" decision was spun as "php sucks" instead of "solo-expert-working-in-isolation" sucks.

You can impose a structure process around wordpress - version control, more of an OO approach, etc - but you're then somewhat out of step with the rest of the wordpress ecosystem. It becomes harder to use anything from the 'regular' wordpress world, which is part of the (often a prime) reason for its continued popularity; an extremely large ecosystem.

And... the availability of "wordpress developers" hinges on people being able to do the 'fast and loose' thing as needed. I know there are WP devs/agencies that use version control for all their stuff, but it's the opposite of how most people learn and work in wordpress.

Perhaps they like being in an office with their team mates. It's the colocation with coworkers, not specifically a particular office space.

The moment I start dealing with other teams/depts, I almost certainly have more context about most things than the manager "managing" me. You end up asking other folks "why X? why Y?" and get their perspective in their terms, and incorporate that in to however you're getting your stuff done.

The only thing "managers" have access to is info they choose not to share, or info they're told not to share, which creates an explicit vaccuum/silo of info, and increases the power imbalance. Most of the teams I've worked on have been this way. Yeah, sure... I don't have "the big picture" you created on a corp retreat with other dept managers... but why don't I have it? Because you've chosen to only share bits and pieces... "for your own good". Makes very little sense to me.

If I know you're planning on doing "functionality A" at some point, inform us now, because that very likely has an impact on decisions I'm making today. I'm far more likely to understand the impact on my own work and my team's work than you are, given that you don't actually know how to do the work (in most cases).

I've had a couple good manager-types over the years, but only a couple.

Casual twitter user here and have heard about 'notes' but not actually seen it in the wild yet? It sounds moderately reasonable; one of my concerns is that there's so much other upheaval going on that whatever effectiveness it might have will be lost in the shuffle or essentially impossible to measure well.

Had an engagement with a client a few years ago and GA came up. Folks on our side tried to avoid Google where possible, and I'd suggested some alternatives. Matomo, Fathom(IIRC) or others - multiple folks on the team had experience with these alternatives, but the client was insistent on GA. "This is the industry standard - look at all the billion dollar companies running GA - this is what we should use". I pointed out those comparison companies also had dozens of engineers per project; we had 3 part time people.

The argument kept coming down to "GA is the standard; GA is what people know". Which is... true, if not somewhat circular.

My other suggestion was try multiple; run GA and Matomo together, for example, for a bit. Or GA on just the public marketing site, and something else on the internal application. Nope, because they wanted to track every single ad spend all the way through to registered user usage of the internal business application. Knowing that the $70 you spent in Tacoma geo lead to 3 users registering then knowing that those 3 people routinely used a budgeting tool more than the $90 spent on 8 people who registered from Toronto... apparently those sorts of analytics might be needed in the future, so we have to have this.

Instead of "let's just install both for a few weeks and try them", this became "let's 'investigate' multiple options and write reports about the pros and cons of each". Nuts. My larger concern was that, for testing/dev purposes, we'd not have as easy a time of 'resetting' an analytics DB that was not under our control (resetting or maybe creating new/unlimited sandboxes for each test run). I didn't find any way in GA (or really any hosted solution) to handle testing well. But maybe that's not a big concern among 'enterprise' analytics users?

At this point, I can't really tell either.

> Some people really just learn one language.

I think that's a gross oversimplification. My colleagues know JavaScript, TypeScript and ECMAScript, as well as YAML, HTML and CSS.

> The first problem is that everyone, even in the same team or org, needs something different from it.

Big yes to this. One of the things I noticed at a client that was using it, and growing, was that multiple people not directly involved in development had a lot of visibility in to developer-focused boards. Those folks were using numbers and info we were recording, taking them largely out of context, and making strategic decisions from those.

One of my big bug bears is 'story points'. In general, I don't like them - the effort involved in accurately getting them "right" usually takes longer than just doing some of the work (not always, but a non-trivial number greater than 0).

Over time, our 'story points' and 'velocity' numbers came to mean a lot of different things to a lot of other people. We had 5 different parties who would routinely check those numbers, and often interject their own questions, call for more meetings, etc. And 99% of it was just... useless. After more talking, I'm realizing that parties A, B, C, D and E all are using the same number (story points in this case) for different purposes, sometimes vastly different.

To counter some people getting upset at seeing certain numbers go up or down too much (or too fast or too slow), sometimes numbers would be changed midway through a sprint. And, sometimes things would be added or removed from tickets mid sprint. These may be unavoidable in some cases - I get it - but the changes weren't at all related to helping the front-line workers get work done. The changes were done to make someone's sprint report numbers acceptable to someone else who asked for these reports. Neither of these parties were ever in meetings with any of us.

In the spirit of cooperation, I suggested we add some more custom fields to track the actual numbers they wanted to track (one of the things Jira does well is letting you add more data collection points). Rather than overload and use one piece of data for multiple purposes (which not everyone was aware of), why not just capture more data, to get more accurate/complete data? "Too confusing. That's too much work for you all". What they meant was "I don't know how to make new reports with this info, and I couldn't compare current data historically against old data, so we'll just keep doing this half-assed thing".

No kids here, but similar in that I remember sessions of long focus, and being able to do them repeatedly, for multiple days in a row. I typically can't do that as much now. Perhaps more to the point, I can't do them on demand. I do still have periods of 'focused flow', and they're great, but they just 'happen'. But... I never could just turn them on/off in the past either - they just happened far more frequently.

I predict you'll have more, just not as frequently as you used to. :)

FWIW, many of the things I used to have to spend long periods of focus on are now simple/common libraries that just didn't exist 30 years ago. Or, if they existed, there wasn't any convenient way of discovering them. So I find my productivity is still comparatively high, even with fewer number of flow states.

> Your "Whys" quickly end with "because so-and-so said so", and will change tomorrow.

The "5 whys" always seemed to stop just short of formally identifying the root cause of conflicting management techniques, inexperienced decision makers, poor planning and people not understanding the technology they were making decisions and deadlines around.

I saw this first hand a couple years back, except... we always seemed to stop one step short of the "so and so said so" because... "we don't want to blame people". So often it would stop at me, instead of going one more level up beyond me to the people who gave me impossible/contradictory things to do.

So, to get past the "no blame" thing, I got "we're not 'blaming' you, but perhaps you need more training on X" and that sort of thing. I've been doing this professionally longer than most of the rest of the team have been adults (or in some cases, alive)... no, I don't need more training on X. The system didn't fail because I hit a problem with X. The system failed because 3 people set too many deadlines concurrently, and when it was pointed out to everyone (individually, then in a group setting), no one would budge and I get told "just make it happen". Laws of physics, etc.

But... let's make sure we don't "blame" people! Just... it's OK if we blame you, we just won't call it 'blame'. We're just "identifying".

Selling time (hourly), I can't keep it up forever, and 10 years ago it was more like $100-$120k. I already see this year slowing down some, but it might be back to more like $120k, but on a part time effort, which will be nice in its own way. I was regularly putting in 50+ hours/week, and it's just not something I could maintain long term.

Wife is from UK, but we're in the US now. She's got some friends/family there, and we keep up with some news/sports/TV from the UK regularly. Have watched some recent reports about how dire some things have gotten over the last year or two. Things are 'bad' all over, but the UK seems to have been hit doubly/triply hard compared to some neighbors, esp with energy prices. Unsure how much brexit is a root cause, but between brexit/covid/ukraine, UK seems to be in a bad spot. Sorry you're dealing with so much that's beyond your control. I completely get this is well beyond "don't eat out as much" territory.

Can confirm. Have done this for the last several years. Wife stopped working a few years back due to an injury (but no disability or other income for better or worse), so I've been the sole breadwinner the last few years. I've typically been bringing in between $150k and $220k (gross), and we've spent most of the last ... 7-8 years not doing or buying much. Min obligations each month are now around $3000/month (mortgage, utilities, food, insurance), so there's been a bunch of savings.

I can't retire and never have to work again, but I'm slowing down a bit, and spending more time not earning money (gym, reading, travel, etc).

On second though, if I absolutely needed to, we could probably 'retire' tomorrow, and do a bit more belt-tightening - savings/investments would last probably another 10-12 years without any major changes to lifestyle, then could collect social security. But that's... not something I want to do. I like doing most of what I'm doing, and am just being a bit choosier about what I do now.

EDIT: no kids, semi-rural southern US.

EDIT 2: Moderately high, but irregular, income from consulting/contract dev/tech work. Not W2.

Somewhat similar reaction - not specifically to Twitter folks, but in general 'techbro' type situations, where people think $500k comp is normal, expected, or hell, even 'deserved'. You got lucky (genetics, right place/right time, etc) along with whatever talent and hard work you've put in.

Have been in your situation where I got in to debt (mid 5 figures). Even after getting new jobs, it was a few years of grind to get back to 0, then several more to have some semblance of long-term savings, all while reducing consumption/expenditures dramatically.

Unsure what "not enough" was, but the standard "3 months" savings advice - even doubling to 6 - is really at the low end. For mid-career software folks, I recommend people aiming for at least a couple years of cash-like savings. Yes, it's hard, but it's easier than in many other professions.

Have gone through spells of no income (job loss, etc) and doing it with no savings vs savings is... far less stressful. And the sun rises in the east - Capt Obvious here. With a tightened, budget, we've got a burn rate of around $3k/month. Loose budget, might be $4k/month. At this rate, we've got probably 2-3 years of cash to weather some 'no income' time period. There's still some stress and other emotions come up without 'real income' coming in, but nothing like going slowly in to debt while not seeing any way out.

Glad you got another job, and hopefully you're getting out of debt again, and ideally you can build a larger safety net for the future.

re: "undocumented". I bought whatever big oreilly book there was on it - "building XUL apps" or similar (https://www.oreilly.com/library/view/creating-applications-w...) it was impossible to follow. Granted, some new-to-me concepts and such in there, but after having respected colleagues try to work through the book with me, and they also gave up, I had to conclude this was not something worth pursuing. I mean no explicit disrespect to the authors; any book is a big effort, and the publisher sometimes overrides decisions or releases something too early. In any event, I vacillate between 'what a big missed opportunity' and 'we all dodged a massive bullet there' - I still can't decide which.

A repeating issue I'll face when trying to 'juice' a bit is... mobile vs desktop.

That 'project management setup' animation is a good example. That is kind slick - definitely useful, and I've found myself coming up with things like that over time. It's not trivial, and takes some time. Then... "but it doesn't work on mobile!". You end up needing to build an entirely different "experience" for mobile users. Or... say "no support for mobile" (and possibly disable it in some sense?) Or let people live with a really bad shrunk down experience.

I know it's all about setting expectations and such, but it's still annoying. The types of 'juice' you'd introduce are going to be somewhat device and screen-size dependent.

Around ~15 years ago ios as a platform became a big thing. It's what powers iphone, and you can write apps for it. You can only write those apps on mac hardware. There are hundreds of millions of ios devices in use, all using apps sold to ios users, developed by people running on macs.

> It's more buggy than Windows, it has the same malware problem as Windows, it's spy- & adware as Windows, it's inflexible,

Citations needed please.

Yes, you can get malware on a mac. That's always been a potential, but malware problems on mac have never come anywhere near the scale of malware-on-windows. Not even close.

> The usability of macOS is even worse than Windows, imho. Still it's very popular.

So what we can conclude is that your 'ho' aren't very popular(?). So what?

That can't be it. It must be that hundreds of millions of people are 'brainwashed'.

I got tired of various windows laptops and every linux distro failing to 'sleep' properly when I closed a laptop lid. I got tired of not being able to have 2 apps both play sound at the same time under linux. Oh shit - pulse? jack? alsa? Oh - you chose the wrong version of the wrong distro - recompile your kernel to make that work right - just copy these 87 lines from a linux forum and paste (as root!) in your console and reboot - just be thankful you're not being 'insecure' like Windows.

"But none of those are problems now! You did it wrong! My mate Paul said it's always worked!"

I moved away from daily Linux-as-desktop in... 2008, because I'd spent a good 6 years on various laptops/hardware/etc trying to 'make it work right', and whenever something didn't work, it was always somehow my own fault for lacking some 'easy' piece of info - if I just keep searching/researching/testing - this time it will be better/fixed/good.

I lost a weekend in 2008 trying to get a new laptop set up. Video worked, but could not connect to an external projector. Hours later, eventually connected, but only mirrored, not two separate screens.

This was a days after I'd been assured "oh no... yeah, I know you've mentioned problems before, but these days, it's all just fine - I never have any problems with my linux/laptop!"

I decided ... 6-7 years of chasing/learning/compiling various options was more than enough.

Forgive me if I'm skeptical after many years of hearing "it works great!" and continually hitting walls where no one could ever help. Then... moving to a platform where... you close the lid, it sleeps. You plug in a monitor, it works. Plug in a printer, it works. Plug in a camera, it works. And then... being told somehow that all that end-user experience is somehow subpar to Linux... just doesn't ring true.

I do daily use Linux servers. And I've been tempted to give desktop linux another spin 15 years later. I have family running daily Linux/desktop/laptop - it's mostly working for them, but I still hear about weird issues I've not had to face in years.

If/when I find myself with a lot of free time, I might give it another spin, but... I'm in no rush.

Colleague of mine working in small company. New 'CTO' hired last year. He's very much of the "everyone's voice deserves to be heard... all input is valid!"

My colleague has 22 years of engineering experience across a wide range of problem spaces and industries and team sizes (large bigco to mom/pop orgs).

Another guy (X) started was a year out of high school.

X insists that 'tech XYZ' is the best. Current tech stack was partially rebuilt by my colleague, but wasn't finished (because... lots of reasons, mostly resourcing).

XYZ is not only not a great fit, but the ecosystem supporting the problem space is small, especially considering what's already in place. Terabytes and years of data need to be migrated (both physically to new data centers and code-wise - new structure handling has to be added to accommodate current and future needs).

In planning meetings, "all voices need to be heard"... so X pushes XYZ a lot. And randomly rebuilds small bits in XYZ. And when it doesn't work - blames everything else (it's the network, it's the supporting libraries, it's ...).

The CTO will not push back. "That sounds great! That sounds like it'll solve all our issues!". There's a criminal deficiency in the understanding of the current tech stack or problems, along with no experience in migrating anything. But any criticism is taken as "we need to be more inclusive and let more people speak up - some of the best ideas can come from people who've not traditionally been heard".

Up to a point, that can make sense. But when do you draw the line? 3 months? 6 months? 18 months? People insisting on promoting child-like understandings of problems and solutions - while not ever delivering anything resembling a working solution - at some point should not be listened to.

Why does my colleague stay? He's only part time right now, and was close to leaving, but there's been some shift to refocus the CTO on something else, which may - over the next month or so - leave the few competent people there alone enough to get things back on track. I think if this was a 'full time' gig for him, he'd have left already.

> see that you watched donkey midget porn once, and can blackmail you with that data

or perhaps we'll just somehow move beyond caring about that sort of stuff? if PH (for example) is hosting it, there's some level of 'legality' they want to adhere to (to stay in business). Something is patently illegal, they'll take it down. So if I'm watching something there... it may be offensive to some, but not illegal.

As a general rule, I really don't care what sort of porn or sports or movies or music a politician consumes. I already have an idea of their governing philosophy based on party affiliation, public statements, voting records. It MIGHT be a problem for people who would be exposed as hypocrites but... even that doesn't seem to have an impact any more - people just double down on party loyalty? Someone voting to remove LGBTQ protections, somehow 'caught' watching lesbian porn... Yawn. That's par for the course now.

How does this work in the context of 'private' mode? This is something I assume a lot of folks would use for adult content. Do they have to verify each time? I've no doubt some people make accounts and stay 'logged in' to PH and similar sites, but I suspect a much larger set of folks browse in private mode without an account.

The 'large PR' issue - I've been on the 'violating' end of that, but... there are actually times when a PR touching a lot of files and making changes is called for. I got push back at the last team I was on where this was an issue, and the stated thing was "it's hard to review".

Yet... no one ever - literally - pulled down code in a PR/branch and reviewed it locally, never reviewed any tests (in 2 years I never got one question about a test as in 'you missed use case X in your tests', etc). They literally just meant "reviewing this on the screen in the github UI is hard when there's more than a handful of files - it's hard to tell where the changes are or what they effect". This is why I would also have tests and (sometimes extensive) documentation in the PR, to help a review. Never happened.

I had "large" PRs (by someone else's labelling) about 10-15% of the time. I would get pushback - "this is too much - it's too confusing".

Me: "OK... let's schedule some time to review - maybe you can help me cut it back some, or you can assist me in some way in this work?".

Others: "don't have any time for that - this is just too much work".

OK, so... complain about the work, but when I ask for help to conform to your standards... I get a refusal.

I point blank asked multiple times when this was lodged as feedback - "what steps could I take to have made this smaller?"

The only substantive thing that would have made it somewhat easier to roll out some of these "larger" changes in smaller chunks would be to have had a more comprehensive feature-flag system in place.

I put a basic flag system in over a weekend - some server side, and some hacky method to respect the flags in client side code as well. It was done over about 3 hours, and was never improved. Again - very hacky. I had an "improvement" ticket in for... about a year, begging for more than a few hours to devote to tightening up "feature flag" system to be a bit more comprehensive, documented, etc.

Every "sprint planning meeting" it was the same "there's no time for that, it's not that important, quarterly deadlines, blah blah blah". But if/when I'd do things that were 'unticketed', that was met with accusations of being passive/aggressive, or being subversive, or 'not a team player'. "If you've got time to do that, you could have been helping out people who were behind". The same people who didn't write tests or documentation, and refused to meet with me when I asked for assistance in trying to accommodate their calls for "smaller PRs".

First year on the project was good, but as it grew, policy/procedure/scrum/agile got in the way, with more process and less ability to get useful stuff done. Second year was far less productive (at least, compared to what it could have been - I'm sure some people just saw forward progress as 'good', but we were greatly slowed by more process and ceremony over time).

I've been in situations as a dev where I've figuratively screamed from the rafters "X is happening - we need to do ABC". It's almost universally ignored because "well, devs just like to do ABC! not happening this year... etc".

No... I hate doing ABC.

What's in my immediate interest is to quietly paper over problems, and pass them along to someone else.

What's also in my interest longer term is the organization to fix operational issues to help ensure there is a 'longer term' for the organization to continue in to. To think I'm not thinking of that, and just wanting to do bullshit busy work because "he's a dev! that's what they do!" is patronizing to say the least.

Many people are capable of looking at things from a few perspectives.

The people who make the decisions don't use the product. That's almost always the root cause of this stuff. I worked on a system for my state - another vendor came in and 'took over' all the functionality my system handled. Supposedly. 7 years later, my system powers the exception to the mandate to 'use system X', because... they refuse to provide the functionality that they sold the state. Contractually, "we provide feature ABC", but the reality is.. they don't. I even provided them our code to use - it was paid for with public money, they should just integrate it and then sell it to other people to make their product better. They can't even be bothered to take the code and integrate it... they prefer to continually lie and say "we provide feature ABC" when... they don't. It's beyond insane. A large majority of the people on the ground know it's bad/lacking/broken, but ... they have 0 voice in the matter.

I feel the same about PHP. It's easy to scale up, and can scale down to small CLI scripts (but can include any utility libraries you need as well).

What 'has' been proven then? No comments or docs? Long variable and method names?

I just had a semi-interview the other day, and was talking with someone about the docs and testing stuff I've done in the past. One of the biggest 'lessons' I picked up, after having adopted doc/testing as "part of the process" was... test/doc hygiene. It wasn't always that stuff was 'out of date', but even just realizing that "hey, we don't use XYZ anymore - let's remove it and the tests", or "let's spend some time revisiting the docs and tests and cull or consolidate stuff now that we know about the problem". Test optimization, or doc optimization, perhaps. It was always something I had to fight for time for, or... 'sneak' it in to commits. Someone reviewing would inevitably question a PR with "why are you changing all this unrelated stuff - the ticket says FOO, not FOO and BAR and BAZ".

Getting 'permission' to keep tests and docs current/relevant was, itself, somewhat of a challenge. It was exacerbated by people who themselves weren't writing tests or code, meaning more 'drift' was introduced between existing code/tests and reality. But blocking someone's PR because it had no tests or docs was "being negative", but blocking my PR because I included 'unnecessary doc changes' was somehow valid.

Maybe he's not a citizen or has whatever national insurance? I had a family member (US citizen) have to pay for hospitalization in belgium. On checking out the staff were apologetic. "This is going to be expensive...". It was somewhere around a few hundred USD for him being in for ... 3-4 days, IIRC. It was insanely nothing. "Maybe you can contact your employer for reimbursement" he was told a couple of times.

not even necessarily CEOs... just the phrase "taking responsibility" seems to have been diluted to usually mean nothing in most corporate settings.

software dev here - was working with a client, and a pm was pushing some not-great idea. I pushed back - "this is not core, not important, shouldn't be a focus, other things are more important, and already decided".

Pushback from them: "no no no, this is vital. Look... if there's a problem, I'll take responsbility".

6 months later, there's a lot of complications that I'd foreseen (and documented) earlier which were summarily ignored at the time. The "I'll take responsibility" person isn't on the project any more - they left. I'm fielding a bunch of "why was this done? this wasn't agreed on - what were you thinking?"

Well... when I don't do what they ask for, I'm stubborn/obstinate/roadblocking/etc. When I do it... it's wrong. Even if that original person was still around, I would be the one fixing all the bad data, having to reverse out the changes, revert to earlier state while keeping newer code in place. The "I'll take responsibility" is essentially meaningless in many situations. And I called that out too at the time and was told I'm too negative/cynical. It's just experience.

Lest this be seem like doom and gloom, I've experienced the opposite situation from above, where 'ownership' and 'responsibility' and whatnot were more enforced and honored across an organization, but it's been very rare in my experience over the last 20 years, and seems to be getting even less common. Having seen both situations, it's easier to tell the difference.

More and more folks having shorter tenures makes it harder for any org/team ethos to 'stick' for any meaningful impact, and absent that, it takes a lot more organizational effort to keep a commitment to stated corporate values. Not impossible, just hard to do, and often slips...

My overarching experience with 'agile story points' (paraphrased combination between multiple teams/projects).

"If it's not a 3, then it might be a 5. But if it's not a 5, that would mean it's an 8, and we can't have 8s. 8s are too much. You have to break it down more".

"What is 'too much'?"

"That's too many days of work".

"But I thought points weren't an estimate of time/hours/days, just a level of effort or complexity.".

"8s are too big"

"But... 8 is the best notion at this point. It's a complex problem. Maybe after working through the ticket, a natural break point will present itself and we can chunk it and make a second ticket with follow on work later. But right now, I can't see any split point".

"Well... you have to break it down first. Make this in to multiple tickets. The sprint starts tomorrow and we can't have 8s".