Live data from Hacker News

Ask HN: What was your most humbling learning moment?

news.ycombinator.com

351–360 of 704 posts

Re: Ask HN: What was your most humbling learning moment?

#351
post #78

In college, meeting someone that was better than me by every conceivable metric. You'd think that he beat me at one thing by neglecting another, but nope, the guy was excelling in every category. Perfect grades, involved in many communities, and generally pleasant to be around. There was no caveat, no excuse. Dude just straight up rocked. I have met more people like that while travelling. I felt badass riding my moto…

But why does it have to be a competition, of thinking "I have to be the best at X, if someone else is better, I feel unworthy.". I ask rhetorically, that sentence probably describes me more than my impression of you from 3 paragraphs.

I identify by the things I love and excel at. If being an artist is a big chunk of who you are, it can hurt your ego to meet q much better artist who is also good at many other things.

Imagine playing the bongos, and you meet some guy who plays it really well… and it’s Richard Feynman.

Re: Ask HN: What was your most humbling learning moment?

#352
post #83

Learning that some folks can produce so much value with crappy code. I've seen entire teams burn so much money by overcomplicating projects. Bikesheding about how to implement DDD, Hexagonal Architecture, design patterns, complex queues that would maybe one day be required if the company scaled 1000x, unnecessary eventual consistency that required so much machinery and man hours to keep data integrity under control.…

I had a colleague who was old school and loved optimising, everything he reviewed come back with tiny changes that would save fractions of a ms. His nemesis was a guy who was arguably the best coder I have ever worked with. Things come to a head in one meeting and old school said if we did things his way our code would run quicker and the response was legendary 'If we coded like you it'd run quicker because most of t…

'Optimising' for simplicity would often be a good idea, though.

Optimising for speed of execution only matters some times.

Re: Ask HN: What was your most humbling learning moment?

#353
post #83

Learning that some folks can produce so much value with crappy code. I've seen entire teams burn so much money by overcomplicating projects. Bikesheding about how to implement DDD, Hexagonal Architecture, design patterns, complex queues that would maybe one day be required if the company scaled 1000x, unnecessary eventual consistency that required so much machinery and man hours to keep data integrity under control.…

I don't remember where I saw this quote, but... "It's okay to half-ass something, when all you need is half an ass". EDIT: Totally agree about the 'important mindest for startup', I had a similar eye-opening experience, working in a startup with 'cowboy' code that was actually quite good, but I had to unlearn a bit of stuff I read as a junior/mid-level developper. It was code that was well-architected, had well-conci…

or "If it's worth doing, it's worth doing badly."

Meaning that e.g. if you really need a ride, then a noisy, beat up old car will do.

Re: Ask HN: What was your most humbling learning moment?

#354
post #83

Learning that some folks can produce so much value with crappy code. I've seen entire teams burn so much money by overcomplicating projects. Bikesheding about how to implement DDD, Hexagonal Architecture, design patterns, complex queues that would maybe one day be required if the company scaled 1000x, unnecessary eventual consistency that required so much machinery and man hours to keep data integrity under control.…

I can totally understand the move fast and break things mentality, but I'd like to stress it's equally important to pay back the occurring tech debts. I am working on a massive spring monolith that's somewhat of a huge pile of spaghetti, and when the higher management decided to enforce code quality in the pipeline, it became a living hell to work on. I can't even add a logger without having to refactor the whole 200…

I've come to the conclusion that you can't architect yourself out of this.

What you might do is write tests early, so at least you have integrated a test rig to build on if the system actually gets any use.

Most of the work on mature systems is like this, rewriting and refactoring stuff. If it is very concrete, non-abstract, it's generally easier to work with in this phase than if it was cleverly and abstractly architected. Even if it's a big spaghett.

Re: Ask HN: What was your most humbling learning moment?

#355

Earlier quoted context omitted.

I don't remember where I saw this quote, but... "It's okay to half-ass something, when all you need is half an ass". EDIT: Totally agree about the 'important mindest for startup', I had a similar eye-opening experience, working in a startup with 'cowboy' code that was actually quite good, but I had to unlearn a bit of stuff I read as a junior/mid-level developper. It was code that was well-architected, had well-conci…

Most scenarios only warrant fractional assing. Also this philosophy provides the opportunity to say “ok guys, this time… we have to whole ass this one,” which is always fun.

Some times you might even have to bring two whole donkeys to bear on a project.

Re: Ask HN: What was your most humbling learning moment?

#356
post #83

Learning that some folks can produce so much value with crappy code. I've seen entire teams burn so much money by overcomplicating projects. Bikesheding about how to implement DDD, Hexagonal Architecture, design patterns, complex queues that would maybe one day be required if the company scaled 1000x, unnecessary eventual consistency that required so much machinery and man hours to keep data integrity under control.…

This is a false dichotomy. On one end, you have "overarchitects everything so much that the code is soon unmaintainable" and on the other end you have "architects the code so little that the code is soon unmaintainable". Always write the simplest thing you can, but no simpler. Finding that line is where all the art is.

> Always write the simplest thing you can, but no simpler. Finding that line is where all the art is.

As much as I love simplicity, optimising for peak simplicity isn't always a good use of your time.

Simple enough is often good enough.

Re: Ask HN: What was your most humbling learning moment?

#357
My boss and I had written a distributed transaction manager. Of all the components of our product, this was considered the lynchpin of reliable enterprise software.

The day came when we had to present it at a very well attended product launch. He and I took turns making different points. Then he announced to the crowd that he had a surprise for me (and turns out, to the entire company), that he had changed the configuration to write the transaction log to a removable drive. Then, in the middle of the demo he proceeded to pop the drive. Our careful demo script had got Putin'd. I went numb, our marketing manager nearly had a coronary.

He then announced that if it were indeed enterprise quality, the system should recover once the disk is put back in again. It freakin' did; the system worked!! He got a laugh out of the crowd that if it survives a demo it would survive failures in production, esp. when one goes off-script. He said that we had spent months and months in careful design and implementation and we have no business writing the word 'reliable' in our marketing literature if we didn't believe it in our core. The crowd lapped it up.

It was a huge humbling and learning moment for me. Although I was the primary implementor of that system, I didn't nearly have enough faith in it as he did. In one instant, I realized all the practices he'd been drilling into our team from the first day, the insistence on creating elaborate mock frameworks to induce faults, embracing the idea that if something could go wrong, it will. I realized that if you are surprised that the system works, you haven't reflected on that doubt enough. He would light up like a child when we encountered a real bug, and he'd follow it up with a session of reflection on why it escaped our attention in the first place. That session would result in a raft of new tests.

Rest in peace, Ed Felt, my friend, mentor and guide. Taken too soon (United flight 91, alas).

Re: Ask HN: What was your most humbling learning moment?

#358
A while back I came across this self-directed question:

"How have I been complicit in creating the conditions I say I don’t want?"

(from Jerry Colonna, according to The Internet).

For me, it has been a sporadic but powerful concept that often sits me on my ass, especially when I find myself feeling ungrateful or put upon.

I was already very familiar with Stoicism which has similar lessons. So not only did I discover that I was responsible for my own situation, I also had the humbling realization that I hadn't actually grasped the lessons I thought I had.

Re: Ask HN: What was your most humbling learning moment?

#359

I consider myself fairly literate and a decent communicator. Until recently I pronounced ‘segue’ how it is spelled. No one ever corrected me. I shudder to think about the meetings where I pronounced it incorrectly.

Mine was 'bourgeois' (amongst many others, but that one stands out).

Re: Ask HN: What was your most humbling learning moment?

#360
post #173
post #83

Learning that some folks can produce so much value with crappy code. I've seen entire teams burn so much money by overcomplicating projects. Bikesheding about how to implement DDD, Hexagonal Architecture, design patterns, complex queues that would maybe one day be required if the company scaled 1000x, unnecessary eventual consistency that required so much machinery and man hours to keep data integrity under control.…

There's a discrepancy that the top comments here say that "some people can produce a ton of value by not caring about code quality" and "I didn't care about code quality and got bit later on". And people discuss that incurring technical debt with bad code can sometimes be worth it and sometimes not be worth it. The logical implication of technical debt having an interest rate (i.e. It costs more to fix something late…

Btw, if you like the financial metaphor, then technical debt is a bit of a misnomer. 'Technical debt' behaves a lot more like equity you sold than like debt you issued.

In the sense that the 'technical debt' is only something to worry about in the future, if your project goes anywhere. But if no-one ever uses your product, you don't need to fix the 'technical debt'.

Post reply on HN