Live data from Hacker News

Ask HN: What was your most humbling learning moment?

news.ycombinator.com

291–300 of 704 posts

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

#291

I lived in Pamplona, Spain for a year, back before my Spanish was particularly good. It was a pretty amazing place, with all its narrow cobbled alleys and small shops. They had a particular style of bread in a few of the shops, kind of a rustic baguette with pointy ends, that I never could find the name of. I'd always have to point and say "that one", which always felt awkward. Worse, my Spanish wasn't yet good enoug…

Hola querido. The Spanish word for bread is Pan, not Pain. Pain is French :)

Moved to France (possible out of shame) so that probably explains it. That’s what my Spanish sounds like these days.

(Fixed)

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

#292

Earlier quoted context omitted.

As a good friend of mine often says: We work in a field of people who envision themselves as artists, when all that is wanted are painters.

No one wants to be a "programmer." They'd rather be called "engineers." With none of the licensure, mandatory education, and so forth. But the world needs programmers and technicians for most of the work we have to do. I do comparably little "engineering" and the little I have done that qualifies for such a statement I recall. Majority of the work is programming and technician work. Nothing wrong with that.

I call myself an engineer- but the way I understand it is that I still have to know when to use a hammer like simply copy paste code and not some complex solution.

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

#293

Meeting less competent people be extremely successful in life compare to the more competent folks. Through my life, I have seen people less curious, less innovative, no passion to learn, not interested in working hard, but are good at gaming the system excel and succeed. They become rich, financially independent, have great success. While people much smarter than me, more curious and innovative fail again and again t…

Interesting, around me, smart people succeed and not-so-smart succeed less.

The smart ones sometimes choose metrics for success that aren't traditionally valued. (Ie. not rich and financially independent like you mentioned. But boy do the smart ones succeed!)

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

#294

When I was working in a queue feature (for example to buy tailor swift ticket), and was proud of my complicated real-time solution using websockets and CRDTs...then a more experienced guy came, rearchitected in a much simpler way using just the DB with long-polling, not real real-time (but who cares), and it ended up simpler to deal with network splits or crashes. Learned the hard way you can never rely on the networ…

People often forget that you have to poll to handle lost network connections, IP changes, etc., so there isn't always a real-world win to web sockets.

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

#295

Earlier quoted context omitted.

No one wants to be a "programmer." They'd rather be called "engineers." With none of the licensure, mandatory education, and so forth. But the world needs programmers and technicians for most of the work we have to do. I do comparably little "engineering" and the little I have done that qualifies for such a statement I recall. Majority of the work is programming and technician work. Nothing wrong with that.

Actually I call myself a developer. I'm not that good of a programmer, but quite resourceful as a developer.

I've come to understand the difference between programmer and software engineer, but what's the difference between (software) developer and programmer?

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

#296
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.

I don't think so. Time and time again the client will insist on stuff like "the customer only needs a single email address/phone number" but you're going to pay for that one later if you do the simple thing and add an "email" column.

Same for addresses.

And a whole bunch of other stuff...you need to normalize the heck out of your DB early on, even if you don't need it now. The code you can mostly make a mess of, just choose a good tech stack.

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

#297
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.…

Exactly this - I've a colleague who just fell into "solution mode" and started whiteboarding a LLM framework he could fine-tune with RAG and some 3rd party vector database. It's six months later and there's still nothing working or even a deliverable schedule.

Compare this to another colleague, with an almost exactly similar use case, who just downloaded an open-source LLM, wrote some glue code and set it loose in production. It's not pretty but it (mostly) gets the job done.

As the old addage goes "Perfect is the enemy of good".

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

#298
post #173

Earlier quoted context omitted.

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…

I agree with this analysis. Another important factor is: How likely will this code actually be used and drive business value? If very likely, then you should invest in making the code high-quality. If unlikely, then you should half-ass the code strategically

I've declared quality bankruptcy. Decisions are now driven by user needs. Did I half-ass that feature? Yes. Is anyone actually using it despite crying it's essential? No. Then it's not getting cleaned up. Are they not using it because it's shoddy? I guess we'll never know.

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

#299
I've worked for some fairly large tech companies, building products customers more or less want. About 6 years ago, I convinced myself that I just need to build something, anything, and customers will come flowing in immediately.

So I scraped job boards and built my own that would "only" cost users $199 to post a job ad.

What I learned here is that your implementation is meaningless to the user if you're not delivering the value they came for. In this case, I wanted to take a technologically inferior product, make it extremely efficient, scalable and "blazing fast", and pocket pure profit from running a serverless job board (effectively free to run for the first million visits a month).

In total, the job board logged 761 sessions for 661 users in 2018.

One of many failures on my way to builing OnlineOrNot.

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

#300
post #173

Earlier quoted context omitted.

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…

I learned this lesson when working on very fast paced projects with way fewer developer resources than needed. to ship a feature on time, shortcuts in quality have to be made, but you learn to make the shortcuts in a way that are easier to go back and clean up later. I became very fond of #TODO ‘s.

My manager gave me gruff the other day for adding a TODO that I had no intention of ever doing. TODOs are like a get out of jail free card. Don't want to do something the reviewer is likely going to call out? Just add a TODO.
Post reply on HN