Live data from Hacker News

Ask HN: What was your most humbling learning moment?

news.ycombinator.com

391–400 of 704 posts

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

#391
post #79

I’m learning swing dancing. It’s been humbling. It’s humbling because all my life, I’ve been really good at technology - I specialize in biotechnology and manipulating DNA, but am also fluent in programming (mainly python, go, lua) and am able to build hardware - even helped run a robotics startup for a while. Anything related to technology and science comes easily and naturally to me. This isn’t to brag, but just a…

I tried to learn to dance (hated it). It is a bit of a weird thing though, there as social events where people feel like it is OK to really try and pressure people into dancing. It is really annoying.

incase you want to give it another shot sometime, teaching your self via youtube/other platforms like steezy.co is a viable option if you want to go at your own pace w/o peer pressure.

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

#392
Early 90s, I had to teach a class to psych undergrads, and I got neural networks. The book had already been decided: Rumelhart and Mclelland's PDP. There was software, we had a computer lab, everything was set.

For the first class, I had prepared a bit of an overview, starting with the perceptron, and then showed Minksy and Papert's proof that it could only learn a linearly separable membership function. So I had these formulas on the blackboard, ending with something like "for every delta > 0 there's an epsilon such that ..." etc. Then before the break, I ask if anybody has questions. One person raises their hand and says: What's a vector?

That was a bit of shock. I had completely not understood the knowledge level of my students. Not that I ever became a good teacher, but that was an eye-opener.

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

#393
post #374
post #292

Earlier quoted context omitted.

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.

The problem in software is that very frequently you dont have a real hammer. You have hundred amalgamations of swiss army knives that do everything. Like what is the hammer when you want to add some nice dynamic content to a website? Is it just javascript or maybe react?, Angular?, Svelte? Or another example: you want to code a command line app, what language is a hammer here?: C++?, Go?, Bash?, Python? This analogy…

Well, the engineer first move should be "do we really need this dynamic to achieve the global goal, or can we do without"?

Most of the time however stakeholders will prefer that someone unleash the last technical shiny tech stack (that no one master in the team and that is about to be dethroned by the even newest thing) to deliver a pixel perfect reproduction of the mock-up rather than question the relevance of the proposal.

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

#396

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.

But other branches of engineering are also about doing a lot of repetitive work, exactly what "programmers" do.

Engineers shouldn't compromise on things like safety, security, legislation, budget, properly documenting, properly communicating with others, etc. Same as anyone working professionally with code should, no matter the title.

But there's nothing that says that engineers should only be doing groundbreaking or interesting work.

The "artist" analogy works much better.

EDIT: Perhaps the main difference is what psychoslave mentions below – engineers are expected to question the relevance and necessity of requirements, and work together with business, rather than just doing as asked.

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

#397
Er. The fact that I don’t realize that there could be a wrong way to lower and raise window blinds tells me that I may be doing it wrong too! Would you mind sharing what you did wrongly?

For my part: I think I learnt at age 35 the difference between sneezing and coughing. Duh!

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

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

So much this. But there is a fine line somewhere in there. I have seen and admittedly worked on such projects where time constraints simply do not allow you to polish all bits and pieces. That's perfectly reasonable during POC/early development stages and if anything, I encourage it: Writing hundreds of tests when all requirements change three times a day is incredibly counter-productive, slow you down and eventually burn you out. It may happen that crappy is much better than shiny, polished and over complicated if the project itself is not going to scale any further than it already has. And once you get a more complete picture of what the end goals are, then you can go back and gradually start doing things "the right way". But I've also been in another extreme. Take my old job for instance, which despite my at the time cognitive dissonance, I hated to a large degree because of this: relatively early stage with ever-changing requirements, endless dependencies, brutally unstable setup for development where deploying a single pod in minikube was a terrifying prospect because everything was hanging by a thread and rebuilding the cluster took hours. That was made even worse by dozens of forked open source projects that were patched left and right to fit the needs, lagging years behind the original projects, wild dependencies between repos, no real observability over what was going on, the version control was catastrophically packed with auto-generated code(like 80% or more) which was made worse by the fact that everything was git push --force so they don't have to deal with conflicts. Imagine having to explain that this practice should be avoided in nearly all cases. In a nutshell imagine crappy code and infrastructure which pretends to be and is sold as an enterprise grade software. I guess cognitive dissonance was a common theme in the company since everyone was under the impression that everything is perfect. Which couldn't have been further from the truth.

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

#399

When I was younger, I had an issue with external vs internal validation. Sadly, it heavily skewed towards external validation. I was on the chunkier side for a lot of my childhood and into high school. Joined wrestling and stayed with it. Lot the weight, grew, and gained muscle. Also started to get a lot of attention from the opposite sex. That, with the external validation issue, leaned into it and just had fun. It…

> “you’re not going to change until the pain of change is less than the pain of staying the same.”

A thought I have had in the past also, I think it is very true.

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

#400

Earlier quoted context omitted.

It's cliche, but I really do feel reading the Art of Unix Programming gave me a very good sense early on for how to walk this line carefully. Unix programs are high quality - but they're also, ideally, small , and written with an eye to compositionality with the rest of the ecosystem. The best architecture is in the middle, and often the best first draft is a simple series of pipes. https://www.catb.org/~esr/writings…

(Honest question) What is the difference between this microservice architecture that gets a lot of hate here?

My take:

Unix utilities are stand alone and used as needed for specific tasks. They hardly change much, have no data persistence, usually no config persistence other than runtime params, and don't know about or call each other directly.

Microservices are moving parts in a complex evolving machine with a higher purpose that can and do affect each other.

Post reply on HN