Ask HN: What was your most humbling learning moment?

[spcebar]

I've worked on large products for large and small companies and written tens of thousands of lines of code across my career, solving complex, abstract, challenging technical problems in a variety of languages on a variety of platforms, sometimes under difficult conditions. I have often been a resource for my friends and co-workers when they have programming or technical questions.

I only recently learned how to correctly raise and lower window blinds--I had been doing it wrong my entire life. It was maybe the dumbest I have ever felt, and was a humbling reminder of how much I don't know about how much I don't know.

Have you had similar experiences?

[hu3]

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. Some of these projects were so late in their deadlines that had to be cancelled.

And then I've seen one man projects copy pasting spaghetti code around like there's no tomorrow that had a working system within 1/10th of the budget.

Now I admire those who can just produce value without worrying too much about what's under the hood. Very important mindset for most startups. And a very humbling realization.

[jaydeegee]

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 the functionality would be still in the backlog.' I still think about that when it comes to optimisation.

[projectileboy]

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.

[mablopoule]

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-concieved data structure, and had business value, but every "professional" coder would deem bad-quality, since it had no unit test, did some stuff unconventionally, and probably would have many linter warning.

[stavros]

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.

[jjmarr]

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 later than now) is that like money, features have time value. This is what makes it worth it to incur technical debt.

Thinking about the implied interest rate of technical debt makes it easier to rank what should be prioritized for a fix. High interest debt should be paid off first. But you might also focus on refactors that reduce the interest rate, such as by modularizing your code so it's easier to replace down the line.

[bicx]

My way of planning and writing software shifted a good bit after I went from working at a mid-size tech company to working for myself. Suddenly I cared very much about how long it took to reach a functional product and very little about developing sophisticated architectures.

[surfingdino]

I can relate. I am now on a small team of half a dozen (2 front, two back, 2 devops). We've been smashing it for the last year, replaced a hodgepodge of systems with a configurable framework and a modular integration layer with third-party systems. As a reward our work the management are bringing in a consultancy we are supposed to train to replace us. That will be a very expensive and inefficient exercise. How do I know? Our small team was created to deliver what the previous consultancy could not do in 5+ years. That experience taught me once again that management in large organisations have no idea what they want to build, how to build it, how to maintain it, and that's where large consultancies come in, milk the client for all they can and leave a massive mess behind them.

[buffalobuffalo]

I think one of the most valuable lessons I have learned in software engineering is that you can write entire projects with the express plan of rewriting them if they actually gain traction. If I want to prototype something these days, I will often write code that, while not quite spaghetti, would definitely not pass a proper code review. It's actually kind of fun. Almost like a cheat day on a diet or something.

[lr4444lr]

I think the other replies miss an important part of your comment:

Some of these projects were so late in their deadlines that had to be canceled

Speed is really important a lot more often than devs like to acknowledge when a company is small and fighting for its life to get revenue, let alone become profitable, and the code debt is often worth it. Fixing the code debt itself doesn't need to be any more thorough than necessary either.

[sevnin]

I have to kind of ask, maybe it's the design comitee that instead produces the sphagetti in that case? They are trying to commit themselves into decisions without much knowledge about the problem they are solving. I understand this is the reality of business and so on but let's not imply that this is good software design. The basic operation of abstraction (as this vague magical thing which creates concepts) is something that has to have something to abstract from. When we do abstraction in a bubble, not informed by the problem - like the design comitee does. What we get is abstractions made from abstractions: foundation less non-sense. Maybe it's this spagetti monster, the rogue coder, the guy that actually tries to solve the problem - the real designer.

[Simon_ORourke]

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".

[spoiler]

Like with all things in life, one need to find balance within the two extremes you posted.

There's overcomplicated, there's too basic, and then there's simple.

I think it's fine adding just enough complexity and abstraction to make something malleable and manageable in the future

[boznz]

I am one of those people who wrote a production system controlling a million-dollar business fifteen years ago that is now controlling almost a billion-dollar production system today. The auditors are the main reason it is being changed, "single man risk" and "Obsolete software" (Delphi/MySQL) being the two highlights from the Deloits IT team.

The code is not brilliant, it is full of technical debt (as thats what happens when companies grow and change) but is still perfectly maintainable.

I have been watching the herculean effort of three different teams to replace this system, carving off the low hanging fruit to NetSuite and React/Java applications while repeatedly delaying the core system while they agree on standards to use.

I stick around as I am quite close to retirement now and the employees and the company are good to work with and don't deserve me to abandon them. At this point I genuinely want the projects to succeed so I can move on as there are many small companies still out there that I can make a difference in even with my age, single man risk and obsolete software.

[tictacttoe]

Having heard a variation of this comment many times, I keep waiting for an “aha” moment, where I see the light and abandon my obsession with minimalism and clean code.

But at least in science roles it hasn’t happened yet. Rather, I keep seeing instances of bogus scientific conclusions which waste money for years before they are corrected.

Being systematic, reproducible, and thorough is difficult, but it’s the only way to do science.

[axegon_]

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.

[typ]

The lack of these design elements in a solo project does not define crappy code. More often, it's due to a codebase being modified by multiple contributors, each wanting to get their work done quickly without paying attention to the overall context or considering others' work.

[jasfi]

Similarly, some entrepreneurs (non-tech)e who can produce a basic MVP that generates money from the start, sometimes to an insane MRR. They use something like Google Sheets, Bubble or pay a dev shop a fraction of a corporate project to get it done.

As a struggling solo tech founder, I'm in awe.

[dev-jayson]

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 2000 line class while writing a whole-ass unit test for it. It's been a full year and I still have to deal with this sort of crap on a weekly basis.

The most ironic part is that most of the devs that cooked the spaghetti are now either in upper management or in the same devOps team that's demanding us to clean the mess up.

[datavirtue]

You refactor and abstract later. A key principle absolutely no one observes. You have to let people turn out slop and then let them clean it up.

Instead it's combative code reviews where everything has to enter the code base perfect.

Makes me sick.

[skepticATX]

I’d argue that by definition, code producing value is good code. It may not be the best, but it has to be at least good.

Almost everything else about code is subjective, but value is objective.

[tcarnell]

100% agree.

JUST_DO_IT (add value, fast) <-----------------------------------> WHAT_THE_BOOK_SAYS (enterprise arch etc etc)

The BIG problem is the total misconception that:

> JUST_DO_IT = bad engineering

> WHAT_THE_BOOK_SAYS = good engineering

In reality, the quality of execution is independent of the development approach - you can make a complete mess of either approach, however, the WHAT_THE_BOOK_SAYS approach WILL cost you a LOT more time and money to discover your team has messed up it and WILL cost a lot more time and money to fix.

My experience is that, just as your product evolves & grows, your engineering strategy should evolve and grow. There's a good reason why fortune 500 companies will have enormous IT teams, using enterprise cloud technology... and there's a good reason why successful tech start-ups do the exact opposite.... but hopefully, the startup will become a fortune 500 company.

[deadbabe]

I wonder if you’ll still admire them when they leave and the burden of maintaining the mess they left behind falls on you.

[khazhoux]

The team that prides themselves on "we'll take a bit longer to get things right" usually winds up takes much, much longer... and still gets it wrong.

By that point, the fast team would be on their third iteration.

[mynameishere]

That's not bikeshedding, but the product of these types:

https://en.wikipedia.org/wiki/Architecture_astronaut

...bikeshedding is when you have that all-day, all-teams meeting where marketing and design and management argue about whether to put X content in the header or footer.

[bch]

So hard to resolve this in my head - unless it’s understood there’s a “detonate” button attached to the code, that it might escape, or worse, that it gets passed on or sold(!!) is a chilling thought.

[bloomingeek]

In 1993 I was interviewed for an operating job in a power plant for a major airline, assigned to their data center. At my current job, I was working in a high rise office building with sixty-six floors.

The operating system computer was a JC8520, which was running a version of MS-DOS. All commands had to be typed in correctly or nothing would happen. While operating the plant, several commands had to be entered every shift, since the owners didn't purchase a very automated package.

In the interview for the data center job, I was asked if I had any experience with Windows. I didn't understand the question because I wasn't aware they were talking about a computer operating system! So, I replied at the office building I worked in there were outside contractors who cleaned the windows.

After my reply all seven of the interviewers were all grinning and I was aware I said something they weren't looking for. One of the men politely told me Windows was a computer operating system. My reply was, "Oh, I see."

When I returned home I told my wife what happened and we shouldn't get our hopes up. To my utter shock, a week later I was offered the job, which I took and after some training, learned something I didn't know before.

[nicbou]

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 motorcycle super far, but wherever I went, there was a greater badass riding along. Some of these travellers were on much longer journeys, on much smaller budgets, on a much worse bikes, riding offroad all the way, camping every night. Some were on bicycles, going around the world under their own power. I was just a rich tourist with a great bike who slept in hotels.

In a way, meeting those people was liberating. I will never be a world champion at anything, so I might as well play for the love of the sport.

[DoreenMichele]

I was a full-time mom and military wife when my kids were little. We moved into a 2 bedroom, 50 year old duplex at a new duty station and there was a low-ceiling basement that was mostly consumed by a giant boiler but there was one low-ceiling room down there and we made it a playroom because our two kids were sharing a really tiny bedroom.

So we set up a TV down there and it's a rental so we don't want to drill holes anywhere and I'm talking to my 8 year old about going to the store, buying like 100 feet of cable and running it the long way around the outer wall of the room etc. when he says "What about the hole (in the wall, directly behind the TV and the other side is the stairs)?"

To be fair, he spent time in that room and the opening in the cement block wall or whatever was full of insulation, so it wasn't obvious, but man did I feel stupid for a minute.

And then very relieved because we already owned a long enough cable to set it up through the hole in the wall. The 100 foot cable would have been a bit of a financial burden and going to buy it and then run it the long way around would have eaten the rest of my day and this was resolved in minutes because I always encouraged my kids to ask questions and didn't treat them like that was "disrespecting my authority" or something.

[eru]

Well, at least you can feel proud of the kid!

[Dangeranger]

New eyes, new mind, freedom of ideas.

[rpgwaiter]

I went from hacky hobbyist programmer to working on core business logic for a startup that eventually the whole company would rely on. I was mostly a one-person team at the company, and I kept a lot of my bad unscalable tendencies from making small fun projects. No formal testing, very little documentation, hundreds of “TODOs”, breaking API changes without really telling anyone, no QA process, no monitoring/reporting, etc.

It all came to a head when my employer was demoing some software that used my API and none of what they were trying to show worked because of multiple unrelated bugs in my code, causing us to lose this very large client. I somehow kept my position, worked with other departments to formalize QA processes, and started regularly communicating with the API users.

Before I was just making software for nobody with 0 stakes, the reality of having actual people, entire revenue streams dependent on my code being reliable didn’t fully register. At my previous (and only other at the time) employer I was basically a paid seat filler. I spent a lot of work hours making personal projects, it felt like going to work and getting paid to make hobby code.

I’m glad I was able to learn from the experience and it didn’t put me out of work or anything

[mr-wendel]

Caught a senior sysadmin in a small company using a proxy on our infrastructure to hide misc web browsing from oversight. The logs were the give-away. It was typical misc IT/nerd news stuff... the kind of thing a different company culture (which did come later) would actually encourage.

I was sure the right thing to do was to report it to the CEO (there wasn't anyone else higher in the hierarchy to consider) for certain chastisement and correction. I was commended and the sysadmin got a browbeating.

I definitely did right by the policies in place. However, not too long after I realized there was certainly a better way to handle it and my behavior had more to do with scoring points than doing the right thing.

This was also someone who went out of their way to mentor younger employees and help kindle a passion for this line of work. I was a major beneficiary of this, so I look back upon that incident with nothing but regret.

[snipethunder]

I am from China and I always thought I am very good at math, because I can get good grades at national Olympiad level math competitions. After I came to America, I realized that I got good grades in China because I internalized the math concepts by doing large amounts of problem sets and it was actually a very slow learning process. In college mathematics courses, I realized that some of my American classmates can grasp new concepts and mental models ways faster than me, without doing much problem sets. We have just been learning math in very different ways.

[wnolens]

Interesting to hear your experience. I grew up in the Canadian system, and then in university my class was ~25%+ international students from China. They mopped the floor with us locals. It was my introduction to not being even a little good at something, relatively (which I was previously #1 at in highschool)

[zerr]

Kind of similar to the leetcode grinding.

[bhy]

This is an extremely interesting insight on math education! Thanks so much for sharing this!

[oblib]

I was in my early 20s talking with a friend who was at least twice my age. I was bitching about a guy who'd look at the work I was doing who really didn't know squat about it and start telling me how I should be doing it.

After listening to me for a bit he quietly said "Well, you can learn something from everyone if you focus on that."

I spent a couple days pondering that. At first I tried dismissing it because he wasn't there when the guy I was whining about was blabbering on and on, and he didn't know the guy, but it kept bugging me and after a few more days it occurred to me that if he was right I'd been missing out.

Just a few days later the guy I was whining about came by again and looked at the work I was doing told me he knew a guy who could do most of that for me and it wouldn't cost as much and I could get it done a lot faster. So I went and talked to the guy, and sure enough he could do it, and do it faster and better, and it cost me a lot less.

I ended up making a lot more money on that work, and the company I was doing it for was thrilled with the changes. And since then I've focused what I can learn from others, even those who tend to annoy me.

[wanderingmind]

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 to make a dent just because they had a late start, poor network, wrong time and place etc.

It made me realise that success is not because of what you are capable of. To, most extent its about how you fit into the system and work it to your favor.

So, while I'm still curious and interested to learn (why else to visit HN), I have stopped feeling bitter about my efforts not providing the returns. Its just the way world works.

[talkingtab]

Yes. I was with two friends in Quetico at a cabin. Temps of -20 below at night. Wood stove, no electricity no running water. We cross country skied over frozen lakes to the cabin. It was a log cabin and the logs were colder than ice cubes and stayed that way over the ten days we were there. In the center was a pot belly wood stove. A foot away from it, the temp was 50. Ten feet away it was 20. Cold.

There was a wood cooking stove and a second older wood cooking stove. We decide to start using the second wood cooking stove for more heat. There was one problem, the stove would smoke. My friend climbed on the roof and cleared the snow away, and we tried to seal leaks but it kept smoking.

One day I came back from drilling a hole in the ice to get water - through 24 inches of ice. I noticed something funny.

When I opened the door, the old wood cook stove stopped smoking. When I closed the door the stove started smoking. I stood there trying to understand. Opening and closing the door over and over. Open the door, no smoke. Close the door, smoke. I started to wonder why it would stop smoking and then it hit me.

The cabin was on fire. When the door was open it got enough air to burst into flame. No smoke. When the door was closed it smoked. I still remember standing there opening and closing the door. Over and over. What an idiot. But I learned something.

We looked underneath the cook stove. The reason there was a newer one wood stove became clear. The firebox on the old stove had rusted through. So coals from the wood were falling through the rusted out part onto the wood floor. We got a fire extinguisher and sprayed it. Then got piles of snow and packed it under there too.

That old adage "where there's smoke there's fire". Not quite accurate.

[AndrewKemendo]

From 2011-2012 was Senior intelligence officer for Anderson Air Force Base, Guam, which is one of the most strategic bases in the United States department of Defense.

As SIO you are statutorily responsible for the joint worldwide intelligence, communication system (JWICS), maintenance, security, growth, interruptibility, etc… in addition to managing all Perssec for SCI holders, and maintaining control, security and for CNWDI as well as ACCM.

I was fresh home after a deployment to Iraq and thrown right into dealing with the Yp-Do crisis in SK and the Japanese Tsunami and Fukushima fallout that we had to provide HA/DR support for.

I was 28 years old with a one year old at home.

As part of maintaining security, I would regularly get inspected as you would expect for any manner of things. There is a special security team that lives at the defense intelligence agency primarily but also they have them for NSA and other organizations, that would do white hat penetration tests on secure information facilities, like all the ones that I was responsible for (I had a half dozen physical locations to manage).

One of these tests was during a large scale exercise. Two civilians who had perfect credentials, were trying to access our primary headquarters SCIF. At the time I think I was managing a top-secret briefing preparation and so I delegated access control, and interrogation of these two people to another Lieutenant, as well as the actual special security officer who was an E6.

They had previously tried to penetrate all of the other places on base, but failed.

The process for getting access to a SCIF if you are not housed there is that that you send a visit request from your home security office to the visiting security office which will then transfer clearance details so that you can understand what access levels to give these people.

About a month before their visit, there was a new guidance released saying that all visit requests had to have a digital requst in 100% of cases whereas are previously you could just print out your details and bring them with you, The special security officer would then look them up in a system (I won’t name), and then it’s up to the security office whether they give you access or not.

My Special Security officer and my lieutenant came to me and said they have everything that they need per the requirements that we were operating under, and that they were comfortable giving them access to a terminal where they could do what they needed to do.

I said “that’s perfectly fine however LT I want you to sit behind them basically and make sure they don’t walk off or do anything more than I’m giving them access to.”

So for like 30 minutes, we had two people in our SCIF who logged onto JWICS, we’re being actively monitored and were able to send an email and then logged off and left.

The next week, my commander asked me to go to a meeting and the penetration team briefed to the whole base how they got into all these places including my SCIF and one other facility

The good thing was, we were basically written up with flying colors, and this was the hardest possible test that they were able to get through and so everybody was generally happy with us.

This was really just one of those things where it was a specific detail that we were not up-to-date with but didn’t have any major defense in depth risks.

[jv22222]

I was asked by a pro. documentary maker (who I met on the plane flying in to London) to get some B role for a G&R concert he was filming (with his spare video camera).

I was given the camera and sent in to the mosh pit to film from that perspective. After the show I gave the camera back to him. He said, "where's the footage?"

I had been "filming" looking through the view finder, but I had forgotten to press record.

Gutted.

[protocolture]

1. Seeing my boss just completely side step an issue, where his switch was sending vlan tags to his carrier causing the carrier to shut down the port, by purchasing a switch that didnt support vlan tagging. I died on the inside but lesson about end user troubleshooting learned.

2. Being able to break into a 24 hour data centre because the data centres building management just didnt give a shit. Turns out they had fired all their staff and were leaving the DC empty until they liquidated. We managed to get our kit and bail. But like physical security provided by a third party is ephemeral.

3. I used to lock my bike to my tool shelf. A thief came along and used my hacksaw from my toolshelf to break my bike lock and steal my bike. Thieves will use anything available, not just what I want them to use.

4. Had 2 console windows open. First to a Junos device on my desk. Second to a Junos core router. I reloaded one, and didnt realise I had reloaded the wrong one until we lost an entire state. Multitasking invites risk.

5. Customer had a huge failure. Kept insisting they would rebuild completely, but would routinely beg for just one more dodgy workaround just to keep them going. They never rebuilt. That network is perma fucked. Customer promises are worthless.

6. Much like 5. Customer got bought out by a larger firm. Began to raise new deployments by escalating to the after hours noc, pretending that new deployments were actually failed existing sites. We asked them to stop and they never did. If theres a large enough financial interest customers will just ignore contract and good practice to make the payday.

[meristohm]

Learning that the world doesn't revolve around me, and that other people (and other animals) have rich and complex inner lives worthy of curiosity, dignity, and love (I can't be sure, but it feels like a healthy perspective). I'm in my 40s and this lesson, started in youth, is still sinking in. Having a child, and the commensurate second childhood, is a major impetus.

[koeng]

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 fact that learning things has mostly been something I do way, way faster than my peers.

But I’ve never danced before, or done anything that required that particular skill set - then realizing I’m real bad at it. Seeing all my peers learn faster and be better, with the same amount of study and practice time, and really trying my hardest and just not being good at it. I’m really thankful for this experience! And I really enjoy dancing, and will definitely keep doing it!

[Stratoscope]

I posted a version of this story once before, but it bears repeating.

I was working at Tymshare, maintaining the assembler and linker for the PDP-10 or the Sigma 7 (I don't quite remember which).

The linker had a bad habit of leaving unused memory uninitialized. Every time you linked a program, the binary would be different. Functionally the same, but they wouldn't compare byte for byte. So my manager asked me to make sure the linker zeroed out all unused memory.

After linking a program, the linker printed a message something like this:

  8412 bytes used
   439 bytes free

The "bytes free" were that unused and uninitialized memory.

The linker was a mess of spaghetti assembly code, and it was a real pain to find and fix all of the places where it failed to clear memory.

My manager knew what a hassle this task was, and he was a chill dude. So just for fun I added a temporary message meant for his eyes only:

  8412 bytes used
   439 bytes free and it's pretty fucking clean

I figured he would get a laugh out of this and then I'd remove it.

Unfortunately my manager wasn't the first to see the message. His manager was giving a demo to a customer, and they were the first ones to see the message. Oops.

[kennu]

Back when cloud computing was mostly for early adopters, I used to work on many customer projects at the same time, or in quick succession, in an architect/developer role. It was great as long as the projects worked out as planned and I could deliver a working system in a few weeks or months and move on to the next project. It was easy to become a little overconfident until I faced unexpected difficulties in some projects and the tight schedules started to fall apart.

For instance, I learned that you should never trust what a customer says about reusing their existing code without actually looking at the code first. You can end up having to rewrite the code, and then have a dissatisfied customer, because the new code doesn't have the same problems as the old code and produces different results. It doesn't matter which one is correct, since the old code was already used for years and everything is based on it.

So the humbling experience has been not to become too optimistic and overconfident after some successful projects. You will become the bad guy if you over-promise and can't deliver, even if you feel someone else is actually to blame. Every time you start something new, you have to check for yourself what the requirements and conditions truly are before accepting a deadline. And you can never trust the documentation or description of an existing system without also looking at the actual system.

[jnsie]

Like many other people who should know better, I tried my hand at day-trading. I bought some course by someone who in hindsight I'm certain made more money off selling courses than they ever did off of day-trading. I got my account setup, had enough funds to allow me to trade short timeframes (I forget what this was called but there is a rule where you need X amount of money before you can do more than Y trades in Z timeframe) and was excited to trade short and long equities. I had some success and some failure with fees effectively eating my profits. I used to do my scans at night to know what I was planning to look at upon market open where there tends to be a lot of volatility and (I'm sure if you knew what you were doing; I didn't) opportunity. One morning I was certain that Boeing was going to plummet so I shorted a very small number of shares and was glued to the screen. I placed my market order, it hit, then Boeing immediately ripped upwards. Now, if you've traded you know that the difference between going long and going short is that going long you can lose everything you invested, going short you can lose everything you own. For about 3 seconds - my heart pounds when I think about this - I hemorrhaged money. I was down a couple thousand dollars before I could hit the key to cover the short at a huge loss (thinking back I know I had a stop loss but am not sure why it didn't trigger. Presumably it was a limit order and the price jumped the bid pre- and post- spike; I don't know). Right as I went to cover the stock dropped back down, as quickly as it shot up, and I ended up making maybe $500 on the trade. My last ever trade. I withdrew my funds and closed my brokerage account immediately thereafter.

There were so many learnings it's hard to know which is the most important, but I know that I am not cut out to day trade, I know that shorting is a fools game for (most?) non-institutional investors, I know that if it sounds too good to be true ("day trading will make you rich!") then it is and I know that even people of regular intelligence (I'd be average give or take) can do really stupid things. Never again. Never again!

[zamalek]

I contributed System.HashCode to .Net Core. I was overzealous with inlining hints to make it go fast. jkotas popped his head into the PR and noted the 2MB of machine code per generic type parameter. The bigger problem was that I knew better, and preached better at the time, but had my head too deep in the weeds. I'm better at occasionally popping my head out of the weeds nowadays to make sure I don't have tunnel vision in a daft direction.

[_boffin_]

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 became something that I just did.

I had been a personal trainer for awhile when I got a new client. An eighty something professor who taught Dante’s Inferno, Italian, collected degrees, and was actively pursuing some field in psychology (forget what one).

For about 6 months, we’d work out on Saturday mornings and he’d always ask of my adventures since we last saw each other. I’d regale him and that was that.

One morning after going though it all, he asked, “what else is there?” or something. Whatever it was, it stopped me in my tracks. I couldn’t answer. That question hit me harder than a freight train.

At that moment, I realized there was a massive issue with myself. I wanted a change, but a) didn’t know what to change, b) how to change, 3) how to feel about myself. We continued to work on him and his goals, which was to bench 135 safely. He got to his goal. ;). He also helped me to get to mine, which was to focus more on internal validation and be happy with self.

I was able to shift from heavily skewed external validation to external validation probably being now around 20%-30% and the rest being internal.

Because of him, I was able to embrace myself and lean into the information seeking snd knowledge gaining person I am today and get to a level that someone with my academic background should not be at.

A quote that I came up with many years ago that explains all of this and the transformation I had, “you’re not going to change until the pain of change is less than the pain of staying the same.”

One other one too. From him, the professor. I have severe adhd and can read the same sentence 50 time and not remember what I just read, if it’s not something I’m highly interested in. I came to him and told him that it’s so damn boring and it’s just a fight to sit there and attempt to read it.

He gave me a mind shift: instead of thinking how it’s important or exciting to you, try to imagine why the author of it thought it was so exciting, to where they spent their career learning about that subject. That allowed me to completely change how I read and that too has helped me more in the past years than I could imagine.