[javajosh]

Three things: voting down a move to microservices, identifying a fundamental flaw in a core data-structure that is the high-level impetus for future refactorings, and encouraging people to be discontent with multi-minute long build-test-debug (BTD) loop.

Unfortunately, I find very long BTD loops to be personally offensive though, to the point it makes me emotional, which harms my ability to make my case. Despite knowing this, it's almost impossible to stop it from coloring my arguments. I fear that I have such a large amount of contempt for those who don't share my view on this that it leaks out whatever I do. I even know, intellectually, that this is wrong - ignorance does not deserve contempt, but compassion, after all. But my traitor heart doesn't want to listen. :(

[np_tedious]

> it makes me emotional, which harms my ability to make my case.

I don't know how true / substantial this effect is, obviously. Nonetheless, seems like good self awareness shown in this comment. That's more than a lot of people can say

[javajosh]

Thanks, but undeserved. Self-awareness may be good eventually, but sometimes it just makes you feel like a helpless observer to your own actions. I think you need more than just awareness - you need to practice feeling the feelings and not acting on them in the usual way. That's the part that will yield results, I hope.

Alternatively, I'd like to work for an organization that's on the same page here. Effectiveness in software (or anything that depends on iterating on a design) relies more on a fast loop than anything; I'm tired of fighting this battle.

[alvarosevilla95]

Awareness may not be sufficient, but it's most definitely necessary. You at least recognized a problem, and want to find a solution, even if you haven't found one yet or even tried.

[vsareto]

>I fear that I have such a large amount of contempt for those who don't share my view on this that it leaks out whatever I do. I even know, intellectually, that this is wrong - ignorance does not deserve contempt, but compassion, after all.

It can be annoying, but at the same time, it forces them to take a break to think about things they're currently working on. When you have nothing to think about and your current work is simple and you're waiting minutes, you tend to get bored and frustrated though.

And also remember that some people would simply rather get paid to do nothing, and a long BTD cycle helps that.

[tayo42]

Idk if it forces someone to take a break. If I get forced into a long compile. Maybe even 30 seconds I might pull out my phone and 5 minutes later.. Oh its done..

[_TwoFinger]

> I find very long BTD loops to be personally offensive though

Encountering these in my very first programming job made me learn make(1).

The thing is, I'm not very bright and my work "style" involves a fair share of trial and error. Obviously, all this waiting prevented me from doing my thing, so I eventually rewrote the whole build system just so I can do more trial-and-error.

I've always considered my dependency on a fast BTD loop a weakness, though. I guess the majority of developers can just imagine what the code does in their head and only make the changes when they know what they're doing.

[celticmusic]

it's not a weakness, it's productive. Anyone writing a lot of code without testing it is doing things in a subpar manner. This isn't about intelligence.

[Cyph0n]

> multi-minute long build-test-debug loop

You should try writing software for SP routers :)

[nojvek]

I feel you. First thing I do is setup some form of hot reloading. In my last workplace we want from half a minute to <5 seconds of dev loop iteration. It’s a night/day difference.

[insomniacity]

I'd be interested to hear more voting down microservices. The title didn't actually specify, but I assume you felt it had a positive impact? :)

When was this, and how does it look now?

[javajosh]

Yes, I felt it had a positive impact. The system was already over-engineered for its purpose, something virtually every senior would admit if pressed. uServices would only add to that administrative overhead at design time, and massive operational complexity at runtime.

Having come off of a project that supported 400k registered and 100k active users on a single server, this project isn't yet at that scale and they were anticipating massive scale issues. This mistake was a real bonanza for an engineering team wanting to learn the latest tech; a massive failure for the product that really needs fast UX iterations to succeed.

If you want to talk more about it, you can email me.

[bcrosby95]

And if you design your monolith carefully enough you might be able to horizontally scale too.

Back in the late 00s we horizontally scaled a monolithic project with 5mil daily users and another 8mil daily users. Peak was 10k and 15k requests/sec of dynamic per-user webpages.

The hardest part was the databases. Our solution was standard for the time but pretty ugly nowadays: sharding MySQL by user id along with heavy use of memcached.

Would have killed for some of the modern scalable databases. Sometimes I wonder if some people using microservices are chasing challenges since much of the actually necessary hard parts are already figured out.

[maest]

What are your main objections to BTD loops? Also, which alternatives do you suggest?

[javajosh]

Software development is the BTD loop; you can't eliminate it. I got my start with Logo[1], which has an amazing BTD loop! People like Bret Victor[2] have talked at length about it (although Victor doesn't use that term, IIRC). Even the trend toward "notebook programming" - Jupyter, Observable, etc are really about shortening that loop. A major reason to use an IDE is to potentially shorten the BTD loop. Lots and lots of tools exist specifically to shorten this loop.

And yet some organizations want to run all the linters, all the tests, for all the languages, orchestrated by Jenkins on a huge Amazon cluster. This is bad.

[1] This is very cool - an Apple IIe emulator running Logo in the browser. https://www.scullinsteel.com/apple2/#logo

[2] Inventing on Principle has improving the BTD loop at its core https://vimeo.com/36579366

[Aperocky]

Well, I don't see how linters/test on a final cluster is bad. This is why we have unit/integration/alpha/canary tests. The first 1 can happen on my laptop over 5 seconds while the second can happen on my personal instance over 20 minutes. Usually first means the second will pass and I just need to run it in the background without breaking any workflows.

i.e. It might not be a bad feedback loop, you just need more of them that are faster.

[celticmusic]

5 seconds is already painful, the point of the other poster is to delay that stuff until the end. When the BTD loop is long it's a looooooot harder to get into the flow, and you have difficult really thinking about the problem.

Imagine trying to read a novel but after every paragraph you had to stop and wait for 5-10 seconds.

[steev]

My main objection is it dramatically decreases your productivity. If building and testing takes 5-10mins (which is the case in our codebase) trying to fix a bug can take forever when you aren't exactly sure what the cause is. You don't want to try multiple fixes simultaneously because if something doesn't work you aren't sure which of the fixes (if any) might be causing the issue.

Maybe a different way to look at it is: if you could shorten the BTD loop to a minute or two, why _wouldn't_ you want that?

[Aeolun]

I would have less time to legitimately read Hackernews!

[hoten]

My first job, the BTD loop was at least an hour. This was 2015.

[MereInterest]

Not OP, but I share the same dislike. Note that he said that he is against long BTD loops, not BTD loops in general. If it takes more than 5 minutes to get more information about a problem, my mind will wander. I'll check email, read up on conference proceedings, etc. If it takes 15 seconds to get more information, then I can keep focus on the current problem, add the new information, and iterate appropriately.

[celticmusic]

> and encouraging people to be discontent with multi-minute long build-test-debug (BTD) loop.

The ole eyebrow started twitching when I read this. I once had a 6 month contract with a RoR shop where they had such bad performance issues they started developing in production mode so it wouldn't reload everything constantly. This allowed you to make some changes quickly, but 90% of everything required you to restart the web server and it literally took minutes for it to load everything. They had close to 200 rubygems, and I've always guessed that was the core of the issue.

When I suggested we need to fix that issue, the senior did-an-internship-here-last-summer developer got extremely passive aggressive with me (I didn't renew that contract). This guy thought he was amazing, I remember him arguing with me about a bug where they were storing decimal numbers as float in MySQL. I seriously had a 30 minute long conversation where he told me repeatedly I was wrong until I finally got exasperated, made the changes, and it fixed the bug. The guy was couldn't believe it fixed the issue and spent another couple of hours looking for why I was wrong.

I've never touched RoR again, that experience was horrific.

Sometimes you can't help the slowness, but I know I seriously dislike header-only libraries in C++ specifically because of their effect on the BTD loop. I have no idea how people can tolerate working like that, it's a slow hell for me.